[Libmesh-devel] Edge case for `Elem::contains_point()`

[Tim A. <tra...@bu...>]

Hello everyone:

I am having an issue with the `Elem::contains_point()` function where it
returns a false negative when the point tested is near the boundary of an
element when using tol=libMesh::TOLERANCE.

I modified introduction_ex1 on this branch
<https://github.com/tradowsk/libmesh/blob/rayfire-issue/examples/introduction/introduction_ex1/introduction_ex1.C>
to
show this behavior. I've manually plotted the element nodes and the point
to confirm that the point is indeed on the element, though right on an edge.

tl;dr
how can I best handle this behavior to avoid a false negative? Arbitrarily
raising the tolerance until the failure goes away seems more like tuning
the code to a specific mesh rather than trying to fix the underlying
problem.

======
longer version

This issue arose in development of the GRINS::RayfireMesh class. In short,
the user supplies an origin point on a mesh boundary, and the class will
walk in a straight line across the mesh in a given direction. On each
element along the line, the class will calculate the points where it enters
and leaves that element to create an EDGE2 element that gets stored
internally. The problem with that calculation is verifying whether or not a
calculated point is actually on the side/face of the given element (SECOND
order elements use a newton solver due to the potential nonlinearity on the
element sides/faces).

The test case above is from a larger mesh where the rayfire traverses the
z=0 mesh boundary. I found that using 10.0*libMesh::TOLERANCE for
`contains_point()` allows the rayfire to complete successfully for this
particular mesh, but I don't know if that tolerance value would work for an
arbitrary mesh.

Does anyone have a suggestion for how I can best handle these cases? In the
test case above, I imagine the failure is due to the difference in
z-components, even though they are all essentially zero.

Any help is greatly appreciated!

~Tim
tradowsk