<div dir="ltr">Thanks so much, Eric!<div>It makes sense to me now. I'll take your suggestion to use the 'oct6'. :-)</div><div><br></div><div>Best,</div><div>Lin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 22, 2017 at 3:35 PM, Eric Larson <span dir="ltr"><<a href="mailto:larson.eric.d@gmail.com" target="_blank">larson.eric.d@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I used ico5 to have a better spatial resolution. I saw several other papers used this setting.</div></div></blockquote><div><br></div></span><div>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.)</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>But I still don't understand why the higher resolution causes this error. I thought the smaller spacing should result in more neighbors...<br></div></div></blockquote><div><br></div></span><div>The "neighbors" here aren't probably aren't quite what you're thinking of, which sound like neighbors in the <i>low-resolution</i> mesh that results from setting up the source space.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Eric</div><div><br></div></font></span></div></div></div>
<br>______________________________<wbr>_________________<br>
Mne_analysis mailing list<br>
<a href="mailto:Mne_analysis@nmr.mgh.harvard.edu">Mne_analysis@nmr.mgh.harvard.<wbr>edu</a><br>
<a href="https://mail.nmr.mgh.harvard.edu/mailman/listinfo/mne_analysis" rel="noreferrer" target="_blank">https://mail.nmr.mgh.harvard.<wbr>edu/mailman/listinfo/mne_<wbr>analysis</a><br>
<br>
<br>
The information in this e-mail is intended only for the person to whom it is<br>
addressed. If you believe this e-mail was sent to you in error and the e-mail<br>
contains patient information, please contact the Partners Compliance HelpLine at<br>
<a href="http://www.partners.org/complianceline" rel="noreferrer" target="_blank">http://www.partners.org/<wbr>complianceline</a> . If the e-mail was sent to you in error<br>
but does not contain patient information, please contact the sender and properly<br>
dispose of the e-mail.<br>
<br></blockquote></div><br></div>