On Tue, Oct 13, 2015 at 9:16 AM, Roy Stogner
wrote:
>
> On Mon, 12 Oct 2015, Paul T. Bauman wrote:
>>
>>
>> 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:
On Mon, 12 Oct 2015, Paul T. Bauman wrote:
On Mon, Oct 12, 2015 at 9:36 AM, Roy Stogner 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_limi
On Mon, Oct 12, 2015 at 10:14 AM, Paul T. Bauman wrote:
>
>
>
>> Seems counter-intuitive, but it
>> works since there's no other sensible meaning for "0" to have - anyone
>> who wants to enforce "no mismatch at all" should be using
>> refine_uniformly().
>>
>
> As an aside, I'm not sure I agree wi
On Mon, Oct 12, 2015 at 9:36 AM, Roy Stogner
wrote:
>
>
> From mesh_refinement.h:
>>
>
> /**
>* If \p edge_level_mismatch_limit is set to a nonzero value, then
>* refinement and coarsening will produce meshes in which the
>* refinement level of two edge neighbors will not differ by m
On Fri, 9 Oct 2015, Christopher Haynes wrote:
I just wanted to confirm the behavior of the edge and node level
mismatch limits. Currently as it stands the
_edge_level_mismatch_limit and _node_level_mismatch_limit have the
default value of 0 and therefore the conditions
if(_edge_level_mismatch_
