Re: [Freesurfer] consistency in recon-all parallel pipeline

2024-02-23 Thread Horn, Mitchell Jacob
This is all with ‘recon-all -parallel’

Thanks,
Mitch

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 On Behalf Of Huang, Yujing
Sent: Friday, February 23, 2024 2:30 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] consistency in recon-all parallel pipeline

Do you run ‘recon-all -parallel’ or ‘recon-all –threads ’?

From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 On Behalf Of Horn, Mitchell Jacob
Sent: Friday, February 23, 2024 12:28 PM
To: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Subject: Re: [Freesurfer] consistency in recon-all parallel pipeline

Bottom line is that when I run any FreeSurfer version 7+ in parallel on COS8 I 
get different results each time.

Thanks,
Mitch

From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 On Behalf Of Douglas N. Greve
Sent: Friday, February 23, 2024 11:03 AM
To: freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>
Subject: Re: [Freesurfer] consistency in recon-all parallel pipeline

So, is the bottom line that when you run 7.4.1 on COS8 in parallel that you get 
(slightly) different results each time?
On 2/2/2024 11:20 AM, Horn, Mitchell Jacob wrote:

Hi FS Devs,



I’m experiencing unreproducible thickness results when running any 7+ version 
with parallelization enabled. Running recon-all without parallelization 
produces consistent thickness results. I’m running this in AlmaLinux8 (a 
library-equivalent downstream OS to CentOS8).



I’m attaching a table (table1) of 12 recons with bert:

  1.  3 parallelized with CentOS8-compiled 7.4.1
  2.  3 non-parallelized with CentOS8-compiled 7.4.1
  3.  3 parallelized with CentOS7-compiled 7.4.1
  4.  3 non-parallelized with CentOS7-compiled 7.4.1



I suspected the downstream CentOS8 libm was the culprit (because of testing I 
did this last 2023 summer). I ran 3 more recons parallelized with the 
CentOS7-compiled 7.4.1, but before running the recon-all command, set 
LD_PRELOAD to a copy of the CentOS7 libm libraries. The thickness results were 
then consistent, see the second table below (table2). I could not run this 
experiment on the CentOS8-compiled version, as that one is obviously not 
backward compatible with CentOS7 libm.



As a quick test of the OS-dependency, I submitted 3 parallel recons on MLSC 
with 7.3.3. Each reported different thickness. See table 3 (table3).



I’m asking if you can please confirm whether running any 7.+ version with 
parallelization is generating reproducible results for you in CentOS8 (or 
equivalent)?



P.S. - I tested 6.0 (CentOS6-compilation) with parallelization, and the results 
were consistent.

Best,
Mitch



___

Freesurfer mailing list

Freesurfer@nmr.mgh.harvard.edu<mailto: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
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
<https://www.massgeneralbrigham.org/complianceline> .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail. 


Re: [Freesurfer] consistency in recon-all parallel pipeline

2024-02-23 Thread Horn, Mitchell Jacob
Bottom line is that when I run any FreeSurfer version 7+ in parallel on COS8 I 
get different results each time.

Thanks,
Mitch

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 On Behalf Of Douglas N. Greve
Sent: Friday, February 23, 2024 11:03 AM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] consistency in recon-all parallel pipeline

So, is the bottom line that when you run 7.4.1 on COS8 in parallel that you get 
(slightly) different results each time?
On 2/2/2024 11:20 AM, Horn, Mitchell Jacob wrote:

Hi FS Devs,



I’m experiencing unreproducible thickness results when running any 7+ version 
with parallelization enabled. Running recon-all without parallelization 
produces consistent thickness results. I’m running this in AlmaLinux8 (a 
library-equivalent downstream OS to CentOS8).



I’m attaching a table (table1) of 12 recons with bert:

  1.  3 parallelized with CentOS8-compiled 7.4.1
  2.  3 non-parallelized with CentOS8-compiled 7.4.1
  3.  3 parallelized with CentOS7-compiled 7.4.1
  4.  3 non-parallelized with CentOS7-compiled 7.4.1



