problem with setting up the source space

Hi all,

I got the following error when creating the source space with
mne.setup_source_space(). The spacing was set to 'ico5'.

*Triangle file: created by lw604 on Sat Dec 3 16:57:00 2016 nvert = 145568
ntri = 291132*
*Mapping lh 08_NonCon -> ico (5) ...*
* Source space vertex moved from 145214 to 145216 because of double
occupation*
* Source space vertex moved from 56257 to 56268 because of double
occupation*
* Source space vertex moved from 56268 to 145227 because of double
occupation*
* Source space vertex moved from 145227 to 57616 because of double
occupation*
*Traceback (most recent call last):*
* File "<stdin>", line 3, in <module>*
* File "<string>", line 2, in setup_source_space*
* File
"/autofs/cluster/kuperberg/nonconMM/MEG/python/anaconda/lib/python2.7/site-packages/mne/utils.py",
line 708, in verbose*
* return function(*args, **kwargs)*
* File
"/autofs/cluster/kuperberg/nonconMM/MEG/python/anaconda/lib/python2.7/site-packages/mne/source_space.py",
line 1311, in setup_source_space*
* subjects_dir)*
* File
"/autofs/cluster/kuperberg/nonconMM/MEG/python/anaconda/lib/python2.7/site-packages/mne/surface.py",
line 677, in _create_surf_spacing*
* '%d / %d' % (k, nmap))*
*RuntimeError: Could not find neighbor for vertex 8590 / 10242*

I have completed the cortical surface reconstruction with FreeSurfer. Also,
there was no error when I set spacing = 'oct6'.

We have 32 participants, and only two participants have this type of error.
What should I do?

Thanks for your help!

Lin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20170522/8f05d94a/attachment.html

In lieu of a better (code) fix, I'd use the default oct6 spacing. Is there
a reason you prefer ico5?

Do these subjects have particularly small heads by any chance?

Eric

Hi Eric,

Thanks for your quick response!

I used ico5 to have a better spatial resolution. I saw several other papers
used this setting.

I quickly checked five participants. Indeed it seems that these two
subjects have smaller brain than others.

But I still don't understand why the higher resolution causes this error. I
thought the smaller spacing should result in more neighbors...

Thanks again for your help!

Lin

I used ico5 to have a better spatial resolution. I saw several other
papers used this setting.

I wouldn't expect it to give much better spatial resolution in practice, at
least for distributed solvers. (Not sure about sparse ones, but I doubt it.)

But I still don't understand why the higher resolution causes this error. I

thought the smaller spacing should result in more neighbors...

The "neighbors" here aren't probably aren't quite what you're thinking of,
which sound like neighbors in the *low-resolution* mesh that results from
setting up the source space.

IIRC the source space is constructed by downsampling the high-resolution
FreeSurfer mesh, specifically by recursively subdividing a standard
icosahedron (ico) or octahedron (oct), doing a nearest-neighbor mapping to
the subject's high-resolution sphere surface, and then de-duplicating any
vertices that are nearest neighbors to more than one of the ico/oct
vertices. The de-duplication thus uses the neighbors according to the
high-resolution mesh triangulation. This error suggests that there are no
neighbors left to choose from, i.e. they are all already in the source
space, and thus the deduplication process could not succeed.

In theory we might be able to work around this in the code by e.g. removing
any vertices (or really equating them in their mesh with their best
duplicate) that happen to have this problem. This might lead lead to some
unintended consequences, though, such as a less uniform sampling of the
surfaces, so it would need some thought, work, and testing to get right.

Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.nmr.mgh.harvard.edu/pipermail/mne_analysis/attachments/20170522/57fdd6ff/attachment.html

Thanks so much, Eric!
It makes sense to me now. I'll take your suggestion to use the 'oct6'. :slight_smile:

Best,
Lin