Make topomaps using virtual magnetometers as mne_analyze

[agramfort]

this would be the killer app and I would never hear again "should I work with the combined grads, the grads or the mag on my sensors?"

this involves forward modeling but it's really worth it I think.

we could do

evoked.plot_topomap(..., ch_type="virtual_mag")

any volunteer? @Eric89GXL ?

[dengemann]

would you btw only use it for topomap plotting? Or would it make sense to convert the sensors.

[agramfort]

just topomaps. It should not be useful for inverse modeling.

[dengemann]

@agramfort I found the corresponding / relevant parts in lead_dots.c -- I can look into it in the course of this release cycle / as we go / after my next submission is done.

[larsoner]

Sounds good. I'm also happy to try if you end up being busy @dengemann.

[agramfort]

Please do. It would really be a killer feature for mne

[dengemann]

@agramfort if you can wait I'm happy to look into this, if not and Eric feels bored I'm happy to let Eric play with this.

[agramfort]

Ok. I just feel you have enough distractions ;)

[dengemann]

@agramfort true, as I said once my submission stack goes down / throughout the release cycle. I'm happy to leave it to Erric. I'll find other distraction projects.

[mshamalainen]

You definitely need to look at MNE/mne_analyze/field_mapping.c to understand how this is exactly done.

I will try to write up the formulas containing the details for you during this weekend to make things easier. It is kind of amusing that something what we started to do almost 25 years ago is now a killer feature :)

[dengemann]

Thanks!

It is kind of amusing that something what we started to do almost 25 years ago is now a killer feature :)

:-)

I think we are in retro mode. I was even thinking about digging into the dipole code in the course of the 0.8 cycle ;-)

[mshamalainen]

The dipole code in mne_dipole_fit is actually quite new because it takes into account the noise covariance, finds the initial guess by exhaustive search, etc.

[dengemann]

I've just seen that this is the case. I was actually not aware of this functionality.

[agramfort]

It is kind of amusing that something what we started to do almost 25 years ago is now a killer feature :)

:)

the killer feature is to be able to use this with 1 line of python :)

mne_dipole_fit is actually quite new because it takes into account the noise covariance

now that we have the forward code in python it's really doable to reimplement mne_dipole_fit. That would be another killer feature and even be turned into a short paper if it's actually new :)

[mluessi]

Maybe we could use the MxNE solution to initialize the dipole fit..

[mshamalainen]

I wonder whether it is necessary. For a single dipole fit, the exhaustive search is enough. For multiple dipoles, one almost always needs human assistance in the fitting. Independent of the initial guesses, the fitting tends to go haywire. One exception is the auditory N100m fit where you can usually get one of the auditory cortices approximately right by just fitting a single dipole. Then you can mirror this dipole to the other hemisphere to get a second initial guess. Finally, you fit both dipoles simultaneously and get the result. For EEG, even this case is difficult.

At one point we tried to promote genetic algorithms for the multidipole fit but they did not receive user acceptance. Maybe this could be revisited.

[agramfort]

I agree. Let s stick to single dipole fit for now. That would already be great.

[larsoner]

FYI, I'm going to be away at a conference this week, so I probably won't make much/any progress on the virtual sensors until the following week.

@agramfort can you give me a couple lines/instructions on how to run C code to get the desired functionality of virtual magnetometers with the sample data? I've looked at field patterns but not virtual sensors before, so it would be good to make sure I know the specific functions of interest before I go on an implementing rampage :)

Any ideas on what would be a good test? I'm worried that we'll have to resort to visual inspection if it really is just a plotting option, which isn't great...

Also, since it sounds like this will make use of the field mapping code, then after implementing virtual sensors I guess we shouldn't be too far from being able to show the field patterns on the scalp / MEG sensors like in mne_analyze.

[dengemann]

@Eric89GXL could we possibly postpone this until the first wave of Py3K cleanups (ping @warrd) and the new IO API are done? Our repo has probably never had as few open PRs as in the moment ...

As to #542 we should soon have a hangout where we refresh + update our discussion.

[agramfort]

I agree that IO module is high priority but @Eric89GXLhttps://github.com/Eric89GXL you can start to have a look.

the virtual magnetometers is not available via command line so it will be hard to test. It's only available via viewer in mne_analyze. It will be also a bit different from the C code has it produces the level lines using a super high resolution helmet we cannot use to produce new Epochs/Evoked. We'll a new virtual help with 102 sensors (easy) or maybe 306 locations to keep as much signal. @mshamalainen should be able to say where to look in the C code.

ping @mshamalainen !

[larsoner]

It is rare for us to have so few PRs open, so it is a great time to push IO and Py3 support. For what it's worth, I don't expect either of those to have too much interaction with the virtual sensor/field line code, so I think we'll be okay either way.

@dengemann are you going to push on the IO front? If you're currently busy, I might be able to work on that tomorrow while I'm traveling. It's (much) easier on my laptop to work on cut/paste refactoring than heavy lifting calculation code (esp. C code, which is setup better on my desktop computer).

So @agramfort the procedure would be first to implement magnetic field calculations, as in the C code. Then implement putting virtual sensors in arbitrary locations, given these field patterns. This would also allow us to (trivially, I think?) implement magnetic field visualization, as in mne_analyze. Sound about right? If so, I can probably figure it out from the C code, but I'm happy to have any help @mshamalainen has time for :)

[dengemann]

are you going to push on the IO front?

Not before Thursday. We should update consensus and discuss what to do exactly before moving forward with IO, maybe we can hangout soonish. What about tomorrow e.g. 5pm Paris time? One word of caution. We should plan this carefully which means no rush. Ideally we will change this only once and will be happy forever. (This does not mean we implement everything but we make the right design choices that foster and do not block future IO development). Second, ideally Py3k and IO should not happen at the same time (cc @warrd)

[larsoner]

I won't be able to hangout, so just let me know what you guys decide. In the meantime I'll read through some C code so next week I can start on the field lines / virtual sensors stuff.

[dengemann]

In the meantime I'll read through some C code so next week I can start on the field lines / virtual sensors stuff.

Yes, I agree, this should not depend on the IO. Ideally you'll be able to start your work with the new IO already.

[agramfort]

we'll discuss with @dengemann tomorrow and maybe start if we're done preparing the materials for the course on wednesday.

[larsoner]

Closing to move discussion to PR.