[BUG] Deal with multi-echo indigestion

[oesteban]

Currently, fmriprep chokes with multi-echo datasets like ds000216:

Traceback (most recent call last):
File "/usr/local/miniconda/lib/python3.6/multiprocessing/process.py", line 249, in _bootstrap
self.run()
File "/usr/local/miniconda/lib/python3.6/multiprocessing/process.py", line 93, in run
self._target(*self._args, **self._kwargs)
File "/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/cli/run.py", line 450, in build_workflow
ignore_aroma_err=opts.ignore_aroma_denoising_errors,
File "/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/workflows/base.py", line 193, in init_fmriprep_wf
ignore_aroma_err=ignore_aroma_err)
File "/usr/local/miniconda/lib/python3.6/site-packages/fmriprep/workflows/base.py", line 461, in init_single_subject_wf
'inputnode.t1_2_fsnative_reverse_transform')]),
File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/workflows.py", line 166, in connect
self._check_nodes(newnodes)
File "/usr/local/miniconda/lib/python3.6/site-packages/niworkflows/nipype/pipeline/engine/workflows.py", line 699, in _check_nodes
raise IOError('Duplicate node name "%s" found.' % node.name)
OSError: Duplicate node name "func_preproc_task_rest_wf" found.

This is derived from the fact that bold runs cannot be fully identified with only the task field:

ds000216]$ find sub-01 -name "*_bold.nii.gz"
./sub-01/func/sub-01_task-rest_echo-1_bold.nii.gz
./sub-01/func/sub-01_task-rest_echo-2_bold.nii.gz
./sub-01/func/sub-01_task-rest_echo-3_bold.nii.gz
./sub-01/func/sub-01_task-rest_echo-4_bold.nii.gz

This will probably be solved with the #921 refinement over #884. Is this right, @emdupre?

[emdupre]

Yes, that should be handled with #921 and #891 ! Sorry for the hiccup, here.

[oesteban]

Actually, this problem was present before #891. It's a design problem of fmriprep.

@chrisfilo: before multi-echo support is completely merged, how we should process these images? Each echo independently? (or break with a particular error message)?

[emdupre]

I've run #891 over ds000210 and haven't seen this, but will run over ds000216 tonight to confirm!

…

On Jan 10, 2018 16:21, "Oscar Esteban" ***@***.***> wrote: Actually, this problem was present before #891 <#891>. It's a design problem of fmriprep. @chrisfilo <https://github.com/chrisfilo>: before multi-echo support is completely merged, how we should process these images? Each echo independently? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#928 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOUk5yRgUfza61gGGAAAk8adUIphSLh7ks5tJSnGgaJpZM4RZ7qx> .

[emdupre]

So I actually am unclear about dfs000216, running it through FMRIPREP. Looking at sub-01, it seems as though the acq files and the echo files are identical. Is there a reason the same data is included twice?

[emdupre]

As a follow-up, I'm a little confused as to the BIDS filename convention for this dataset. The acq- keyword has no associated label, which is confusing the grouping scheme I suggested in #921. @chrisfilo, if you have any insight on this I'd be grateful!

[chrisgorgo]

I think I must be lacking some context. What do you mean by "acq- keyword has no associated label"?

To answer @oesteban question. I think it would make sense to treat each echo independently until the MEICA functionality is merged (which will use them together). Let me know if this works for you @emdupre.

[emdupre]

Sorry for being unclear! sub-01 of ds000216 (as pulled from datalad) has 8 scans. Four are of the form `sub-01_task-rest_echo-?_bold.nii.gz` and 4 are ` sub-01_task-rest_acq-echo-?_bold.nii.gz`. My confusion is (1) that the content of these files seems identical for identical echoes and (2) that no label exists after the `acq-` keyword such as `acq-singleband` (the example given in the spec). I'd expect `echo` as a keyword to be preceded by an underscore. Please let me know if that provides appropriate clarification!

…

On Jan 10, 2018 23:05, "Chris Filo Gorgolewski" ***@***.***> wrote: I think I must be lacking some context. What do you mean by "acq- keyword has no associated label"? To answer @oesteban <https://github.com/oesteban> question. I think it would make sense to treat each echo independently until the MEICA functionality is merged (which will use them together). Let me know if this works for you @emdupre <https://github.com/emdupre>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#928 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOUk5wKGug_YT6IYD_OCZf0HEPyeXPfJks5tJYhtgaJpZM4RZ7qx> .

[chrisgorgo]

This seems to be an issue with datalad (@yarikoptic). I only see 4 scans on OpenfMRI https://openfmri.org/s3-browser/?prefix=ds000216/ds000216_R1.0.1/uncompressed/sub-01/func/

[emdupre]

I opened an issue at datalad/datalad#2069 which @yarikoptic addressed with stunning efficiency. Thank you !!

@oesteban, with #921 and #891 I'm able to run FMRIPREP with no errors-- the report it generates is linked here: https://www.dropbox.com/sh/ip6xpd6oc5awnbm/AADp92KIKev9h6Yb8fIZsYu7a?dl=0