Re: [Freesurfer] questions about split region from the 7 and 17 networks, from huasheng liu

[Thomas Yeo]

Hi Huasheng,

Here you go: 
https://dl.dropboxusercontent.com/u/5734119/Outgoing/Yeo_JNeurophysiol11_SplitLabels.zip

I am also cc-ing the freesurfer list.

--Thomas

On Tue, Aug 30, 2016 at 11:05 AM, liuhas_20040125
 wrote:
> Dear professor Yeo :
>
>
>
>   My name is Huasheng Liu, I'm from central south university, china.
>
>   I read the emails you wrote to Yu-chieh Chen in freesurfer's mail-archive,
>
> (from:
> https://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg41288.html)
>
> and you provided a link to files you extracted individual regions from the 7
> and 17 networks:
>
>
>
> " I have previously extracted individual regions from the 7 and 17
> networks. You can download them here
> (https://www.dropbox.com/s/u23nn3ov18tlhfs/Yeo_JNeurophysiol11_SplitLabels.zip?dl=0)."
>
>
>
>
>
>   It seems the link has broken, and i can't get zip file, can you kindly
> give me a copy?
>
>
>
>
>
>   Thank you very much for read this email and sorry for occupied your time.
>
>
>
>  Best wishes!
>  Huasheng Liu
>
>
>
> 2016-08-30
> 
> liuhas_20040125
___
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.

Re: [Freesurfer] mri_glmfit-sim permutation testing running after 3 days!

[Harms, Michael]

Hi,
I wouldn’t say that non-orthogonal designs are “wrong” to use with
permutation.  Rather, there are different approaches to handling that
situation and produce approximate p-values.  See Table 2 in Winkler’s 2014
paper, and the results therein comparing the various approaches:

http://www.ncbi.nlm.nih.gov/pubmed/24530839


PALM actually gives you control over the method used, with the default
(and recommended) approach being that of “Freedman-Lane", which is the
same approach used by FSL’s ‘randomise’ tool to handle correlated
covariates.

cheers,
-MH

--
Michael Harms, Ph.D.

---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave.Tel: 314-747-6173
St. Louis, MO  63110Email: mha...@wustl.edu




On 8/29/16, 7:49 PM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of
Matt Glasser"  wrote:

PALM handles GIFTI and CIFTI data.

Peace,

Matt.

On 8/29/16, 6:21 PM, "Douglas N Greve"
 wrote:

>Does PALM do surface-based? Also, there is no way to appropriately
>handle this. For permutation, non-orthogonal designs are wrong. There
>are ways to try to compensate for it, which is what PALM is doing. Sorry
>to be nit-picky!
>
>
>On 08/29/2016 06:12 PM, Harms, Michael wrote:
>> Hi Maaike,
>> Why not just use PALM?  Then you don¹t have to worry about this (since
>> PALM appropriately handles the situation of correlated covariates).
>>
>> cheers,
>> -MH
>>
>> --
>> Michael Harms, Ph.D.
>>
>> ---
>> Conte Center for the Neuroscience of Mental Disorders
>> Washington University School of Medicine
>> Department of Psychiatry, Box 8134
>> 660 South Euclid Ave.Tel: 314-747-6173
>> St. Louis, MO  63110Email: mha...@wustl.edu
>>
>>
>>
>>
>> On 8/29/16, 4:45 PM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf
>>of
>> Douglas N Greve" > gr...@nmr.mgh.harvard.edu> wrote:
>>
>> It is hard to say. Since the subjects are not exchangeable, the
>> permutation is technically not appropriate. Check the winkler paper,  I
>> think he talks about what happens if you just don't do anything.
>>
>>
>> On 08/29/2016 11:07 AM, maaike rive wrote:
>>> Hi all,
>>>
>>>
>>> Is using forced permutation for non-orthogonal design matrices wrong
>>> or is it allowed to do this instead of using tools like palm (what
>>> happens eg with the covariates when using forced permutation)? I
>>> used forced permutation  and it seemed to work, results were (partly)
>>> comparable to what I found with monte carlo simulations.
>>>
>>>
>>> Thanks, Maaike
>>>
>>>
>>>
>>> *Van:* freesurfer-boun...@nmr.mgh.harvard.edu
>>>  namens Harms, Michael
>>> 
>>> *Verzonden:* vrijdag 26 augustus 2016 01:00:13
>>> *Aan:* Freesurfer support list
>>> *Onderwerp:* Re: [Freesurfer] mri_glmfit-sim permutation testing
>>> running after 3 days!
>>>
>>> Hi,
>>> You might want to check out FSL¹s PALM tool, which has a bit more
>>> sophisticated permutation framework, and allows for permutation in the
>>> context of non-orthogonal covariates.
>>>
>>> cheers,
>>> -MH
>>>
>>> --
>>> Michael Harms, Ph.D.
>>> ---
>>> Conte Center for the Neuroscience of Mental Disorders
>>> Washington University School of Medicine
>>> Department of Psychiatry, Box 8134
>>> 660 South Euclid Ave.Tel: 314-747-6173
>>> St. Louis, MO  63110Email: mha...@wustl.edu
>>>
>>> From: >> > on behalf of Ajay
>>> Kurani >
>>> Reply-To: Freesurfer support list >> >
>>> Date: Thursday, August 25, 2016 at 4:13 PM
>>> To: Freesurfer support list >> >
>>> Subject: Re: [Freesurfer] mri_glmfit-sim permutation testing running
>>> after 3 days!
>>>
>>> Hi Doug,
>>> Thanks for the help!  I think I figured out the issue based on your
>>> response.
>>> 1) I created a template to use for this group and named it fsaverage
>>> (including creating monte carlo simulations) for simplicity of
>>> integrating with freesurfer as I am newer to it.  This is why the
>>> sizes didn't match up as you expected
>>>  but the mri_glmfit still ran.
>>>
>>> 2) I deleted the folder and restarted without background processes.
>>> The error became apparent.  Of my covariates (2 fix factors and 3
>>> quantitative), not all were orthogonal.  In looking at the error more,

