On Wed, Sep 19, 2018 at 10:30 AM John Peterson <jwpeter...@gmail.com> wrote:
> > > On Wed, Sep 19, 2018 at 9:43 AM Tim Adowski <trado...@buffalo.edu> wrote: > >> 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! >> > > Would it be more correct for you to use Elem::close_to_point() instead of > Elem::contains_point() in your application? > > I haven't had a chance to try your example yet, but thanks for providing > it. I'm curious if you know whether the initial bounding box test is what > returns false, or the subsequent FEInterface::inverse_map() and > FEInterface::on_reference_element() checks? > I forgot to mention, the initial bounding box test in Elem::point_test() (which is called by Elem::contains_point()) is doing a relative check using hmax() to normalize, so in your case the signed z-coordinate comparisons are n(2) - p(2) <= hmax * box_tol n(2) - p(2) >= -hmax * box_tol and the right hand side of both of these is O(1.e-3 * 1.e-6) = 1.e-9. So if your point is outside the box by a slightly larger amount, e.g. 1.e-7, one or the other of these tests will fail... -- John
_______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
