[FLASH-USERS] Problem with applyBCEdge

[Klaus Weide]

On Wed, 2 Dec 2009, James Guillochon wrote:

> Disabling gravity seems to have gotten rid of the artifacts. I notice 
> from an earlier posting 
> (http://flash.uchicago.edu/pipermail/flash-users/2008-July/002592.html) 
> that you say the grid topology for the multigrid and the 
> grav_boundary_type must match, is the same true for multipole?

James,

That message dealt mainly with the non-support for combinations of 
periodic Grid boundary conditions (for Hydro) with non-periodic boundary
conditions for Gravity, and non-periodic Grid BCs with periodic Gravity 
BCs.  That doesn't really apply to your setup, since with the Multipole 
Poisson solver, only "isolated" Gravity BCs are supported anyway. (And you 
are not trying to combine them with "periodic" Grid boundary conditions...)

I think now that a likely cause of your artifacts is the following: 
When you add a self-gravity solver to you setup, some additional variables
are added to UNK. In particular, GPOT_VAR.  Your boundary condition 
routine probably does not do anything to initialize the guard cells for 
this variable, but silently leaves them initialized.

At other boundaries, where you don't use the USER_DEFINED type, guard 
cells for gpot are initialized as for other variables, e.g. by copying 
appropriate values from interior cells for OUTFLOW or REFLECTING.  So 
nothing goes as obviously wrong as in the USER_DEFINED case, since
gpot has somewhat plausible values.  HOWEVER, that still doesn't mean
that the behavior is really correct. After all, the gpot values are used 
to derive accelerations (by finite-differencing of values in different 
cells) which then influence the dynamics (see Gravity_accelOneRow.F90),
and the accelerations (or think of them as forces) introduced this way
may be quite unphysical.  (Maybe GPOT_VAR should be handled at your 
boundaries like

           case(GRIDBC_MG_EXTRAPOLATE)

is handled in the default 
Grid/GridBoundaryConditions/Grid_bcApplyToRegion.F90 file?)

One may wonder why the default boundary conditions implementations, as 
well as examples like what you found in WindTunnel, don't do anything more 
sensible with GPOT_VAR.  I think the answer is that using self-gravity in 
a domain where there is anything significant happening at the boundaries
is basically not a supported combination.

Btw., everything above about GPOT_VAR may equally apply to GPOL_VAR.
I.e., you may need to initialize guard cell values ad boundaries for that 
variable, too.


> The work-around that I see at the moment is to just set the xl boundary 
> to diode and then reset the left-most cells within the actual domain 
> (not the ghost cells) using Driver_sourceTerms, but I would prefer to 
> modify the edge boundary conditions themselves to make things work. 

I don't think your planned workaround would work - Hydro, at least, 
requires values in several layers of guard cells (up to 4, in the default 
split PPM Hydro!), and obviously you won't feed the right input to Hydro 
for cells close to boundaries if you try to only "fix" interior cells.


Klaus