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

[Kirk, B. \(JSC-EG\) <ben...@na...>]

Nice effort, y'all.

I agree with both (heh, how political...) of you.

inverse_map() is probably as good as anything to robustly determine if
an elem->contains_point(), but I must confess when I wrote it I
envisioned that the point *would* be in the element.  It was only later
I thought about using it for elem->contains_point().  Clearly
inverse_map() needs to return a bad point when iteration fails, right
now it is luck of the draw...

Similarly, I envisoned elem->contains_point() as generally being called
when the element actually contains the point.  A simple improvement
could be to check the bounding box of the element's nodes before
beginning Newton iteration.  Clearly if a point is not contained in the
Cartesian bounding box of an element's nodes (with some allowance for
delta_z~0 in a 2D mesh) we have no business expecting the inverse_map()
to work.

Certainly optimizations are possible for certain elements, especially
linear simplices, but you might want to profile the code to see if it is
worth the effort.  If you are volunteering to write some code I'd love
to have you help me update the XDR mesh format... ;-)

-Ben


-----Original Message-----
From: lib...@li...
[mailto:lib...@li...] On Behalf Of Roy
Stogner
Sent: Friday, June 23, 2006 10:38 AM
To: Derek Gaston
Cc: lib...@li...
Subject: Re: [Libmesh-devel] FE::inverse_map() not converging...

On Thu, 22 Jun 2006, Derek Gaston wrote:

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

This is what I was afraid of - the fix is as I suggested the other
day: if the Newton iteration doesn't converge, return a point like
(1.e6,1.e6,1.e6) so we don't get a false positive from contains_point().

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

I think I disagree.  These Newton failures should only happen if the
element is badly twisted or if the point is outside the element, right?
So in that case, if we just return a junk point when Newton fails, we
should still get correct results.

> 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=20
> 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=20
> stuff to fall back on in case we don't want to implement=20
> contains_point in a concrete_class... but for elements for which it=20
> would be easy (maybe even trivial?) to do it for manually... why not?

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

Works for me!  I'm not sure how much of an improvement you can make in
general, but at the very least it might be a little optimization for
TRI3/QUAD4.

For the more complicated geometric elements you might try testing
has_affine_map() first - if the element transformation is affine (and I
don't know about your weird smoothed meshes but in my meshes most of the
elements are affine) then you can implement contains_point with n_sides
inequality tests.
---
Roy

Using Tomcat but need to do more? Need to support web services,
security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
Libmesh-devel mailing list
Lib...@li...
https://lists.sourceforge.net/lists/listinfo/libmesh-devel