Most everything I've tested so far is good, but there is still a problem in
ex10. It now dies at step 43 with
Solving time step 43, time=1.1000...
Refining the mesh...
ex10: src/mesh/mesh_refinement.C:198: bool
From: Roy Stogner [mailto:roystgnr@...]
Sent: Wednesday, May 18, 2005 1:31 PM
To: KIRK, BENJAMIN (JSC-EG) (NASA)
Subject: RE: [Libmesh-devel] Unstable code: incoming
On Wed, 18 May 2005, KIRK, BENJAMIN (JSC-EG) (NASA) wrote:
> Check out out.gmv.020 from ex10... It seems that somehow the
> refinement flags are getting changed in a way they should not... The
> mesh starts as uniformly refined and should coarsen immediately
> everywhere except around the initial pulse. Now there are refined
> regions that persist, they seem to be coarsened one layer at a time on
> the perimeter. My guess is something is being overlooked in
Something was overlooked in my new eliminate_unrefined_patches(). I've
committed the fix to CVS, and it appears to work.
Note that even if eliminate_unrefined_patches() is working now, there's one
behavior change: instead of just eliminating unrefined patches, now AMR will
refuse to create them in the first place. I seem to recall some
"flickering" in one of John's experiments, of a cell that was coarsened
every odd timestep by the error indicator and refined every even timestep by
eliminate_unrefined_patches(); hopefully the change will prevent situations
> Updating the neighbors for all the cells is serious overkill. There
> is a TODO at the beginning of find_neighbors() that shouldn't be
> there, provided elem->nullify_neighbors() gets called in the right
I don't think it's where elem->nullify_neighbors() gets called, but rather
what it does. If it set neighbor pointers to the correct values rather than
to NULL, that would handle coarsening at least.
> Last time I tried that (a *long* time ago) I had some trouble, but I
> haven't messed with it recently.
With the luck I'm having this week, I'm not going to mess with a troublesome
change just for efficiency's sake, not when the inefficient code is still
O(n). In fact, I think I may add an additional find_neighbors() call
(wrapped in #ifdef DEBUG) to the middle of refine_and_coarsen_elements() so
redundant calls of
eliminate_unrefined_patches() will continue to be no-ops and I can leave in
Fixing nullify_neighbors to set pointers for a newly coarsened cell itself
should be easy, but making sure every element's neighbor's descendants all
get set correctly sounds ugly, and writing another function to handle
neighbors of newly refined cells correctly would be even uglier.