Re: [Freesurfer] mri_glmfit-sim permutation testing running after 3 days!

[Matt Glasser]

PALM handles GIFTI and CIFTI data.

Peace,

Matt.

On 8/29/16, 6:21 PM, "Douglas N Greve"
 wrote:

>Does PALM do surface-based? Also, there is no way to appropriately
>handle this. For permutation, non-orthogonal designs are wrong. There
>are ways to try to compensate for it, which is what PALM is doing. Sorry
>to be nit-picky!
>
>
>On 08/29/2016 06:12 PM, Harms, Michael wrote:
>> Hi Maaike,
>> Why not just use PALM?  Then you don¹t have to worry about this (since
>> PALM appropriately handles the situation of correlated covariates).
>>
>> cheers,
>> -MH
>>
>> --
>> Michael Harms, Ph.D.
>>
>> ---
>> Conte Center for the Neuroscience of Mental Disorders
>> Washington University School of Medicine
>> Department of Psychiatry, Box 8134
>> 660 South Euclid Ave.Tel: 314-747-6173
>> St. Louis, MO  63110Email: mha...@wustl.edu
>>
>>
>>
>>
>> On 8/29/16, 4:45 PM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf
>>of
>> Douglas N Greve" > gr...@nmr.mgh.harvard.edu> wrote:
>>
>> It is hard to say. Since the subjects are not exchangeable, the
>> permutation is technically not appropriate. Check the winkler paper,  I
>> think he talks about what happens if you just don't do anything.
>>
>>
>> On 08/29/2016 11:07 AM, maaike rive wrote:
>>> Hi all,
>>>
>>>
>>> Is using forced permutation for non-orthogonal design matrices wrong
>>> or is it allowed to do this instead of using tools like palm (what
>>> happens eg with the covariates when using forced permutation)? I
>>> used forced permutation  and it seemed to work, results were (partly)
>>> comparable to what I found with monte carlo simulations.
>>>
>>>
>>> Thanks, Maaike
>>>
>>> 
>>>
>>> *Van:* freesurfer-boun...@nmr.mgh.harvard.edu
>>>  namens Harms, Michael
>>> 
>>> *Verzonden:* vrijdag 26 augustus 2016 01:00:13
>>> *Aan:* Freesurfer support list
>>> *Onderwerp:* Re: [Freesurfer] mri_glmfit-sim permutation testing
>>> running after 3 days!
>>>
>>> Hi,
>>> You might want to check out FSL¹s PALM tool, which has a bit more
>>> sophisticated permutation framework, and allows for permutation in the
>>> context of non-orthogonal covariates.
>>>
>>> cheers,
>>> -MH
>>>
>>> --
>>> Michael Harms, Ph.D.
>>> ---
>>> Conte Center for the Neuroscience of Mental Disorders
>>> Washington University School of Medicine
>>> Department of Psychiatry, Box 8134
>>> 660 South Euclid Ave.Tel: 314-747-6173
>>> St. Louis, MO  63110Email: mha...@wustl.edu
>>>
>>> From: >> > on behalf of Ajay
>>> Kurani >
>>> Reply-To: Freesurfer support list >> >
>>> Date: Thursday, August 25, 2016 at 4:13 PM
>>> To: Freesurfer support list >> >
>>> Subject: Re: [Freesurfer] mri_glmfit-sim permutation testing running
>>> after 3 days!
>>>
>>> Hi Doug,
>>> Thanks for the help!  I think I figured out the issue based on your
>>> response.
>>> 1) I created a template to use for this group and named it fsaverage
>>> (including creating monte carlo simulations) for simplicity of
>>> integrating with freesurfer as I am newer to it.  This is why the
>>> sizes didn't match up as you expected
>>>  but the mri_glmfit still ran.
>>>
>>> 2) I deleted the folder and restarted without background processes.
>>> The error became apparent.  Of my covariates (2 fix factors and 3
>>> quantitative), not all were orthogonal.  In looking at the error more,
>>> it seems that i need to add the
>>> --perm-force if I wanted the simulation to run, however the background
>>> processes were not aware of this error and kept polling as you
>>>mentioned.
>>>
>>> This brings me to a new but related issue.  From what I have read in
>>> other freesurfer posts, it is statistically incorrect to use
>>> --perm-force for non-orthogonal covariates (or continuous covariates).
>>> I am unsure how to proceed.
>>> a) If I ran permutation testing (to overcome the issue of incorrect
>>> smoothness estimations from the gaussian distribution assumption),
>>> then I run into the issue of non-orthogonal covariates.  Is there a
>>> way to orthogonalize the data in
>>>  freesurfer, or a solution to this issue?
>>>
>>> b) If orthogonalizing is difficult to implement, another option is
>>> running Qdec with the montecarlo simulation at a more conservative p
>>> value (p< 0.001).  From your previous posts, the testing at this p
>>> value for 10mm seems to meet the 5% FPR.  One question is if the

Re: [Freesurfer] mri_glmfit-sim permutation testing running after 3 days!

[Douglas N Greve]

Does PALM do surface-based? Also, there is no way to appropriately 
handle this. For permutation, non-orthogonal designs are wrong. There 
are ways to try to compensate for it, which is what PALM is doing. Sorry 
to be nit-picky!


