Q: sEEG source estimate

[maedoc]

I tried a volumetric source estimate on sEEG data and got it to execute though I didn't yet check the results. The difficulties I encountered were

• defining the forward dict

fwd = {
    'info': raw.info.copy(),
    'source_ori': mne.io.constants.FIFF.FIFFV_MNE_FREE_ORI,
    'nchan': len(raw.ch_names),
    'sol': {
        'row_names': raw.ch_names,
        'data': Vr,
    },
    '_orig_sol': Vr,
    'sol_grad': None,
    'src': [{'vertno': r_[:nsrc]}],
}
stc = mne.beamformer.lcmv_raw(raw, fwd, ncov, dcov, picks=picks)

where Vr is calculated for a set of points in space using Sarvas 1987 Eq 12 (point dipole in homogeneous space).

• using the EEG channel type because prepare_noise_cov only expects MEG or EEG channels

My question is if this is a reasonable way to do this, and if it would be useful to contribute the code for this?

[maedoc]

Also, in free orientation, MNE expects the lead field to store the three dipoles continguously right?

[larsoner]

I suppose that's a reasonable way, but it would be better to extend the forward code to support sEEG somehow so you don't have to construct a dict yourself. You must already have the forward calculation code, so it would be a matter of fitting it in the right place. @agramfort WDYT?

Yes, they should be contiguous.

[maedoc]

OK cool. My implementation for Vr is

sigma = 1.0
dr = reg_xyz - seeg_xyz[:, newaxis]
ndr = sqrt((dr**2).sum(axis=-1))[..., newaxis]
Vr = 1.0 / (4 * pi * sigma) * dr / ndr**3
Vr_ = Vr.reshape((len(seeg_xyz), len(reg_xyz) * 3))
bVr_ = array([Vr_[i] - Vr_[j] for i, j in bipidx])

where reg_xyz are the voxel centers and seeg_xyz are the contact locations. I ended up with the bipolar form because it seemed to give more spatially specific localizations but could be application specific.

[kingjr]

It's a bit off topic, but can I ask how you reference your sEEG before estimating the cov etc?

[maedoc]

bit off topic, but can I ask how you reference your sEEG

Quite on topic I think, reminds me of a third difficulty: I ran into MNE asking for an average reference for EEG (since sEEG not supported by the noise covariance estimation). Usually an external EEG style electrode is used in the clinical data I'm using, but it's not always in the dataset unfortunately.

[kingjr]

Quite on topic I think, reminds me of a third difficulty: I ran into MNE asking for an average reference for EEG (since sEEG not supported by the noise covariance estimation). Usually an external EEG style electrode is used in the clinical data I'm using, but it's not always in the dataset unfortunately.

Thanks. I'm not an expert on this, but I think [needs confirmation] that the average reference makes sense because scalp EEG sensors roughly cover a sphere (so, the average ref should tend towards zero in a world where the brain is spherical), but I don't think that holds with sEEG.

[jona-sassenhagen]

@kingjr if you're actually intrinsically interested in EEG average referencing, there's a lot of literature on this and the basic idea is that with typical setups, the sphere is approximated pretty badly. (On the other hand, literally every other referencing scheme sucks too.)

[kingjr]

thanks Jona, yes that was my understanding; my worry is that this is a critical issue if ones wants to do source modelling with seeg.

[kingjr]

(That's why I'd go for current source density only.)

[agramfort]

I suppose that's a reasonable way, but it would be better to extend the forward code to support sEEG somehow so you don't have to construct a dict yourself. You must already have the forward calculation code, so it would be a matter of fitting it in the right place. @agramfort https://github.com/agramfort WDYT?

extending the forward code to support sEEG is not straightforward and the only solver I know that can do this is OpenMEEG. A nice integration of OpenMEEG into MNE for "exotic" forward models has been on my todo list for some time now... I am glad to see someone going in this direction.

[agramfort]

regarding referencing this is no fundamental issue as long as it stays linear such as for the average reference. If it can be done with a proj everything should go smoothly.

I am more worried about whitening and various parameters that have been hard coded for MEG/EEG in the inverse solvers.

[maedoc]

whitening

I've noticed that sEEG tends to be highly kurtotic ("spiky"), and I was a little worried about covariance estimation being biased.. would it be worth trying a robust covariance estimator?

[agramfort]

are these spikes artifacts? Why not using the reject trick and a standard noise cov?

[maedoc]

extending the forward code to support sEEG

I understand but just wanting to have something to use in the short short term. The source estimates then get smoothed and are data for a further Bayesian inversion... so I'm not yet looking for quantitatively correct estimates.

[maedoc]

are these spikes artifacts? Why not using the reject trick and a standard noise cov?

The period used for data cov is the seizure, so high kurtosis, whereas the period used for noise cov is after seizure, quieter but still contains many spikes. Reject samples isn't an option here, but maybe I'm not sure what you mean by the reject trick.

[agramfort]

I mean reject time windows with a spike like we do for Epochs with reject param.

[larsoner]

Closing as dup of #1624. @maedoc do you have some data to test with?

[maedoc]

@Eric89GXL as in other thread, I will try to see if a few datasets can be considered for sharing. Is it realistic to work with sEEG alone or you want to have the simultaneous sEEG / MEG?

Btw, If you're at BIOMAG, you can look up Anne-Sophie Dubarry's poster (no idea which day it is) to see what the data is coming from.

[larsoner]

SEEG by itself should be fine, but sEEG/MEG would be cool if you can get it

[maedoc]

I'm at this again with Sarvas '87 Eqn 12, with LCMV estimates for sEEG, and I've got some nice results I think. Would a simple forward model for sEEG be worth a PR, with OpenMEEG a distant second possibility?

SEEG by itself should be fine, but sEEG/MEG would be cool if you can get it

this is unfortunately always clinical data and hard to obtain shareable samples, but we're getting closer to having a nice dataset to share.

[agramfort]

really exciting news.

I still need to find the bandwidth to integrate openmeeg in mne-python. What you're doing has been on my list for some time now... :'(

[larsoner]

Would a simple forward model for sEEG be worth a PR, with OpenMEEG a distant second possibility?

That sounds good to me. Since it's all under the hood, I don't think there will even need to be any API changes, just properly supporting sEEG in the internal forward computation code.

At the user facing end, we can .. warn:: in the make_forward_solution Notes section about sEEG being experimental. Eventually what you have can serve as a first-order check on OpenMEEG working (hopefully to a rtol=0.1 level or so), or maybe even be usable if it's good enough.