Re: [Libmesh-users] Adaptative Mesh Refinement

[Roy S. <roy...@ic...>]

On Tue, 12 Jun 2018, Vinicius C. Reis wrote:

> Hi John, I pasted a somewhat smaller version of my code below. By playing
> with the refinement steps limit and the commented out init() and reinit()
> lines you should be able to reproduce the two exceptions I got.

Got it reproduced.

The exceptions you get when omitting that reinit in the loop are an
intentional design decision: libMesh can't handle solution projections
through more than one level of refinement at a time, and we aren't
going to change that any time soon, but doing a reinit after each
refinement step is an adequate workaround.

Unfortunately, the exceptions you get when *including* that reinit in
the loop appear to be a missing feature: libMesh can't currently
handle solution projections with subdomain-specific variables where
elements are added to subdomains from one mesh to the next.

We could try to start treating that the way we currently treat element
addition mid-simulation: all the newly created DoFs get coefficients
initialized to zero.  I assume that's the behavior you're hoping for?

I'm not immediately sure how to implement it, though.  With
newly-created elements it was relatively easy: just skip the element
entirely.  With newly-set subdomains we can't currently call
old_dof_indices() (because it will scream when the newly present
variable has no indices found) but we also can't skip it entirely
(because other variables may still exist there and need projection).
The value of old_dof_indices() isn't even defined in this case since
there simply are no indices whose values in the old solution vector
are guaranteed to be zero.  We could return invalid_id and then test
for that?  But even then I'd want to use an entirely different method,
or turn on an "out of mesh mode" like we have in MeshFunction, or
*something* to make it a non-default behavior, because for 99% of
users trying to query a nonexistant DoF is going to indicate a bug.
---
Roy