Fix: invalid value in divide

[christianbrodbeck]

Should prevent the RuntimeWarning discussed in. @yaylim let me know if it actually does.

Closes #48

[yaylim]

I just tested it, and I am not getting the same error message anymore. But if I do not exclude the bad channels, the issue still persists (which is expected). I am not getting an error message stating that there are flat channels in the MEG data in that case though.

[christianbrodbeck]

So if I understand correctly, you don't get invalid value in divide when you exclude bad channels, but you do get invalid value in divide when you do not exclude bad channels. That would mean we've identified the source of the issue, but my PR is not doing what it's supposed to do. Can you debug my PR with your data so that we properly raise the error and do not get invalid value in divide when users supply bad data? You can make a PR into my PR (or create a new PR from your own branch if that's easier).

[yaylim]

The invalid value in divide error occurs when one of the MEG channels contains only zeros. This situation arises because during the pre-whitening stage the MEG channel is set to all zeros. The whitening filter is created using the noise covariance matrix, which is calculated from the empty-room recordings. During the eigenvalue decomposition performed in the construction of the pre-whitening filter (in _inv_sqrtm), the real parts of the eigenvalues are compared against a threshold defined by _R_tol. If any rows fail to exceed this threshold, those rows are set to zero. Consequently, during the pre-whitening stage, the MEG data are multiplied by the resulting filter, causing the corresponding channel to become entirely zero. Therefore, the root cause of this issue is not flat MEG channels in the data itself, but rather the properties of the empty-room recordings used to compute the noise covariance matrix. @proloyd I would appreciate your input on this.

[proloyd]

@yaylim we can also check if the diagonal of the covariance matrix contain any zeros, and accordingly raise error just the way @christianbrodbeck raises the error in his commit. That should address the problem and notify the user possible changes that they have to make.