<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap:break-word">
<div>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.</div>
<div><br>
</div>
<div>Paul</div>
<div><br>
</div>
<div><br>
</div>
<div style="font-size:8px">Paul M. Ricker</div>
<div style="font-size:8px">Associate Professor of Astronomy</div>
<div style="font-size:8px">University of Illinois</div>
<div style="font-size:8px">http://sipapu.astro.illinois.edu/~ricker</div>
<br>
<br>
<div>-------- Original message --------</div>
<div>From: Sean Couch </div>
<div>Date:05/23/2014 9:32 AM (GMT-06:00) </div>
<div>To: John ZuHone </div>
<div>Cc: Michael Zingale ,flash-users@flash.uchicago.edu </div>
<div>Subject: Re: [FLASH-USERS] refinement problems with FLASH 4.2 </div>
<div><br>
</div>
<div>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.
<div><br>
</div>
<div>Sean<br>
<div>
<div style="color:rgb(0,0,0); font-family:Helvetica; font-style:normal; font-variant:normal; font-weight:normal; letter-spacing:normal; line-height:normal; orphans:2; text-indent:0px; text-transform:none; white-space:normal; widows:2; word-spacing:0px; word-wrap:break-word">
<span class="Apple-style-span" style="color:rgb(0,0,0); font-family:Helvetica; font-style:normal; font-variant:normal; font-weight:normal; letter-spacing:normal; line-height:normal; orphans:2; text-indent:0px; text-transform:none; white-space:normal; widows:2; word-spacing:0px; border-collapse:separate; border-spacing:0px"><span class="Apple-style-span" style="border-collapse:separate; color:rgb(0,0,0); font-family:Helvetica; font-style:normal; font-variant:normal; font-weight:normal; letter-spacing:normal; line-height:normal; orphans:2; text-indent:0px; text-transform:none; white-space:normal; widows:2; word-spacing:0px; border-spacing:0px">
<div style="word-wrap:break-word">
<div><br class="Apple-interchange-newline">
--------------------------------------------------------</div>
<div>Sean M. Couch</div>
<div>Hubble Fellow</div>
<div>Flash Center for Computational Science</div>
<div>Department of Astronomy & Astrophysics</div>
<div>The University of Chicago</div>
<div>5747 S Ellis Ave, Jo 315</div>
<div>Chicago, IL 60637</div>
<div>(773) 702-3899</div>
<div><a href="http://www.flash.uchicago.edu/~smc">www.flash.uchicago.edu/~smc</a></div>
<div><br>
</div>
</div>
</span></span></div>
<br class="Apple-interchange-newline">
<br class="Apple-interchange-newline">
</div>
<br>
<div>
<div>On May 22, 2014, at 8:19 PM, John ZuHone <<a href="mailto:jzuhone@milkyway.gsfc.nasa.gov">jzuhone@milkyway.gsfc.nasa.gov</a>> wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">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. <br>
<br>
If this situation were a real bug, then we might not have ever found it. <br>
<br>
On May 22, 2014, at 8:21 PM, Christoph Federrath <<a href="mailto:christoph.federrath@monash.edu">christoph.federrath@monash.edu</a>> wrote:<br>
<br>
<blockquote type="cite"><br>
Dear Michael, Dear Matthew,<br>
<br>
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.<br>
<br>
Kind regards,<br>
<br>
Christoph<br>
<br>
________________________________<br>
Dr. Christoph Federrath<br>
Monash Centre for Astrophysics,<br>
School of Mathematical Sciences,<br>
Monash University,<br>
Clayton, VIC 3800, Australia<br>
+61 3 9905 9760<br>
<a href="http://www.ita.uni-heidelberg.de/~chfeder/index.shtml?lang=en">http://www.ita.uni-heidelberg.de/~chfeder/index.shtml?lang=en</a><br>
<br>
<br>
Am 22.05.2014 um 16:38 schrieb Michael Zingale:<br>
<br>
<blockquote type="cite">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.<br>
<br>
<br>
On Thu, May 22, 2014 at 7:29 PM, Christoph Federrath <christoph.federrath@monash.edu> wrote:<br>
<br>
Hi Klaus, Hi Thomas,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Kind regards,<br>
<br>
Christoph<br>
<br>
<br>
<br>
________________________________<br>
Dr. Christoph Federrath<br>
Monash Centre for Astrophysics,<br>
School of Mathematical Sciences,<br>
Monash University,<br>
Clayton, VIC 3800, Australia<br>
+61 3 9905 9760<br>
http://www.ita.uni-heidelberg.de/~chfeder/index.shtml?lang=en<br>
<br>
<br>
Am 22.05.2014 um 15:22 schrieb Klaus Weide:<br>
<br>
<blockquote type="cite">On Thu, 22 May 2014, Thomas Peters wrote:<br>
<br>
<blockquote type="cite">Dear Kevin, Christoph and John,<br>
<br>
the attached slice shows that the density field is smooth across refinement<br>
boundaries. Since the velocity field jumps across the boundary, the momentum<br>
must jump as well.<br>
<br>
I have also attached slices at exactly z = 0, as well as at 10 and 20 times<br>
the finest grid size off the midplane. The effect is still clearly visible,<br>
there are just fewer jumps in refinement in that region.<br>
<br>
I would not call this "noise" since in these slices, the z-velocity is of the<br>
same size as the x- and y-velocities were in the previous slices.<br>
</blockquote>
<br>
I just finished looking (with Sean Couch) at a different 3D problem, but<br>
with the same kind of symmetry - a central plane z = 0 where z-velocities<br>
should vanish. We saw the same kinds of behavior in z-slices of velz taken<br>
at close to z=0 with Visit.<br>
<br>
We came to the conclusion that the apparent jumps in velz are exactly<br>
what one would expect, given the following assumptions:<br>
(1) slices are just showing cell values, without interpolation.<br>
(2) requesting a slice at exactly z=0.0 actually gives you the same<br>
slice as either z=0.0+epsilon or 0.0-epsilon (since z=0.0 is a cell<br>
boundary).<br>
(3) Cell values represent volume averages.<br>
(The cell value of velz should actually be interpreted, strictly<br>
speaking, as <mom_z> / <dens>, where <*> means volume average, but<br>
I don't think it matters here that this is different from <velz>.)<br>
<br>
Basically we think that Christoph's explanation is correct and FLASH 4.2<br>
is behaving as it should, for a finite volume representation of data on<br>
an AMR grid.<br>
<br>
I would expect slices to look substantially different when using a tool<br>
that actually does a (correct) linear interpolation of the cell values.<br>
<br>
<blockquote type="cite">Not sure if this helps, but I have not seen this effect in any of the collapse<br>
simulations I have run with FLASH 2.5.<br>
</blockquote>
<br>
It would be really surprising if these kinds of apparent jumps were<br>
absent from FLASH2.5 checkpoint or plot files (at the same resolution and<br>
otherwise comparable, viewed with the same kind of tool). Can you confirm<br>
that that is the case?<br>
<br>
Klaus<br>
</blockquote>
<br>
<br>
<br>
<br>
<br>
-- <br>
Michael Zingale<br>
Associate Professor<br>
<br>
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800<br>
phone: 631-632-8225<br>
e-mail: Michael.Zingale@stonybrook.edu<br>
web: http://www.astro.sunysb.edu/mzingale<br>
</blockquote>
<br>
</blockquote>
</blockquote>
</div>
<br>
</div>
</div>
</body>
</html>