Re: [Libmesh-devel] Patch

[<ti...@ce...>]

Dear Roy,

On Fri, 4 Aug 2006, Roy Stogner wrote:

> On Fri, 4 Aug 2006, Tim Kr=F6ger wrote:
>
>> I did these changes now; see the attached patch.  Please commit it to th=
e=20
>> repository (provided that you are satisfied with it).
>
> One problem I see: in the case of quadratic mappings (or any more
> complicated mappings, if the University of Auckland folks decide to
> code them!) it's possible for an element's nodes to all be inside a
> bounding box even though part of the element interior extends outside
> the box.

You are right, I did not think about this.

> I don't know of any fast way to get the real bounding box for even a
> quadratic element.  This will be a very uncommon problem, though -
> perhaps an adequate solution for now is just to leave in the fallback
> linear search.

> 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=20
thus crash.  At least, this call to error() should be removed --=20
perhaps by giving the solver class an optional argument.

The other problem that I see when leaving the linear search in is that=20
when I will later implement the possibiliy to evaluate the=20
MeshFunction outside the domain covered by the grid, the linear search=20
will slow this down considerabely.

What about adding some heuristic safety margin around the bounding box=20
in the case of quadratic mappings?  Well, not really satisfying ...

Perhaps better: Enable the linear search only if quadratic mappings=20
are involved.

Any suggestions?

Best Regards,

Tim