On Mon, 7 Aug 2006, Roy Stogner wrote:
> On Mon, 7 Aug 2006, Tim Kr=F6ger wrote:
>> On Fri, 4 Aug 2006, Roy Stogner wrote:
>>> The inverse map iteration definitely won't converge for some elements
>>> if the physical point is outside the element, but that shouldn't cause
>>> a problem for Elem::constains_point() anymore; if its call to
>>> inverse_map() doesn't converge, the result is a distant point that
>>> will make sure on_reference_element() is false.
>> No: If the nonlinear solver doesn't converge, it will call error() and t=
>> crash. At least, this call to error() should be removed -- perhaps by=
>> giving the solver class an optional argument.
> That's exactly why the inverse_map function has the "bool secure"
> argument. If secure is false (as it is when contains_point() calls
> inverse_map() ), then Newton isn't expected to converge and
> inverse_map just exits after 10 iterations.
Strange enough, this didn't happen last week when I had changed the=20
code such that only active elements were inserted into the tree but=20
they were still handled only by their centroid: The code crashed=20
because Newton didn't converge within 20 iterations (with warnings=20
from the 11th iteration on). I have no explanation for that because=20
when I look at the code, it seems to me that you are right.
>> Any suggestions?
> No good ones. All I can think to do is warn about the problem. When
> you add an interface for out-of-mesh MeshFunction extensions, let that
> interface turn off (well, replace) the linear search, and add an
> assert() or #ifdef DEBUG block in that code path which verifies that
> it doesn't see any quadratic mappings.
Okay, so I think the best thing to do is: Whenever the=20
out-of-mesh-extension of MeshFunction is enabled, it will check=20
Elem::has_affine_map() for all elements (at least in debug mode), and=20
if any element returns true, an error will be generated. But,=20
however, I wonder whether Elem::has_affine_map() could occasionally=20
return false due to rounding errors. What do you think? Should the=20
equality checks be replaced by some fabs()<eps stuff?