On 08/29/2016 06:12 PM, Harms, Michael wrote:
> Hi Maaike,
> Why not just use PALM?  Then you don’t have to worry about this (since
> PALM appropriately handles the situation of correlated covariates).
>
> cheers,
> -MH
>
> --
> Michael Harms, Ph.D.
>
> ---
> Conte Center for the Neuroscience of Mental Disorders
> Washington University School of Medicine
> Department of Psychiatry, Box 8134
> 660 South Euclid Ave.Tel: 314-747-6173
> St. Louis, MO  63110Email: mha...@wustl.edu
>
>
>
>
> On 8/29/16, 4:45 PM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of
> Douglas N Greve"  gr...@nmr.mgh.harvard.edu> wrote:
>
> It is hard to say. Since the subjects are not exchangeable, the
> permutation is technically not appropriate. Check the winkler paper,  I
> think he talks about what happens if you just don't do anything.
>
>
> On 08/29/2016 11:07 AM, maaike rive wrote:
>> Hi all,
>>
>>
>> Is using forced permutation for non-orthogonal design matrices wrong
>> or is it allowed to do this instead of using tools like palm (what
>> happens eg with the covariates when using forced permutation)? I
>> used forced permutation  and it seemed to work, results were (partly)
>> comparable to what I found with monte carlo simulations.
>>
>>
>> Thanks, Maaike
>>
>> 
>> *Van:* freesurfer-boun...@nmr.mgh.harvard.edu
>>  namens Harms, Michael
>> 
>> *Verzonden:* vrijdag 26 augustus 2016 01:00:13
>> *Aan:* Freesurfer support list
>> *Onderwerp:* Re: [Freesurfer] mri_glmfit-sim permutation testing
>> running after 3 days!
>>
>> Hi,
>> You might want to check out FSL’s PALM tool, which has a bit more
>> sophisticated permutation framework, and allows for permutation in the
>> context of non-orthogonal covariates.
>>
>> cheers,
>> -MH
>>
>> --
>> Michael Harms, Ph.D.
>> ---
>> Conte Center for the Neuroscience of Mental Disorders
>> Washington University School of Medicine
>> Department of Psychiatry, Box 8134
>> 660 South Euclid Ave.Tel: 314-747-6173
>> St. Louis, MO  63110Email: mha...@wustl.edu
>>
>> From: > > on behalf of Ajay
>> Kurani >
>> Reply-To: Freesurfer support list > >
>> Date: Thursday, August 25, 2016 at 4:13 PM
>> To: Freesurfer support list > >
>> Subject: Re: [Freesurfer] mri_glmfit-sim permutation testing running
>> after 3 days!
>>
>> Hi Doug,
>> Thanks for the help!  I think I figured out the issue based on your
>> response.
>> 1) I created a template to use for this group and named it fsaverage
>> (including creating monte carlo simulations) for simplicity of
>> integrating with freesurfer as I am newer to it.  This is why the
>> sizes didn't match up as you expected
>>  but the mri_glmfit still ran.
>>
>> 2) I deleted the folder and restarted without background processes.
>> The error became apparent.  Of my covariates (2 fix factors and 3
>> quantitative), not all were orthogonal.  In looking at the error more,
>> it seems that i need to add the
>> --perm-force if I wanted the simulation to run, however the background
>> processes were not aware of this error and kept polling as you mentioned.
>>
>> This brings me to a new but related issue.  From what I have read in
>> other freesurfer posts, it is statistically incorrect to use
>> --perm-force for non-orthogonal covariates (or continuous covariates).
>> I am unsure how to proceed.
>> a) If I ran permutation testing (to overcome the issue of incorrect
>> smoothness estimations from the gaussian distribution assumption),
>> then I run into the issue of non-orthogonal covariates.  Is there a
>> way to orthogonalize the data in
>>  freesurfer, or a solution to this issue?
>>
>> b) If orthogonalizing is difficult to implement, another option is
>> running Qdec with the montecarlo simulation at a more conservative p
>> value (p< 0.001).  From your previous posts, the testing at this p
>> value for 10mm seems to meet the 5% FPR.  One question is if the
>> non-orthogonal data affects this analysis as well for this model?
>>
>> Thanks,
>> Ajay
>>
>> On Thu, Aug 25, 2016 at 12:18 PM, Ajay Kurani
>> > wrote:
>>
>>  Hi Freesurfer Experts,
>> I am trying to use freesurfer's 

Re: [Freesurfer] mri_glmfit-sim permutation testing running after 3 days!

[Harms, Michael]

Hi Maaike,
Why not just use PALM?  Then you don’t have to worry about this (since
PALM appropriately handles the situation of correlated covariates).

cheers,
-MH

--
Michael Harms, Ph.D.

---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave.Tel: 314-747-6173
St. Louis, MO  63110Email: mha...@wustl.edu




On 8/29/16, 4:45 PM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of
Douglas N Greve"  wrote:

It is hard to say. Since the subjects are not exchangeable, the
permutation is technically not appropriate. Check the winkler paper,  I
think he talks about what happens if you just don't do anything.


