What happened?

The midthickness step of fmriprep takes much longer when the thread count OMP_THREADS is set high >=8. It actually finishes faster at low threads. This isnt a bug per se but when you reduce the threads for mris_expand it causes other long steps like antsRegistration to also use that low thread count, which makes them slow. Would it be possible to specifically restrict mris_expand to use say 1 thread?

Is another option to manually run the mris_expand command in the Freesurfer directories and have fmriprep pick up those outputs?

Thanks in advance.

What command did you use?

singularity run \
    --cleanenv \
    -B $HOME/fj49_scratch/oyeg/02_JDFI/templateflow:/templates \
    -B ${bids_dir_30}:/bids_dir:ro \
    -B ${output_dir_aroma}:/output_dir \
    -B ${work_dir_aroma}:/work \
    -B ${license}/license.txt:/opt/freesurfer/license.txt \
    fmriprep-25.0.0.sif \
    /bids_dir /output_dir participant \
    -w /work \
    --participant-label ${subj} \
    --output-spaces T1w func fsnative MNI152NLin2009cAsym fsaverage MNI152NLin6Asym MNI152NLin6Asym:res-2 \
    --nthreads $NUMTHREADS \
    --omp-nthreads 12 \
    --fs-license-file /opt/freesurfer/license.txt \
    --skip_bids_validation \
    --ignore t2w flair slicetiming \
    --fs-no-resume \
    --cifti-output \
    --notrack -v

What version of fMRIPrep are you running?

25.0.0

How are you running fMRIPrep?

Singularity

Is your data BIDS valid?

Yes

Are you reusing any previously computed results?

No

Please copy and paste any relevant log output.

It doesnt crash, it's just super slow.

Additional information / screenshots

No response