Sophisticated PEPOLAR schemes are unsupported.

[zugmana]

What happened?

Hi all,

I'm trying to process multi-echo fMRI data for our lab using fmriprep, but the results when using versions 20.X are distorted when using fieldmaps. I've been following the discussion on #2210 and saw the recent suggestion of using the more recent unstable version. I've tried that today but I've encountered the following error.

Are there any plans to implement a solution or a current workaround for this? We are using fmriprep on multiple projects and a solution to this issue would be really helpful since we can’t wait too long before preprocessing our data.

Thank you,

p.s.: This issue is related to the same data referred in nipreps/sdcflows#227 I had previously posted the jsons file there.

What command did you use?

fmriprep BIDS/ temp/ participant --participant-label s22686

What version of fMRIPrep are you running?

unstable

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.

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 451, in init_single_subject_wf
    raise NotImplementedError(
NotImplementedError: Sophisticated PEPOLAR schemes are unsupported.

Additional information / screenshots

No response

[oesteban]

Hi @zugmana thanks for reporting this.

Fieldmap support before 21.0 was limited in many ways, and for that reason, we are trying to make a more comprehensive coverage of susceptibility distortions estimation & correction on 21.0.

However, there was a lot of ground to cover, and we started with the most common cases.

This error is complaining that fMRIPrep does not have enough information to set up an estimation strategy. It occurs to me that you can help fMRIPrep out by leveraging the experimental new B0 identifiers of BIDS (https://bids-specification.readthedocs.io/en/latest/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#echo-planar-imaging-and-b0-mapping).

If you correctly set the same B0FieldIdentifier of all EPI blips that must be used together to reconstruct the fieldmap, it may the case that fMRIPrep can actually set it up.

This is an experimental feature, so please don't raise your expectations too much. Please, don't forget to report your experience back, in either case, whether it worked or not.

Thanks much!

[zugmana]

Hi @oesteban,
Thanks for your reply.
I did include the B0FieldIdentifier, however fMRIPrep finished with errors.
The error on the report page is pasted below. Let me know if there's any additional testing I can do.

Best,

File: /lscratch/27036161/sXXXX.out/sub-sXXXX/log/20211118-113745_0052781f-156a-498a-a08e-5645cbf942ce/crash-20211118-130638-zugmana2-fix_coeff-2904d37b-1cf6-475f-b3f2-86c55183a407.txt
Working Directory: /lscratch/27036161/sXXXX.wrk/fmriprep_wf/single_subject_sXXXX_wf/fmap_preproc_wf/wf_ME_REST/fix_coeff
Inputs:

    fmap_ref: /lscratch/27036161/sXXXX.wrk/fmriprep_wf/single_subject_sXXXX_wf/fmap_preproc_wf/wf_ME_REST/flatten/sub-sXXXX_ses-1_dir-opposite_epi_idx-000.nii.gz
    in_coeff: ['/lscratch/27036161/sXXXX.wrk/fmriprep_wf/single_subject_sXXXX_wf/fmap_preproc_wf/wf_ME_REST/topup/sub-sXXXX_ses-1_dir-opposite_epi_idx-000_merged_base_fieldcoef.nii.gz']
    pe_dir: j-

Traceback (most recent call last):
  File "/opt/conda/lib/python3.8/site-packages/nipype/pipeline/plugins/multiproc.py", line 344, in _send_procs_to_workers
    self.procs[jobid].run(updatehash=updatehash)
  File "/opt/conda/lib/python3.8/site-packages/nipype/pipeline/engine/nodes.py", line 516, in run
    result = self._run_interface(execute=True)
  File "/opt/conda/lib/python3.8/site-packages/nipype/pipeline/engine/nodes.py", line 635, in _run_interface
    return self._run_command(execute)
  File "/opt/conda/lib/python3.8/site-packages/nipype/pipeline/engine/nodes.py", line 741, in _run_command
    result = self._interface.run(cwd=outdir)
  File "/opt/conda/lib/python3.8/site-packages/nipype/interfaces/base/core.py", line 428, in run
    runtime = self._run_interface(runtime)
  File "/opt/conda/lib/python3.8/site-packages/sdcflows/interfaces/bspline.py", line 420, in _run_interface
    self._results["out_coeff"] = [
  File "/opt/conda/lib/python3.8/site-packages/sdcflows/interfaces/bspline.py", line 422, in 
    _fix_topup_fieldcoeff(
  File "/opt/conda/lib/python3.8/site-packages/sdcflows/interfaces/bspline.py", line 480, in _fix_topup_fieldcoeff
    raise ValueError(
ValueError: Shape of coefficients file [64 64 34] does not meet the expectation given the reference's shape [64 64 34].

[oesteban]

@zugmana - we've pushed nipreps/fmriprep:pepolar-2628 to dockerhub. Could you try with this new image?

EDIT: In addition, since the original issue has been fixed, let's follow up on this secondary problem on nipreps/sdcflows#250.

[Shotgunosine]

I've run into this error as well with a dataset in which I inadvertently omitted the IntendedFor tags on our field maps. I've corrected the jsons and I'll retry with nipreps/fmriprep:pepolar-2628.

[Shotgunosine]

This runs without error and seems to produce nicely corrected images from multiecho sequences for me. I was slightly confused by having the B0 field mapping section of the report completely separate from the task section, but other than this, it was fine.

[oesteban]

@Shotgunosine thanks much! If you want to have a more precise handling of fieldmaps, please see the proposed new release of the BIDS specs - https://bids-specification.readthedocs.io/en/latest/04-modality-specific-files/01-magnetic-resonance-imaging-data.html#echo-planar-imaging-and-b0-mapping

[Shotgunosine]

Double checking just now, it looks like I made a mistake and hadn't actually updated the IntendedFor tags, but nipreps/fmriprep:pepolar-2628 appears to have worked anyway. I'm going to test again with IntendedFor tags and see if that changes anything.

[Shotgunosine]

@oesteban, so I've run things with the IntendedFor tags and they're definitely different that what I got without the IntendedFor tags. Screenshots don't really convey the difference especially well, but they're attached. In this case for a multi-echo rest sequence it looks like it worked better without the intended for tags.
With IntendedFor tags

Without IntendedFor tags

But on this subject for a single echo task sequence it looks like it worked better with the intended for tags.
With IntendedFor tags

Without IntendedFor tags

[Shotgunosine]

Ah, sorry, I was overestimating the logic, if there was no IntendedFor tag, the field maps are calculated, but not applied. As to why the fieldmap seems not to have helped in one case, that's probably a more techincal question about that specific scan and fieldmap pair.

[oesteban]

Ah, sorry, I was overestimating the logic, if there was no IntendedFor tag, the field maps are calculated, but not applied. As to why the fieldmap seems not to have helped in one case, that's probably a more techincal question about that specific scan and fieldmap pair.

This makes sense :)

However, when I gave you the link to the latest BIDS spec, I meant that you had a look into the new B0FieldIdentifier/B0FieldSource pair.

That will allow you, for instance, to pull all the EPI blips together to calculate only one fieldmap (hopefully, more reliably as you are pulling in more data). Then, instead of pointing at the BOLD targets a fieldmap can correct, B0FieldSource has the opposed logic of IntendedFor. In this case, from the BOLD scan metadata you point at the fieldmap identifier(s) that should be used to correct the BOLD scan.

[Shotgunosine]

I saw those identifiers, but I didn't understand that there would be any difference in functionality. I've i've got a blip up and blip down that both say they're intended for the same scans, don't they both get used to calculate the fieldmap? What is the difference between this and the B0FieldIdentifier/B0FieldSource pair?

[Shotgunosine]

For what its worth, it appears that even without IntendedFor the blips were being appropriately combined:

{
  "AnatomicalReference": "sub-20900_ses-v1_acq-rest_run-1_fmapid-auto00000_desc-epi_fieldmap.nii.gz",
  "AssociatedCoefficients": [
    "sub-20900_ses-v1_acq-rest_run-1_fmapid-auto00000_desc-coeff_fieldmap.nii.gz"
  ],
  "B0FieldIdentifier": "auto_00000",
  "IntendedFor": [],
  "RawSources": [
    "/data/MBDU/mid_share/data/bids_defaced/sub-20900/ses-v1/fmap/sub-20900_ses-v1_acq-rest_dir-match_run-1_epi.nii.gz",
    "/data/MBDU/mid_share/data/bids_defaced/sub-20900/ses-v1/fmap/sub-20900_ses-v1_acq-rest_dir-opp_run-1_epi.nii.gz"
  ],
  "Units": "Hz"
}

Or is there something I'm missing?

[oesteban]

It seems you only have two blips intended for all bold runs, so yes, in your case the new feature doesn't add anything. I thought you had several fieldmaps per subject.

…

On Tue, Dec 14, 2021, 18:33 Dylan Nielson ***@***.***> wrote: For what its worth, it appears that even without IntendedFor the blips were being appropriately combined: { "AnatomicalReference": "sub-20900_ses-v1_acq-rest_run-1_fmapid-auto00000_desc-epi_fieldmap.nii.gz", "AssociatedCoefficients": [ "sub-20900_ses-v1_acq-rest_run-1_fmapid-auto00000_desc-coeff_fieldmap.nii.gz" ], "B0FieldIdentifier": "auto_00000", "IntendedFor": [], "RawSources": [ "/data/MBDU/mid_share/data/bids_defaced/sub-20900/ses-v1/fmap/sub-20900_ses-v1_acq-rest_dir-match_run-1_epi.nii.gz", "/data/MBDU/mid_share/data/bids_defaced/sub-20900/ses-v1/fmap/sub-20900_ses-v1_acq-rest_dir-opp_run-1_epi.nii.gz" ], "Units": "Hz" } Or is there something I'm missing? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2628 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESDRXHJBOMH4BI76Z5EITUQ55X3ANCNFSM5IE7S45A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.