Re: [Libmesh-devel] PointLocator safety and element loops?

[Cody P. <cod...@gm...>]

On Mar 2, 2011, at 9:27 AM, Roy Stogner wrote:

> 
> On Wed, 2 Mar 2011, Cody Permann wrote:
> 
>>> point_locator(), and topological_neighbor(), and perhaps an expanding
>>> range of future functions, should not be used inside element loops
>>> unless the loop is preceded by an explicit PointLocator construction.
>> 
>> Yes - I did in fact run into this in our code.
> 
> And in the library code; one or two of the broken spots in
> MeshRefinement had "codyperm" in the svn blame column.  ;-)
> 
> Not to criticize; I looked at the code too and didn't see the problem.
> And in hindsight my fix isn't the best: we should only build a new
> PointLocator in cases where there actually is a non-empty
> PeriodicBoundaries.  I'll add a utility function for that now.
> 
>> We were puzzled why we needed that extra call in there but it seemed
>> to be necessary for correct functionality.
> 
> How'd the bug manifest for you?  I just discovered that, at least with
> mpich2, our "parallel_only();" calls are much less effective than
> intended.  Instead of a failing libmesh_assert() doing the nice
> message, stack trace file, and exception thing, we get an obscure MPI
> stack error due to mismatched buffer sizes and the whole program
> exits.  Hard problem, since by definition it's an assert that's
> supposed to fail when catching code that would be trying to
> communicate with mismatched buffer sizes.  We're going to need to use
> MPI_Errhandler_set or something to catch these things properly.

I know that wasn't the way ours died but it was awhile back.  Ours was seg faulting in optimized mode and catching various asserts in debug mode back when I was going through the development stage.

> 
>> When using Periodic Boundaries we've noticed that
>> occasionally under the right conditions as we get lots of activity
>> near the nodes that are double constrained, it appears that
>> "sometimes" during the mesh coarsening phase some of the values at
>> those nodes appear to get "bad" values.  In 2D, I'm talking about
>> the four corners of a square domain where periodic boundaries are
>> applied at both sets of edges.  In 3D I'm talking about the edges
>> (lines) of the cube where periodic boundaries are applied on all 3
>> sets of sides.  I did build a problem in MOOSE that demonstrates the
>> problem.  It's actually an adaptation of the existing periodic
>> boundaries example but I moved the forcing function around the
>> domain and approached one of the edges.  Some of the nodes
>> eventually get the wrong values.
> 
> Definitely see if you can get this to trigger with an example.
> Preferably 2D first, if it shows up there.

:) I do have a 2D case that shows the problem but it is a huge polycrystal example.  I haven't had as much luck getting any other test case to fail in 2D.  The 3D problems are just that much more complicated but at least we can get a failure mode more often and with a more simple problem.  

> 
> One thing you might try: Add topological_neighbor support to
> JumpErrorEstimator.  Then you'll be able to use DiscontinityMeasure
> (for C0, or Kelly for C1) as a simple way of automatically detecting
> when and where the constraints aren't being properly satisfied.

This seems like a really good idea - I'll take a crack at it and let you know.


> ---
> Roy