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

[Nathan Goldbaum]

I think the cleanest way to deal with this would be to override the
[x,y,z]-velocity fields provided by Zeus datasets and from them derive
cell-centered velocities, which, for a given cell, should be the arithmetic
mean of the velocities at the neighboring cell faces.

This would allow us to get rid of all of the silly pf['HydroMethod'] == 2
checks we have in the field definitions.  Not sure how hard it would be to
implement in practice.


On Tue, Sep 10, 2013 at 3: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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20130910/387d54eb/attachment.html>