[FLASH-USERS] Error in AMR Prolong Routine

[Klaus Weide]

On Fri, 1 May 2009, James Guillochon wrote:
[...]
> In regards to this comment:
> 
> > By the way, gr_updateRefinement (or its caller, Grid_updateRefinement) is
> > not required to leave *guard cells* in a "sane" state; it is the
> > responsibility of any routine that might be called next - in particular,
> > any physics unit routine that applies some operator to advance the
> > solution - to fill guard cells as needed, usually by calling
> > Grid_fillGuardCells.  Interior cells must of course have valid cell
> > data after Grid_updateRefinement returns.   (But even that can only
> > be expected to be true for leaf blocks, as discussed recently in some
> > other flash-users messages.)
> 
> So in my calculation the only physics is the Hydro routine, and checking the
> hy_updateSoln routine, the sanitizing calls are in the same loops as the hydro
> updates which only run over the interior cells. So since Grid_updateRefinement
> doesn't sanitize the guard cells...and neither does Hydro...nothing prevents
> the prolong routine from using zero-value cells in its calculations. I think
> the guard cells *should* be sanitized prior to running prolong to avoid ending
> up with grid cells where rho < smlrho, the question is where?

James,

I am not sure I understand your meaning. To be clear what we are
talking about, I suggest we use the following terminology (for this
exchange at least):



(1) to fill guard cells == to put well-defined values into guard cells of
certain variables of certain blocks, by either
  o  simple copying from neighboring blocks at the same refinement level, or
  o  interpolation from coarser neighboring blocks, or
  o  averaging from finer neighboring blocks, or
  o  filling at the boundary of the physical domain according to
     boundary condition.

This is normally done, as far as the FLASH code is concerned, as a
global operation by call Grid_fillGuardCells. This is absolutely
necessary for FLASH to function.


(2) to sanitize guard cells == to fix up values in the guard cells of
certain variables of certain blocks, after they have (supposedly) been
filled, by forcing them to lie in a certain range - for example, [smlrho, \infty)
for density.

This could be considered a form of error recovery.  It is not
necessary in general and is, in fact, not done in FLASH3 for variables
in general with the default settings (of
gr_convertToConsvdInMeshInterp in particular).


(3) to check guard cells == to verify that the values in the guard
cells of certain variables of certain blocks, after they have
(supposedly) been filled, are within a certain range - for example,
[smlrho, \infty) for density - ang generated messages if not.

This is part of what the unfortunately-named
gr_sanitizeDataAfterInterp does with the default settings (of
gr_convertToConsvdInMeshInterp in particular). I say "part of" because
it also (and sometimes only) checks interior cells.

As the name gr_sanitizeDataAfterInterp implies, the primary concern is
with out-of-range values that may be created during interpolation (by
undershooting input data). The routine is therefore called in two
places after interpolation may have happened to updated some cell
values:
  o  after guard cell filling (in Grid_fillGuardCells), and
  o  after new leaf blocks may have been created (in gr_updateRefinement).



Note that guard cells *are* filled at the beginning of applying Hydro,
actually (with PPM) one at the beginning of each sweep; the
Grid_fillGuardCells call is one of the first executable statements in
hy_sweep.F90.

Guard cells are *not* filled at the end of Hydro. This is consistent
with requiring every unit that needs valid data in guard cells to make
sure they're there. You could call that a policy of lazy guard cell
filling.

As far as Grid_updateRefinement is concerned - it plays by the same
rules as top routines of physics units.  When it needs updated values
in guard cells, it takes care of filling them.  But just like Hydro,
Grid_updateRefinement isn't required to leave guard cells in a defined
state. Having zeroes there for density is okay, the next user of guard
cells will have to fill them first.

Finally, as an implementation detail about the Paramesh3 / Paramesh4
implementations of gr_updateRefinement in particular. With these
versions, the PARAMESH routine amr_prolong does not require valid
guard cell data on entry. Rather, parent guard cell values required as
input for interpolation for to leaf blocks are filled automatically
and internally as needed. Therefore there is no need for a separate
call to Grid_fillGuardCells before the call to amr_prolong.

Does this clarify things? If not please feel free to ask again!


Klaus