I suspected the downstream CentOS8 libm was the culprit (because of testing I 
did this last 2023 summer). I ran 3 more recons parallelized with the 
CentOS7-compiled 7.4.1, but before running the recon-all command, set 
LD_PRELOAD to a copy of the CentOS7 libm libraries. The thickness results were 
then consistent, see the second table below (table2). I could not run this 
experiment on the CentOS8-compiled version, as that one is obviously not 
backward compatible with CentOS7 libm.



As a quick test of the OS-dependency, I submitted 3 parallel recons on MLSC 
with 7.3.3. Each reported different thickness. See table 3 (table3).



I’m asking if you can please confirm whether running any 7.+ version with 
parallelization is generating reproducible results for you in CentOS8 (or 
equivalent)?



P.S. - I tested 6.0 (CentOS6-compilation) with parallelization, and the results 
were consistent.

Best,
Mitch




___

Freesurfer mailing list

Freesurfer@nmr.mgh.harvard.edu<mailto: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
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
<https://www.massgeneralbrigham.org/complianceline> .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail. 


Re: [Freesurfer] aparcstats2table - append option

2023-12-18 Thread Horn, Mitchell Jacob
Wow that was fast! Thanks!
-Mitch

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Huang, Yujing 

Sent: Monday, December 18, 2023 2:18:19 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] aparcstats2table - append option


'--append' option is added to aparcstats2table and asegstats2table. It should 
be available tomorrow in Freesurfer dev version.



From: freesurfer-boun...@nmr.mgh.harvard.edu 
 On Behalf Of Horn, Mitchell Jacob
Sent: Monday, December 18, 2023 9:06 AM
To: Freesurfer support list 
Subject: Re: [Freesurfer] aparcstats2table - append option



Exactly.



My understanding (and correct me if I’m wrong) is that both commands 
create/overwrite the specified --tablefile each time it’s run.



Best,

Mitch





From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 On Behalf Of Huang, Yujing
Sent: Monday, December 18, 2023 8:55 AM
To: Freesurfer support list 
mailto:freesurfer@nmr.mgh.harvard.edu>>
Subject: Re: [Freesurfer] aparcstats2table - append option



I would like to confirm that this is what you have in mind:

  1.  the new ‘—append’ flag will work with ‘--tablefile=OUTPUTFILE’
  2.  when same OUTPUTFILE is specified, new stats output will be appended to 
the end of file



Best,



Yujing



From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 On Behalf Of Horn, Mitchell Jacob
Sent: Tuesday, December 12, 2023 10:10 AM
To: freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>
Subject: [Freesurfer] aparcstats2table - append option



Hi FS Devs,



Would it be possible to add an “append” flag for use with aparcstats2table and 
asegstats2table? If I understand their usage correctly, each time one of them 
are run they will create (or overwrite) a new file. Not urgent but would be 
useful.



Thanks,

Mitch
___
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
<https://www.massgeneralbrigham.org/complianceline> .


Re: [Freesurfer] aparcstats2table - append option

2023-12-18 Thread Horn, Mitchell Jacob
Exactly.

