I wonder if all this confusion is telling us something, that perhaps we've overloaded the functionality in a pretty obtuse way?
Perhaps (at least from the public: perspective) we should implement a few functions that are more clear: contains_point(p); // really, i'm serious close_to_point(p, tol=default_tolerance); of course they might use the same private implementation if it makes sense... On 2/1/12 1:47 PM, "John Peterson" <jwpeter...@gmail.com> wrote: > On Wed, Feb 1, 2012 at 12:27 PM, Roy Stogner <royst...@ices.utexas.edu> wrote: >> >> >> On Wed, 1 Feb 2012, John Peterson wrote: >> >>> A related question is: do we want contains_point() to return "true" in >>> cases where the point is definitely outside the element (to within >>> floating point tolerance), but is "inside" the element (to within >>> user-specified tolerance)? >> >> >> My first inclanation is to say no, but I'm not sure. > > I'd like to say "no" as well. The reason I ask is that, if I > understand correctly, the folks doing contact here have been using > contains_point() as I described above with relatively large (larger > than TOLERANCE) tolerances to detect when a point is at least "nearby" > the element. > > For linear elements, the TOLERANCE bounding box checks must have been > causing contains_point() to return "false" more often than they > otherwise would have wanted... > > >>> If no: then contains_point() probably shouldn't accept any >>> user-specified tolerance at all. >> >> >> This I'm not so sure about. Think of the user-specified tolerance as >> just a way for users to *shrink* the false-positive region if they >> need to, rather than a way to grow it. > > So by "false-positive region," do you mean the size of the bounding > box used in the first-order element optimization? > > If that's the case, we should > > 1.) actually use the user-specified tolerance in the bounding box > tests, not TOLERANCE > 2.) Give the parameter a more descriptive name and document its purpose > better. > 3.) Use TOLERANCE/10 and TOLERANCE for the inverse_map() and > on_reference_element_calls(), respectively (?) ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d _______________________________________________ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