On 08/29/2016 11:07 AM, maaike rive wrote:
>
> Hi all,
>
>
> Is using forced permutation for non-orthogonal design matrices wrong
> or is it allowed to do this instead of using tools like palm (what
> happens eg with the covariates when using forced permutation)? I
> used forced permutation  and it seemed to work, results were (partly)
> comparable to what I found with monte carlo simulations.
>
>
> Thanks, Maaike
>
> 
> *Van:* freesurfer-boun...@nmr.mgh.harvard.edu
>  namens Harms, Michael
> 
> *Verzonden:* vrijdag 26 augustus 2016 01:00:13
> *Aan:* Freesurfer support list
> *Onderwerp:* Re: [Freesurfer] mri_glmfit-sim permutation testing
> running after 3 days!
>
> Hi,
> You might want to check out FSL’s PALM tool, which has a bit more
> sophisticated permutation framework, and allows for permutation in the
> context of non-orthogonal covariates.
>
> cheers,
> -MH
>
> --
> Michael Harms, Ph.D.
> ---
> Conte Center for the Neuroscience of Mental Disorders
> Washington University School of Medicine
> Department of Psychiatry, Box 8134
> 660 South Euclid Ave.Tel: 314-747-6173
> St. Louis, MO  63110Email: mha...@wustl.edu
>
> From:  > on behalf of Ajay
> Kurani >
> Reply-To: Freesurfer support list  >
> Date: Thursday, August 25, 2016 at 4:13 PM
> To: Freesurfer support list  >
> Subject: Re: [Freesurfer] mri_glmfit-sim permutation testing running
> after 3 days!
>
> Hi Doug,
>Thanks for the help!  I think I figured out the issue based on your
> response.
> 1) I created a template to use for this group and named it fsaverage
> (including creating monte carlo simulations) for simplicity of
> integrating with freesurfer as I am newer to it.  This is why the
> sizes didn't match up as you expected
> but the mri_glmfit still ran.
>
> 2) I deleted the folder and restarted without background processes.
> The error became apparent.  Of my covariates (2 fix factors and 3
> quantitative), not all were orthogonal.  In looking at the error more,
> it seems that i need to add the
> --perm-force if I wanted the simulation to run, however the background
> processes were not aware of this error and kept polling as you mentioned.
>
> This brings me to a new but related issue.  From what I have read in
> other freesurfer posts, it is statistically incorrect to use
> --perm-force for non-orthogonal covariates (or continuous covariates).
> I am unsure how to proceed.
> a) If I ran permutation testing (to overcome the issue of incorrect
> smoothness estimations from the gaussian distribution assumption),
> then I run into the issue of non-orthogonal covariates.  Is there a
> way to orthogonalize the data in
> freesurfer, or a solution to this issue?
>
> b) If orthogonalizing is difficult to implement, another option is
> running Qdec with the montecarlo simulation at a more conservative p
> value (p< 0.001).  From your previous posts, the testing at this p
> value for 10mm seems to meet the 5% FPR.  One question is if the
> non-orthogonal data affects this analysis as well for this model?
>
> Thanks,
> Ajay
>
> On Thu, Aug 25, 2016 at 12:18 PM, Ajay Kurani
> > wrote:
>
> Hi Freesurfer Experts,
>I am trying to use freesurfer's mri_glmfit-sim tool to run
> permutation testing on cortical thickness data (as recommended by
> Doug in my previous post:
>
>http://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg48653.html
>
>l>
> )
>
> Most of the tutorials I found were not related to permutation
> testing so the subsequent steps may be incorrect.  

Re: [Freesurfer] mri_glmfit-sim permutation testing running after 3 days!

[Douglas N Greve]

It is hard to say. Since the subjects are not exchangeable, the 
permutation is technically not appropriate. Check the winkler paper,  I 
think he talks about what happens if you just don't do anything.


On 08/29/2016 11:07 AM, maaike rive wrote:
>
> Hi all,
>
>
> Is using forced permutation for non-orthogonal design matrices wrong 
> or is it allowed to do this instead of using tools like palm (what 
> happens eg with the covariates when using forced permutation)? I 
> used forced permutation  and it seemed to work, results were (partly) 
> comparable to what I found with monte carlo simulations.
>
>
> Thanks, Maaike
>
> 
> *Van:* freesurfer-boun...@nmr.mgh.harvard.edu 
>  namens Harms, Michael 
> 
> *Verzonden:* vrijdag 26 augustus 2016 01:00:13
> *Aan:* Freesurfer support list
> *Onderwerp:* Re: [Freesurfer] mri_glmfit-sim permutation testing 
> running after 3 days!
>
> Hi,
> You might want to check out FSL’s PALM tool, which has a bit more 
> sophisticated permutation framework, and allows for permutation in the 
> context of non-orthogonal covariates.
>
> cheers,
> -MH
>
> -- 
> Michael Harms, Ph.D.
> ---
> Conte Center for the Neuroscience of Mental Disorders
> Washington University School of Medicine
> Department of Psychiatry, Box 8134
> 660 South Euclid Ave.Tel: 314-747-6173
> St. Louis, MO  63110Email: mha...@wustl.edu
>
> From:  > on behalf of Ajay 
> Kurani >
> Reply-To: Freesurfer support list  >
> Date: Thursday, August 25, 2016 at 4:13 PM
> To: Freesurfer support list  >
> Subject: Re: [Freesurfer] mri_glmfit-sim permutation testing running 
> after 3 days!
>
> Hi Doug,
>Thanks for the help!  I think I figured out the issue based on your 
> response.
> 1) I created a template to use for this group and named it fsaverage 
> (including creating monte carlo simulations) for simplicity of 
> integrating with freesurfer as I am newer to it.  This is why the 
> sizes didn't match up as you expected
> but the mri_glmfit still ran.
>
> 2) I deleted the folder and restarted without background processes.  
> The error became apparent.  Of my covariates (2 fix factors and 3 
> quantitative), not all were orthogonal.  In looking at the error more, 
> it seems that i need to add the
> --perm-force if I wanted the simulation to run, however the background 
> processes were not aware of this error and kept polling as you mentioned.
>
> This brings me to a new but related issue.  From what I have read in 
> other freesurfer posts, it is statistically incorrect to use 
> --perm-force for non-orthogonal covariates (or continuous covariates). 
> I am unsure how to proceed.
> a) If I ran permutation testing (to overcome the issue of incorrect 
> smoothness estimations from the gaussian distribution assumption), 
> then I run into the issue of non-orthogonal covariates.  Is there a 
> way to orthogonalize the data in
> freesurfer, or a solution to this issue?
>
> b) If orthogonalizing is difficult to implement, another option is 
> running Qdec with the montecarlo simulation at a more conservative p 
> value (p< 0.001).  From your previous posts, the testing at this p 
> value for 10mm seems to meet the 5% FPR.  One question is if the 
> non-orthogonal data affects this analysis as well for this model?
>
> Thanks,
> Ajay
>
> On Thu, Aug 25, 2016 at 12:18 PM, Ajay Kurani 
> > wrote:
>
> Hi Freesurfer Experts,
>I am trying to use freesurfer's mri_glmfit-sim tool to run
> permutation testing on cortical thickness data (as recommended by
> Doug in my previous post:
> http://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg48653.html
> 
> 
> )
>
> Most of the tutorials I found were not related to permutation
> testing so the subsequent steps may be incorrect.  Please let me
> know where I go wrong...
>
> 1) I first ran QDec to generate a folder for the analysis which
> would create the subsequent fsgd and y files needed my
> mri_glmfit-sim.  I am running both left and right hemisphere
> cortical thickness analysis with 10mm smoothing.  The following is
> for just the left hemisphere.   Note I am doing a 3 group
> comparison, but for this 2 group ttest I manually centered the
> data based on the 3 group mean for age and education.
>
> 2) I ran the following command:
> /mri_glmfit-sim --glmdir 

