<div dir="ltr"><div dir="ltr">On Fri, Sep 25, 2020 at 7:44 AM Jeremy Theler <<a href="mailto:jeremy@seamplex.com">jeremy@seamplex.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2020-09-24 at 18:30 -0400, Matthew Knepley wrote:<br>
> > There is also DMPlexFindVertices() which finds the nearest vertex<br>
> > to<br>
> > > the given coords in the given radius.<br>
> > <br>
> > At first I had understood that this function performed a nearest-<br>
> > neighbor search but after a closer look it sweeps the local DM and<br>
> > marks whether the sought points coincide with a mesh node within<br>
> > eps or<br>
> > not. Neat.<br>
<br>
This DMPlexFindVertices() sweeps over DMGetCoordinatesLocal() which<br>
returns both the local and ghost coordinates, so at the end of the day<br>
I might get more than one process claiming to have found the same node.<br>
<br>
How can I ignore ghost points so each vertex actually belongs to the<br>
process that found it?<br></blockquote><div><br></div><div>This is just a debugging function from Vaclav. It is not intended to be used</div><div>for production code. If you wanted to change it, you can just have it search</div><div>DMGetCoordinates(). It is consistent with Plex since mesh points exist in the</div><div>local space, and you only have a notion of global with the SF. I think the right</div><div>modification would be to optionally pass the pointSF and not return points</div><div>contained in it.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> > > I wrote it some time ago mainly for debug purposes. It uses just<br>
> > > brute force. I'm not sure it deserves to exist :-) Maybe we<br>
> > should<br>
> > > somehow merge these functionalities.<br>
> > <br>
> > It works, although a kd-tree-based search would be far more<br>
> > efficient<br>
> > than a full sweep over the DM.<br>
> <br>
> We should not need to do that. LocatePoints() does not sweep the<br>
> mesh.<br>
> It just does grid hashing. kd is a little better with really<br>
> irregular distributions,<br>
> but hashing should be fine.<br>
<br>
Yes, it seems to be pretty efficent (although there is no support for<br>
3D so far).<br>
<br>
Two more things about plexgeometry.c:<br>
<br>
 1. shouldn't line 224 in DMPlexLocatePoint_Simplex_3D_Internal()<br>
compare against -eps instead of against zero as donde in line 145 in<br>
DMPlexLocatePoint_Simplex_2D_Internal()?<br></blockquote><div><br></div><div>I hate to do it, but I made the change. It is practical. The Right Thing to do is use the robust predicates</div><div>from Shewchuk and Bailey. That is on my list for someday.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
 2. wouldn't it be better to replace DMGetDimension() by<br>
DMGetCoordinateDim() in line 45 inside DMPlexFindVertices? I have a 2D<br>
mesh with 3D coordinates and PetscUnlikely() is triggered.<br></blockquote><div><br></div><div>You are right. I fixed it. I will put this branch in today hopefully.</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks<br>
--<br>
jeremy<br></blockquote></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>