My understanding (and correct me if I'm wrong) is that both commands 
create/overwrite the specified --tablefile each time it's run.

Best,
Mitch


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 On Behalf Of Huang, Yujing
Sent: Monday, December 18, 2023 8:55 AM
To: Freesurfer support list 
Subject: Re: [Freesurfer] aparcstats2table - append option

I would like to confirm that this is what you have in mind:

  1.  the new '-append' flag will work with '--tablefile=OUTPUTFILE'
  2.  when same OUTPUTFILE is specified, new stats output will be appended to 
the end of file

Best,

Yujing

From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 On Behalf Of Horn, Mitchell Jacob
Sent: Tuesday, December 12, 2023 10:10 AM
To: freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>
Subject: [Freesurfer] aparcstats2table - append option

Hi FS Devs,

Would it be possible to add an "append" flag for use with aparcstats2table and 
asegstats2table? If I understand their usage correctly, each time one of them 
are run they will create (or overwrite) a new file. Not urgent but would be 
useful.

Thanks,
Mitch
___
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
<https://www.massgeneralbrigham.org/complianceline> .


[Freesurfer] aparcstats2table - append option

2023-12-12 Thread Horn, Mitchell Jacob
Hi FS Devs,

Would it be possible to add an "append" flag for use with aparcstats2table and 
asegstats2table? If I understand their usage correctly, each time one of them 
are run they will create (or overwrite) a new file. Not urgent but would be 
useful.

Thanks,
Mitch
___
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
 .


Re: [Freesurfer] HPC Usage - Moving On from CentOS7

2023-03-31 Thread Horn, Mitchell Jacob
Hi R.,

I just made a copy of the libm.so library from 7.

Alma is the same downstream from RHEL as Rocky. Most hpc’s will be switching to 
one of these (Harvard is moving to Rocky).

Thanks,
Mitch

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of fsbuild 

Sent: Thursday, March 30, 2023 11:13:37 PM
To: freesurfer@nmr.mgh.harvard.edu 
Subject: Re: [Freesurfer] HPC Usage - Moving On from CentOS7


External Email - Use Caution

We don’t use Alma OS which I believe is somewhere downstream from the official 
RedHat CentOS8 Stream distribution, i.e., the libs may not be the same.  I also 
don’t see that RedHat CentOS8* releases include CentOS7 versions of libraries.

- R.

On Mar 30, 2023, at 12:12, Horn, Mitchell Jacob  wrote:

As an update I’ve tested another run (bert, 7.2.0, no flags, recon-all) on an 
OS-8 system but set LD_PRELOAD to the 7 system’s libm.so:

export LD_PRELOAD=/alma/cos7lib/libm.so
recon-all ….

And that produced the equivalent results of all my CentOS7 runs:



I believe this is very important information to the general community for 
stability with the imminent and inevitable switch to OS-8 HPC platforms.

Best,
Mitch
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu>
MailScanner has detected a possible fraud attempt from "secure-web.cisco.com" 
claiming to be 
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer<https://secure-web.cisco.com/1B6HYjaD58teLd8kQAFAoHcbINfWos_Odjqm1uUcjpYlXltcBY5-Pe4gnq6ErXMVdaae2vCWl159gMoIKkhC0MaUdpZiMUk0pAkXBceoZQigvnOmY17QcZ1lsOGzDOTF2GNFMtw1zh-mdp_lHPfv6WBi--IDzT-vHmRi-sgoQvOOS7sTRtXjj471Jl6u1XGY5n6PsmvLZZGN1jNj0Y5nIxgADkQZemoQ_AWmm7iNOgpQYBtEi3XvdZBJTcT4nNV55rl-BhnqIT9paMQc_0qpId-SvO5Gz2zrwcasB-TAwNybYtey2UIYjMtB9m5ARRLgJ/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer>

___
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
<https://www.massgeneralbrigham.org/complianceline> .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail. 


[Freesurfer] Neuroimaging Scientist Position - Massachusetts General Hospital, Department of Neurology

2022-12-06 Thread Horn, Mitchell Jacob
Senior Research Technologist - (3220849)

Background

The Senior Research Technologist will perform duties in structural and 
functional magnetic resonance imaging at the Massachusetts General Hospital 
Stroke Research Center and the Athinoula A. Martinos Center for Biomedical 
Imaging. The research focus of this group is brain hemorrhage, which is a major 
cause of death and disability in the United States. We seek to understand what 
determines the risk of developing a brain hemorrhage as well as the 
consequences suffered after the hemorrhage occurs. Our lab has structural and 
functional MRI analysis pipelines that have resulted in multiple scientific 
articles published in first tier peer-reviewed Neurology journals.

Responsibilities:
The position will focus on the application of structural and functional image 
analysis algorithms in the study of brain aging and neurological diseases. The 
incumbent will work independently with minimal guidance of the Principal 
Investigator(s) and/or the Director of Clinical Research Operations and will 
collaborate with research fellows, clinical research coordinators and other 
research staff.

Specific tasks may include:

  *   Independently performs non-routine, highly specialized scanning sequences 
in accordance with study-specific MRI protocols
  *   Develops research methodologies within parameters of experimental 
protocols and research objectives
  *   Works with PI(s) in determining the most suitable design and methodology 
of research imaging protocols
  *   Performs independent design and modification of protocols
  *   Transfers, organizes, and summarizes acquired data
  *   Prepares and presents research reports, manuscripts, posters or other 
documents for publication and/or presentation
  *   Performs data analyses using advanced scientific, statistical and/or 
computational techniques
  *   Responsible for troubleshooting problems and instructing others in highly 
specialized imaging and/or imaging data analysis techniques
  *   Assists with other research/imaging-related tasks as needed


Skills and competencies:

  *   Excellent interpersonal, organizational and communication skills
  *   Ability to work independently and as team member
  *   Ability to make independent, effective decisions
  *   High degree of computer literacy, including programming skills
  *   Analytical skills and ability to resolve technical problems
  *   Ability to effectively mentor and train junior research technicians
  *   Demonstrated competence in research techniques and methodologies
  *   Ability to identify problems and develop solutions
  *   Bachelor's degree required, MA preferred

Minimum Technical Standards:

  *   Experience with MATLAB is required
  *   Experience with Neuroimaging modalities (i.e., FreeSurfer, FSL, SPM) is 
strongly preferred
  *   Experience with Linux/Unix and Bash Shell Scripting is strongly preferred
  *   Proficiency in Microsoft Office is required
  *   Experience with Statistical Software (i.e., SPSS, JMP etc.) is strongly 
preferred
  *   Experience with Python is a plus
Job description for Senior Research 
Technologist
 here, or can be found by searching job number 3220849 on the MGH Careers 
portal.

___
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
 .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail. 


Re: [Freesurfer] Scalable recon workflow

2022-05-03 Thread Horn, Mitchell Jacob
Hi Paul,

Thanks for your speedy response! In that case, I assume 1GB/core is the memory 
allocation? Is it helpful to increase that?

Best,
Mitch

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Paul Wighton 

Sent: Tuesday, May 3, 2022 1:34 PM
To: Freesurfer support list 
Subject: Re: [Freesurfer] Scalable recon workflow


External Email - Use Caution

Hi Mitch,

In our experience, -openmp 8 gives faster recons than -openmp 4, but the gains 
after -openmp 8 diminish quickly and aren't worth it.

-Paul

On Tue, May 3, 2022 at 12:51 PM Horn, Mitchell Jacob 
mailto:mjh...@mgh.harvard.edu>> wrote:
Hi Experts,

If I have 100s of subjects to recon and have access to an HPC with both GPU and 
CPU options what is the recommended flags to maximize speed performance? Is … 
-parallel -openmp 4 … still the best approach? And if so, is 2GB memory/core 
best (keeping it 8GB memory/subject) or is there some better arrangement?

Best,
Mitch




___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto:Freesurfer@nmr.mgh.harvard.edu>
MailScanner has detected a possible fraud attempt from "secure-web.cisco.com" 
claiming to be 
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer<https://secure-web.cisco.com/1KwX_rLAvesnrj3sVBEmrKlInc5WVsWyRLeOP9S9eAg0OshRNiuN-Ah-YsWHXgPswXDNOuknm3WuIwW2uqT8Ifphx_C-TOwxjBeBqNgwbFZz87zgrJ2-2iGbZaVfaggfExMtQGY_r0NGX52-85cFulaPJfe_HIgruLaiqtXMlPtbqKZe782JlfYvS2yGDPs30UpkiKPUV6SKWlUrolMumbSHe3PrM-9pJfBMrYc3wieA6jitXpU3JvIYTTUhCaL2GK3ewzON3kmKGx-FgUbmkZj79FToVMWEy276qcNpNygxJFYl1L9xzBT7cdjTibKb-/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer>
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 Mass General Brigham 
Compliance HelpLine at MailScanner has detected a possible fraud attempt from 
"secure-web.cisco.com" claiming to be 
https://www.massgeneralbrigham.org/complianceline<https://secure-web.cisco.com/1WxqT2k67AYeX_6TtvedmLH3c-AlZH7neY7yJ3tCTkhZZWqH_9u9jXF3UGKrGRC6ybXdqizqBFcN0wVMw2y9SijUuXXQI0bIUE9OhJAAqbEzmgtkwgPO-bvo6Oacen2R7AiLlg9E32BiOpwvVHdqYBRCmu0Pnf8YfBv_7q_yYLDJrJ-AMhmbsDFGN6NmQGdaTpHxj8Cz9KmZ3a5l5F__k7NJXxt1eF_CjRNQwG7l_XipuoMQPvv66uR28cK2S2Qju5ODWi6_oGcnkt22cqStgroiVnovgtnxZXFRtnbKwjUXySXWwrjmXyeNn4hYV4yJg/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline>
 https://www.massgeneralbrigham.org/complianceline<https://secure-web.cisco.com/1WxqT2k67AYeX_6TtvedmLH3c-AlZH7neY7yJ3tCTkhZZWqH_9u9jXF3UGKrGRC6ybXdqizqBFcN0wVMw2y9SijUuXXQI0bIUE9OhJAAqbEzmgtkwgPO-bvo6Oacen2R7AiLlg9E32BiOpwvVHdqYBRCmu0Pnf8YfBv_7q_yYLDJrJ-AMhmbsDFGN6NmQGdaTpHxj8Cz9KmZ3a5l5F__k7NJXxt1eF_CjRNQwG7l_XipuoMQPvv66uR28cK2S2Qju5ODWi6_oGcnkt22cqStgroiVnovgtnxZXFRtnbKwjUXySXWwrjmXyeNn4hYV4yJg/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline>>
 .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted 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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
<https://www.massgeneralbrigham.org/complianceline> .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail. 


[Freesurfer] Scalable recon workflow

2022-05-03 Thread Horn, Mitchell Jacob
Hi Experts,

If I have 100s of subjects to recon and have access to an HPC with both GPU and 
CPU options what is the recommended flags to maximize speed performance? Is … 
-parallel -openmp 4 … still the best approach? And if so, is 2GB memory/core 
best (keeping it 8GB memory/subject) or is there some better arrangement?

Best,
Mitch




___
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
 .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail. 


[Freesurfer] mri_vol2surf; --projfrac-avg and --projfrac-max

2021-03-10 Thread Horn, Mitchell Jacob
Dear FS Experts,

When using --projfrac-max or --projfrac-avg, how is the “min” component 
defined? If I specify:

--projfrac-max -2 1 0.1

Is the min (-2) simply 2x the thickness at each vertex below/inside the GM/WM 
boundary?

Thanks in advance!
Mitch
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] Cerebellar Segmentation Definitions

