|
From: Roy S. <roy...@ic...> - 2006-06-23 17:11:40
|
On Fri, 23 Jun 2006, Kirk, Benjamin (JSC-EG) wrote:
> Similarly, I envisoned elem->contains_point() as generally being called
> when the element actually contains the point.
If that was the case, wouldn't contains_point(){return true;} have
been much easier to code? ;-)
> 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.
Yes, but the opposite isn't true. Just picture a QUAD4 with one
corner gradually being brought toward the center. There will
eventually be a point where the Jacobian inside the element is
positively bounded below (and so it's still an acceptable element) but
where there are points in the bounding box with inverted Jacobians
that might trash Newton.
> 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... ;-)
Hey! If we've got a volunteer on our hands, I want to see the FE
shape function initialization better optimized and the build process
moved to automake.
---
Roy
|