<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div><br></div><div>Thanks for your help Klaus, I'll update with my results once I have them.<br><div><div> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div><br class="Apple-interchange-newline">-- <br>James Guillochon<br>Department of Astronomy & Astrophysics<br>University of California, Santa Cruz<font class="Apple-style-span" color="#144FAE"><span class="Apple-style-span" style="text-decoration: underline; -webkit-text-decorations-in-effect: underline; "><br></span></font></div><div><a href="mailto:jfg@ucolick.org">jfg@ucolick.org</a></div></span> </div><br><div><div>On Dec 3, 2009, at 8:59 AM, Klaus Weide wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Wed, 2 Dec 2009, James Guillochon wrote:<br><br><blockquote type="cite">Disabling gravity seems to have gotten rid of the artifacts. I notice <br></blockquote><blockquote type="cite">from an earlier posting <br></blockquote><blockquote type="cite">(<a href="http://flash.uchicago.edu/pipermail/flash-users/2008-July/002592.html">http://flash.uchicago.edu/pipermail/flash-users/2008-July/002592.html</a>) <br></blockquote><blockquote type="cite">that you say the grid topology for the multigrid and the <br></blockquote><blockquote type="cite">grav_boundary_type must match, is the same true for multipole?<br></blockquote><br>James,<br><br>That message dealt mainly with the non-support for combinations of <br>periodic Grid boundary conditions (for Hydro) with non-periodic boundary<br>conditions for Gravity, and non-periodic Grid BCs with periodic Gravity <br>BCs. That doesn't really apply to your setup, since with the Multipole <br>Poisson solver, only "isolated" Gravity BCs are supported anyway. (And you <br>are not trying to combine them with "periodic" Grid boundary conditions...)<br><br>I think now that a likely cause of your artifacts is the following: <br>When you add a self-gravity solver to you setup, some additional variables<br>are added to UNK. In particular, GPOT_VAR. Your boundary condition <br>routine probably does not do anything to initialize the guard cells for <br>this variable, but silently leaves them initialized.<br><br>At other boundaries, where you don't use the USER_DEFINED type, guard <br>cells for gpot are initialized as for other variables, e.g. by copying <br>appropriate values from interior cells for OUTFLOW or REFLECTING. So <br>nothing goes as obviously wrong as in the USER_DEFINED case, since<br>gpot has somewhat plausible values. HOWEVER, that still doesn't mean<br>that the behavior is really correct. After all, the gpot values are used <br>to derive accelerations (by finite-differencing of values in different <br>cells) which then influence the dynamics (see Gravity_accelOneRow.F90),<br>and the accelerations (or think of them as forces) introduced this way<br>may be quite unphysical. (Maybe GPOT_VAR should be handled at your <br>boundaries like<br><br> case(GRIDBC_MG_EXTRAPOLATE)<br><br>is handled in the default <br>Grid/GridBoundaryConditions/Grid_bcApplyToRegion.F90 file?)<br><br>One may wonder why the default boundary conditions implementations, as <br>well as examples like what you found in WindTunnel, don't do anything more <br>sensible with GPOT_VAR. I think the answer is that using self-gravity in <br>a domain where there is anything significant happening at the boundaries<br>is basically not a supported combination.<br><br>Btw., everything above about GPOT_VAR may equally apply to GPOL_VAR.<br>I.e., you may need to initialize guard cell values ad boundaries for that <br>variable, too.<br><br><br><blockquote type="cite">The work-around that I see at the moment is to just set the xl boundary <br></blockquote><blockquote type="cite">to diode and then reset the left-most cells within the actual domain <br></blockquote><blockquote type="cite">(not the ghost cells) using Driver_sourceTerms, but I would prefer to <br></blockquote><blockquote type="cite">modify the edge boundary conditions themselves to make things work. <br></blockquote><br>I don't think your planned workaround would work - Hydro, at least, <br>requires values in several layers of guard cells (up to 4, in the default <br>split PPM Hydro!), and obviously you won't feed the right input to Hydro <br>for cells close to boundaries if you try to only "fix" interior cells.<br><br><br>Klaus<br><br>!DSPAM:10135,4b17ee7027630021468!<br><br></div></blockquote></div><br></div></div></body></html>