fmriprep: Fieldmaps causing fMRIprep to get crash

What happened?

I’m currently working with unprocessed 3T MRI and fMRI data from the human connectome project. I’m using:

• T1w scan, with corresponding ‘phasediff’, ‘magnitude1’, and ‘magnitude2’ fieldmaps
• T2w scan, with corresponding ‘phasediff’, ‘magnitude1’, and ‘magnitude2’ fieldmaps
• Four functional task runs, each with corresponding RL and LR epi spin echo fieldmaps (two opposite phase encoding directions for each run). Each also has a corresponding SBRef scan.

The dataset comes up as totally fine on the BIDS validator, and when I run fMRIPrep with the fieldmaps removed from the directory, everything works perfectly. If I try again with the fieldmaps returned to their ‘fmap’ subdirectory, the job appears to crash before fMRIPrep even starts running. By looking at my other log files, the step it’s getting stuck on normally takes 20 seconds on so, and the next step should be acknowledging any fieldmaps/SBRef files available for each functional run.

Between successful runs and my unsuccessful ones with fieldmaps, nothing in the script has changed, just the presence of fmap files in the BIDS directory. Clearly something in the fieldmaps is causing things to stick here but I’m not sure what it is. Does fMRIPrep expect some specific BIDS-compatible naming convention or sidecar information that I might be missing? I’ve provided all the available metadata I can find, as shown here:

Example NIFTI filename: ‘sub-100307_acq-EmotionLR_dir-LR_epi.nii.gz’

Example JSON metadata: {“IntendedFor”: “bids::sub-100307/func/sub-100307_task-Emotion_dir-LR_bold.nii.gz”, “Manufacturer”: “Siemens”, “ManufacturersModelName”: “Connectome Skyra”, “MagneticFieldStrength”: 3, “ReceiveCoilName”: “Standard 32-Channel Siemens Receive Head Coil”, “ReceiveCoilActiveElements”: “HEA;HEP”, “PulseSequenceType”: “Spin Echo Field Map”, “NonlinearGradientCorrection”: “false”, “MRAcquisitionType”: “2D”, “MTState”: “false”, “EffectiveEchoSpacing”: 0.00058, “EchoTime”: 0.058, “FlipAngle”: 90, “MultibandAccelerationFactor”: 1, “TaskName”: “Emotion”, “RepetitionTime”: 7.06, “TotalReadoutTime”: 0.08346, “B0FieldIdentifier”: “EmotionLR_bold_fmap”, “PhaseEncodingDirection”: “i”}

Or is it possible this might be a memory issue, not related to fMRIPrep itself?

Any advice would be really appreciated!

Nick

What command did you use?

singularity run --cleanenv \
    -B ${DATA_DIR}:/data \
    -B ${OUT_DIR}/:/out \
    -B ${SCRATCH_DIR}:/wd \
    -B ${LICENSE}:/license \
    /research/cisc2/shared/fmriprep_singularity/fmriprep_22.1.1.simg \
    --skip_bids_validation \
    --participant-label ${SUBJECT} \
    --omp-nthreads 1 --nthreads 5 --mem_mb 30000 \
    --output-spaces MNI152NLin6Asym:res-2 MNI152NLin2009cAsym fsaverage T1w fsLR:den-32k \
    --fs-license-file /license \
    --work-dir /wd \
    --cifti-output 91k \
    --ignore slicetiming \
    --track-carbon \
    --country-code GBR \
    --random-seed 1234 \
    --skull-strip-fixed-seed \
    --clean-workdir \
    /data /out/ participant

What version of fMRIPrep are you running?

22.1.1.

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.

Number of subjects = 1
This is the task id 1
this is i 0
sub-100307
230210-14:37:04,973 nipype.workflow IMPORTANT:
	 CodeCarbon tracker started ...
230210-14:37:04,974 nipype.workflow IMPORTANT:
	 Using country_iso_code: GBR
230210-14:37:04,974 nipype.workflow IMPORTANT:
	 Saving logs at: /out/logs
