On Mon, 12 Oct 2015, Paul T. Bauman wrote:
On Mon, Oct 12, 2015 at 9:36 AM, Roy Stogner <royst...@ices.utexas.edu> wrote:
(and likewise for node_level_mismatch_limit)
Derp. Sorry, and thanks.
So yes, here "0" means "infinity".
OK, so we think this is the problem with the
over/underrefined_boundary_limit. In that case, we want "0" to
really mean no mismatch
Indeed we do. Again from mesh_refinement.h:
* If \p overrefined_boundary_limit is negative, then level
* differences will be unlimited.
*
* \p overrefined_boundary_limit is 0 by default. This implies that
* adaptive coarsening can only be done on an interior element if
* any boundary elements on its sides are simultaneously coarsened.
*/
So here "0" is documented to mean "0", a convention whose
intuitiveness I would congratulate myself about if it wasn't
immediately preceded by "negative numbers"-mean-"infinity".
and, IMHO, we should support that case for
over/underrefined_boundary_limit. We can/will cook up a PR, but any
comments before we do so?
"IMHO, we should support that case" makes it sound like "Roy decided
not to support that case but we should change that decision"; the
reality is "that was the primary case Roy intended to support but we
need a real programmer to revisit his cut-and-pasted hack job".
It looks like the fix might just be two lines: change e.g.
if (_overrefined_boundary_limit)
to
if (_overrefined_boundary_limit >= 0)
in mesh_refinement.C, likewise for _underrefined_boundary_limit.
But the hard work is that someone should do what I failed to do in
the first place: add some more mixed dimension mesh refinement unit
tests to actually *exercise* this option.
---
Roy------------------------------------------------------------------------------
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
