[FLASH-USERS] Problem with applyBCEdge

[James Francis Guillochon]

Ah, this makes complete sense. I will try and fill the GPOT and GPOL  
vars sensibly at the grid boundaries. It seems that self-gravity in  
combination with a wind-condition should be perfectly viable as long  
as the mass contribution from the wind is negligible, so I would think  
by default the code should fill the BCs with the potential calculated  
by the gravity routine (instead of copying neighboring values). The  
caveat would be that one should not trust those values if the mass in  
the wind is comparable to the total mass in the box.

Thanks for your help Klaus, I'll update with my results once I have  
them.

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

On Dec 3, 2009, at 8:59 AM, Klaus Weide wrote:

> 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
>
> !DSPAM:10135,4b17ee7027630021468!
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://flash.rochester.edu/pipermail/flash-users/attachments/20091203/4feb1c48/attachment.htm>