We rely extremely heavily on contains_point(). If there is going to be a change here we would want to review the patch first. For one thing, if it is going to add any more time to contains_point()... Then we might want to provide an optional argument to turn on the more aggressive checking...
Derek Sent from my iPad On Mar 25, 2011, at 4:28 AM, Johannes Huber <[email protected]> wrote: > Hi, > I didn't change inverse_map, but the contains_point function. Sorry for the > confusion I created. > Hannes > On Friday 25 March 2011 10.14:38 Kirk, Benjamin (JSC-EG311) wrote: >> I'd propose if any changes are made to inverse_map() to check that the >> mapped point agrees that it be turned on only through an optional argument >> or something like that. I'm pretty sure there are places that rely on >> finding this normal projection to get the *closest* point, even if it is >> not an exact match. I know I've used that in applications, at least... >> >> -Ben >> >> >> >> ________________________________________ >> From: Roy Stogner [[email protected]] >> Sent: Friday, March 25, 2011 12:05 AM >> To: [email protected] >> Cc: [email protected] >> Subject: Re: [Libmesh-users] Problem with contains_point in face element in >> 3D >> >> On Fri, 25 Mar 2011, [email protected] wrote: >>> I have a 2D mesh in 3 spacial dimensions and I'd like to get the >>> element, which contains a point. The point_locator uses >>> Elem::contains_point which uses FEInterface::inverse_map and then >>> checks, if the reference point is in the reference element. For 3D >>> points the inverse map is not defined in the whole space, which causes >>> problems, when mapping non coplanar points falsely to the reference >>> element. >> >> Hmm... yes, inverse_map() is solving the normal equations, and so >> ought to be converging to the inverse of the projection of the point >> into the plane/line of the element... which is fine on interior meshes >> or on boundary meshes generated from "flat enough" boundary subsets >> but which would give false positives for many boundary meshes. >> >>> I then changed the function a bit by mapping the reference >>> point back again in physical space and checked the distance there for >>> < tol*hmin(). However now it looks like I've got other problems >>> probably caused by this hack. >> >> That sounds like the right fix, but inverse_map is used in a lot of >> places and it would indeed be easy to break something else by missing >> a corner case... like we seem to have done in the first place. >> >> Are your other problems replicable on any of the examples or on >> anything you can send us in a short code? >> >>> Am I doing something wrong, is there a common pitfall with boundary >>> meshes, or does anybody know, how to locate an element containing the >>> point on boundary meshes. >> >> You're doing everything right, and found a bug that needs fixing; it's >> just not a common pitfall because it's not a common usage type, I >> suppose. >> --- >> Roy >> >> --------------------------------------------------------------------------- >> --- Enable your software for Intel(R) Active Management Technology to meet >> the growing manageability and security demands of your customers. >> Businesses are taking advantage of Intel(R) vPro (TM) technology - will >> your software be a part of the solution? Download the Intel(R) >> Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar >> _______________________________________________ >> Libmesh-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/libmesh-users >> >> --------------------------------------------------------------------------- >> --- Enable your software for Intel(R) Active Management Technology to meet >> the growing manageability and security demands of your customers. >> Businesses are taking advantage of Intel(R) vPro (TM) technology - will >> your software be a part of the solution? Download the Intel(R) >> Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar >> _______________________________________________ >> Libmesh-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/libmesh-users > > > > -- > ************************************************* > Johannes Huber > Mathematisches Institut > Universität Basel > Rheinsprung 21 > CH-4051 Basel > Switzerland > Phone: +41 61 267 39 93 > http://www.math.unibas.ch/~huber/ > ************************************************* > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Libmesh-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libmesh-users ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
