Fmriprep: Allow choosing the dimensionality of Melodic in --use-aroma

[dangom]

For huge datasets (1k timepoints+) Melodic may choke and not converge, take forever to run, or sometimes return over 400, 500 components. Smoothing may help here, but it's far from ideal.

The problem can be worked around by disabling the automatic dimensionality estimation., so I'll open a PR adding an extra command line argument that allows setting a fixed number of components.

I'd be interested in hearing what others think of this, and whether this feature is relevant at all for the FMRIPREP project.

Thx

[effigies]

This sounds reasonable to me. Does setting the dimensionality to N mean you will get exactly N components, or that you will get at most N components?

I feel it would be better from a user perspective if we could set a reasonable upper bound without changing the behavior on datasets that aren't at risk of exceeding it. And then the option would be to increase or decrease the limit for specific needs.

[dangom]

Exactly N components, though I suppose Melodic will throw an error if the user inserts too high a number, say a number higher than the number of voxels in the image.

The trick is that there is no reasonable upper bound that fits all scenarios, as that depends a lot on the dimensionality of each dataset. From a practical point of view, I find it cumbersome to deal with anything higher than 200, as the interpretability of components is then lost. When using the 'symmetric' approach (default), high numbers also mean that "networks" may split in multiple components.

Also, there is no way to tell Melodic to set an upper bound, at least not in the current implementation. =/

[effigies]

Exactly N components

I was afraid of that.

From a practical point of view, I find it cumbersome to deal with anything higher than 200, as the interpretability of components is then lost.

Yeah, this is the kind of limit I was thinking. Ah well. #1052 is probably the right way to go about it, then.

@chrisfilo @jdkent Do you have any thoughts on exposing MELODIC configuration?

[chrisgorgo]

This conceptually difficult problem and we also can only work within the limitations of current melodic features, so the proposed solution seems good to me.

[jdkent]

I agree with your assessments, melodic as it currently stands doesn't bend to this use case. We could try to hijack CanICA from nilearn and adopt our own heuristic to handle such a use, but I think the current proposal is much more pragmatic.

[dangom]

PR #1052 ready for review

[oesteban]

Closed via #1052

[markushs]

Hi!
Sorry for reopening this thread, but I just discovered that there is a (hidden) option in Melodic that sets an upper bound for the number of estimated components. Simply use the --dim argument (in Melodic) / aroma_melodic_dim argument (in fmriprep) with a negative number, and it will estimate at maximum abs(dim) dimensions.

E.g. --aroma_melodic_dim -200 will produce at most 200 components, but less than that if the automatic dimensionality estimation converges at a lower number.

(Ah, apparently I didn't reopen this issue by just adding a comment. Maybe this does the trick) @oesteban @chrisfilo @effigies

[effigies]

@markushs To be clear, is that true as-is, or do we need to modify anything to make a negative number behave in this way? If so, I think the best option is to update the documentation to make this clear.

[markushs]

I've run some tests, and all one needs to do is to pass a negative number to Melodic (or fmriprep). So true as-is, updating documentation should be sufficient.

Seems like the HCP pipeline also solves it this way:

hcp_fix
Line 106: ${HOME}/pipeline_tools/fix1.06a/melodic -i $fmri -o ${fmri}.ica/filtered_func_data.ica -d -250 --nobet --report --Oall --tr=$tr retCode=$?

[effigies]

That's really handy. Let's update the docs. Any interest in submitting a patch?

Also, perhaps we should set a default. As you found, HCP is setting the limit to 250, and @dangom said above in https://github.com/poldracklab/fmriprep/issues/1051#issuecomment-380880940:

From a practical point of view, I find it cumbersome to deal with anything higher than 200, as the interpretability of components is then lost.

So maybe one of these?

[markushs]

Sure, I can submit a patch.

So if aroma_melodic_dim is not set, maximum number of components defaults to, say, 200. If someone wants an even higher number they can use the argument for that. As long as this is stated clearly in the documentation it sounds like a good solution.

[effigies]

Great! That sounds good to me, as well.