Menu
▾
▴
Re: [Libmesh-users] Problem with contains_point in face element in 3D
|
From: Derek G. <fri...@gm...> - 2011-03-25 13:56:02
|
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 <joh...@un...> 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 [roy...@ic...] >> Sent: Friday, March 25, 2011 12:05 AM >> To: Joh...@un... >> Cc: lib...@li... >> Subject: Re: [Libmesh-users] Problem with contains_point in face element in >> 3D >> >> On Fri, 25 Mar 2011, Joh...@un... 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 >> Lib...@li... >> 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 >> Lib...@li... >> 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 > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libmesh-users |