[FLASH-USERS] refinement problems with FLASH 4.2

Fri May 23 10:49:11 EDT 2014

I agree with Sean. I might add that having the default behavior be that of yt allows one to generate interpolated maps "by hand," whereas having the interpolation happen inside the library forestalls this possibility.

Paul

Paul M. Ricker
Associate Professor of Astronomy
University of Illinois
http://sipapu.astro.illinois.edu/~ricker

-------- Original message --------
From: Sean Couch
Date:05/23/2014 9:32 AM (GMT-06:00)
To: John ZuHone
Cc: Michael Zingale ,flash-users at flash.uchicago.edu
Subject: Re: [FLASH-USERS] refinement problems with FLASH 4.2

At the risk of unnecessarily expanding this discussion, let me lead off by saying I think everybody’s right.  And I think the summary is as follows.  Visualization generally serves two, arguably distinct purposes:  analysis and presentation.  For analysis we care very much about quantitative accuracy.  For presentation, we care that it looks good and conveys the right qualitative impressions.  Inarguably, for the former purpose the default behavior of yt, VisIt, and FIDLR is best, whereas for presentation purposes one might prefer the interpolation a al Christoph’s QuickFlash slice.  Now for me, I spend the vast majority of my time doing visualization for the purpose of analysis and verification, making sure my sims are behaving as I expect.  Then at the end I spend some smaller amount of time making pretty viz for papers, movies, etc.  So, from my point of view the default behavior of a slice operator should be nearest-neighbor.  This, in and of itself, does not engender confusion rather it’s the lack of the user’s awareness that this is the behavior of the operator that can lead to confusion.  It did for me until Klaus and I convinced ourselves of what exactly VisIt was doing.  Now, the documentation for VisIt is atrocious, but I’d bet a shiny penny that the default behavior of yt’s slice operator is spelled out explicitly and clearly somewhere in the voluminous yt docs.

Sean

--------------------------------------------------------
Sean M. Couch
Hubble Fellow
Flash Center for Computational Science
Department of Astronomy & Astrophysics
The University of Chicago
5747 S Ellis Ave, Jo 315
Chicago, IL  60637
(773) 702-3899
www.flash.uchicago.edu/~smc<http://www.flash.uchicago.edu/~smc>

On May 22, 2014, at 8:19 PM, John ZuHone <jzuhone at milkyway.gsfc.nasa.gov<mailto:jzuhone at milkyway.gsfc.nasa.gov>> wrote:

I guess the point is that if you were doing interpolation by default, you might not catch actual bugs (say at block boundaries) that might otherwise be smoothed out by the interpolation. I can imagine some bugs related to divB in MHD simulations at block boundaries that this might cover up.

If this situation were a real bug, then we might not have ever found it.

On May 22, 2014, at 8:21 PM, Christoph Federrath <christoph.federrath at monash.edu<mailto:christoph.federrath at monash.edu>> wrote:

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

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