Re: [Libmesh-devel] Refinement flag assert trip when using GMG + AMR

[Boris B. <bor...@bu...>]

For posterity's sake, I'd just like to note that this issue has been
migrated to https://github.com/libMesh/libmesh/issues/1832 under some
slightly simpler mesh configurations.

On Wed, Aug 22, 2018 at 11:50 AM, Boris Boutkov <bor...@bu...>
wrote:

> Hello all,
>
> Ive been looking into using GMG with AMR on an L-shaped domain problem and
> am having issues uniformly_coarsening during the GMG setup phase after I've
> refined some elements on the first AMR step in both serial and parallel
> situations. I am using elem_fraction AMR flagging and am setting a small
> refinement_percentage and have set coarsening_percentage to 0 to keep
> things simple.
>
> Specifically in this 2 level GMG scenario, I  end up tripping the assert
> on elem_refinement.C:157 i.e.
> libmesh_assert_equal_to (mychild.refinement_flag(), Elem::COARSEN) while
> trying to coarsen an element, at this point mychild.refinement_flag() ==
> coarsen_inactive.
>
> When I hit the assert, the element in question that's being coarsened is
> actually already inactive, level 0 and having a coarsen_inactive refinement
> flag, and has children with refinement flags: c[0]: inactive, c[1]:
> coarsen_inactive, (both of which are inactive) while c[2], c[3]: are active
> with a flag == coarsen.
>
> While the c[0,2,3] children have no children themselves, c[1] does, and
> has all its children as active, but with a refinement flag == coarsen.
>
> In short, I've been trying to understand how the refinement flags got into
> such a state but haven't had much luck so far and wondering if there were
> any clues about how I could have ended up in such a situation while trying
> to do the uniform coarsening.
>
> Thanks in advance for any info provided,
> - Boris
>
>
>