[FLASH-USERS] refinement problems with FLASH 4.2

[Matthew Turk]

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).

Yup, yt does not, and it's an intentional design decision.  When
slicing at grid refinement boundaries, yt will preferentially select
the grid that satisfies:

left_edge[self.axis] <= slice_coord < right_edge[self.axis]

> 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
>
>