Dear Sahil, -approx tail and -twotail are completely different things:
-approx tail switch on the tail approximation which speeds up the permutations. -twotail switch on two-sided hypothesis, without -twotail the hypothesis is only one-sided. It is reassuring that you see some clusters in _tstat_fwep.mgz now. I think that this starts to make sense: Since without -twotail there was no value in clustere_tstat_fwep.mgz, I think that your setup without -twotail was testing the opposite one-sided hypothesis. You have to decide which hypothesis you want to test. If you want to test one-sided hypothesis of negative correlation and use cluster forming threshold 0.05 (~ 1.3 in FreeSurfer -log10(p) convention), then I think you should invert sign of your contrast vector in Contrast.csv. With one-sided hypothesis you can modify your cluster-forming threshold to qnorm(1-10^-1.3)=1.643704 to be consistent with the mri_glmfit-sim behaviour. If you are testing two-sided hypothesis, your command line is I think almost OK, with following recommendations When not using -approx tail, I would increase number of permutations at least to 5000. Or add -approx tail and then you are running with tail approximation. Then you can retain -n 500 as Anderson recommended and your execution time would be much shorter. To report on cluster by use mri_surfcluster, you can use the code snippet I send in some of my earlier mails. You can also get cluster-wise p-value by loading the *clustere_tstat_fwep.mgz into freeview and clicking on the cluster. You can get cluster area by clicking on particular cluster in clustere_tstat.mgz. For visualization purposes Anderson mentioned that it is better to use -log10(p) (use the option -logp). Then you can interactively threshold your clusters according to the cluster-wise p-values (put 1.3 to min to hide clusters not significant at cluster-wise p=0.05). Do not forget to apply Bonferroni correction on your p-values when you analyze both hemispheres. To get *cope.mgz for the comparison, you should add -saveglm. As for comparison of F.mgh and dpv_tstat.mgh: F should be (approximately?) square of _tstat at the same vertex, if your contrast vector has one row. The correspondence should be (almost?) exact in orthogonal design (as I wrote previously, I got exact correspondence in my testing orthogonal design). I am not sure for non-orthogonal but I think that this should approximately also correspond, so -2 in dpv_tstat.mgh and 12 in F.mgh in the same vertex is maybe OK, but I am not sure. Antonin Hi Antonin, Just quick updates and few more points: (A) Earlier, I was using "-approx tail" in my PALM command and I was not getting any thing close to that big cluster but I noticed that you mentioned '-twotail' in your last email. So I replaced "-approx tail" with ''-twotail'' so the command I am running now is: palm -i *.10.mgh -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh -d Xg.csv -t Contrast.csv -m mask.mgh -o Left_Hemi_results -C 1.95 -twotail -n 500 -nouncorrected and I found that I can see a cluster when I view *_culstere_tstat_fwep or _dpv_tstat_fwep (both positive magnitude), which are very identical to sig.mgh (negative magnitude) from mri_glmfit and big cluster of very high negative PCC which I sent earlier. Here, I am sending you a screen of *_culstere_tstat_fwep, *_dpv_tstat_fwep and sig.mgh. Could you please confirm if thats correct? If so, I have few more questions: - When reporting about this cluster for publication, how can I find the size, annotation etc. of this cluster? - What 'min' and 'max' range of color bar would you recommend when reporting *_culstere_tstat_fwep results for the best view possible (at p < 0.05)? (B). Even though you said the matchings are valid for orthogonal design only, still I just check quickly and found that: 1. Here, I could not find any file with name: *cope.mgh 2. Here, clusters between F.mgh and *dpv_tstat.mgh are very similar but magnitude of dpv_tstat.mgh is very small and negative (~ -2) and of F.mgh is very high and positive (~ +12) 3. Here, magnitude of sig.mgh is roughly same as *dpv_tstat_uncp.mgh: both negative and similar big cluster (I am assuming that *dpv_tstat_uncp.mgh represents uncorrected p here and is same as *dpv_tstat.mgh, somehow I do not see *_uncp.mgh in my outputs). Thanks a lot for Antonin, Sahil On Fri, Mar 10, 2017 at 1:58 AM, Antonin Skoch <a...@ikem.cz> wrote: > Dear Sahil, > > thinking of that, the comparisons I suggested in previous mail are > probably valid only for the case of orthogonal design. And even with the > orthogonal design as Anderson said, the values can a bit differ: > > https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1604&L= > FSL&D=0&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=318728 > > As I did my own tests with orthogonal design, the values were equal to the > reasonable precision, apart from the case 3. > > So you could produce some testing orthogonal design and make similar tests > on that. > > Antonin > > > > Dear Sahil, > > I would suggest at first to make check of your GLM PALM setup by comparing > mri_glmfit and PALM output files (using the same design and contrast): > > 1. values of gamma.mgh should correspond to values of *cope.mgh > > 2. values of F.mgh should be (*dpv_tstat.mgh) ^2. > > 3. values of sig.mgh should be {roughly) values of > -log10(*dpv_tstat_uncp.mgh) - I am currently not sure why I do not get > exact correspondence here. > > 4. When you threshold the sig.mgh by some threshold in freeview (let it be > x) and use the same corresponding cluster-forming z-score threshold -C in > PALM computed as > > qnorm(1-10^-x/2) > > (and use two-sided hypothesis by specifying -twotail), your > *clustere_tstat.mgz should show the clusters with the same shape > (regardless of their values, the clusters will be defined by non-zero > value, other vertices would be zero) as the thresholded display of sig.mgh > (computed by -two sided hypothesis). > > If there is any inconsistence, then there is probably something wrong with > your PALM setup. > > Antonin > > > Dear Antonin, > > Could you please have a look at the attached screen shot. This map is with > full number of permutations, without -approx tail -n 500 -nouncorrected > > Here, I noticed that its only *_dpv_tstat.mgz which looks correct and > giving very high negative value, close to that big cluster, small positive > values at red clusters and the value changes when I change the position of > cursor. > > *_dpv_tstat_fwep shows value of 1 mostly but shows between 0.97 and 1 > close/at the red clusters and 1 elsewhere, even at the big blue negative > cluster. > > Third, *_clustere_tstat_fwep and *_clustere_tstat shows 1 and 0 > respectively everywhere, even at the big blue negative cluster. > > If there is something fishy with the analysis, would you mind looking at > the data and the detailed commands I am using to run the analysis? > > Thanks a lot, > Sahil > > On Wed, Mar 8, 2017 at 11:54 PM, Antonin Skoch <a...@ikem.cz> wrote: > > > Dear Sahil, > > > > to assure that there is no other issue with your setup, I would > recommend to obtain cluster-wise p-pvalue of that big cluster to see if it > is reasonable, i.e. if it is somewhat close to the significance. > > > > Therefore, I would load *_clustere_tstat_fwep and click to the area of > big cluster and see what the values of the vertices in that region are. > > > > Or, I would increase --thmax in mri_surfcluster to see the cluster-wise > p-value(s). If you use --thmax 0.9999 (or maybe 1), you should see > cluster-wise FWER corrected p-values of all clusters formed by used > cluster-forming threshold. > > > > I would also maybe try to switch-off tail approximation and run it in > full number of permutations (i.e. do not use -approx tail -n 500 > -nouncorrected). > > > > If there is no other issue, then yes, the conclusion would be, that for > the used cluster-extent inference and currently set cluster-forming > threshold, none of the clusters survived FWER correction at cluster-wise > p-value threshold of 0.05. > > > > Antonin > > > > > > > > Dear Antonin, > > > > Setting minimum to 1.3 for *_clustere_tstat_fwep doesn't show any > > significant cluster and similarly thresholded map *dpv_tstat.mgz also > > doesn't show anything at -log10(0.05) = 1.3. As you said, it seems like > > even though there is big cluster but after FWER correction, the > > significance goes away. Actually, even when I removed -logp, I still do > not > > see any significant cluster. > > > > Next, I tried to use mri_surfcluster using following three commands > > following instructions from the link you sent: > > > > mri_binarize --i Results_Left_clustere_tstat_fwep.mgz --min 1 --o > p_bin.mgz > > > > mris_calc --output pmap_filter.mgz Results_Left_clustere_tstat_fwep.mgz > sub > > p_bin.mgz > > > > mri_surfcluster --in pmap_filter.mgz --subject fsaverage --hemi lh > --surf > > white --annot aparc.a2009s --thmin 0.00000001 --thmax 0.05 --mask > > glmdir/mask.mgh --sum summary --nofixmni > > > > This gives me 'zero' cluster in the summary file. > > > > If the above steps are correct, would you conclude that the LGI results > are > > not significant and un-reportable for publication purpose and I should > give > > a try to thickness, volume and area maps? > > > > Thanks you so much Antonin for all your help. > > Sahil > > > > > > > > On Wed, Mar 8, 2017 at 3:05 PM, Antonin Skoch <a...@ikem.cz> wrote: > > > > > Dear Sahil, > > > > > > If you used -logp as Anderson suggested, you should set your min to > 1.3 to > > > threshold your *_clustere_tstat_fwep map and see the clusters. > > > > > > What is the value of *_clustere_tstat_fwep in the region of the big > > > cluster seen at thresholded map *dpv_tstat.mgz ? This should > correspond to > > > your -log10(p) of your cluster. > > > > > > I personally did not use -logp and use the mri_surfcluster for the > > > reporting of the clusters, as I wrote in previous mail here: > > > > > > freesurfer@nmr.mgh.harvard.edu > </msg52042.html"" > target="_blank">http://www.mail-archive.com/%3Ca%20href=>/msg52042.html"; > title=" > freesurfer@nmr.mgh.harvard.edu/msg52042.html"" > title="http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52042.html""; > > target="_blank">http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg52042.html";; > > target="_blank">freesurfer@nmr.mgh.harvard.edu" > title="http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu"; > target="_blank">http://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu > /msg52042.html > > > > > > > > But it is only matter of personal preference. > > > > > > And, beware, that the LGI is very smooth measure, therefore also > rather > > > big cluster can be insignificant after FWER correction. > > > > > > Antonin > > > > > > > > > > > > > > > Hi Antonin, > > > > > > Here, I am sending you more information: > > > > > > (1). I used following command: > > > palm -i lh.Behav_LGI.10.mgh -s fsaverage/surf/lh.white > > > fsaverage/surf/lh.white.avg. > > area.mgh -d Xg_Behav.csv -t > > > Contrast_Behav.csv > > > -m lh.Behav_LGI.glmdir/mask.mgh -o Results_Left -Cstat extent -C 1.95 > > > -approx tail -n 500 -nouncorrected -logp > > > > > > (2). Somehow, view of *_clustere_tstat_fwep is single colored, > thresholded > > > 0 (min) and 1(max), which seems suspicious. Please find it attached. > > > > > > (3). Data showed in screen shot 1 is just partial correlation > coefficient > > > (PCC, limiting between 0.30-0.35), obtained after running glm_fit > command > > > and saved in glm directory. > > > > > > (4). *_clustere_tstat_fwep is attached here in this email. > > > > > > (5). If I load *dpv_tstat.mgz and threshold it between 1.3 (p = 0.05) > and > > > 2 > > > (max), I get the map attached 2nd in attached figure. I am not sure > > > how to "threshold > > > it by your cluster-forming threshold (I suppose that you should > correctly > > > convert z value to t-value), to see your initial clusters after > > > thresholding". > > > > > > Thanks a lot Antonin. > > > Sahil > > > > > > > > > > > > On Wed, Mar 8, 2017 at 2:06 PM, Antonin Skoch <a...@ikem.cz> wrote: > > > > > > > Dear Sahil, > > > > > > > > could you send the full command-line and unthresholded view of > > > > *_clustere_tstat_fwep ? > > > > > > > > How the data showed in screenshot 1 were produced? > > > > > > > > How are the actual p-values of your clusters in > *_clustere_tstat_fwep? > > > > > > > > You can also use -saveglm and inspect the files containing values of > GLM > > > > fit. > > > > You can load the *dpv_tstat.mgz file and threshold it by your > > > > cluster-forming threshold (I suppose that you should correctly > convert z > > > > value to t-value), to see your initial clusters after thresholding. > > > > > > > > Regards, > > > > > > > > Antonin > > > > > > > > > > > > > > > > Thanks a lot Anderson and Antonin, that's really useful. > > > > > > > > Actually, I am having trouble in interpreting the results. Could you > > > > please > > > > share any document explaining all these tests/outputs and their > > > > interpretation in simple terms? > > > > > > > > Here I am attaching a screen shot: (1) Simple partial correlations > (I > > > > adjusted the color bar between 0.30 and 0.35 to visualize the high > > > > correlation coefficients, which is ~0.35) and (2) Results I get when > I > > > > used cluster > > > > extent stats: *dpv_tstat > > > > But I do not see any significant clusters when I view > > > > *_clustere_tstat_fwep, *_dpv_tstat_fwep, which is very unexpected in > my > > > > data set. > > > > > > > > So basically I really doubt if I am running the stats correctly > because > > > > PCC > > > > looks high at that big cluster (shown in PCC in attached screen > shot). > > > > > > > > Could you please suggest if there is any alternative (less stronger) > > > stat > > > > flag I can use here while running PALM command? > > > > > > > > I would be more than happy sharing any required files to interpret > the > > > > results. > > > > > > > > Thanks. > > > > > > > > On Wed, Mar 8, 2017 at 10:20 AM, Sahil Bajaj <sahil.br...@gmail.com> > > > > > wrote: > > > > > > > > > Thanks a lot Anderson and Antonin, that's really useful. > > > > > > > > > > Actually, I am having trouble in interpreting the results. Could > you > > > > > please share any document explaining all these tests/outputs and > their > > > > > interpretation in simple terms? > > > > > > > > > > Here I am attaching two screen shots: (1) Results I get when I > used > > > > cluster > > > > > extent stats: *dpv_tstat and (2). Simple partial correlations (I > > > > adjusted > > > > > the color bar between 0.30 and 0.35 to visualize the high > correlation > > > > > coefficients, which is ~0.35). > > > > > I do not see any significant clusters when I view > > > *_clustere_tstat_fwep, > > > > > *_dpv_tstat_fwep, which is very unexpected in my data set. > > > > > > > > > > So basically I really doubt if I am running the stats correctly > > > because > > > > > PCC looks high at that big cluster (shown in PCC in attached > screen > > > > shot). > > > > > > > > > > Could you please suggest if there is any alternative (less > stronger) > > > > stat > > > > > flag I can use here while running PALM command? > > > > > > > > > > I would be more than happy sharing any required files to interpret > the > > > > > results. > > > > > > > > > > Thanks. > > > > > > > > > > On Wed, Mar 8, 2017 at 9:27 AM, Martin Juneja <mj70...@gmail.com> > > > > wrote: > > > > > > > > > >> Hi Antonin and Anderson, > > > > >> > > > > >> That's wonderful ! I am able to run PALM now, without any > problem. > > > > >> > > > > >> Thank you so much for your help and time, I really appreciate > that. > > > > >> > > > > >> Best, > > > > >> MJ > > > > >> > > > > >> > > > > >> > > > > >> On Wed, Mar 8, 2017 at 6:30 AM, Anderson M. Winkler < > > > > >> wink...@fmrib.ox.ac.uk> wrote: > > > > >> > > > > >>> Hi all, > > > > >>> > > > > >>> That's exactly as Antonin says -- I have very little to add :-) > > > > >>> > > > > >>> Only a few suggestions: > > > > >>> > > > > >>> - With surfaces, both cluster and TFCE statistics tend to be > slow. > > > > >>> Consider using the tail approximation ("-approx tail -n 500 > > > > -nouncorrected") > > > > >>> > > > > >>> - Include -logp, so that the p-values are in log-10 scale. > > > Significant > > > > >>> p-values are then those above 1.3 (i.e., -log10(0.05). This will > > > help > > > > to > > > > >>> make the figures nicer later. > > > > >>> > > > > >>> All the best, > > > > >>> > > > > >>> Anderson > > > > >>> > > > > >>> > > > > >>> > > > > >>> On 8 March 2017 at 00:19, Antonin Skoch <a...@ikem.cz> wrote: > > > > >>> > > > > >>>> Dear Sahil, > > > > >>>> > > > > >>>> I suppose, for qcache 1.3 the equivalent cluster-forming > threshold > > > > >>>> z-value is > > > > >>>> > > > > >>>> two-tailed test: > > > > >>>> qnorm(1-10^-1.3/2)=1.958949 > > > > >>>> > > > > >>>> for one-tailed test: > > > > >>>> qnorm(1-10^-1.3)=1.643704 > > > > >>>> > > > > >>>> (qnorm is R function call for quantile function of normal > > > > distribution, > > > > >>>> you can compute this by using other methods or use statistical > > > > z-tables) > > > > >>>> > > > > >>>> And, the directionality of the hypothesis is I suppose > specified by > > > > the > > > > >>>> sign of your contrast vector, as I wrote in my previous mail. > > > > >>>> > > > > >>>> As for the output files, you can look at the documentation: > > > > >>>> > > > > >>>> https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/PALM/UserGuide# > Output_files > > > > > > >>>> > > > > >>>> For example, if you are looking for the p-values, used cluster > > > extent > > > > >>>> inference and used t-contrast, the file with FWER-corrected > > > p-values > > > > would > > > > >>>> be something like > > > > >>>> > > > > >>>> output_basename_clustere_tstat_fwep.mgz > > > > >>>> > > > > >>>> Antonin > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> Hello Martin and Antonin, > > > > >>>> > > > > >>>> I was following this conversation very closely to understand > how to > > > > use > > > > >>>> PALM in FreeSurfer. > > > > >>>> > > > > >>>> Can any of you please confirm in case I am interested in > checking > > > > >>>> correlation between gyrification index (LGI) and behavioral > measure > > > > using > > > > >>>> two tailed, p < 0.05: > > > > >>>> Step 1: I used --cache 1.3 > > > > >>>> Step 2: Because (1-10^-1.3)= 0.95, so I will have to use -C > 0.95 in > > > > palm > > > > >>>> command > > > > >>>> > > > > >>>> Could you please confirm if thats correct and the output > > > *_tstat.mgz > > > > is the > > > > >>>> final two-tailed corrected significant correlation map between > LGI > > > > and > > > > >>>> behavioral data? > > > > >>>> > > > > >>>> Thanks a lot for this wonderful discussion. > > > > >>>> Sahil > > > > >>>> > > > > >>>> PS: For one-tailed: it will be -C -0.95 in palm command, > correct? > > > > >>>> > > > > >>>> > > > > >>>> > > > > >>>> On Tue, Mar 7, 2017 at 3:48 PM, Antonin Skoch <a...@ikem.cz> > > > wrote: > > > > >>>> > > > > >>>> > Dear Martin, > > > > >>>> > > > > > >>>> > after -s option, there have to be 2 arguments, as I specified > in > > > my > > > > previous > > > > >>>> > mail: > > > > >>>> > > > > > >>>> > -s fsaverage/surf/lh.white fsaverage/surf/lh.white.avg.area.mgh > > > > > >>>> > > > > > >>>> > And beware that -C has to have negative sign, if your > hypothesis > > > is > > > > >>>> > one-tailed negative. > > > > >>>> > > > > > >>>> > Antonin > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > Hi Antonin, > > > > >>>> > > > > > >>>> > Thank you so much for this detailed explanation, that's > really > > > > useful. > > > > >>>> > > > > > >>>> > Following your instructions, I ran: > > > > >>>> > > > > > >>>> > palm -i lh.MEQ_LGI.10.mgh -s > > > > >>>> > fsaverage/surf/lh.white.avg.area.mgh > > > > > > > > -d > > > > >>>> > check.csv -t Contrast_MEQ.csv -n 5000 -m > > > lh.MEQ_LGI.glmdir/mask.mgh > > > > -o > > > > >>>> > myresults -Cstat extent -C 3.719016 > > > > >>>> > > > > > >>>> > but I am getting following error: > > > > >>>> > > > > > >>>> > Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) with > the > > > > following > > > > >>>> > options: > > > > >>>> > -i lh.MEQ_LGI.10.mgh > > > > >>>> > -s fsaverage/surf/lh.white.avg.area.mgh > > > > >>>> > -d check.csv > > > > >>>> > -t Contrast_MEQ.csv > > > > >>>> > -n 5000 > > > > >>>> > -m lh.MEQ_LGI.glmdir/mask.mgh > > > > >>>> > -o myresults > > > > >>>> > -Cstat extent > > > > >>>> > -C 3.719016 > > > > >>>> > Loading surface 1/1: fsaverage/surf/lh.white.avg.area.mgh > > > > >>>> > Reading input 1/1: lh.MEQ_LGI.10.mgh > > > > >>>> > > > > > >>>> > Struct contents reference from a non-struct array object. > > > > >>>> > > > > > >>>> > Error in palm_takeargs (line 1632) > > > > >>>> > if any(size(plm.srf{s}.data.vtx, > > > > >>>> > 1) == ... > > > > >>>> > > > > > >>>> > Error in palm_core (line 33) > > > > >>>> > [opts,plm] = palm_takeargs(varargin{:}); > > > > >>>> > > > > > >>>> > Error in palm (line 81) > > > > >>>> > palm_core(varargin{:}); > > > > >>>> > > > > > >>>> > Could you please help me in resolving this error? > > > > >>>> > > > > > >>>> > Thanks much. > > > > >>>> > > > > > >>>> > On Tue, Mar 7, 2017 at 2:55 PM, Antonin Skoch <a...@ikem.cz> > > > > wrote: > > > > >>>> > > > > > >>>> > > Dear Martin, > > > > >>>> > > > > > > >>>> > > input -i input file is > > > > >>>> > > > > > > >>>> > > lh.MEQ_LGI.10.mgh file in your glmdir directory (for left > > > > hemisphere). > > > > >>>> > > > > > > >>>> > > As you could read in following messages in the referenced > > > thread > > > > in FSL > > > > >>>> > > discussion forum, cluster-forming threshold need to be > > > specified > > > > in z, not > > > > >>>> > > in t. > > > > >>>> > > > > > > >>>> > > Therefore, you would have to select cluster forming > threshold > > > and > > > > specify > > > > >>>> > > it as a z score. > > > > >>>> > > > > > > >>>> > > I think that your z-score for your original mri_glmfit-sim > > > > commandline > > > > >>>> > > argument > > > > >>>> > > > > > > >>>> > > --cache 4 neg > > > > >>>> > > > > > > >>>> > > will be -qnorm(1-10^-4)=-3.719016. (I am not perfectly > sure > > > > since I never > > > > >>>> > > tried negative one-side hypothesis testing in PALM). > > > > >>>> > > > > > > >>>> > > You could also use other statistics, such as cluster mass, > or > > > > TFCE. See > > > > >>>> > > PALM user guide. > > > > >>>> > > > > > > >>>> > > Do not include -pmethodp none and -pmethodr none, since you > > > would > > > > need the > > > > >>>> > > partitioning due your non-orthogonal design matrix. > > > > >>>> > > > > > > >>>> > > ?h.white.avg.area.mgh file (which you will find under > fsaverage > > > > directory) > > > > >>>> > > goes as second argument after -s option. > > > > >>>> > > > > > > >>>> > > Therefore I suppose the commandline for cluster extent > > > inference > > > > with > > > > >>>> > > cluster forming threshold p=0.0001, negative one-sided > > > > hypothesis, left > > > > >>>> > > hemisphere, will be hopefully something like > > > > >>>> > > > > > > >>>> > > palm > > > > >>>> > > -i y.mgh > > > > >>>> > > -s fsaverage/surf/lh.white > > > > >>>> > > fsaverage/surf/lh.white.avg.area.mgh > > > > > > > > >>>> > > -d Xg.csv > > > > >>>> > > -t your_contrasts.csv > > > > >>>> > > -n number_of_permutations > > > > >>>> > > -m mask.mgh > > > > >>>> > > -o output_basename > > > > >>>> > > -Cstat extent > > > > >>>> > > -C -3.719016 > > > > >>>> > > -saveglm > > > > >>>> > > -savedof > > > > >>>> > > -savemetrics > > > > >>>> > > > > > > >>>> > > The last 3 commandline options are only for diagnostical > > > > purposes. > > > > >>>> > > > > > > >>>> > > The output is surface overlay you can visualize in > freeview. > > > > >>>> > > > > > > >>>> > > I use following code snippet for the reporting significant > > > > clusters in MNI > > > > >>>> > > coordinates: > > > > >>>> > > > > > > >>>> > > # PALM output cluster extent p maps have 1 outside cluster > - > > > > problem with > > > > >>>> > > mri_surfcluster and also for display in freeView > > > > >>>> > > #here we set values 1 to 0 in pmaps. > > > > >>>> > > #done by binarizing and subtracting > > > > >>>> > > if [[ $# -ne 2 ]]; then > > > > >>>> > > echo "get cluster summary of PALM statistics. Expecting 2 > > > > arguments: 1- > > > > >>>> > > input p-map, 2- hemisphere (lh/rh)" > > > > >>>> > > exit > > > > >>>> > > fi > > > > >>>> > > mri_binarize --i $1 --min 1 --o p_bin.mgz > > > > >>>> > > mris_calc --output ${1%%.mgz}_filtered.mgz $1 sub p_bin.mgz > > > > >>>> > > mri_surfcluster --in ${1%%.mgz}_filtered.mgz --subject > > > fsaverage > > > > --hemi $2 > > > > >>>> > > --surf white --annot aparc --thmin 0.000000001 --thmax 0.05 > > > > --mask mask.mgh > > > > >>>> > > --sum ${1%%.mgz}_cluster.summary --nofixmni > > > > >>>> > > rm p_bin.mgz > > > > >>>> > > > > > > >>>> > > They are not Bonferroni-corrected for 2 hemispheres > > > (--2spaces). > > > > >>>> > > > > > > >>>> > > Regarding your design and contrast: > > > > >>>> > > > > > > >>>> > > Design has to be matrix of values. You can use qdec to > produce > > > > Xg.dat file > > > > >>>> > > with design matrix, then rename it to Xg.csv to be > correctly > > > > readable by > > > > >>>> > > PALM. > > > > >>>> > > > > > > >>>> > > Regards, > > > > >>>> > > > > > > >>>> > > Antonin > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > > > > > >>>> > > Hi Antonin, > > > > >>>> > > > > > > >>>> > > As you suggested in discussion forum, I tried to run > following > > > > command > > > > >>>> > > after mri_glmfit: > > > > >>>> > > > > > > >>>> > > palm -s fsaverage/surf/lh.white -n 10000 -m mask.mgh -Cstat > > > > extent -C > > > > >>>> > > 1.974975 -pmethodp none -pmethodr none -twotail -d > > > Design_MEQ.txt > > > > -t > > > > >>>> > > Contrast_MEQ.txt > > > > >>>> > > > > > > >>>> > > Running PALM alpha104 using MATLAB 9.0.0.341360 (R2016a) > with > > > the > > > > following > > > > >>>> > > options: > > > > >>>> > > > > > > >>>> > > -s fsaverage/surf/lh.white > > > > >>>> > > > > > > >>>> > > -n 10000 > > > > >>>> > > > > > > >>>> > > -m mask.mgh > > > > >>>> > > > > > > >>>> > > -Cstat extent > > > > >>>> > > > > > > >>>> > > -C 1.974975 > > > > >>>> > > > > > > >>>> > > -pmethodp none > > > > >>>> > > > > > > >>>> > > -pmethodr none > > > > >>>> > > > > > > >>>> > > -twotail > > > > >>>> > > > > > > >>>> > > -d Design.txt > > > > >>>> > > > > > > >>>> > > -t Contrast.txt > > > > >>>> > > > > > > >>>> > > Found FSL in /usr/share/fsl/5.0 > > > > >>>> > > > > > > >>>> > > Found FreeSurfer in /usr/local/freesurfer > > > > >>>> > > > > > > >>>> > > Found SPM in /usr/local/spm12 > > > > >>>> > > > > > > >>>> > > Error using palm_takeargs (line 1141) > > > > >>>> > > > > > > >>>> > > Missing input data (missing "-i"). > > > > >>>> > > > > > > >>>> > > Error in palm_core (line 33) > > > > >>>> > > > > > > >>>> > > [opts,plm] = palm_takeargs(varargin{:}); > > > > >>>> > > > > > > >>>> > > Error in palm (line 81) > > > > >>>> > > > > > > >>>> > > palm_core(varargin{:}); > > > > >>>> > > > > > > >>>> > > Looks like error is because its missing -i input here, I am > not > > > > sure what's > > > > >>>> > > input file here? > > > > >>>> > > > > > > >>>> > > Also, I am trying to correlate LGI versus behavioral score, > > > > regressing out > > > > >>>> > > the effect of sex and age. So I just wanted to confirm if > my > > > > design.txt and > > > > >>>> > > contrast.txt files are correct here. Please find both > > > following: > > > > >>>> > > > > > > >>>> > > Design file (Variables Behav, Age) as following: > > > > >>>> > > > > > > >>>> > > S001 Male 60 36 > > > > >>>> > > > > > > >>>> > > S003 Female 73 29 > > > > >>>> > > > > > > >>>> > > S004 Male 48 39 > > > > >>>> > > > > > > >>>> > > .......so on...... > > > > >>>> > > > > > > >>>> > > Contrast file as following: > > > > >>>> > > 0 0 0.5 0.5 0 0 (same as *.mtx file used for glm_fit) > > > > >>>> > > > > > > >>>> > > Thank you so much for your help and time. > > > > >>>> > > > > > > >>>> > > On Tue, Mar 7, 2017 at 10:49 AM, Martin Juneja < > > > mj70...@gmail.com> > > > > wrote: > > > > >>>> > > > > > > >>>> > > > Hi Antonin, > > > > >>>> > > > > > > > >>>> > > > Thanks a lot for your reply. > > > > >>>> > > > > > > > >>>> > > > Somehow, in the link you sent, I could not find any > response > > > to > > > > your > > > > >>>> > > > email. But I can see your email to Anderson and command > line > > > > parameters. > > > > >>>> > > > > > > > >>>> > > > As I am not an expert in using FreeSurfer, so would it be > > > > possible for you > > > > >>>> > > > to share detailed step-by-step guide and PALM command > after I > > > > run > > > > >>>> > > > mri_glmfit > > > > >>>> > > > command and how and where to include > '?h.white.avg.area.mgh' > > > > file? > > > > >>>> > > > > > > > >>>> > > > I would really appreciate any help. > > > > >>>> > > > > > > > >>>> > > > On Mon, Mar 6, 2017 at 4:28 PM, Antonin Skoch < > a...@ikem.cz> > > > > wrote: > > > > >>>> > > > > > > > >>>> > > >> Dear Martin, > > > > >>>> > > >> > > > > >>>> > > >> I think yes, you can use PALM with FreeSurfer surfaces, > see > > > my > > > > >>>> > > >> conversation with Anderson on FSL list: > > > > >>>> > > >> > > > > >>>> > > >> https://www.jiscmail.ac.uk/ > cgi-bin/webadmin?A2=ind1604&L=FSL > > > > >>>> > > > > >>>> > > > > > >>>> > > > > > > >>>> > > >> > > > > >>>> > > >> &D=0&1=FSL&9=A&J=on&d=No+Match%3BMatch%3BMatches&z=4&P=239088 > > > > >>>> > > >> > > > > > > > > >>>> > > >> > > > > >>>> > > >> but beware not to forget to include average the vertex > area > > > > >>>> > > >> (?h.white.avg.area.mgh) file. > > > > >>>> > > >> > > > > >>>> > > >> Antonin > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> If you don't have an orthogonal design, then you can't > use > > > > >>>> > > >> mri_glmfit-sim. I think you can use PALM: > > > > >>>> > > >> > > > > >>>> > > >> https://fsl.fmrib.ox.ac.uk/fsl/fslwiki/PALM > > > > >>>> > > >> > > > > >>>> > > >> I have not tried it yet. > > > > >>>> > > >> > > > > >>>> > > >> Anderson, can you use PALM with surfaces? > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> > > > > >>>> > > >> On 03/06/2017 05:23 PM, Martin Juneja wrote: > > > > >>>> > > >> > Hi Dr. Greve, > > > > >>>> > > >> > > > > > >>>> > > >> > I tried to run: mri_glmfit-sim --glmdir > lh.MEQ_LGI.glmdir > > > > --sim perm > > > > >>>> > > >> > 1000 3 permcsd --sim-sign abs --cwpvalthresh .05 > > > > >>>> > > >> > It gives error that ERROR: design matrix is not > > > orthogonal, > > > > cannot be > > > > >>>> > > >> > used with permutation. > > > > >>>> > > >> > > > > > >>>> > > >> > But when I run: mri_glmfit-sim --glmdir > lh.MEQ_LGI.glmdir > > > > --sim perm > > > > >>>> > > >> > 1000 3 permcsd --sim-sign abs --cwpvalthresh .05 > > > > --perm-force, it > > > > >>>> > > >> > works. > > > > >>>> > > >> > > > > > >>>> > > >> > I am not sure whether I will have to make the design > > > matrix > > > > >>>> > > >> > orthogonal. If so, could you please tell me how that > can > > > be > > > > done? > > > > >>>> > > >> > > > > > >>>> > > >> > Or using --perm-force should be fine? > > > > >>>> > > >> > > > > > >>>> > > >> > Thanks. > > > > >>>> > > >> > > > > > >>>> > > >> > On Mon, Mar 6, 2017 at 1:58 PM, Douglas N Greve > > > > >>>> > > >> > <gr...@nmr.mgh.harvard.edu <mailto: > gr...@nmr.mgh.harvard <gr...@nmr.mgh.harvard>. > > > edu > > > > <gr...@nmr.mgh.harvard.edu> > > > > >>>> > > >> > <gr...@nmr.mgh.harvard.edu> > > > > >>>> > > >> > <gr...@nmr.mgh.harvard.edu> > > > > >>>> > > >> > <gr...@nmr.mgh.harvard.edu>>> wrote: > > > > >>>> > > >> > > > > > >>>> > > >> > This is a problem with using LGI in that it is > already > > > > extremely > > > > >>>> > > >> > smooth > > > > >>>> > > >> > that the smoothness exceeds the limit of the look > up > > > > table that we > > > > >>>> > > >> > supply. I recommend that you not use a > gaussian-based > > > > correction > > > > >>>> > > >> > for > > > > >>>> > > >> > LGI. Instead, use permutation (see mri_glmfit-sim > > > > --help). > > > > >>>> > > >> > > > > > >>>> > > >> > > > > > >>>> > > >> > > > > > >>>> > > >> > On 03/06/2017 01:36 PM, Martin Juneja wrote: > > > > >>>> > > >> > > Hello everyone, > > > > >>>> > > >> > > > > > > >>>> > > >> > > I am trying to extract clusters showing > significant > > > > correlation > > > > >>>> > > >> > > between LGI and a behavioral measure. I am able > to > > > > extract PCC > > > > >>>> > > >> > and > > > > >>>> > > >> > > sig.mgh but at the last step when I try to run > > > > simulation command > > > > >>>> > > >> > to > > > > >>>> > > >> > > view corrected results and I run: > > > > >>>> > > >> > > > > > > >>>> > > >> > > mri_glmfit-sim --glmdir lh.MEQ_LGI.glmdir > --cache 4 > > > > neg --cwp > > > > >>>> > > >> > 0.05 > > > > >>>> > > >> > > --2spaces > > > > >>>> > > >> > > > > > > >>>> > > >> > > I get following error: > > > > >>>> > > >> > > > > > > >>>> > > >> > > ERROR: cannot find > > > > >>>> > > >> > > > > > > >>>> > > >> > > > > > >>>> > > >> > /usr/local/freesurfer/average/mult-comp-cor/fsaverage/lh/ > > > > > cortex/fwhm35/neg/th40/mc-z.csd > > > > >>>> > > >> > > > > > > >>>> > > >> > > But I can see mc-z.csd file in fwhm30 etc. > > > > >>>> > > >> > > > > > > >>>> > > >> > > Full message on terminal window is attached > > > following. > > > > >>>> > > >> > > > > > > >>>> > > >> > > Any help would be really appreciated. > > > > >>>> > > >> > > > > > > >>>> > > >> > > ----- Full message ---- > > > > >>>> > > >> > > > > > > >>>> > > >> > > cmdline mri_glmfit.bin --y lh.MEQ_LGI.10.mgh > --fsgd > > > > MEQ.fsgd > > > > >>>> > > >> > dods --C > > > > >>>> > > >> > > Corr-MEQ-cor.mtx --surf fsaverage lh --cortex > > > --glmdir > > > > >>>> > > >> > lh.MEQ_LGI.glmdir > > > > >>>> > > >> > > > > > > >>>> > > >> > > WARNING: unrecognized mri_glmfit cmd option > > > > mri_glmfit.bin > > > > >>>> > > >> > > > > > > >>>> > > >> > > SURFACE: fsaverage lh > > > > >>>> > > >> > > > > > > >>>> > > >> > > log file is > > > > >>>> > > >> > lh.MEQ_LGI.glmdir/cache.mri_glmfit-sim.log > > > > > > > > > > > > >>>> > > >> > > > > > > >>>> > > >> > > /usr/local/freesurfer/bin/mri_glmfit-sim > > > > >>>> > > >> > > > > > > >>>> > > >> > > --glmdir lh.MEQ_LGI.glmdir --cache 4 neg --cwp > 0.05 > > > > --2spaces > > > > >>>> > > >> > > > > > > >>>> > > >> > > $Id: mri_glmfit-sim,v 1.60 2016/04/30 15:13:36 > greve > > > > Exp $ > > > > >>>> > > >> > > > > > > >>>> > > >> > > Mon Mar 6 11:11:13 MST 2017 > > > > >>>> > > >> > > > > > > >>>> > > >> > > setenv SUBJECTS_DIR > > > > >>>> > > >> > > > > > > >>>> > > >> > /data/emot/Freesurfer/FreeSurferSegmentation/SB_AgingAll > > > > > > > > > > > > >>>> > > >> > > > > > > >>>> > > >> > > FREESURFER_HOME /usr/local/freesurfer > > > > >>>> > > >> > > > > > > >>>> > > >> > > Original mri_glmfit command line: > > > > >>>> > > >> > > > > > > >>>> > > >> > > cmdline mri_glmfit.bin --y lh.MEQ_LGI.10.mgh > --fsgd > > > > MEQ.fsgd > > > > >>>> > > >> > dods --C > > > > >>>> > > >> > > Corr-MEQ-cor.mtx --surf fsaverage lh --cortex > > > --glmdir > > > > >>>> > > >> > lh.MEQ_LGI.glmdir > > > > >>>> > > >> > > > > > > >>>> > > >> > > DoSim = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > UseCache = 1 > > > > >>>> > > >> > > > > > > >>>> > > >> > > DoPoll = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > DoPBSubmit = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > DoBackground = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > DiagCluster = 0 > > > > >>>> > > >> > > > > > > >>>> > > >> > > gd2mtx = dods > > > > >>>> > > >> > > > > > > >>>> > > >> > > fwhm = 35.073391 > > > > >>>> > > >> > > > > > > >>>> > > >> > > ERROR: cannot find > > > > >>>> > > >> > > > > > > >>>> > > >> > > > > > >>>> > > >> > /usr/local/freesurfer/average/mult-comp-cor/fsaverage/lh/ > > > > > cortex/fwhm35/neg/th40/mc-z.csd > > > > >>>> > > >> > > > > > > >>>> > > >> > > > > _______________________________________________ > Freesurfer mailing list > Freesurfer@nmr.mgh.harvard.edu > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer > > > The information in this e-mail is intended only for the person to whom it > is > addressed. If you believe this e-mail was sent to you in error and the > e-mail > contains patient information, please contact the Partners Compliance > HelpLine at > http://www.partners.org/complianceline . If the e-mail was sent to you in > error > but does not contain patient information, please contact the sender and > properly > dispose of the e-mail. >
_______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
