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 <ansk@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 <ansk@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
> <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.
>