Re: [Freesurfer] Reproducibility of freesurfer analyses across different version of linux

[R Edgar]

On 29 August 2016 at 02:24, Knut J Bjuland  wrote:

> Is it possible to use a script to extract information about which library
> that is used for each recons?Or are there any other means to get this
> information?

I'm not sure about that. At least some of the info is recorded as part
of the official freesurfer build, but I don't know off hand if all the
library versions are recorded.

> How do you? "Use the differences between different library versions (not
> just libc, but all the other
> numerical libraries Freesurfer uses) to provide an estimate of the
> confidence levels/error bounds on your Freesurfer runs"

Run the same analysis of your subjects with builds linked against
different library versions (in a manner similar to that in the paper
you mention). Check to see that those results still support your
preliminary conclusion.

Regards,

Richard
___
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.

Re: [Freesurfer] Results different between mean-centered and raw covariates -- glm_fit

[Douglas N Greve]

You definitely do not want to demean within group. Having said that, no 
demeaning method is more "sound" than the other. The problem is in the 
interpretation. Imagaine you have a plot of volume vs ICV for each 
group. When you have an interaction, the best-fit lines will intersect 
at some ICV. If you test at that intersection, then you will get no 
difference. If you test on one side of the intersection, you will get a 
difference of some sign. If you test on the other side, you will get a 
difference of the opposite sign. So your results depend on what ICV you 
test at.


On 08/29/2016 03:43 PM, Corinna Bauer wrote:
> Yes, I agree completely. We are using DODS and it is clear that we 
> have different results depending on which type of ICV we use. The 
> question is... which type of ICV correction for DODS is the most 
> statistically sound? demean across all groups, no demeaning, or demean 
> within groups separately.
>
> What would you recommend.
>
> On Mon, Aug 29, 2016 at 3:33 PM, Douglas N Greve 
> > wrote:
>
> If there was not an interaction between group and ICV, I would say to
> use DOSS where demeaning does not make a difference. Since there is an
> interaction, you have to use DODS, but the interpretation is no longer
> easy. If you do not demean, then you are implictly testing for a
> difference at ICV=0 (this is what "regressing out" means). If you
> demean, you are implicitly testing at ICV=MeanICV. The problem is that
> the results can change depending on the ICV you test it at.
>
>
> On 08/29/2016 02:53 PM, Corinna Bauer wrote:
> > Sorry for not specifying. Yes, we are looking at difference in
> volume
> > between the two groups using DODS. What is the most statistically
> > sound... raw values, demeaning across the entire sample, or
> demeaning
> > with groups separately? FYI, I exported the ICV values to SAS and
> > there is a significant different between the two groups for ICV.
> >
> >
> >
> > On Mon, Aug 29, 2016 at 2:48 PM, Douglas N Greve
> > 
>  >> wrote:
> >
> > not sure what you are testing, but if you are, eg, looking
> at the
> > difference between two groups regressing out ICV, then it
> can make a
> > huge difference
> >
> >
> > On 08/29/2016 12:36 PM, Corinna Bauer wrote:
> > > Hello all,
> > >
> > > I am wondering why results would change completely for
> between group
> > > volume analysis when using demeaned/mean-centered ICV
> compared to
> > > using ICV as a covariate in mri_glmfit? See the figures below.
> > >
> > > Does demeaning the covariate inherently change the results
> > comapred to
> > > the raw covariate values?
> > >
> > > Thanks
> > >
> > > Corinna
> > >
> > >
> > > ___
> > > Freesurfer mailing list
> > > Freesurfer@nmr.mgh.harvard.edu
> 
> >  >
> > >
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
> >  >
> >
> > --
> > Douglas N. Greve, Ph.D.
> > MGH-NMR Center
> > gr...@nmr.mgh.harvard.edu 
> >
> > Phone Number: 617-724-2358 
> >
> > Fax: 617-726-7422   >
> >
> > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> 
> >  >
> > FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> 
> >  >
> > www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> 
> >  >
> > Outgoing:
> > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
> 
> > 

Re: [Freesurfer] Results different between mean-centered and raw covariates -- glm_fit

[Corinna Bauer]

Yes, I agree completely. We are using DODS and it is clear that we have
different results depending on which type of ICV we use. The question is...
which type of ICV correction for DODS is the most statistically sound?
demean across all groups, no demeaning, or demean within groups separately.

What would you recommend.

On Mon, Aug 29, 2016 at 3:33 PM, Douglas N Greve 
wrote:

> If there was not an interaction between group and ICV, I would say to
> use DOSS where demeaning does not make a difference. Since there is an
> interaction, you have to use DODS, but the interpretation is no longer
> easy. If you do not demean, then you are implictly testing for a
> difference at ICV=0 (this is what "regressing out" means). If you
> demean, you are implicitly testing at ICV=MeanICV. The problem is that
> the results can change depending on the ICV you test it at.
>
>
> On 08/29/2016 02:53 PM, Corinna Bauer wrote:
> > Sorry for not specifying. Yes, we are looking at difference in volume
> > between the two groups using DODS. What is the most statistically
> > sound... raw values, demeaning across the entire sample, or demeaning
> > with groups separately? FYI, I exported the ICV values to SAS and
> > there is a significant different between the two groups for ICV.
> >
> >
> >
> > On Mon, Aug 29, 2016 at 2:48 PM, Douglas N Greve
> > > wrote:
> >
> > not sure what you are testing, but if you are, eg, looking at the
> > difference between two groups regressing out ICV, then it can make a
> > huge difference
> >
> >
> > On 08/29/2016 12:36 PM, Corinna Bauer wrote:
> > > Hello all,
> > >
> > > I am wondering why results would change completely for between
> group
> > > volume analysis when using demeaned/mean-centered ICV compared to
> > > using ICV as a covariate in mri_glmfit? See the figures below.
> > >
> > > Does demeaning the covariate inherently change the results
> > comapred to
> > > the raw covariate values?
> > >
> > > Thanks
> > >
> > > Corinna
> > >
> > >
> > > ___
> > > Freesurfer mailing list
> > > Freesurfer@nmr.mgh.harvard.edu
> > 
> > > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> > 
> >
> > --
> > Douglas N. Greve, Ph.D.
> > MGH-NMR Center
> > gr...@nmr.mgh.harvard.edu 
> > Phone Number: 617-724-2358 
> > Fax: 617-726-7422 
> >
> > Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> > 
> > FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> > 
> > www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> > 
> > Outgoing:
> > ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
> > 
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu  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
>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> gr...@nmr.mgh.harvard.edu
> Phone Number: 617-724-2358
> Fax: 617-726-7422
>
> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Results different between mean-centered and raw covariates -- glm_fit

[Douglas N Greve]

If there was not an interaction between group and ICV, I would say to 
use DOSS where demeaning does not make a difference. Since there is an 
interaction, you have to use DODS, but the interpretation is no longer 
easy. If you do not demean, then you are implictly testing for a 
difference at ICV=0 (this is what "regressing out" means). If you 
demean, you are implicitly testing at ICV=MeanICV. The problem is that 
the results can change depending on the ICV you test it at.


On 08/29/2016 02:53 PM, Corinna Bauer wrote:
> Sorry for not specifying. Yes, we are looking at difference in volume 
> between the two groups using DODS. What is the most statistically 
> sound... raw values, demeaning across the entire sample, or demeaning 
> with groups separately? FYI, I exported the ICV values to SAS and 
> there is a significant different between the two groups for ICV.
>
>
>
> On Mon, Aug 29, 2016 at 2:48 PM, Douglas N Greve 
> > wrote:
>
> not sure what you are testing, but if you are, eg, looking at the
> difference between two groups regressing out ICV, then it can make a
> huge difference
>
>
> On 08/29/2016 12:36 PM, Corinna Bauer wrote:
> > Hello all,
> >
> > I am wondering why results would change completely for between group
> > volume analysis when using demeaned/mean-centered ICV compared to
> > using ICV as a covariate in mri_glmfit? See the figures below.
> >
> > Does demeaning the covariate inherently change the results
> comapred to
> > the raw covariate values?
> >
> > Thanks
> >
> > Corinna
> >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu
> 
> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> 
>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> gr...@nmr.mgh.harvard.edu 
> Phone Number: 617-724-2358 
> Fax: 617-726-7422 
>
> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> 
> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> 
> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> 
> Outgoing:
> ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
> 
>
> ___
> 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

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Results different between mean-centered and raw covariates -- glm_fit

[Corinna Bauer]

Sorry for not specifying. Yes, we are looking at difference in volume
between the two groups using DODS. What is the most statistically sound...
raw values, demeaning across the entire sample, or demeaning with groups
separately? FYI, I exported the ICV values to SAS and there is a
significant different between the two groups for ICV.



On Mon, Aug 29, 2016 at 2:48 PM, Douglas N Greve 
wrote:

> not sure what you are testing, but if you are, eg, looking at the
> difference between two groups regressing out ICV, then it can make a
> huge difference
>
>
> On 08/29/2016 12:36 PM, Corinna Bauer wrote:
> > Hello all,
> >
> > I am wondering why results would change completely for between group
> > volume analysis when using demeaned/mean-centered ICV compared to
> > using ICV as a covariate in mri_glmfit? See the figures below.
> >
> > Does demeaning the covariate inherently change the results comapred to
> > the raw covariate values?
> >
> > Thanks
> >
> > Corinna
> >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu
> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> gr...@nmr.mgh.harvard.edu
> Phone Number: 617-724-2358
> Fax: 617-726-7422
>
> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>
> ___
> 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.

Re: [Freesurfer] Results different between mean-centered and raw covariates -- glm_fit

[Douglas N Greve]

not sure what you are testing, but if you are, eg, looking at the 
difference between two groups regressing out ICV, then it can make a 
huge difference


On 08/29/2016 12:36 PM, Corinna Bauer wrote:
> Hello all,
>
> I am wondering why results would change completely for between group 
> volume analysis when using demeaned/mean-centered ICV compared to 
> using ICV as a covariate in mri_glmfit? See the figures below.
>
> Does demeaning the covariate inherently change the results comapred to 
> the raw covariate values?
>
> Thanks
>
> Corinna
>
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

-- 
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Phone Number: 617-724-2358
Fax: 617-726-7422

Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
www.nmr.mgh.harvard.edu/facility/filedrop/index.html
Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/

___
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.

Re: [Freesurfer] volume, surface area, and thickness

[Bruce Fischl]

Hi Woo-Suk

why not just do the surface analysis that they are requesting? I'm not
sure what you are asking, but certainly volume = surface area * thickness 
in general, and so a volumetric effect can be driven by one or both of 
surface area and thickness


