Can you try it with -threads instead? We don't typically use -parallel

On 2/23/2024 2:44 PM, Horn, Mitchell Jacob wrote:

This is all with ‘recon-all -parallel’

Thanks,

Mitch

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

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

*From:*freesurfer-boun...@nmr.mgh.harvard.edu <freesurfer-boun...@nmr.mgh.harvard.edu> *On Behalf Of *Horn, Mitchell Jacob
*Sent:* Friday, February 23, 2024 12:28 PM
*To:* Freesurfer support list <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 <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

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

Reply via email to