ICA non-convergence and data quality in tedana / ME-ICA

, , , ,
1

Hi everyone,

I am working with multi-echo fMRI data processed using an ME-ICA / tedana-style workflow.

I noticed that datasets acquired with the same sequence and processed using the same parameters can show different ICA convergence behavior. Some runs converge normally, while others reach the maximum number of iterations without convergence. In some non-converged cases, the workflow can still return ICA components and continue with BOLD/non-BOLD component classification.

I would like to better understand how this situation should be interpreted.

  1. What does ICA non-convergence imply for the reliability of the resulting components and the final denoised data?

    If ICA does not converge but still returns components, can those components still be considered meaningful, or should the decomposition be regarded as unreliable?

    If the components can still retain some meaningful information despite non-convergence, does the denoising result generated from those components still have scientific or practical value?

  2. Does ICA non-convergence indicate that there may be a problem with the original fMRI data?

    In other words, can convergence failure itself be considered a potential data-quality warning, or is it mainly an optimization issue that does not necessarily reflect the quality of the input data?

  3. If ICA non-convergence may be related to data quality, how should the underlying problem be investigated?

    Are there recommended QC procedures or signal-level analyses for identifying why one dataset fails to converge while another dataset acquired and processed in the same way converges successfully?

  4. How should a non-converged run be interpreted if BOLD-like components are still identified?

    Can the subsequent BOLD/non-BOLD classification still be trusted, or does ICA non-convergence make those classification results unreliable?

  5. What does it mean if ICA converges but no BOLD-like components are identified?

    Can such a result still be considered valid, and would the final denoised data still be suitable for subsequent scientific analysis?

  6. Why can datasets acquired with identical acquisition parameters show very different ICA convergence behavior?

    What characteristics of the data are most likely to drive these differences?

Ultimately, I am trying to understand whether ICA convergence status can be used as a practical indicator of data quality, and how non-converged datasets should be evaluated before deciding whether they can still be used.

Any references, recommended QC procedures, or experience with similar cases in tedana / ME-ICA would be greatly appreciated.

2

ICA convergence happens when the algorithm identifies stable & statistically independence non-Gaussian signal sources (i.e. ICA components). Barring something really weird with the data, this should always be possible with fMRI data. That said, in my hands, the biggest reason convergence fails is because the estimated number of components is bad. That is, if you have 200 volumes of fMRI data it might be hard to find 150+ statistically independent components. Similarly, if you are trying to model 200 volumes of data with 10 components, it is sometimes difficult to converge on something stable that represents the data. For the runs that do not converge do they tend to have non-trivially more or non-trivially fewer components than other runs that quickly converge?

What this means in practice is that converge is less about data quality and more about whether a plausible number of ICA components was requested. The hard part is how to define “plausible”. There are a bunch of methods to estimate the number of true non-Gaussian sources in data. tedana has options for several of these methods, but they sometimes fail (way too many or way to few components). I had an OHBM2026 poster that specifically looked into this issue: https://fim.nimh.nih.gov/assets/presentations/Marlene_OHBM_poster.pdf

The short version is that I compared the methods we use in tedana to the methods in MELODIC and some newer bootstrapping based methods. It seems like all component number estimation methods fail (implausibly too few or too many components) for some runs. The specific runs that fail differ by method and there is little relationship between the methods’ estimates. This means this is likely more an issue with these estimation methods rather than the data itself.

That all said, at least for the dataset I’m testing on the poster, it seems like tedana denoising results are fairly stable across a wide range of numbers of components. My current recommendation is to run tedana to see what the typical number-of-components estimates for a runs that converge and then use the high end of that range for the runs that don’t converge. You can do this with –tedpca X where X is an integer number of components. You could also does the estimates in advance and then pick a fixed number for all runs.

Specifically for your questions:

1.Try to get ICA to converge. Non-convergence could mean that it was very close, but not quite at threshold. Increasing the default number of iterations with --maxit could address that, but the tedana default is already fairly high (500) so it’s more likely a sign that the estimated number of components is wrong.

2-4,6. I doubt the issue is with the data. I think the number-of-component estimation errors might be due to spatially distant statistical dependence between voxels due to modern acceleration methods, but that’s not inherently right or wrong. It’s that the estimation methods may include incorrect assumptions. I don’t know why the failures happen on only a subset of runs with the same acquisition parameters, but it may be about how dependence appears across voxels.

  1. If you have any too many or too few components, that can sometimes result in no BOLD comopnents being identified. If you have a plausible number of components and are not identifying BOLD components, that could be a sign of other issues. I may be able to help more with more details.

Hope this helps.

Dan

3

Thank you very much for the quick response. I really appreciate your help.

I have a few follow-up questions:

1、You mentioned that, unless there is something “really weird” with the data, ICA should generally be able to converge for fMRI. From your experience, what kinds of data problems would fall into that category? Are there particular acquisition failures, artifacts, or signal characteristics that you have seen directly interfere with convergence?

2、Regarding component-number estimation, could inaccurate estimates themselves be related to the statistical properties of a particular run? In other words, even if the estimation method is the main limitation, can certain data features systematically push the estimate too high or too low?

3、I have now run 144 runs, each with 723 time points. The estimated component numbers ranged from 26 to 115. Eight runs failed to converge, with 115, 104, 101, 77, 68, 65, 59, and 39 components, corresponding to about 15.9%, 14.4%, 14.0%, 10.7%, 9.4%, 9.0%, 8.2%, and 5.4% of the time points. So the failed runs are not consistently at the highest or lowest end of the distribution.

My sequence setting:

  • Voxel size (mm): 3 × 3 × 3

  • Slice thickness (mm): 3

  • Number of slices: 52

  • Flip angle (deg): 60

  • TR (ms): 1000

  • TEs (ms): 12.5, 30.5, 48.5

  • Effective echo spacing (ms): 0.275

My current workflow uses:

  • PCA method: tedpca

  • ICA method: FastICA

  • fittype: loglin

  • Spatial mask: an all-one mask was provided to preserve extracranial structures, including the skull

  • All other processing parameters were left unchanged and set to the default values provided by tedana.

These runs were still processed with an all-one spatial mask, so I am wondering whether that could still be contributing. In your experience, if a more conventional brain/analysis mask is used across runs acquired with the same protocol, would you expect the estimated component-number range to be relatively stable across runs?

4、For manually setting the component number, is there usually a practical range relative to the number of time points, rather than testing many values for every run? This would be very helpful for large datasets.

Also, if a manually selected component number leads to convergence, is that alone enough to consider the denoising result acceptable, or would you still check BOLD-component identification, variance explained, or denoising stability?

Thanks again for taking the time to share your thoughts on this.