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

Matthew Turk matthewturk at gmail.com
Tue Sep 10 15:32:00 PDT 2013


On Tue, Sep 10, 2013 at 6:21 PM, Nathan Goldbaum <nathan12343 at gmail.com> wrote:
> 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.

Probably not too bad, but it's worth keeping in mind that
reconstructing the correct Zeus values would require ghost zones,
since one zone is stripped off before being written to disk.

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

Getting a proper treatment of cell/face/edge fields is necessary, but
the way Zeus in Enzo is written to disk makes it quite difficult in
practice.

I don't have a good answer to the rest.  Perhaps Elizabeth or Greg might?

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