From: KIRK, B. (JSC-E. (NASA) <ben...@na...> - 2005-05-18 16:25:21
|
In that case I bet there is an issue with the neighbor information getting out of sync? An element can try to access its neighbor, which has previously been deleted in contract(). Of course, dereferencing the neighbor pointer is invalid. Just a thought. The call to prepare_for_use() will update the neighbor information and prevent that. BTW, WTF is an ancestor? :-) -Ben -----Original Message----- From: Roy Stogner [mailto:roy...@ic...] Sent: Wednesday, May 18, 2005 11:15 AM To: KIRK, BENJAMIN (JSC-EG) (NASA) Cc: lib...@li... Subject: RE: [Libmesh-devel] Unstable code: incoming On Wed, 18 May 2005, Roy Stogner wrote: > There may be something wrong with the Elem::active() changes I checked > in a while ago, in that case! Other than wasting memory and keeping > around children for project_vector to play with, an uncontracted mesh > is supposed to behave the same as a contracted one. Well, I've found one place where an uncontracted mesh fails: DoFMap::create_dof_constraints was happily calling FE::compute_constraints() on every element. The tests inside compute_constraints() skip over ancestor elements, but when acting on subactive elements could end up with disaster. With that fixed (already committed to CVS), adding a prepare_for_use() call to the end of Mesh::contract() appears to make the bug go away. I'm not going to commit that second change until I fully understand it, though - I want to make sure it's actually fixing a bug and not just hiding one again. --- Roy |