[FLASH-USERS] Odd numbers of guardcells?

[Klaus Weide]

On Wed, 3 May 2017, Sean M. Couch wrote:

> Hi all,
> 
> Does any know if it is possible to use an odd number of guardcells in 
> FLASH with Paramesh 4dev? I vaguely remember some lore that only even 
> numbers of guardcells per dimension worked. I’m developing a stencil 
> based solver for which, technically, only an odd number of zones would 
> be needed but I am getting weird results. If I add an extra guardcell 
> layer (which is never accessed by the solver), all is fine again… 
> Which is to say, I can’t find the bug in MY code so I’m hoping to 
> just blame FLASH (well, Paramesh) ;-P


Hi Sean,

You remember that lore right, more or less. Some details -

1) Paramesh supports, in principle, any number of guard cells (as long as 
the number is not too large in relation to NXB,NYB,NZB), including odd 
numbers.

2) One concern comes from Grid interpolation of cell values, which
comes into play (a) when new leaf blocks are created in prolongation, and 
(b) in filling of fine-side guard cells at fine/coarse boundaries.
Different interpolation methods require different stencil sizes, thus
different minimum numbers of guard cells (coarse cells around the location 
where interpolation is required.)

In addition to the requirement of a *minimum number* of guard cells based 
on the interpolation method (and order), there may also exist a 
requirement of *evenness* of that number. I don't know whether this is a 
requirement of PARAMESH's builtin interpolation methods 
('-gridinterpolation=native'), maybe not. It definitely used to be 
required for the default interpolation ('-gridinterpolation=monotonic'). 

That requirement may or may not still exist. I committed changes to 
amr_prolong_gen_unk1_fun.F90 with the intent to remove it in June 2010, 
but the result was never properly tested. Therefore there is still the 
line
   PPDEFINE GRID_GC_LAYERS_ALWAYS_EVEN
in GridMain/paramesh/interpolation/Paramesh4/prolong/Config, which 
enforces using an even number of input guard cells in at least some 
situations. You may try to remove it and see what happens...

3) Maybe more importantly - PARAMESH requires more layers of guard 
cells to be filled in PARENT (and ANCESTOR?) blocks than the number you as 
a user (e.g., caller of Grid_fillGuardCells) actually need. This is to 
provide enough input (coarse) cells where interpolation occurs to fill
(fine) guard cells. And this requirement can cascade over several levels 
of refinement. With the default -gridinterpolation=monotonic and
interpol_order=2:

If the user requires 1 (or 2) layers of guard cells at level L,
then the parent block at level L-1 requires 1+2 = 3 layers.
If a block at level L-1 requires 3 (or 4) layers,
then its parent at level L-2 requires 2+2 = 4 layers.
(That's where it stops, in this case).
Bottom line - if you are using that default interpolation,
and you want ANY guard cells, you always need at least 4 layers.

Klaus