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 ------------------------------------------------------------------------------ Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
