Respect allowflag limitations when buffering patches

[rjleveque]

The routine allowflag is still used in 3d to allow the user to specify whether a cell is allowed to be flagged at a given level. But this is only checked when doing the initial flagging, not when buffering, and so the patches create may extend into the region where refinement to this level should not be allowed.

@cjvogl has a problem with an interface where there's a big jump in wave speed. We'd like to have the finest level grid up to the interface on one side but never extending into the other side (where the CFL would be >1 with the time step desired).

I suggest we check allowflag when buffering.

Also, we might want the restrictions imposed by regions to also apply when buffering, as a special case of the above.

In 2d I think we eliminated calls to allowflag when regions were introduced, but cases like this suggest it might also be nice to have an allowflag that the user could use to specify constraints like this that don't map to rectangles nicely?

And we should introduce regions in 3d to complement allowflag.

[mjberger]

Problem with not allowing buffering is that grids won’t be properly nested. I know it’s a pain to fuss with the regions so that you exactly control the locations, but without buffering the grid ding is going to fail.

Not sure what you are suggesting with regions - what special case?K As for regions — Marsha

On Jan 23, 2016, at 1:32 PM, Randall J. LeVeque [email protected] wrote:

The routine allowflag is still used in 3d to allow the user to specify whether a cell is allowed to be flagged at a given level. But this is only checked when doing the initial flagging, not when buffering, and so the patches create may extend into the region where refinement to this level should not be allowed.

@cjvogl has a problem with an interface where there's a big jump in wave speed. We'd like to have the finest level grid up to the interface on one side but never extending into the other side (where the CFL would be >1 with the time step desired).

I suggest we check allowflag when buffering.

Also, we might want the restrictions imposed by regions to also apply when buffering, as a special case of the above.

In 2d I think we eliminated calls to allowflag when regions were introduced, but cases like this suggest it might also be nice to have an allowflag that the user could use to specify constraints like this that don't map to rectangles nicely?

And we should introduce regions in 3d to complement allowflag.

— Reply to this email directly or view it on GitHub.

[rjleveque]

@cjvogl: So I think a better way to do this is to write allowflag to only allow flagging a cell if it is more than ibuff cells away from the interface, so that after buffering it won't extend beyond the interface. And then modify flag2refine2.f90 to call this allowflag function.

I added an example to illustrate this in my allowflag_buffer branch in directory dev/allowflag_buffer/advection_2d_square, see https://github.com/rjleveque/amrclaw/tree/allowflag_buffer/dev/allowflag_buffer/advection_2d_square

This allows refinement only in the green rectangle in this figure, in which 2 levels are used and grid cells are plotted only on Level 2 patches...

[cjvogl]

@rjleveque: I did implement this and saw some improvement in the slower-wave region. This does come at the expense of accuracy in the faster-wave region, because the way the refinement ratios are set (in order to have less time refinement in the slower-region, we need less space refinement in the faster-wave region).

I do have another idea how to approach this and will keep you posted on the outcome.