Part of pre-run FreeSurfer not seen by fMRIPrep

Summary of what happened:

Hi all. I run the fMRIPrep, version 21.0.2, on the pre-run and manually corrected Freesurfer data, version 7.1.1. When looking at the reports I noticed that for half of my participants their report says “FreeSurfer reconstruction: Run by fMRIPrep”, while for the rest of them the freesurfer input was correctly detected. I did some tests on a couple of participants and I got the impression that for those that have the “Run by fMRIPrep” text, it’s mainly the autorecon3 that was repeated. However, I’m not sure whether I can be sure of that, and I’d like to make sure fMRIPrep uses the correct GM and WM segmentations.
Unfortunately, as I’m dependent on some other sites and research requirements, updating to the newer version of fMRIPrep is impossible in my case, as well as using an older version of the freesurfer.

Command used (and if a helper script was used, a link to the helper script or the command generated):

while read subject;
do singularity run --cleanenv -B /mnt/nasips2/kasia/rest:/data,/home/katarzyna/Documents:/fs \
/home/katarzyna/Documents/fmriprep-21.0.2.simg/ /data /data/derivatives participant \
--participant-label $subject -t rest --work-dir ${HOME}/workdir \
--fs-license-file /fs/license.txt \
--output-spaces anat MNI152NLin2009cAsym:res-2 fsaverage:den-10k \
-v --notrack --ignore slicetiming --cifti-output --md-only-boilerplate \
--stop-on-first-crash --use-aroma
done < $1


fMRIPrep, version 21.0.2, Freesurfer version 7.1.1

Environment (Docker, Singularity, custom installation):


Data formatted according to a validatable standard? Please provide the output of the validator:

Relevant log outputs (up to 20 lines):

resume recon-all : recon-all -all -noskullstrip -subjid sub-13227 -sd /data/derivatives/sourcedata/freesurfer -nomotioncor -notalairach -nonuintensitycor -nonormalization -nogcareg -nocanorm -nocareg -nocalabel -nonormalization2 -nomaskbfs -nosegmentation -nofill -notessellate -nosmooth1 -noinflate1 -noqsphere -nofix -nowhite -nosmooth2 -noinflate2 -nocurvHK -nocurvstats -nosphere -nosurfreg -nojacobian_white -noavgcurv -nocortparc -nopial -noparcstats -nocortparc2 -noparcstats2 -nocortparc3 -noparcstats3 -nopctsurfcon -nocortribbon -nohyporelabel -noaparc2aseg -nosegstats -nowmparc -nobalabels
221221-15:54:36,102 nipype.workflow INFO:
[Node] Finished


resume recon-all : recon-all -autorecon3 -openmp 8 -subjid sub-13227 -sd /data/derivatives/sourcedata/freesurfer -nosphere -nosurfreg -nojacobian_white -noavgcurv -nocortparc -nopial -noparcstats -nocortparc2 -noparcstats2 -nocortparc3 -noparcstats3 -nopctsurfcon -nocortribbon -nohyporelabel -noaparc2aseg -nosegstats -nowmparc -nobalabels
221221-16:06:05,681 nipype.workflow INFO:
[Node] Running “autorecon3” (“smriprep.interfaces.freesurfer.ReconAll”), a CommandLine Interface with command:
recon-all -autorecon3 -openmp 8 -subjid sub-13227 -sd /data/derivatives/sourcedata/freesurfer -nosphere -nosurfreg -nojacobian_white -noavgcurv -nocortparc -nopial -noparcstats -nocortparc2 -noparcstats2 -nocortparc3 -noparcstats3 -nopctsurfcon -nocortribbon -nohyporelabel -noaparc2aseg -nosegstats -nowmparc -nobalabels
221221-16:06:05,682 nipype.interface INFO:
resume recon-all : recon-all -autorecon3 -openmp 8 -subjid sub-13227 -sd /data/derivatives/sourcedata/freesurfer -nosphere -nosurfreg -nojacobian_white -noavgcurv -nocortparc -nopial -noparcstats -nocortparc2 -noparcstats2 -nocortparc3 -noparcstats3 -nopctsurfcon -nocortribbon -nohyporelabel -noaparc2aseg -nosegstats -nowmparc -nobalabels

Other occurrences of the recon-all in the log: “recon-all: nothing to do” or “recon-all complete : Not running

Yes, that’s a known issue: autorecon3 always rerun · Issue #307 · nipreps/smriprep · GitHub

My experience is that it adds effectively no runtime, so it hasn’t been high priority for me to look into, but I’d be happy to review a pull request. This would involve updating the dependency table in nipype:

I see, thanks for the quick reply. In this case, can I assume the manual corrections done on WM/GM are correctly taken as input, given (if I understand correctly) they’re normally processed before the autorecon3? Do you know if I can safely assume that the final output is the same then, even knowing by definition these operations were done in different Freesurfer versions? Also, is this bug so well established that if I’m sure the fmriprep has access to the inputs, then it’s rerunning only this part? Or shall I rerun all the participants with the “Run by fMRIPrep” report and double-check their logs?