2021-01-26 Thread Horn, Mitchell Jacob
Hi Doug,

Thanks for your reply.

Would it be safe to say that these deep grey nuclei are included in the 
cerebellar white matter?

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

[Freesurfer] Cerebellar Segmentation Definitions

2021-01-22 Thread Horn, Mitchell Jacob
Hi FS Experts,

I am planning to use the cerebellar segmentations in the routine recon-all 
which parcellates the cerebellum into cerebellar-white-matter and 
cerebellar-gray-matter. I am trying to define the two terms, as it appears that 
the cerebellar-white-matter label includes much if not all the deep-gray nuclei 
of the cerebellum (which is ideal, due to resolution and size of these 
structures).

Is there a reference I can specifically point to that details the labels and 
further the inclusion of these deep grey structures in the 
cerebellar-white-matter? I could not easily track down the correct FS white 
paper for this.

Thanks in advance,
Mitch


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

Re: [Freesurfer] vol2surf: lesion overlap across group into surfaces

2020-09-27 Thread Horn, Mitchell Jacob
Thanks again for your input! I made some output surfaces and now I have another 
question:



Instead of creating a surface image directly from of these lesion-maps, I’d 
like to try to create a “derived” cortical lesion-map. In a similar fashion to 
the mri_aparc2aseg --labelwm (but in the other direction), I’d like to apply 
the label of my native T1w lesioned white matter to that of the surrounding 
cortex (with a dmax parameter). Does something like this already exist?



