[FLASH-USERS] cell density goes to zero when refining several times

Klaus Weide klaus at flash.uchicago.edu
Wed May 28 15:50:19 EDT 2014


On Wed, 28 May 2014, Andrea Gatto wrote:

> Dear all,
> 
> I'm running a simulation with FLASH 4.0.1 of a turbulent interstellar medium.
> 
> For different reasons, some regions of my domain are refined several times
> during the evolution (nrefs=2), so that every two timesteps blocks in the
> same region are refined, derefined, refined again etc.
> 
> After few hundreds timesteps, however, the code crashes due to a steep
> increase in internal and kinetic energy.
> Every time I checked, I found that a single/few cells belonging to one of
> this highly time-varying blocks show a density that rapidly goes to zero
> and a subsequent explosion in temperature and velocity.
> 
> I tried several solutions, such as the inclusion of guard cells filling
> routines in different parts of the code, but the problem remains.
> 
> This doesn't happen when the blocks are not refined so often.
> 
> Do you have any idea on how to solve this problem?

Andrea,

First of all, I think a situation like this should be avoided if at all 
possible. I.e., don't refine-then-derefine the same region so many times.

Second, the behavior will likely depend on the Hydro version you are using 
and its runtime parameters, like "order", "RiemannSolver", etc. if you are
using unsplit Hydro. Others will be better able to give guidance here.

Third, the following MAY be helpful for circumventing or analyzing the
problematic behavior:
In FLASH4.2, we have added two runtime parameter to make it easier to
deal with situations where some invalid values start appearing in density
(also, total and internal energy). Note that the mode that "fixes" data
by flooring, gr_sanitizeDataMode=3, has not been tested much in practice.

Excerpt from source/Grid/GridMain/paramesh/paramesh4/Config :

========================================================================
D gr_sanitizeDataMode What to do when gr_sanitizeDataAfterInterp is called
D & to check for acceptable values in the dens, ener, and eint cell-centered variables
D & after a Grid operation may have resulted in grid interpolation.
D & 0: Do nothing.
D & 1: Check (if variable is not masked out) and report (see sanitizeVerbosity).
D & 2: Check (ignoring variable mask) and report (see sanitizeVerbosity).
D & 3: Check (if variable is not masked out) and fix (apply floor value).
D & 4: Check (if variable is not masked out) and abort if cell is found below floor value.
PARAMETER gr_sanitizeDataMode   INTEGER 1       [0,1,2,3,4]

D gr_sanitizeVerbosity How to write information about unacceptable
D & values in the dens, ener, and eint cell-centered variables if gr_sanitizeDataAfterInterp
D & finds value that are below the acceptable floor.
D & This reporting is in addition to other actions selected with gr_sanitizeDataMode=3 or 4.
D & 0: Be quiet.
D & 1: Only write a log file message per block if unacceptable value found on MASTER_PE.
D & 4: As 1, and each proc writes a line to standard output for each block with bad values.
D & 5: As 4, and each proc writes lines showing the values in all cells of the block (in 1D/2D)
D & 5: or a 2D slice (in 3D).
PARAMETER gr_sanitizeVerbosity  INTEGER 5       [0,1,4,5]
========================================================================

HTH,
Klaus



More information about the flash-users mailing list