--force-syn error FMRIPREP 1.5.7

Dear FMRIPREP experts,

I have been trying out the pipeline on a couple of subjects, and had no issues with version 1.5.5.

After upgrading to 1.5.7, the -force-syn workflow is giving this error on completion:

could not run node: fmriprep_wf.single_subject_xxx_wf.func_preproc_task_rest_wf.syn_unwarp_report_wf.map_seg
fMRIPrep failed: Workflow did not execute cleanly. Check log for details

This is what I see in the log file:

ValueError: FixHeaderApplyTransforms requires a value for input ‘reference_image’. For a list of required inputs, see FixHeaderApplyTransforms.help()

I am running the pipeline with a phasediff fieldmap for SDC, but would like to have the anatomical based correction as well (using the --force-syn flag). How can I get this to work?

Thanks in advance,

Hi @nicdc, @dorianps,

Thanks a lot for catching this. We’ve tracked down the bug, and will issue a bug-fix release when it’s resolved.

If either of you is using Docker, you could help us verify the fix works for your dataset.


Fixing in:

@effigies thank you. I use docker/singularity and can easily check the fix.

The strange thing is that I had a few subjects that succeeded, but I am not sure why some finished without error and some not. Is this related to some BOLD scans not having fields maps or anything like that? I am asking because the presence of this error may prompt us to do more checks on the raw data.

It may be related to some subjects having fieldmaps. There are a couple points of subtle logic where the treatment will be slightly different depending on whether you have fieldmaps, whether you ignore fieldmaps, and whether you use --use-syn-sdc and/or --force-syn. I’m proposing changes that will make the cases where fieldmaps are missing or ignored equivalent, and in those cases, both --use-syn-sdc and --force-syn will be equivalent.

@dorianps @nicdc: You can try the poldracklab/fmriprep:fix_force_syn image. Also testing it locally, but might not get back to this before morning, so if you have some minutes to try it, go for it.

While working out any kinks, it might be easier to continue this conversation on https://github.com/poldracklab/fmriprep/pull/1951.

@effigies thanks for the quick and efficient support!

@dorianps if you could check it, that would be great! I’m not sure how to access a pre-release version - I tried pulling the latest version but that didn’t work.

Just to be certain, is the error only with the generation of the report of the --force-syn workflow, or would the fieldmap correction itself be incomplete or unreliable? In other words, do I need to reprocess everything?

Thanks again,

I put a case to test, will report tomorrow if it’s fixed. Fyi, I did not delete the work folder for the subject, so it is not a fully fresh run.

@effigies If this works I’d like to use 1.5.8 as an official container to save with the data rather than the temporary tag. Are you pushing 1.5.8 soon?

Thank you.

Yes, if this works for you, we’ll release 1.5.8 tomorrow.

The failure does not appear anymore, my test subject finished without errors this time. Looking forward for 1.5.8 tag in dockerhub.

Thanks for the quick fix @effigies.

1.5.8 has been pushed to DockerHub.

1 Like

Fantastic, thank you.

@effigies A follow up question. I plan to keep the container image with the processed data. So far I have processed different subjects with 1.5.5, 1.5.7 and 1.5.8. Is it OK to assume that nothing is different in terms of outputs or processes, except the bug fixes, from 1.5.5 to 1.5.8, so I can perhaps drop the older containers to save 10Gb of storage?

Thank you.

Yes. The only changes from 1.5.5 to 1.5.8 are those necessary to effect the bug fixes listed in the changelog.

If you still have the working directories, it might nonetheless be worth re-running on the subjects run with 1.5.5 and 1.5.7, for that extra bit of assurance of consistency.

Yes, sure, I rerun anyone who has crash logs until every subject is error free. Work folders are kept if singularity exits with an error code, so I do have work folders for all error cases (~100Gb per subject :slight_smile: ).