My end result would be a binary mask of part of the cortex that is within some 
distance of the lesion.



My other intuition is to just dilate the lesion ROI to encompass the cortex and 
find the overlap but this method seems crude. Maybe there’s a more appropriate 
tool for this I’m not aware of?

Thanks,
Mitch

From: Greve, Douglas N.,Ph.D. 
Date: Thursday, September 10, 2020 at 12:36 PM
To: Horn, Mitchell Jacob , Freesurfer support list 

Subject: Re: [Freesurfer] vol2surf: lesion overlap across group into surfaces
The question is more for you. The lesions are not on the  surface but you want 
to display them on the surface. How do you want to do that?
ps. please remember to post to the list
On 9/10/2020 10:25 AM, Horn, Mitchell Jacob wrote:
Thanks so much Douglas.

Many of the lesions are in the white matter, and many span across WM and GM. In 
the case where the lesions on not strictly cortical, is this surface mapping 
not possible? Or perhaps a representative surface map showing the occurrences 
of lesions in any lobe/ROI?

Best,
Mitch

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

Re: [Freesurfer] vol2surf: lesion overlap across group into surfaces

2020-09-10 Thread Horn, Mitchell Jacob
Thanks so much Douglas.

Many of the lesions are in the white matter, and many span across WM and GM. In 
the case where the lesions on not strictly cortical, is this surface mapping 
not possible? Or perhaps a representative surface map showing the occurrences 
of lesions in any lobe/ROI?

