On Tue, 13 Oct 2009, Joa Ljungvall wrote: > #5 0x00007fff81116bfc in __cxa_throw () > #6 0x000000010512afa4 in RemoteElem::n_nodes () > #7 0x000000010510acf4 in DofMap::dof_indices () > #8 0x000000010510e2d9 in DofMap::add_neighbors_to_send_list () > > This I don't understand at all...
Hmm... there was a bug last year that looked like this, but it was fixed before 0.6.3 was released. It may be that you've inadvertently triggered the same problem that the bug did, though: When we refine an element, we need to create any new nodes its children will have, or we need to point them to the appropriate existing node in the mesh. We look for that existing node by location: calculate the point where we'd build a new node, see if any node exists at that point yet, if so attach to it and if not then build a new one. But what happens if you refine one element, create a hanging node, then *move the hanging node*? When you refine the element's neighbor, it will look to see if a node exists yet on that edge or face, the answer will be "no", and a new node will be created. This tears the topology of the mesh, which is a nasty bug that can manifest as the incorrect creation of a RemoteElem in our find_neighbors() algorithm. (but which should have triggered a libmesh_assert() earlier - did you run in devel or dbg mode?) Anyway, the solution is probably to, after you've looped over all nodes, loop over all constraint equations in the dof map and apply them to nodes' xyz coordinates. --- Roy ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
