On Mon, 2 Jun 2008, David Knezevic wrote: > I guess the attachment didn't come through the mailing list, I've > attached it to this email. The test code is just a very simple > linear example with refinement driven by Kelly error estimator...
Okay, running through this, I can see what's breaking: A node at (0.3125, 0.10000000000000001) exists in the mesh, for element e. A node at (0.31249999999999994, 0.10000000000000001) is requested in the mesh for neighboring element n. These are in separate "bins" of a LocationMap key hash, so MeshRefinement thinks they're two different nodes. Since elements e and n don't share the same nodes on their common side, find_neighbors thinks it isn't a common side. But this means that e and n would eventually get neighbor pointers pointing to the other's parent, which find_neighbors in debug mode recognizes as an invalid topology. Making the "bins" larger would just make the problem less likely to trigger. Using our old keys (based on pointer values) would fail on a ParallelMesh. Searching all neighboring bin keys would make LocationMap::find() take 3^d times longer, but that's the best fix I can think of. Anyone else have any suggestions before I get to it? --- Roy ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
