BUG: CTF and proj (re)application

[larsoner]

In principle we should be able to:

1. apply compensation or proj
2. compute forward on full set of channels
3. pick channels in data (maybe dropping compensation channels)
4. compute inverse without reapplying proj or compensation (BUG: Epochs constructor (re-creates) and re-applies proj even if proj is False if raw.proj is True #2310)

So we need to:

1. Always keep info['comps'].
2. Always keep info['projs'] complete with the set of channels that were used when they were applied, i.e., do not subselect channels if proj['active'].
3. If projs are applied to raw, for epochs(..., picks=[1], proj=True), raise an error telling people to use proj=False because they should not reapply?
4. Check for correspondence between comps and proj and data channels in the forward object during inverse application.

This non-reduction of the projs, however, would create some things to think about:

• In master, if you apply projs, then subselect channels, then compute the inverse, the projection operator is reapplied (I think?). This is a bit weird because it means that there were actually two spatial operators that got applied, but only the last (with fewer channels) gets applied to the lead fields.
• Currently we get the rank for inverse computation by subtracting the number of projectors, but this will only work if all channels are kept. We could still use n_proj -- we would just underestimate the rank, which is at least safer than overestimating it (and blowing up near-zero singular values).

This would probably take a lot of careful coding and testing to get right, but it should be doable. It seems like the cleanest option. @agramfort do you see any problems with this approach?

[bloyl]

What do you think of breaking this up into multiple PRs?
with the first being to

Always keep info['comps']

and convert this RuntimeError to a RuntimeWarning

mne-python/mne/io/pick.py

Lines 403 to 408 in 4f7f515

	if current_comp != 0:
	raise RuntimeError(
	'Compensation grade %d has been applied, but '
	'compensation channels are missing: %s\n'
	'Either remove compensation or pick compensation '
	'channels' % (current_comp, comps_missing))

This would revert us to pre #5133 status, and you/we would have slightly more time to properly triage this?

[larsoner]

Seems reasonable as an intermediate step to me

[larsoner]

We should do this intermediate step for 0.17 and the full fix for 0.18. @bloyl do you have time in the next two weeks to do the RuntimeError->RuntimeWarning? If not I can do it.

[larsoner]

... and just a note that whatever fix we have should incorporate the gist that will eventually show up in #5384 :)

[bloyl]

similar to #5610

if possible we should check that covariance objects match the compensation grade of data they are being applied to.

[larsoner]

Unfortunately for cov IIRC we don't store the actual info['chs'] field, just the ch_names so we can't check the grade

[agramfort]

so are we screwed? what are your thoughts?

[larsoner]

I'll have to look deeper at the code and the output. For example if we always store the uncompensated one, then it can be compensated then picked on the fly. It's possible this already happens, I haven't checked

[dengemann]

@agramfort @larsoner greets from Lyon. People run into this issue and it blocks their progress in adopting MNE :) essentially what we see is that you have to drop the ref channels in order to apply refs. We see that excluding the reference channels is hard-coded that https://github.com/mne-tools/mne-python/blob/master/mne/proj.py#L74. I'm wondering what is the right thing to do here ...

[agramfort]

can you be more specific? do you have a script that crashes where it should not?

[dengemann]

We can see if we can repeat it on CTF sample data. What we see is that computing projs and applying them is broken if ref channels are present because the proj by default excludes them.