[FLASH-USERS] Problem with applyBCEdge

[James Guillochon]

An update:

Simply setting the GPOT and GPOL vars as an outflow condition (e.g., equal to the closest interior cell value) solves the problem described previously in this thread. However, as Klaus mentioned, these values are not really correct because the potential there should still depend on the position.

I have been fiddling around with the gr_mpolePotential routine, and I changed the routine to loop over all cells (including ghost cells) and filling them with the potential. I then am preventing gr_bcPutRegion from modifying the ghost cells in unk1. Unfortunately, this approach does not seem to work; the values in these ghost cells still appear to be "garbage" values. Are there any other places in the code where the boundary cells are set besides bcPutRegion that would be overwriting the potential calculated by gr_mpolePotential?

One thing I tried was expanding the size of the multipole expansion region to include the boundary cells, but this doesn't seem to affect the results. Another thing I tried was filling in the potential values directly using gr_zonePotential, but the multipole expansion is not available during the initial construction of the grid, and additionally there would be no easy way to fill GPOL properly using this method.

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

On Dec 3, 2009, at 9:12 AM, James Francis Guillochon wrote:

> 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,4b17f18d28430245126300!

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