[FLASH-USERS] refinement problems with FLASH 4.2

Thu May 22 20:21:14 EDT 2014

Dear Michael, Dear Matthew,

that's all very well understandable and I basically agree with you that the current behavior in xflash, visit, yt, etc. might actually be the desired behavior. But you see where this gets us: confusion! Strictly speaking this all wrong, of course, because whenever the user tries to slice to something that is NOT a cell center, then one should say: "Ohh, there is no real data where you put your slice and return an error message, prompting the user to define what to do now: nearest neighbor as you seem to prefer or some kind of interpolation. But for practical reasons, visualization should result in something that is the *intuitively* correct answer. That's at least how I feel about visualization. Interpolation is frequently done in image processing. I think interpolation should really be default for visualization, but I don't want to start a philosophical debate about this.

Kind regards,

Christoph

________________________________
Dr. Christoph Federrath
Monash Centre for Astrophysics,
School of Mathematical Sciences,
Monash University,
Clayton, VIC 3800, Australia
+61 3 9905 9760
http://www.ita.uni-heidelberg.de/~chfeder/index.shtml?lang=en

Am 22.05.2014 um 16:38 schrieb Michael Zingale:

> As the one who originally wrote the xflash stuff long long ago (and there are much better tools around now, like yt), I can tell you that I had to work around bugs in IDL to get xflash to NOT interpolate the data.  For a finite-volume dataset, you really don't want to do any interpolation.  The data is the average value in that cell.  Any interpolation that the vis program does is likely not the interpolation that the hydro code is doing when building interface states, etc., so it is probably misleading.  The cell-averages matches the spirit of finite-volume data.
> 
> 
> On Thu, May 22, 2014 at 7:29 PM, Christoph Federrath <christoph.federrath at monash.edu> wrote:
> 
> Hi Klaus, Hi Thomas,
> 
> yes, this is exactly what's happening. I assumed Visit performs an interpolation by default, but that's apparently not the case and neither does xflash (apparently also yt doesn't perform interpolation by default). Using my own projection and slicer based on QuickFLASH, I produced a properly interpolated slice of velz at z=0 and voila, out comes the correct answer: noise around zero with an amplitude of 10^-12, i.e., the actual z-velcoity at z=0 is indeed zero, close to machine precision, as it should.
> 
> Attached is my reproduction of the problem in visit (without interpolation, directly plotted from the FLASH plot file) and the other image is exactly the same, but first I extract a slice with my projection/slicer tool using QuickFLASH (properly interpolated) and then plot the image of that slice in visit.
> 
> What do we learn from that? When slicing a finite-volume simulation, the tool should really perform an interpolation, i.e. it should take a slice with a finite thickness of dx at the highest level of AMR. Otherwise, the result is simply an unpredictable thing: either it plots the value from the cell at z = 0 + eps or z = 0 - eps, which are of course different. An interpolation helps to avoid this behavior.
> 
> Kind regards,
> 
> Christoph
> 
> 
> 
> ________________________________
> Dr. Christoph Federrath
> Monash Centre for Astrophysics,
> School of Mathematical Sciences,
> Monash University,
> Clayton, VIC 3800, Australia
> +61 3 9905 9760
> http://www.ita.uni-heidelberg.de/~chfeder/index.shtml?lang=en
> 
> 
> Am 22.05.2014 um 15:22 schrieb Klaus Weide:
> 
> > On Thu, 22 May 2014, Thomas Peters wrote:
> >
> >> Dear Kevin, Christoph and John,
> >>
> >> the attached slice shows that the density field is smooth across refinement
> >> boundaries. Since the velocity field jumps across the boundary, the momentum
> >> must jump as well.
> >>
> >> I have also attached slices at exactly z = 0, as well as at 10 and 20 times
> >> the finest grid size off the midplane. The effect is still clearly visible,
> >> there are just fewer jumps in refinement in that region.
> >>
> >> I would not call this "noise" since in these slices, the z-velocity is of the
> >> same size as the x- and y-velocities were in the previous slices.
> >
> > I just finished looking (with Sean Couch) at a different 3D problem, but
> > with the same kind of symmetry - a central plane z = 0 where z-velocities
> > should vanish. We saw the same kinds of behavior in z-slices of velz taken
> > at close to z=0 with Visit.
> >
> > We came to the conclusion that the apparent jumps in velz are exactly
> > what one would expect, given the following assumptions:
> >  (1) slices are just showing cell values, without interpolation.
> >  (2) requesting a slice at exactly z=0.0 actually gives you the same
> >      slice as either z=0.0+epsilon or 0.0-epsilon (since z=0.0 is a cell
> >      boundary).
> >  (3) Cell values represent volume averages.
> >      (The cell value of velz should actually be interpreted, strictly
> >      speaking, as <mom_z> / <dens>, where <*> means volume average, but
> >      I don't think it matters here that this is different from <velz>.)
> >
> > Basically we think that Christoph's explanation is correct and FLASH 4.2
> > is behaving as it should, for a finite volume representation of data on
> > an AMR grid.
> >
> > I would expect slices to look substantially different when using a tool
> > that actually does a (correct) linear interpolation of the cell values.
> >
> >> Not sure if this helps, but I have not seen this effect in any of the collapse
> >> simulations I have run with FLASH 2.5.
> >
> > It would be really surprising if these kinds of apparent jumps were
> > absent from FLASH2.5 checkpoint or plot files (at the same resolution and
> > otherwise comparable, viewed with the same kind of tool). Can you confirm
> > that that is the case?
> >
> > Klaus
> 
> 
> 
> 
> 
> -- 
> Michael Zingale
> Associate Professor
> 
> Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800
> phone:  631-632-8225
> e-mail: Michael.Zingale at stonybrook.edu
> web: http://www.astro.sunysb.edu/mzingale