Allow different AMR flag methods on each level about amrclaw HOT 5 OPEN

@mjberger and I also just discussed the possibility of specifying that the finest level(s) should be frozen beyond some time, after which re-gridding is never done for these level(s). This would be useful e.g. in GeoClaw simulations where the finest levels cover a fixed coastal region at very fine resolution, and frequent re-gridding is both expensive and unnecessary. This may take a bit of work to implement but should be possible.

from amrclaw.

See clawpack/geoclaw#454 for a related suggestion in GeoClaw, eliminating the automatic creation of regions corresponding to each topo or dtopo file.

from amrclaw.

Another suggestion: I think in setrun.py, in addition to e.g.

amrdata.amr_levels_max = 3

we should also have something like:

amrdata.amr_levels_max_outside_flagregions = 2

as the default maximum refinement level in portions of the computational domain not covered by any flagregion.

This would be equivalent to specifying a flagregion with spatial extent covering the entire domain and with minlevel = 1, maxlevel = 2 (in the case shown above), but without having to specify a flagregion. This would be convenient and also perhaps clearer to the user.

Currently the default is that any level up to amr_levels_max is allowed for any cell that is not in any flagregion (whether the cell is flagged or not then depends on other criteria such as flag2refine or Richardson).

Sometimes this is what one wants, but often not. In particular, if the finest levels are only intended to be used in a small part of the domain (e.g. one coastal site for a tsunami simulation) then there might be a flagregion that forces refinement to this level in a small region, but another flagregion would have to be introduced to forbid refinement to this level elsewhere, regardless of the size of wave.

from amrclaw.

For the former suggestion were you thinking of specifying a time at which a level would be frozen?

from amrclaw.

@mandli: Yes, it would be good to be able to specify a time at which each level is frozen. Perhaps we could allow this to also vary with level, with default time infinity, and with the requirement that frozen_time[L+1] <= frozen_time[L] since if a level is frozen then all finer levels must also be frozen.

For the tsunami application I mentioned, we often have a finest level with minlevel==maxlevel but that doesn't turn on until some time time t1 just before we expect the tsunami to arrive (based on coarse exploratory runs) and so it would be natural to freeze at time t1.

However, one potentially tricky issue is that the regridding that introduces this finest grid will not in general happen exactly at time t1, but only at the next regridding time after t1. So it has to do this regridding to introduce the fine level in the first place before it is frozen, and hence it's not enough to check if t > frozen_time when deciding whether to regrid this level, at least not if the user sets frozen_time = t1. If the user is aware of this they could specify a frozen_time somewhat larger than t1, if they know how much larger it needs to be (to guarantee that at least one regridding happened between t1 and this time), or we could try to automate this by keeping track of whether it has already regridded after frozen_time and only freezing it after the first regridding following frozen_time.

Or since in general there would probably only be one such time for each run (or very few at least), we could force the code to adjust the time step if need to hit that time exactly (as we do for output times) and then force a regridding at exactly that time and freeze afterwards.

None of these is a perfect solution, but could be workable.

from amrclaw.