I'm investigating an issue with PointLocators... and so I was digging
through the logic in TreeNode... and came across some weirdness.
There appears to be some logic mismatches between TreeNode::find_element()
and TreeNode::find_element_in_children()
I can see what the _intention_ was - but I don't think the code actually
does what the comments say it is doing.
The problem is that find_element() duplicates some of the checks already
being done in find_element_in_children()... specifically the bounding box
checks. Because of this... even though the comments in
find_element_in_children() ultimately say that every element in the mesh is
searched... that is NOT true!
Here's what's actually happening in find_elements_in_children():
1. Active children who's bounding box contains the point are searched.
2. If that fails then all active children are _tried_
- HOWEVER: The bounding box check is _repeated_ in find_element()...
meaning that the elements won't be searched because the bounding box check
will fail (otherwise these children would have been searched in step 1)
- THEREFORE: Even though find_elements_in_children() _tries_ do do an
exhaustive search... it really just loops over all other Tree nodes and
bails out at the bounding box search in find_element()... NEVER actually
testing an element!
3. Returns NULL
What this means is that if the bounding boxes have floating point tolerance
issues (which they do)... you can end up with a situation where a point
"slips through the cracks" between the bounding box checks and the
Elem::contains_point() checks...
My proposal to fix this? Well... I think the logic could be changed quite
a bit in find_elements_in_children()... it is trying to do too much (it
should just recurse instead of doing checks... but I understand that's it's
trying to speed things up by recursing favorably into children who's
bounding boxes contain the point first)
BUT - a simple fix that doesn't change too much logic is simply to remove
the "if (this->bounds_point(p) || this->contains_ifems)" line from
find_element(). If you made it into find_element() and that node is active
then it means we really _do_ want to search the elements in that node...
regardless of what the bounding box says!
Finally: I think that something that could speed things up and make things
more robust is to use a "fuzzy" bounding box. There's no reason why they
have to be so rigid. We should use floating point fuzzy comparisons to see
if we lie in the bounding boxes. The bounding boxes are simply there to
speed up getting down to a set of elements that's in the right area... and
having floating point tolerance issues keep us from traversing down into
the right set of elements doesn't make sense...
Let me know if I've missed something...
Derek
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
