[FLASH-USERS] Refinement bug on boundaries

[Klaus Weide]

On Fri, 7 Apr 2017, Mark Richardson wrote:

> >
> > Hello everyone,
> >
> >   I've been noticing an issue in blocks that refine on the boundaries, and
> > so I've reduced it to a simple setup that seems to recreate the issue.

Hi Mark,

It seems that either you have misunderstood the purpose of the "DIODE" 
boundary condition, or your are deliberately using it in an unphysical 
way to demonstrate some extreme behavior...

The DIODE bc is intended to be used at boundaries where matter is allow to 
flow out but not in. It acts like OUTFLOW, except that velocity components 
in guard cells get zeroed if they point in the wrong direction.

You are combining a DIODE bc at the left domain boundary with a very large
INWARD POINTING constant velocity as the initial condition. I am not sure 
what you are expecting (and I am not sure what I am expecting) to happen, 
but this is not a physically meaningful situation. (It may not even be a 
a valid discretization of a well-define continuous PDE system. Maybe if you 
used a REFLECTING left boundary...)

So for practical purposes, the answer to this problem is basically "Don't 
do that". I.e., don't use the DIODE bc where it doesn't fit.

Now, the specific kind of strange behavior that you found in this situation
is interesting. Maybe it even points to a potential problem that could 
occur in more physically meaningful situations. While I cannot investigate 
this now, here are some thoughts and pointers:

1) This should be investigated in 1D.
At least I assume the same kind of behavior should appear in 1D.
The values in the first few cells of additional variables should be 
plotted - velx, pres, temp, ener, eint.

2) Don't suppress some messages with 'gr_sanitizeverbosity = 0', there
may be useful warnings there.

3) Does the same behavior occur with Hydro prevented from changing the 
state of the solution, e.e., useHydro=.FALSE. or updateHydroFluxes=.FALSE. ?

4)
> > [Aside: This also leads to an increasing in the integrated internal energy
> > of the box by more than a factor of 20. 

This, and the fact that in your setup e_kin >> e_int, leads to the 
suspicion that the weirdness has something to do with eintSwitch.

Try lowering eintSwitch (possibly to 0.0), and/or set 
use_auxEintEqn=.FALSE.

5)
> >  These refinements are done at the end of step=2, and while the high
> > pressure strip is present in the images I make of the checkpoint file at
> > step=2, they are not present in the images I make of the plotfile at
> > step=2, as the plotfile is generated before the refinements are done. This
> > has convinced me it is the refinements causing the incorrect pressure.

You have nicely narrowed this down to a (possibly indirect) effect of Grid
refinement, so it likely has to do with fine-to-coarse grid interpolation 
of cell data.

The following runtime parameter are related to this and may affect the 
behavior:

# interpol_order    (try 1 or 0)
# convertToConsvdInMeshInterp  (try .FALSE.)
# convertToConsvdForMeshCalls (try either setting with convertToConsvdInMeshInterp .FALSE.)

Also, one could try to set up with -gridinterpolation=native .


> > Any help in understanding why this is happening would be very useful! Is
> > this the expected result for a prolongation on a simulation boundary with
> > diode condition and motion away from the boundary? Or could there be a bug
> > in gr_updateRefinement?

I hope this was useful, and I would be interested in learning what you 
find out if you can do some further investigation.



Klaus