Fmriprep: [ME-EPI] Confirm that MELODIC is run on the optimally combined echo

[oesteban]

This is step 0 to address #2153.

[oesteban]

@emdupre or @tsalo, can I assign this one to either one of you? What is your bandwidth looking at releasing a 20.1.2 soon-ish?

[tsalo]

It seems like AROMA takes its BOLD inputs directly from bold_std_trans_wf:

https://github.com/poldracklab/fmriprep/blob/50e6dc739be3d67bf63ab7418eb80738fde7d59b/fmriprep/workflows/bold/base.py#L724-L727

And bold_std_trans_wf gets _its_ BOLD input from bold_t2s_wf, via a BOLD splitter, for multi-echo data.

https://github.com/poldracklab/fmriprep/blob/50e6dc739be3d67bf63ab7418eb80738fde7d59b/fmriprep/workflows/bold/base.py#L649-L662

[tsalo]

Sorry, I was compiling that when you commented. I'm willing to look into this.

[emdupre]

I don't have bandwidth to push on this right now but please feel free to ping me in @tsalo !

[tsalo]

Thanks @emdupre!

I noticed that there are a bunch of folders in a number of post-optimal combination nodes corresponding to the echo-specific files. I _think_ that the problem could stem from the fact that the bold_mask used after optimal combination comes from init_bold_preproc_trans_wf, which is run echo-wise. Does that make sense?

[emdupre]

We moved bold_mask generation from the T2StarMap to the main BOLD workflow
with #2109, so it makes sense to me that we could now be generating
echo-specific masks. In that case, though, I'd still expect the passed BOLD
file to be the optimal combination ?

Le ven. 5 juin 2020 18 h 14, Taylor Salo [e-mail] a
écrit :

Thanks @emdupre https://github.com/emdupre!

I noticed that there are a bunch of folders in a number of post-optimal
combination nodes corresponding to the echo-specific files. I think
that the problem could stem from the fact that the bold_mask used after
optimal combination comes from init_bold_preproc_trans_wf, which is run
echo-wise. Does that make sense?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/poldracklab/fmriprep/issues/2175#issuecomment-639860167,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADSSJZ2OIR3PECH6WM62FMLRVFU4FANCNFSM4NUIFCKQ
.

[tsalo]

It is, but if there are multiple masks passed, then I think that explains multiple folders labeled after the original echoes. The only difference in the MELODIC runs should be the masks, though, so I can't see why some are failing. Perhaps the first echo's bold_mask is overly permissive, but the optimally combined data should have zeros in voxels outside _its_ mask, so that on its own shouldn't lead to failures AFAIK.

Still, I think we need to join the outputs from bold_bold_trans_wf and grab one of the masks. Also, we can add --mask to our tedana interface to better control which voxels are combined in the t2smap_wf. WDYT?

EDIT: Never mind about including --mask, since tedana.utils.make_adaptive_mask will just reduce user-provided masks based on the mask it would use regardless. So it wouldn't respect the mask provided by the interface.

[tsalo]

I'm fairly sure that the problem is the masks and not the actual data that MELODIC is being run on. I have a possible fix in #2181, although it's not very pretty.