[Mne_analysis] hacking mne_setup_source_space

[Eric Larson]

Hey David,

Responses inline below.

> ... surface, if you wish. There is some primitive and lightly tested
> support for this in mne-python, and some work on this might be done this
> summer. If you're interested, feel free to open an issue there and we can
> work on it.
>
> Hi were could i find these primitive versions and support ?
>
>
Some of the stable volume/discrete source space functionality is documented
here:

http://martinos.org/mne/stable/generated/mne.setup_volume_source_space.html#mne.setup_volume_source_space

The equivalent in the C code would be "mne_volume_source_space". In Python,
a "source space" is just a type of list, the most common of which is a
two-element list containing one space for the left hemisphere, and the
other for the right. So in principle one could append to this standard
two-element list any arbitrary number of additional volume or discrete
source spaces, such as the amygdala or hippocampus. We haven't extensively
tested how such code integrates with the rest of the pipeline (e.g., with
forward solutions and inverses, let alone plotting), but this is the type
of approach we will likely use in the near future. It would be great if we
could get your input or (even better!) contributions to the code base to
help this along.

If you prefer working with the C+MATLAB tools instead of Python, you could
consider using "mne_volume_source_space" to set up a discrete source space
containing any additional structures of interest, and then using the MATLAB
toolbox to combine them and write them out to disk.

> Another option that might work would be to not compute patch stats (no
> -cps), but I would guess faking the surfaces this way will cause (more)
> problems as you go, as various pieces of software may reasonably (but
> incorrectly) assume hemispheres refer to the original freesufer surfaces.
>
> ...
> You mention problems down the road, what kind of problems do you think we
> might encounter?
>

The source space FIFF files created by MNE (both MNE-C
mne_setup_source_space and mne-python equivalent) are marked as being of
"surface" type, as opposed to "discrete" or "volume" type:

https://github.com/mne-tools/mne-python/blob/master/mne/fiff/constants.py#L531

And I'd have to check, but they might even explicitly be marked as left and
right hemisphere somewhere:

https://github.com/mne-tools/mne-python/blob/master/mne/fiff/constants.py#L274

I think some of the downstream code assumes (at least) a couple of things
about such source spaces, namely 1) that each surface-type source space
will contain a valid triangulation (e.g., all nodes exist in the
triangulation somewhere), and 2) that these source spaces will correspond
to the left and right hemispheres as obtained from Freesurfer. Both of
these assumptions appear to be violated by your modifications, so any code
that relies on the assumptions above may be prone to failures.

For example, "--cps" appears to be one instance. I'd have to think about
how well forward solution code would handle it; having source locations and
normals might be sufficient there, since that's all you'd get with a
discrete source space (which forward solutions can be calculated for), but
having the FIFF tags indicating that the two spaces are of surface type
might break something somewhere. I wouldn't expect plotting utilities like
mne_analyze or PySurfer to succeed on any STCs or inverses downstream,
since valid triangulations are the bread and butter of the OpenGL calls at
the heart of those code sets -- and these programs also assume things about
surfaces coming from Freesurfer. I also wouldn't expect any morphing
procedures to work, since these use the Freesurfer-defined morph maps.
There may be other examples, but these are a few I can think of for now.

Cheers,
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20140414/48e3abf8/attachment.html