<div dir="ltr">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.<div>

<br></div><div>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.</div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">On Tue, Sep 10, 2013 at 3:16 PM, Cameron Hummels <span dir="ltr"><<a href="mailto:chummels@gmail.com" target="_blank">chummels@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr">Hi everyone,<div><br></div><div>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.</div><div><br></div>

<div>

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.</div>



<div><br></div><div>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.</div>



<div><br></div><div>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.</div>



<div><br></div><div>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.</div>



<div><br></div><div>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.</div><span class="HOEnZb"><font color="#888888"><div>

<br></div><div>Cameron</div><div><br>

</div><div>-- <br>Cameron Hummels<div>Postdoctoral Researcher</div><div>Steward Observatory</div><div>University of Arizona</div><div><a href="http://chummels.org" target="_blank">http://chummels.org</a></div>
</div></font></span></div>
<br>_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
<br></blockquote></div><br></div>