On Mon, Jul 18, 2016 at 12:42 PM, Xujun Zhao <xzha...@gmail.com> wrote:
> It sounds like this is an inherent problem of the present algorithm for > determining if a point is in an element??? especially for complex elements > such as HEX27. > It's only a problem because we aren't properly handling the failure case... We know that points will sometimes be outside elements, we just need the inverse_map function to not throw an error in such a case. > Is there any other more robust solution in computational geometry? > For that element, I doubt it, however, we accept pull requests. > I also tried to use the 1st order element, it passed the test for this > simple case, although I am not sure if this really solves the problem. Is > it possible to add another contains_point(Point& pt, ORDER order) that > allows using lower order shape function? In CFD with mixed finite elements, > we sometimes use higher order interpolation for velocity and lower order > ones for pressure. But when to determine which element a point moves into, > we can still use first order algorithm as an approximation. > Also, how about the tri/tet elements? Will they cause zero determinant > problems? The lower order ones (TRI3 and TET4) have contains_point() specializations, but I see that the Tet4 one also needs a similar try/catch block fix since it uses TypeTensor::solve(). -- John ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports.http://sdm.link/zohodev2dev _______________________________________________ Libmesh-users mailing list Libmesh-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-users
