[yt-users] yt's treatment of enzo velocity data: Zeus vs PPM

Matthew Turk matthewturk at gmail.com
Thu Sep 19 06:12:46 PDT 2013


Hi Cameron,

On Tue, Sep 10, 2013 at 6:16 PM, Cameron Hummels <chummels at gmail.com> wrote:
> Hi everyone,
>
> This is a pretty technical question about the differences in how yt deals
> with enzo velocity data, both those created using the Zeus or the PPM
> backends.
>
> As I understand it, PPM creates all fields, including velocity fields, as
> cell-centered quantities.  On the other hand, Zeus creates all fields as
> cell-centered quantities, except velocity fields, which are defined as the
> left-face of each corresponding cell.  If I'm wrong about this, then stop me
> here.
>
> Since for the most part, yt treats PPM and Zeus datafiles identically
> (although there are a few exceptions to this, which I'll talk about below),
> it seems that analyzing or visualizing a velocity field from a Zeus dataset
> is actually wrong, albeit only by half a cell size.  So if one makes a slice
> of "x-velocity" or something like that, to get the *true* velocity slice,
> everything should be shifted over to the left by one-half of one cell width,
> yes?  I'm not grouching about this; I'm just curious if this is true.
>
> The problem I see is when one starts to deal with derived fields which rely
> upon both spatial and velocity fields, such as DivV or Shear, which require
> use of "dx" or "soundspeed" value for a cell (cell centered), for combining
> with velocity data for a cell (edge-centered).  Yes, these are small
> precision problems, but as I'm finishing up the Shear derived field, I want
> to make sure it's correct as opposed to just approximate.
>
> I guess one solution to this would be to provide a corrected version of the
> velocity fields in yt (when reading in Zeus data), which trilinearly
> interpolates edge-centered data so as to get cell-centered data?  Or have
> people already thought about this and done it?  Or is it too small of an
> effect and people just haven't worried about it?  Elizabeth, I saw you had
> talked about this in the past for Zeus-based fields.
>
> Just curious to bounce this off some more heads before I barrel through with
> this interpolation, since it may break old results made from enzo zeus data.

I've done some thinking about this and chatted with others about it.
I think you have a few options.

 * Live with the existing situation, which is that ZEUS fields will
always correspond to one face.  For fields that utilize ghost zones,
this is actually workable, as the ghost zone generation will follow
the same procedure that Enzo does internally for generating boundary
zones.  So as long as your stencil is correct (i.e., it knows about
face-centered values) it will reflect what Enzo would calculate
internally.
 * Create *new* fields in yt that are ValidateSpatial(1) that generate
cell-centered velocities for Zeus data.  This will slow down any
access considerably, as the boundary zones would be created before any
velocity could be queried.  However, if you instruct Enzo to write out
ghost zones to disk, yt will utilize that and it should be
considerably faster (although still slower since the computation of
cell-centered values will still need to occur.)
 * Modify how Enzo writes out ZEUS fields, such that it writes out /
reads in the *internal* fields as some other name ("face-x-velocity"
for instance) and then writes out a cell-centered average as the
original field name.  This would break backwards compatibility, but I
suspect it would be manageable via modifying the version number
written in the Enzo parameter file.

Let me know if you decide one of these is a good idea and want some help.

-Matt

>
> Cameron
>
> --
> Cameron Hummels
> Postdoctoral Researcher
> Steward Observatory
> University of Arizona
> http://chummels.org
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>



More information about the yt-users mailing list