Subdomain mesh adaptivity issues for finite volume problems

[pbehne]

Bug Description

Undesirable behavior and crashes are observed for finite volume problems that use mesh adaptivity on a subdomain.

Steps to Reproduce

Consider the test input in moose/test/tests/indicators/gradient_jump_indicator/gradient_jump_indicator_test.i. This problem is split into 2 subdomains: the left half with unknown variable u0 and the right half with unknown variable u1. Mesh adaptivity is imposed on the left half of the domain by defining an indicator on variable u0 and a marker on said indicator. The mesh for the initial condition is shown below:

The mesh for the last timestep is shown below:

The undesirable feature of this result is that although mesh adaptivity is only defined for variable u0 on the left half of the domain, adaptivity appears to be used on the right half as well. This effect can be mitigated by adding block = 0 to the marker. This results in the following mesh for the final time step:

Although not as drastic, the coarsening still spills into the right half of the domain. When adding block = 0 to the indicator, the problem crashes with Segmentation fault: 11 in opt mode and eventually crashes in devel mode with the following message:

We caught a libMesh error in ThreadedElementLoopBase:Assertion `comp < this->n_comp(s,var)' failed.
comp = 0
this->n_comp(s,var) = 0

Finally, when attempting to use subdomain mesh adaptivity on a FV fluids problem that uses Rhie-Chow interpolation (see attached cask.txt), the problem crashes. In devel mode, the following message is given:

Assertion `it != _a.end()' failed
We definitely should have found something
at /Users/behnpa/projects/moose/modules/navier_stokes/src/userobjects/INSFVRhieChowInterpolator.C, line 455

This error only seems to occur when running on more than one processor.

Impact

Prevents getting work done, as mesh adaptivity can be crucial for large simulations.

cask.txt

[lindsayad]

Although not as drastic, the coarsening still spills into the right half of the domain.

This is not specific to FV. In MOOSE we ask that there be at most a level-1 mismatch in refinement level between neighboring elements

[pbehne]

Makes sense. I wanted to point it out in case the effect is unintended.