Best,
Mitch

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

[Freesurfer] vol2surf: lesion overlap across group into surfaces

2020-09-09 Thread Horn, Mitchell Jacob
Dear FS Experts,



I would like to show the distribution and overlap of lesions on an average 
inflated brain surface as a heat map.



I have a 150 subjects of which I’ve made masks of T2 lesions and moved into 
their respective subject-T1w-spaces (using T1.mgz as reference) where I have 
completed recons.



What are the steps in bringing these subject-T1w-space lesions into an average 
brain and presenting them as a surface? Again, I hope to show the lesion 
distribution scaled by the number of times (out of 50 subjects) that any voxel 
is a lesion.



Thanks in advance,

Mitch

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

[Freesurfer] Lesion Correction

2020-01-10 Thread Horn, Mitchell Jacob
Hi Freesurfer Team,

I have a couple cases with large hemispheric ICH that have caused my recon to 
hit the default wall-time of 96 hours. It seems to get hung up on the 
correcting topology defects step for the affected hemisphere. My goal is to 
have the recon at least finish so I can analyze the unaffected hemisphere.

I have tried WM-edits, and just recently tried generously covering the ICH in 
the aseg.presurf with the WM-hypointensity label 77. I then submitted the recon 
to start just after the aseg.presurf generation with the following tags, < 
recon-all -autorecon2-cp -autorecon3 -subjid $subject >. However, when it gets 
to the fix topology point for the affected hemisphere, it hangs at this point 
with a huge defect as shown below:

reading brain volume from brain...
reading wm segmentation from wm...
Reading original properties of orig.nofix
Reading vertex positions of inflated.nofix
Computing Initial Surface Statistics
  -face   loglikelihood: -9.2324  (-4.6162)
  -vertex loglikelihood: -6.5360  (-3.2680)
  -normal dot loglikelihood: -3.5251  (-3.5251)
  -quad curv  loglikelihood: -6.0339  (-3.0169)
  Total Loglikelihood : -25.3274
CORRECTING DEFECT 0 (vertices=26285, convex hull=5359, v0=0)

Is there something I can do to at least skip the correction of the affected 
hemisphere?

Thanks in advance,

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