[FLASH-USERS] Error in AMR Prolong Routine

[James Guillochon]

Thanks for the informative reply, Klaus. It is looking more and more  
that this was an issue of memory corruption of some sort, although I  
am still baffled as to how it was happening at the exact same point in  
execution, and how it spontaneously went away. If it recurs again, I  
will investigate the issue more deeply; however it seems that the  
error must have been occurring in the amr_prolong routine if the  
routine itself is responsible for filling the GCs with sane values.

Thanks again!

-- 
James Guillochon
Department of Astronomy & Astrophysics
University of California, Santa Cruz
jfg at ucolick.org

On May 1, 2009, at 2:43 PM, Klaus Weide wrote:

> 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
>
> !DSPAM:10135,49fb6d1125597021468!
>