ICA failed to converge

AFNI Message Board
11

Sorry for the delayed response.

But it doesn't say how many components you should try. How did you get to 80-90?

This involves a bit of trial and error. If you run tedana on your data and get plausible estimates 4/5 of the time and it fails the rest, then pick something close to the highest plausible value from the good runs. There are three ways to define "plausible":

  1. For typical fMRI where you're not doing something like pushing the limits of thermal noise with very small voxels, I'd expect the number of components to be 20-40% of the time of fMRI volumes (time points). That is, for a run with 200 volumes, I'd expect 40-80 components.

  2. You can look at the curves from the PCA estimates. Note the file is ./figures/pca_criteria.png with the figures having the title "PCA Criteria" (There's another file ./figures/pca_variance_explained.png which is what you've pasted above. That shows how much variance is explained at each threshold.) I'm going to paste a few examples to show what the criteria should look like.

This one is reasonable. For the AIC, KIC, and MDL cost functions, the value drops, there's a clear local minimum, and then it gradually increases.

image
image809×707 72.1 KB

Sometimes, the cost functions have a much steeper drop and then a steep rise. This is a failure that usually results in too few components estimated.

image
image809×707 72.1 KB

I can't quickly dig up a great example, but sometimes the curves have a similar initial drop and are flat for even decreasing without a clear local minimum. In these cases, the number selected as a local minimum is noiser and is sometimes the highest value (i.e. number of components = number of volumes). This is another failure state.

image
image571×528 38.2 KB

FWIW, my current hypothesis on the reasons for these values is that these cost functions assuming independent and identically distributed data and so some times to make fMRI data more i.i.d. but modern acceleration methods cause problems.

  1. If you are running tedana with robustICA, look at the outputs of some runs & play around. Start with a high value, like 100 for 200 time points. By default, robustICA runs 30 iterations of ICA. If your initial pick is too high, you'll see a 5+ messages about ICA failing to converge on the screen and it keeps repeating until it gets 30 iterations of ICA that do converge. Then step down to try another starting point. robustICA also reduces the number of components. If you request 90 components and robustICA outputs 80-85 ICA components, that's a good sign. If you request 90 and get 70 ICA components, you should try a lower initial value. For this approach, I'd recommend running just tedana on some data you've already preprocessed with AFNI rather than repeated running afni_proc just for the tedana step.

One more (maybe silly) question, I use proc.py with -combine_method m_tedana \, where do the flags go?

In addition to including -combine_method m_tedana there's another flag: -combine_opts_tedana that is used to pass parameters to tedana. To run tedana with robustICA and starting with 90 components, you could include -combine_opts_tedana --tedpca 90 --ica_method robustica If you want to play with the number of ICA iterations that are used by robustICA, you can also include --n_robust_runs That might be useful if you want to quickly test a bunch of starting points with 10 iterations.

Best

Dan