cheers
Bruce


On 
Sat, 27 Aug 2016, Woo-Suk Tae wrote:



Dear FreeSurfer experts and developers

I am confronted with some technical question of a reviewer.
I am not sure about "volume = thickness-by-surface area" and the review's
opinion (attached below) about volume, surface area, and thickness was
correct.
Any comments from FreeSurfer's experts would help me.

Sincerely yours

Woo-Suk Tae
Seoul, Korea

I added the reviewer's comments.  
-
1. Volume/thickness: The authors cite many papers that show volume and
thickness differences in MDD. The unresolved part here, however, is the
RELATION between cortical thickness and cortical volume: There is no doubt,
that both measures are found affected in MDD. This is, because cortical
thickess multiplied by the surface area of a gyrus results in its volume, so
volumse = thickness-by-surface area. Surface area values themselves are
technically more noisy and usually thus less sensitive (due to the problem
of false attributions to an area). 

So, volume is influenced by thickness and surface and is the less specific
measure. If a volume effect is detected in a study, it is unclear, if it is
driven by thickness, or surface area, or both. In this respect, the study of
Schmaal et al. is telling, as it analyzed BOTH measures, finding only
thickness effects of MDD, and (practically) no surface area changes except
for adolescent MDD. In the adolescent MDD samples gross surface area
differences were detected.

This means, that the question of "superiority" is rather a question of
"specificity": (Cortical) volume findings in adult MDD are mostly driven by
thickness differences and are in on way independent from thickness
differences. In this respect, the authors should follow the basic geometric
principles of morphometry and point out the relatedness of the two. They can
simply check this in their FreeSurfer variables (e. g. for total grey matter
volume). Not reporting surface area is leaving an interpretational gap as
surface area differences could in addition drive volume differences. The
authors may want to decide not to present surface area results, but then
they should discuss this as limitation to disentangle the origin of
volumetric (cortical) effects. This seems important as methylation effects
and FKBP5 interact with early life time stress, so effects on surface area
as seen in adolescent MDD highlight that surface area effects could play
in. 





 

---
-
Woo-Suk, Tae  Ph.D.  Research Professor
Brain Convergence Research Center, Medical Research Center
Anam Hospital, Korea University Medical Center, Seoul, Korea
mobile: 82-10-9120-4629
office: 82-2-920-6831
email: woosuk@gmail.com, woos...@gmail.com
---
-


___
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.

Re: [Freesurfer] wm.mgz enclosed in pial/white surface

[Bruce Fischl]

do you mean the ones that are between the two surfaces? You could use 
mris_fill to  fill the interior of the white then use it as a mask in 
mri_mask


cheers
Bruce


On Sun, 28 Aug 2016, Fire Tech wrote:


Dear all
 
I am searching for a solution to remove wm.mgz voxels which are enclosed by
pial & white surface. Is there an automated way to do so?
 
Greetings
 
 

___
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] Results different between mean-centered and raw covariates -- glm_fit

[Corinna Bauer]

Hello all,

I am wondering why results would change completely for between group volume
analysis when using demeaned/mean-centered ICV compared to using ICV as a
covariate in mri_glmfit? See the figures below.

Does demeaning the covariate inherently change the results comapred to the
raw covariate values?

Thanks

Corinna
___
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.

Re: [Freesurfer] mri_glmfit-sim permutation testing running after 3 days!

[maaike rive]

Hi all,


Is using forced permutation for non-orthogonal design matrices wrong or is it 
allowed to do this instead of using tools like palm (what happens eg with the 
covariates when using forced permutation)? I used forced permutation  and it 
seemed to work, results were (partly) comparable to what I found with monte 
carlo simulations.


Thanks, Maaike


Van: freesurfer-boun...@nmr.mgh.harvard.edu 
 namens Harms, Michael 

Verzonden: vrijdag 26 augustus 2016 01:00:13
Aan: Freesurfer support list
Onderwerp: Re: [Freesurfer] mri_glmfit-sim permutation testing running after 3 
days!


Hi,
You might want to check out FSL’s PALM tool, which has a bit more sophisticated 
permutation framework, and allows for permutation in the context of 
non-orthogonal covariates.

cheers,
-MH

--
Michael Harms, Ph.D.
---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave. Tel: 314-747-6173
St. Louis, MO  63110 Email: mha...@wustl.edu

From: 
>
 on behalf of Ajay Kurani 
>
Reply-To: Freesurfer support list 
>
Date: Thursday, August 25, 2016 at 4:13 PM
To: Freesurfer support list 
>
Subject: Re: [Freesurfer] mri_glmfit-sim permutation testing running after 3 
days!

Hi Doug,
   Thanks for the help!  I think I figured out the issue based on your response.
1) I created a template to use for this group and named it fsaverage (including 
creating monte carlo simulations) for simplicity of integrating with freesurfer 
as I am newer to it.  This is why the sizes didn't match up as you expected
but the mri_glmfit still ran.

2) I deleted the folder and restarted without background processes.  The error 
became apparent.  Of my covariates (2 fix factors and 3 quantitative), not all 
were orthogonal.  In looking at the error more, it seems that i need to add the
--perm-force if I wanted the simulation to run, however the background 
processes were not aware of this error and kept polling as you mentioned.

This brings me to a new but related issue.  From what I have read in other 
freesurfer posts, it is statistically incorrect to use --perm-force for 
non-orthogonal covariates (or continuous covariates).  I am unsure how to 
proceed.
a) If I ran permutation testing (to overcome the issue of incorrect smoothness 
estimations from the gaussian distribution assumption), then I run into the 
issue of non-orthogonal covariates.  Is there a way to orthogonalize the data in
freesurfer, or a solution to this issue?