230210-14:37:18,647 nipype.workflow IMPORTANT:
	 Running fMRIPrep version 22.1.1

         License NOTICE ##################################################
         fMRIPrep 22.1.1
         Copyright 2022 The NiPreps Developers.
         
         This product includes software developed by
         the NiPreps Community (https://nipreps.org/).
         
         Portions of this software were developed at the Department of
         Psychology at Stanford University, Stanford, CA, US.
         
         This software redistributes the versioneer Python package, which is
         Public domain source code.
         
         This software is also distributed as a Docker container image.
         The bootstraping file for the image ("Dockerfile") is licensed
         under the MIT License.
         
         This software may be distributed through an add-on package called
         "Docker Wrapper" that is under the BSD 3-clause License.
         #################################################################
230210-14:37:18,723 nipype.workflow IMPORTANT:
	 Building fMRIPrep's workflow:
           * BIDS dataset path: /data.
           * Participant list: ['100307'].
           * Run identifier: 20230210-143658_66b8c928-cdde-44a9-a44b-3822885560c3.
           * Output spaces: MNI152NLin6Asym:res-2 MNI152NLin2009cAsym:res-native fsaverage:den-164k T1w fsLR:den-32k.
           * Pre-run FreeSurfer's SUBJECTS_DIR: /out/sourcedata/freesurfer.
Done

Additional information / screenshots

My BIDS filetree:

| dataset_description.json | participants.json | participants.tsv | README.txt |
-–sub-100307 ±–anat | sub-100307_T1w.json | sub-100307_T1w.nii.gz | sub-100307_T2w.json | sub-100307_T2w.nii.gz |
±–fmap | sub-100307_acq-EmotionLR_dir-LR_epi.json | sub-100307_acq-EmotionLR_dir-LR_epi.nii.gz | sub-100307_acq-EmotionLR_dir-RL_epi.json | sub-100307_acq-EmotionLR_dir-RL_epi.nii.gz | sub-100307_acq-EmotionRL_dir-LR_epi.json | sub-100307_acq-EmotionRL_dir-LR_epi.nii.gz | sub-100307_acq-EmotionRL_dir-RL_epi.json | sub-100307_acq-EmotionRL_dir-RL_epi.nii.gz | sub-100307_acq-MotorLR_dir-LR_epi.json | sub-100307_acq-MotorLR_dir-LR_epi.nii.gz | sub-100307_acq-MotorLR_dir-RL_epi.json | sub-100307_acq-MotorLR_dir-RL_epi.nii.gz | sub-100307_acq-MotorRL_dir-LR_epi.json | sub-100307_acq-MotorRL_dir-LR_epi.nii.gz | sub-100307_acq-MotorRL_dir-RL_epi.json | sub-100307_acq-MotorRL_dir-RL_epi.nii.gz | sub-100307_acq-T1w_magnitude1.nii.gz | sub-100307_acq-T1w_magnitude2.nii.gz | sub-100307_acq-T1w_phasediff.json | sub-100307_acq-T1w_phasediff.nii.gz | sub-100307_acq-T2w_magnitude1.nii.gz | sub-100307_acq-T2w_magnitude2.nii.gz | sub-100307_acq-T2w_phasediff.json | sub-100307_acq-T2w_phasediff.nii.gz |
-–func sub-100307_task-Emotion_dir-LR_bold.json sub-100307_task-Emotion_dir-LR_bold.nii.gz sub-100307_task-Emotion_dir-LR_events.tsv sub-100307_task-Emotion_dir-LR_sbref.json sub-100307_task-Emotion_dir-LR_sbref.nii.gz sub-100307_task-Emotion_dir-RL_bold.json sub-100307_task-Emotion_dir-RL_bold.nii.gz sub-100307_task-Emotion_dir-RL_events.tsv sub-100307_task-Emotion_dir-RL_sbref.json sub-100307_task-Emotion_dir-RL_sbref.nii.gz sub-100307_task-Motor_dir-LR_bold.json sub-100307_task-Motor_dir-LR_bold.nii.gz sub-100307_task-Motor_dir-LR_events.tsv sub-100307_task-Motor_dir-LR_sbref.json sub-100307_task-Motor_dir-LR_sbref.nii.gz sub-100307_task-Motor_dir-RL_bold.json sub-100307_task-Motor_dir-RL_bold.nii.gz sub-100307_task-Motor_dir-RL_events.tsv sub-100307_task-Motor_dir-RL_sbref.json sub-100307_task-Motor_dir-RL_sbref.nii.gz

No response