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

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

This is driving me nuts.

GDB absolutely refuses to automatically stop on breakpoints set in
fe_map.  If I "Step Into" a bunch I can dig down into it manually, but
I have no idea why it won't stop automatically.  This is making it
pretty hard to get a trace on one of the actual failing calls.

One weird thing though... I changed the "Warning" print statement in
inverse_map so that it would print out "secure" as well... and here's
what I get:

WARNING: Newton scheme has not converged in 31 iterations:
   physical_point=(x,y,z)=(0.158938, 0.422823,        0)
   physical_guess=(x,y,z)=(0.497654,  0.17708,        0)
   dp=(x,y,z)=(-9.77611,  7.05057,        0)
   p=(x,y,z)=(0.685321, 0.746925,        0)
  secure=1   error=12.0533

How in the _HELL_ is secure=1?!???!???!?!!

Continuing to dig....

Derek

On 6/21/06, Derek Gaston <fri...@gm...> wrote:
> 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
> >
>