[FLASH-USERS] Error in AMR Prolong Routine

[Klaus Weide]

On Thu, 30 Apr 2009, James Guillochon wrote:

> Problem solved! So it seems the problem was that the gr_updateRefinement
> routine does not sanitize the guard cells. So if you happen to derefine a
> block that has density values close to smlrho, it is possible that guard cells
> will end up with 0 density values and will never be sanitized. This is
> resolved by changing a line in gr_updateRefinement from this:
> 
> call gr_sanitizeDataAfterInterp(gr_blkList, numLeafBlocks, 'after
> amr_prolong', 0, 0, 0)
> 
> to this:
> call gr_sanitizeDataAfterInterp(gr_blkList, numLeafBlocks, 'after
> amr_prolong', NGUARD, NGUARD, NGUARD)

James,

It is very surprising that you should get such an effect from changing the 
last three arguments to gr_sanitizeDataAfterInterp!  That subroutine (in 
spite of its name) does not modify any data at all, it only does some 
simple checks of variable values after (in this case) prolongation,
and produces warning messages if it finds suspicious values.

Your change would simply increase the number of cells to which the checks 
apply, from all interior cells to all cells (including guard cells).

Have you perhaps made some other changes at the same time that could
explain why your problem disappeared?


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.)


Finally a caveat, the calling convention for gr_sanitizeDataAfterInterp
has changed slightly in FLASH3.1 and later; the last three integer 
arguments are now replaced by an integer array.  This shouldn't matter
as long as you don't mix source files from different releases in the
same Grid source subtree (definitely not recommended!), but it explains
why the calls quoted above (from FLASH3.0) look different in the most 
recent code.

Klaus