STC saturated – rank problem?

[SophieHerbst]

I am not happy with the stcs of some of my subjects, they look like the screenshot attached: at one moment in time there is very high activity everywhere, which messes up the scale. I remember that a similar outcome was caused by differences in rank between the cov used for whitening, and the rank given to compute the inverse.

With cfg.noise_cov = 'rest', the following should read the info of the resting state run to compute the inverse.

l. 52 in source/_05_make_inverse.py
in_files["info"] = bids_path.copy().update(**cfg.source_info_path_update)

I cannot figure out what the **cfg.source_info_path_update does.
Thanks for any help!

[larsoner]

Yes it's probably a rank mismatch between the empty room resting state and task data. Are you using movement compensation? If subjects move a lot it could be an issue with our imperfect/incomplete capturing of movements during runs compared to empty rooms. Or you could be hitting #760.

A long-term plan for at least some of this stuff could come out of mne-tools/mne-python#4676, but even with that I don't think we're guaranteed to solve all issues.

I've been meaning to add something that allows computing the rank robustly from the epochs of interest -- in my work with infants who move a lot I almost always use something like:

rank = mne.compute_rank(epochs, tol=1e-3, tol_kind="relative")

and it has worked well. I propose we add something like:

rank_kind: Union[Literal["info"], Dict[str, Any]]

where the backward-compatible rank_kind = "info" is what we do currently (guess as best we can from info), otherwise allow a dict which is a set of kwargs to pass to mne.compute_rank(epochs, **rank_kind). So in your case to follow my suggestion you would just add to your config:

rank_kind = dict(tol=1e-3, tol_kind="relative")

and then this would compute the rank from epochs and also pass rank=... to the covariance, inverse, and (possibly) decoding code.

[SophieHerbst]

thanks for the fast reply @larsoner!
would your solution still work if the rank of the resting state run is lower than that of the epochs (because there was one more bad sensor for instance)?

in my own code I did the following to prevent the problem:

• compute covariance from resting state with rank=info
• when computing the inverse, load the resting state again and pass its info (not the one of the epochs) to compute_inverse

[larsoner]

Ahh yes in principle you should probably compute the rank over whatever you're using to compute the covariance. So it should be computed in the compute_covariance step probably using whatever data you're computing the covariance over, which could be rest, empty room or task epochs. And in the case of a custom covariance note for people that the rank will be computed over the returned covariance which is generally less numerically accurate (but probably okay).

[SophieHerbst]

@larsoner it seems already the case that one can chose the file from which to read the info in source/05_make_inverse.py
l. 51: in_files["info"] = bids_path.copy().update(**cfg.source_info_path_update)

After setting source_info_path_update in config, my stcs look fine.

noise_cov = 'rest'
source_info_path_update = {'processing': 'clean',
                            'suffix': 'raw',
                            'task': noise_cov}

Is this the intended usage?
If yes, wouldn't it make more sense to automatically use the info from the file from which the cov was computed?

[larsoner]

Yeah it seems like that would make sense. Not sure what the current behavior / default is for source_info_path_update is, seems like it should use the noise_cov if it can

[hoechenberger]

Not sure what the current behavior / default is for source_info_path_update is, seems like it should use the noise_cov if it can

It reads the Info from the Evoked

[SophieHerbst]

I agree. I couldn't figure out what the default behavior does.

[hoechenberger]

So the solution would be to NOT use the Info from the Evoked if the noise cov was estimated from empty-room or resting-state data, do I understand this correctly?

[SophieHerbst]

yes, I think this is what causes the mismatch in ranks and the weird stcs

[SophieHerbst]

@hoechenberger if you can point me to where this happens, I can try to change it

[hoechenberger]

@hoechenberger if you can point me to where this happens, I can try to change it

Sorry, I can't give any useful advice for now, as I'm busy with other stuff … maybe by the end of the week, but I cannot promise anything!