On Wed, Jun 4, 2014 at 5:25 PM, Gaston, Derek R <derek.gaston@inl.gov> wrote:
Note that just today John submitted some enhancements for PointLocator to make it operate only on local elements: https://github.com/libMesh/libmesh/pull/264

So PointLocator is definitely ripe for enhancement like this.

Personally, I would like to see the interface change to where we could pass in arbitrary element begin/end iterators to set the elements to be searched ( I could use that for some other purposes ).

As for working with ParallelMesh...  If you're using MOOSE (which I'm kind of assuming you are) then it's not too bad - we already have an interface where you can specify off-processor elements to be ghosted to the local processor (we use it for contact with ParallelMesh).  Just let me know when you're ready and I can show you where those interfaces are.
Derek, we are ready :-) 
We are ultimately using MOOSE, but for the point location purposes we decided to go straight to libMesh to cut down on the learning curve a bit.

Just so we're clear: PointLocator is _not_ a "parallel" search: It is a local search that can be wrapped up to do a parallel search.
That's exactly what we are looking for -- wrapping the local search to achieve a parallel search.
 However, I actually recommend just ghosting the region to the local processor that you believe you will need to search so that you can just do pure local searches using PointLocator....
Yes, but we might not be able to afford that much ghosting: we are developing an algorithm where particles interact with one another via a long-range field.  There are some clever techniques used to attenuate this interaction, but in general we cannot guarantee that a couple of ghost layers will do the trick -- the "halos" might be as big as a processor subdomain.

If you were to use the mesh-to-mesh transfer as a model (in my view it is similar to our situation, since it involves location of a bunch of source points in a target mesh), what would be the common pitfalls/gotchas?

Thanks for the feedback!
Dmitry.

Derek



On Wed, Jun 4, 2014 at 2:24 PM, Dmitry Karpeyev <karpeev@mcs.anl.gov> wrote:
John,

Thanks for the pointer.  
That's what we figured -- that ParallelMesh would return nothing, unless the point is in a locally owned/ghosted element.  Our halos are expected to extend beyond the ghost region and we want to be able to work with ParallelMesh as well.  Our plan was to extend the ParallelMesh PointLocator functionality in a separate branch and later issue a pull request for you guys to consider.  

Dmitry.


On Wed, Jun 4, 2014 at 3:18 PM, John Peterson <jwpeterson@gmail.com> wrote:



On Wed, Jun 4, 2014 at 1:56 PM, Dmitry Karpeyev <karpeev@mcs.anl.gov> wrote:
Guys,

Matthew Michelotti is a summer student working on a project that deals with particles in a fluid.
At the end of the day we have to locate the points within a certain halo of a given mesh partition, 
so we are looking at libMesh's PointLocator stuff.  We would like to have it work for ParallelMesh as well (partly, because it is too easy otherwise :-).

libMesh's PointLocator should work with ParallelMesh, but, using the default options, the result you get will differ depending on whether you are using SerialMesh or ParallelMesh.  ParallelMesh will return NULL on a given processor if the Point is in an element owned by another processor (and is not a ghost element of the current processor) but SerialMesh will happily return a pointer to the off-processor element since it has access to the whole Mesh.

The "certain halo of a mesh partition" detection is not currently implemented in libmesh, but could probably be done in the application code.

--
John