Re: [Libmesh-devel] FE::inverse_map() not converging...

[Derek G. <fri...@gm...>]

Ok... so here's the deal.

elem::contains_point() is using the same flawed logic to decide
whether or not the point is contained in the element (meaning the
newton iterations).  What's happening is that the newton iterations
are failing to converge so severely that the final guess as where the
point is... actually lies within the element!  Thus giving a false
positive.

So here's the deal... inverse_map is _NOT_ a good idea to use for
finding out if the point lies within the element!

My question is this: contains_point() is a virtual function right?
Can we not just override it in the concrete classes so that we don't
have to do this newton thing at all?  I mean a quad4 should be able to
figure out pretty quickly whether or not a point lies in it....
without all the newton iteration stuff.  Sure we can leave the newton
stuff to fall back on in case we don't want to implement
contains_point in a concrete_class... but for elements for which it
would be easy (maybe even trivial?) to do it for manually... why not?

Open for comments

Derek

PS: Yes, this is me "volunteering" to go write contains_point()
functions for all our dang elements ;-)



On 6/22/06, Derek Gaston <fri...@gm...> wrote:
> It would appear that for that element and that point
> element->contains_point(p) _is_ returning true!  There's definitely
> something going on there!
>
> Derek
>
> On 6/22/06, Roy Stogner <roy...@ic...> wrote:
> > On Thu, 22 Jun 2006, Derek Gaston wrote:
> >
> > > It does appear that it is finding the wrong element... here is an
> > > element and a point for which the newton iterations fail (as they very
> > > well probably should since the point is outside the element...)
> > >
> > > ################
> > > Node 0:0.131279 0
> > > Node 1:0.17075 0
> > > Node 2:0.167717 0.032511
> > > Node 3:0.131771 0.0454457
> > > Point: 0.184449 0.121701
> > > #####################
> > >
> > > They are x y pairs.  The nodes are the nodes of the "element" pointer
> > > at around line 192 of mesh_function.C the point is the x y pairs of
> > > "p" in the same place.
> > >
> > > It would appear that "p" is _not_ in "element"....
> >
> > Okay, then our next step is figuring out why the code thinks
> > otherwise.  The MeshFunction shouldn't be trying to use an element for
> > which element->contains_point(p) hasn't returned true.  If you run
> > Elem::contains_point on that element with that p, does it return true
> > or false?
> > ---
> > Roy
> >
>