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 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

Hi Cameron, On Tue, Sep 10, 2013 at 6:16 PM, Cameron Hummels 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org