make_coarsening_compatible in uniformly_coarsen()

[roystgnr]

Otherwise we create inconsistent coarsening flags on adaptively h-refined meshes!

This should fix #1832

@bboutkov, could you try it out too?

[roystgnr]

I'd also love a unit test if one of you has time to add it; I'm behind on other things (not that I wasn't way behind on this...) at the moment.

[pbauman]

This is tripping the ARefEE test. Today is a total horror show for me, but I'll try to get a unit going tomorrow and see if I can also replicate a failure similar to the ARefEE test. But you should be able to just run the regression/extra_quadrature_order_laplace_arefee_amr.sh test on this branch. Output from CIVET is below, looks like it failed after the first AMR step.

==========================================================
GRINS Version: e2257258a20d94472b737c86dc67bae2ce4d006c
libMesh Version: 24f7f7f32455bc95b9a8b5db9714c3ce14635018
Running with command:
/femputer/pbauman/civet_build_testing_root/build-grins-libmesh/test/.libs/lt-generic_solution_regression --input /femputer/pbauman/civet_build_testing_root/grins-libmesh/test/input_files/extra_quadrature_order_laplace_arefee_amr_regression.in soln-data=/femputer/pbauman/civet_build_testing_root/grins-libmesh/test/test_data/extra_quadrature_order_laplace_arefee_amr_regression.xdr vars=T norms=L2 H1 tol=1.0e-10 qois=-3.3293172601959668e+01 
==========================================================
==========================================================
List of Enabled Physics:
HeatConduction
ParsedSourceTerm
==========================================================
*** Warning, This code is deprecated, and likely to be removed in future library versions! /femputer/pbauman/civet_build_testing_root/libMesh/src/mesh/boundary_info.C, line 2146, compiled Sep  5 2018 at 18:31:42 ***
==========================================================
List of Enabled QoIs:
weighted_flux
==========================================================
 Mesh Information:
  elem_dimensions()={2}
  spatial_dimension()=2
  n_nodes()=289
    n_local_nodes()=289
  n_elem()=64
    n_local_elem()=64
    n_active_elem()=64
  n_subdomains()=1
  n_partitions()=1
  n_processors()=1
  n_threads()=1
  processor_id()=0

 EquationSystems
  n_systems()=1
   System #0, "GRINS"
    Type "Implicit"
    Variables="T" 
    Finite Element Types="LAGRANGE", "JACOBI_20_00" 
    Infinite Element Mapping="CARTESIAN" 
    Approximation Orders="SECOND", "THIRD" 
    n_dofs()=289
    n_local_dofs()=289
    n_constrained_dofs()=64
    n_local_constrained_dofs()=64
    n_vectors()=1
    n_matrices()=1
    DofMap Sparsity
      Average  On-Processor Bandwidth  1e-15
  Nonlinear solver converged, step 2, relative step size 1.03094e-09 ) at /femputer/pbauman/civet_build_testing_root/libMesh/src/error_estimation/adjoint_refinement_estimator.C:559
#6  0x00007f8a2d73f0bc in GRINS::MeshAdaptiveSolverBase::estimate_error_for_amr (this=this@entry=0x17f7f48, context=..., error=...) at /femputer/pbauman/civet_build_testing_root/grins-libmesh/src/solver/src/mesh_adaptive_solver_base.C:210
#7  0x00007f8a2d75779d in GRINS::SteadyMeshAdaptiveSolver::solve (this=0x17f7f00, context=...) at /femputer/pbauman/civet_build_testing_root/grins-libmesh/src/solver/src/steady_mesh_adaptive_solver.C:124
#8  0x00007f8a2d72802d in GRINS::Simulation::run (this=0x17df3f0) at /femputer/pbauman/civet_build_testing_root/grins-libmesh/src/solver/src/simulation.C:264
#9  0x00007f8a2d770293 in GRINS::Runner::run (this=this@entry=0x7ffca243c1b0) at /femputer/pbauman/civet_build_testing_root/grins-libmesh/src/solver/src/runner.C:111
#10 0x000000000040c512 in main (argc=, argv=) at /femputer/pbauman/civet_build_testing_root/grins-libmesh/test/regression/generic_solution_regression.C:85
[0] /femputer/pbauman/civet_build_testing_root/libMesh/src/error_estimation/adjoint_refinement_estimator.C, line 559, compiled Sep  5 2018 at 18:31:03

[roystgnr]

I can replicate this... and superficially I understand it: some make_coarsening_compatible operation is suggesting that a recoarsening is impossible and unflagging it, so the uniform coarsening then doesn't perfectly undo the uniform refinement.

What I don't understand is why anything would be unflagged. I specifically used make_coarsening_compatible() without the whole array of other smoothing methods so as to try and avoid such a situation. It seems at some point either we let a different smoothing heuristic slip into that method or we made something there overzealous.

[roystgnr]

And now I understand why.

make_coarsening_compatible has a bug dating back to at least Jan 10, 2003, the very earliest version of mesh_refinement.C we have in version control.

If an element flagged for coarsening has an inactive neighbor, we change the element's flag to do nothing, under the theory that if it really needed to be coarsened we'll end up flagging it again later after the inactive neighbor is coarsened into activity. Apparently "you can't adaptively coarsen quite as fast as you should be able to" never bothered anyone enough to notice the problem before.

[pbauman]

@bboutkov is cooking up a CPPUnit based test, but he mentioned that the patch as is still gave him a failure with mismatched n_local_dofs() and n_dofs() (he can chime in). So hopefully the "full" fix will fix that too. Either way, hopefully his unit test(s) will capture that failure as well.

[bboutkov]

make_coarsening_compatible has a bug dating back to at least Jan 10, 2003, the very earliest version of mesh_refinement.C we have in version control.

Wow, that's quite a sneaky one!

RE the unit test, I pushed a couple of quick checks to the same branch which I can flesh out with a 3d case or two and make a PR of, but I'm not sure what a good approach would be if we want to add a little more robustness for further checking beyond just these basic cases.

As for the n_local_dofs vs n_dofs issue, I was a bit hasty with my conclusions earlier - hope I didn't cause any extra heart palpitations! I think the make_coarsening_compatible fix exposed to me some GMG related issues which I think would be more appropriate to address separately from this issue.

[roystgnr]

So we're partway there. The good news is that the fix in that last commit ought to prevent us from undercoarsening on serialized meshes.

The first bit of bad news is that this still won't pass CI, because GRINS (and probably MOOSE and MOOSE apps and so on; I'm not looking forward to seeing how extensively) regression tests with undercoarsened gold results will no longer match those results. We'll need to regenerate those and we'll have the annoyance of tests failing except when the test result version matches the libMesh version.

The second bit of bad news is that the fix for distributed meshes is going to be trickier. With minimal (i.e. standard default) ghosting there's no way to get this right on corner cases without putting a communication step into that while loop. I'll add that shortly.

[jwpeterson]

This PR has been marked "do not merge" since we are no longer accepting PRs into the master branch. All new PRs should be made on the devel branch instead. Once this PR's target branch has been updated to devel, the "do not merge" label will be removed.