Part of pre-run FreeSurfer not seen by fMRIPrep

khat · January 30, 2023, 7:32pm

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

Version:

fMRIPrep, version 21.0.2, Freesurfer version 7.1.1

Environment (Docker, Singularity, custom installation):

Singularity

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”

effigies · January 30, 2023, 9:16pm

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:

github.com

nipy/nipype/blob/28d424f5dda3a23b01227379d91a825b0932efae/nipype/interfaces/freesurfer/preprocess.py#L1072-L1443

      
        
            # Steps are based off of the recon-all tables [0,1] describing, inputs,
            # commands, and outputs of each step of the recon-all process,
            # controlled by flags.
            #
            # Each step is a 3-tuple containing (flag, [outputs], [inputs])
            # A step is considered complete if all of its outputs exist and are newer
            # than the inputs. An empty input list indicates input mtimes will not
            # be checked. This may need updating, if users are working with manually
            # edited files.
            #
            # [0] https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllTableStableV5.3
            # [1] https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllTableStableV6.0
            # [2] https://surfer.nmr.mgh.harvard.edu/fswiki/ReconAllTableStableV6.0#ReconAllTableStable7.1.1
            _autorecon1_steps = [
                ("motioncor", ["mri/rawavg.mgz", "mri/orig.mgz"], []),
                (
                    "talairach",
                    [
                        "mri/orig_nu.mgz",
                        "mri/transforms/talairach.auto.xfm",

This file has been truncated. show original

khat · February 1, 2023, 3:13pm

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?