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 |