Fmriprep / Docker: Error in ‘epi_to_t1w_transform’ and ‘epi_to_mni_transform’

1

Hi fmriprep users,

We were intrigued by fmriprep and wanted to see if we can preprocess our MRI data with the pipeline. We have two runs for two tasks inside the scanner (total of 4 epi files) and a high-res structural (T1) scan.

When setting everything up on a local machine, fmriprep (implemented via docker) worked really well, but since we moved to a cluster, we have not managed to get it to run through again. The error is not limited to a specific file, and trying the same starting command on different participants made no difference, the process still threw an error and crashed.

We would greatly appreciate any pointers with the crash log, as we have not been able to localize the exact problem and fix it accordingly. The crash log indicates the problem to occur at the stage of transforming the epi image to mni/t1w, but we are not exactly sure what is (not) happening. Since everything ran fine on the local machine, the first idea is that there is some problem with the cluster, but again, we would massively appreciate your comments!

This is the command that starts fmriprep in docker (please note: I have edited out path details with ‘/…/’, but the path was properly specified)
docker run -i --rm --cpus=6 --memory=12G -v /Network/Servers/…/ML_project/data:/bidsdata:ro -v /Network/Servers/…/ML_project/BIDS_out:/outputs bids/fmriprep /bidsdata /outputs participant --participant_label 004 --no-freesurfer

This is a screenshot of the command line at the point of the first error message

error_1.png1996×926 164 KB

And finally, we extracted the error message from the crash log files: (1) epi-to-mni / (2) epi-to-t1w
(1) traits.trait_errors.TraitError: The trait 'reference_image' of an ApplyTransformsInputSpec instance is an existing file name, but the path '/root/src/fmriprep/work/fmriprep_wf/single_subject_004_wf/func_preproc_task_gambles_run_01_wf/epi_mni_trans_wf/gen_ref/1mm_T1_reference.nii.gz' does not exist.

(2) traits.trait_errors.TraitError: The trait 'reference_image' of an ApplyTransformsInputSpec instance is an existing file name, but the path '/root/src/fmriprep/work/fmriprep_wf/single_subject_004_wf/func_preproc_task_gambles_run_02_wf/epi_reg_wf/gen_ref/highres001_BrainExtractionBrain_reference.nii.gz' does not exist.

Any help with the problem and pointers towards solutions would be great!
Thanks in advance for your time!

Kind regards, Loreen

2

Seems like an issue with writing outputs to the working directory. Could you try mounting an extra directory and passing it via -w command line argument?

3

Dear Chris,

Many thanks for your quick response, much appreciated!

We did think it might be a problem along the lines you suggested, but discounted this possibility because we found quite a lot of new files were written into the specified directory prior to those specific errors occurring (both anat_out and func_out files; see image).

Screen Shot 2017-08-16 at 11.42.36.png1394×567 173 KB

So, we thought it was not a general issue with writing output to the wd. We will investigate your suggestion further, many thanks!

Best, Loreen

4

Hi Loreen,

Just to add some context, the working (or scratch) directory will generally use a lot more disk space than the output directory, since it needs to store intermediate files. If the working directory is not mounted into the Docker container, then it may face limits related to either containers or the filesystem that running Docker containers are stored on.

As an additional consideration, by using a persistent working directory, you can take advantage of caching, and reuse results over multiple runs (e.g. if you upgrade from one version of FMRIPREP to the next).

For both reasons, we generally recommend preparing a scratch directory and mounting it into the Docker container. If you use fmriprep-docker, you can easily do this with just the -w flag.

Chris

1 Like
5

Hi Chris,

Thanks for the clarification, super helpful! We will see if we can implement your suggestions - we also realised that we may be facing some restrictions because we are mounting our directories in a VM, which may impose limitations we had not considered before.

Thanks again for the helpful comments!

Best, Loreen