fmriprep: Sophisticated PEPOLAR schemes are unsupported
What happened?
Dear fmriprep team,
Thanks for the update! I am looking forward to testing the changes! (also see https://twitter.com/DalenbergJr/status/1471392667481300994).
I have PA AP scans but PEPOLAR is not working in v21 while it ran in 20.2.5.
The console output tells me: “Sophisticated PEPOLAR schemes are unsupported” but I do not understand why it’s “sophisticated”. It’s a regular PA vs AP setup.
I am looking forward to use this implementation because the previous PEPOLAR implementation failed on half my multi-echo data set and I had to use syn-sdc (and sometimes even had to remove phase encoding direction info) to get the distortion correction right.
-Jelle
What command did you use?
docker run -ti --rm \
-v /share/nemo/data/source/neuroimaging/MRI/test/:/data:ro \
-v /share/nemo/data/derivatives/MRI/test/:/out \
-v /home/data/software/freesurfer/license.txt:/opt/freesurfer/license.txt \
-v /home/data/tmp/scratch/:/scratch \
nipreps/fmriprep:21.0.0 /data /out participant --participant-label sub-p1197 \
--fs-no-reconall --nprocs 6 --fs-license-file /opt/freesurfer/license.txt -t hands2 -w /scratch
What version of fMRIPrep are you running?
21.0.0
How are you running fMRIPrep?
Docker
Is your data BIDS valid?
Yes
Are you reusing any previously computed results?
No
Please copy and paste any relevant log output.
Setting-up fieldmap "auto_00000" (EstimatorType.PEPOLAR) with <sub-p1197_dir-PA_run-1_epi.nii.gz, sub-p1197_task-rest1_echo-1_bold.nii.gz, sub-p1197_task-rest1_echo-2_bold.nii.gz, sub-p1197_task-rest1_echo-3_bold.nii.gz, sub-p1197_task-hands1_echo-1_bold.nii.gz, sub-p1197_task-hands1_echo-2_bold.nii.gz, sub-p1197_task-hands1_echo-3_bold.nii.gz>
Process Process-2:
Traceback (most recent call last):
File "/opt/conda/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
self.run()
File "/opt/conda/lib/python3.8/multiprocessing/process.py", line 108, in run
self._target(*self._args, **self._kwargs)
File "/opt/conda/lib/python3.8/site-packages/fmriprep/cli/workflow.py", line 118, in build_workflow
retval["workflow"] = init_fmriprep_wf()
File "/opt/conda/lib/python3.8/site-packages/fmriprep/workflows/base.py", line 85, in init_fmriprep_wf
single_subject_wf = init_single_subject_wf(subject_id)
File "/opt/conda/lib/python3.8/site-packages/fmriprep/workflows/base.py", line 452, in init_single_subject_wf
raise NotImplementedError(
NotImplementedError: Sophisticated PEPOLAR schemes are unsupported.
Additional information / screenshots
If you need more info, let me know!
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 24 (11 by maintainers)
21.0.1 is released.
Hi, thanks for following up! We had a call about this this morning, and are going to do two things:
IntendedFor
to make sure that users can get that behavior, if they desire. (Long-term, probably 21.0.1 or 21.0.2.)Case 1: Blip-up/blip-down fieldmaps + BOLD file
In this case, both
sub-01_dir-AP_epi.json
andsub-01_dir-PA_epi.json
would include something likeand
sub-01_task-rest_dir-PA_bold.json
would includeCase 2: BOLD file + reverse-blip fieldmap
To achieve the expected result where the first few volumes of BOLD are combined with the EPI to estimate the fieldmap, then we need to add
B0FieldIdentifier
to bothsub-01_dir-AP_epi.json
andsub-01_task-rest_dir-PA_bold.json
:so
sub-01_task-rest_dir-PA_bold.json
would look includeCase 3: Independently correcting multiple BOLD files with one reverse-blip fieldmap (Legacy behavior)
Because we’re independently correcting, we need to use multiple identifiers for
sub-01_dir-AP_epi.json
:And then each BOLD file would include itself as part of one of these identifiers:
Case 4: Estimating a single fieldmap for all BOLD files, with one reverse-blip fieldmap
In this case, we can use the first volumes of all PA BOLD runs to find a single fieldmap that we will use to correct all BOLD runs. In this case, we would use a single identifier for
sub-01_dir-AP_epi.json
:And then each BOLD file would include itself as part of this identifier and be corrected by that identifier
Note that these might produce errors, we haven’t really tested these cases yet. But we’ve agreed (please check the above @oesteban) that we should be supporting these cases.