Re: [Libmesh-devel] FE::inverse_map() not converging...

[Derek G. <fri...@gm...>]

Here's the stack:

FE<2u, (libMeshEnums::FEFamily)0>::inverse_map (elem=0xed4cf0,
physical_point=@0xf68920, tolerance=0.0001, secure=false) at
fe_map.C:1220
FEInterface::inverse_map(dim=2, fe_t=@0x7fffff8c05a0,
elem=0xed4cf0,p=@0xf68920, tolerance=0.0001, secure=false) at
fe_interface.C1186
Elem::contains_point(this=0xed4cf0, p=@0xf68920) at elem.C:629
PointLocatorTree::operator()(this=0xf6d8b0, p=@0xf68920) at
point_locator_tree.C:162
MeshFunction::operator()(this=0x7fffff8c0a40, p=@0xf68920,
output=@0x7fffff8c07f0) at mesh_function.C:171
MeshFunction::operator()(this=0x7fffff8c0a40, p=@0xf68920, time=0) at
mesh_function.C:157
main(argc=5, argv=0x7fffff8c11d8) at ex10.C:461

gdb is having a tough time actually stopping at the point I want it
too... so this isnt a call that actually produces one of the error
messages... but it should be close enough.

The weird part to me is that secure is definitely false... but somehow
the messages are still coming out?!  Looking over the code the
"if(secure)" part should definitely never be true.... weird.

I'll keep looking.

Derek

On 6/21/06, Roy Stogner <roy...@ic...> wrote:
> On Wed, 21 Jun 2006, Kirk, Benjamin (JSC-EG) wrote:
>
> > Which point locator class is he using?  In my experience the Tree based
> > ones with a fairly small number of elements per bin help avoid this
> > problem.
> >
> > Furthermore, it is not clear to me why this is getting tripped at all,
> > since Elem::contains_point() calls FEInterface::inverse_map() with the
> > secure flag set to false?
>
> That's a very good question.  I didn't notice that contains_point()
> turned off the secure flag.
>
> Derek, would you run your code in gdb?  Stack traces of the places
> where convergence is failing would help a lot.
> ---
> Roy
>