b) If orthogonalizing is difficult to implement, another option is running Qdec 
with the montecarlo simulation at a more conservative p value (p< 0.001).  From 
your previous posts, the testing at this p value for 10mm seems to meet the 5% 
FPR.  One question is if the non-orthogonal data affects this analysis as well 
for this model?

Thanks,
Ajay

On Thu, Aug 25, 2016 at 12:18 PM, Ajay Kurani 
> wrote:
Hi Freesurfer Experts,
   I am trying to use freesurfer's mri_glmfit-sim tool to run permutation 
testing on cortical thickness data (as recommended by Doug in my previous post: 
http://www.mail-archive.com/freesurfer%40nmr.mgh.harvard.edu/msg48653.html )

Most of the tutorials I found were not related to permutation testing so the 
subsequent steps may be incorrect.  Please let me know where I go wrong...

1) I first ran QDec to generate a folder for the analysis which would create 
the subsequent fsgd and y files needed my mri_glmfit-sim.  I am running both 
left and right hemisphere cortical thickness analysis with 10mm smoothing.  The 
following is for just the left hemisphere.   Note I am doing a 3 group 
comparison, but for this 2 group ttest I manually centered the data based on 
the 3 group mean for age and education.

2) I ran the following command:
/mri_glmfit-sim --glmdir ./HCvsPAT_lh_thickness_10mm/ --sim perm 1 2 
perm.abs.2 --sim-sign abs --bg 16

Prior to running the command above, from the y.fsdg file I deleted the fwhm 
estimate of 13mm since this was not correctly estimated (ACF with long tails).  
I assumed that by removing this estimate, it would force the permutation test 
to calculate based on the data but when looking at the log output I see the 
following which says fwhm 0:

cmdline mri_glmfit.bin --C 
./HCvsPAT_lh_thickness_10mm//tmp.mri_glmfit-sim-19468/lh-Avg-Intercept-thickness.mtx
 --C 
./HCvsPAT_lh_thickness_10mm//tmp.mri_glmfit-sim-19468/lh-Diff-Male-Female-Intercept-thickness.mtx
 --C 

[Freesurfer] How to transfer the VTK cortical surface to the diffusion space?

[Islem Rekik]

Hi there!

Since this is my first time using FreeSurfer, I found it quite challenging
to get the handle on the different coordinate systems used. My goal is to
generate vtk files where the vtk cortical surface and the vtk fiber tracts
are in the same space (for one individual subject).

Basically, I used recon-all to generate the cortical surfaces and trac-all
to generate dtifit_FA.mgz and dtifit_V1.mgz for tractography in the
original diffusion space.

I used the transformation matrices generated in dmri/xmfs to transfer the
cortical surface into the diffusion space, but not of them seem to work.
What I find quite confusing is that when I visualize the surface lh.pial
and the anatomical image brainmask.mgz using FreeView they nicely overlap;
however, after I convert lh.pial to lh.pial.vtk and brainmask.mgz to
brainmask.mha and visualize them using Paraview, they are in different
spaces.

To do so, I used the command line mri_surf2surf so the surface will overlay
with brainmask.mha image when using Paraview, but none of the
transformation matrices seems to warp the surface onto the anatomical
(structural FreeSurfer) space. I also tried to warp it to the diffusion
space and the anatomical original space, but it never overlapped with the
images nested in these respective spaces. It is always floating somewhere
else!

I would like to know which transformation I need to:
1. apply to have the VTK surface overlap with the brainmask.mha image in
the anatomical space and,
2. apply another transformation to transfer the VTK surface to the
diffusion space where I perform tractography.

Also, does TRACULA perfom whole brain tractography?

I really appreciate your help!

Kindly,
Islem
___
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.

Re: [Freesurfer] Reproducibility of freesurfer analyses across different version of linux

[Knut J Bjuland]

On 08/28/2016 05:57 PM, R Edgar wrote:

On 28 August 2016 at 06:59, Knut J Bjuland  wrote:


I found this paper about named “Reproducibility of neuroimaging analyses
across operating systems” (Glatard et al., 2015).   There were differences
in cortical morphometry like cortical thicknes between  images proscced in
the same version of freesurfer with different version of Linux or glibc for
Freesurfer, and according to the paper, it was caused by how different
version of glibc handles small single precssion floating numbers. I have
therefore some questions.

Are there plans for freesurfer to use double floating numbers in steps that
may be affected by numerical stability? Or can this problem be solved by
using staticall linking glibc into Freesurfer?

Freesurfer does use double precision numbers extensively on the CPU
side (on the GPU side of things, I generally went back to singles).
The issue is not one of numeric stability, and going to all-double (or
all-quad) would not remove the differences - they are fundamental to
how floating point arithmetic works. Put simply, for floating point
numbers:
a+(b+c) != (a+b)+c
Any attempt to ignore this fact is going to come to grief at some point.

Freesurfer often has to do things such as "find voxels exceeding
threshold" or "find most likely label for voxel." Operations like this
are always going to be vulnerable to differences in the least
significant bit.

Speaking from a numerical background (I have no experience in
neuroscience), I would suggest embracing this behaviour rather than
trying avoid it (arguably a fool's errand). Use the differences
between different library versions (not just libc, but all the other
numerical libraries Freesurfer uses) to provide an estimate of the
confidence levels/error bounds on your Freesurfer runs. If your
conclusion depends critically on using version x.y.z of a library,
rather than x.y.z+1, then unless you can point to a specific bug in
the library, you probably don't really have a conclusion.

Regards,

Richard

___
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.


Hi


Thanksfortheanswer.

Isitpossibletouseascripttoextractinformation 
aboutwhichlibrarythatisusedforeachrecons? 
Orarethereanyothermeanstogetthisinformation?


How do you? "Use the differences between different library versions (not 
just libc, but all the other


numerical libraries Freesurfer uses) to provide an estimate of the confidence 
levels/error bounds on your Freesurfer runs"


Regards

Knut Jørgen



___
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.