<div dir="ltr">Klaus,<div> <br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I intend to apply your changes to the FLASH code base, so they can be<br>
included in the next FLASH release if no unexpected problems show up.<br></blockquote><div><br></div><div>Thank you for your response and for being willing to add this to the public distribution.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
</span>There is code in states.F90 that takes geometry into account (lines<br>
related to 'dloga'). Have you considered those "corrections" to states "to<br>
include geometry terms"?  Do they address part of your concern?<br></blockquote><div><br></div><div>My understanding is that those terms are there to correct the domain of dependence for geometry when computing the 'modified states' for the Riemann solution.</div><div><br></div><div>The point about the reconstruction is a separate one. For consistency with the Eulerian formulation of the hydrodynamic equations in conservative form, the PPM polynomial that yields the first guess at the zone interface value should assume that the independent coordinate $\xi$ is the volume. Otherwise the interface value does not arise out of volume-average values.</div><div><br></div><div>Colella & Woodward (1984) mention this explicitly in their paper (third paragraph of section 3) when discussing the Eulerian formulation of PPM. It just so happens that when using cartesian coordinates, the volume is proportional to the coordinate. </div><div><br></div><div>The subroutine coeff.F90 takes the coordinate increments (dx) as input to compute the coefficients.</div><div><br></div><div>Perhaps someone already thought about this a long time ago and I'm inventing the wheel here...</div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(Of course, users should always make sure the resolution is good enough<br>
for their purposes, no matter how accurately the methods represents<br>
something like coordinate-dependent transverse areas in curvilinear<br>
coordinates!)<span><font color="#888888"><br></font></span></blockquote><div><br></div><div>Agree. The code does give the right answer at sufficiently high resolution, of that I'm sure because I've tested it in 2D (and recently in 3D). There is some irreducible level of noise under some circumstances, but nothing too serious. </div><div><br></div><div>Best,</div><div><br></div><div>Rodrigo</div><div><br></div></div></div></div>