I meant to add that I ran the script below on an isolated galaxy disc
with radius 12 kpc, smallest cell size of 8pc and a steep velocity
gradient in the radial direction. With a small sphere radius around 20
pc, then the difference between zeus-adjusted and non-zeus is not at
all bad:
x: 0.966613809275
y: 0.9929356881
z: 0.611797194496
(z-direction is not well resolved).
But scale that up to 1 kpc and it's more dramatic:
x: 0.51838881789
y: 1.57845583686
z: 4.74831176192
Elizabeth
On 24 February 2012 20:00, Elizabeth Tasker
Hi,
I wanted to discuss a possibly more consistent way of dealing with velocities in yt when analysing a simulation with Enzo's Zeus hydro scheme (HydroMethod = 2).
Because Zeus' velocities are face-centred, not cell centred, there is a half-cell off-set that the routines in yt sometimes allow for and sometimes do not. For instance, the DivV does allow for Zeus' off-set but the calculation of the SpecificAngularMomentum does not. I often hit this problem when examining objects with yt. Either I have to pretend Zeus has cell-centred velocities or write a new routine which is a nuisance.
I was wondering if we could introduce a universal field that cell-centred Zeus' velocities. I think it would look like this:
http://paste.yt-project.org/show/2192/
But, I have three questions:
(1) Does the scheme (using the slice(None, -1, None) for arrays) work if "data" is not a continuous region, e.g. a collection of cells made through extract_region?
(2) Could this be implemented such that, if you were using Zeus, the universal fields "x-velocity", "y-velocity" and "z-velocity" were over-written by these new definitions? (If that was done throughout yt, then other references to Zeus in routines like DivV would have to be removed. This is probably still easier than adding in new ones everywhere).
(3) Is it possible for me to do that on my own local version? e.g. can I put field definitions in a folder to over-write the default yt ones?
Thanks~
Elizabeth