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
Hi Elizabeth, (Welcome to yt-dev!) On Fri, Feb 24, 2012 at 8:00 PM, Elizabeth Tasker <tasker@astro1.sci.hokudai.ac.jp> wrote:
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.
Yes, this is problematic, and I don't like it either.
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?
The insertion of ValidateSpatial ensures that the data[] fed in will always be 3D.
(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).
I have to think about this. I would very, very much like it to be the case, but it may require some thought and care. Let's sync up on IRC and test it out. We should incorporate this functionality, and other functionality like it, to ensure fidelity of results. This also argues for the idea of having a set of field names that are largely distinct from field names on disk, and that may only coincidentally overlap. As it stands, right now we do a lot of checks like "if field in field_list" which checks a name against another name, but we'd instead want to compare against some external set of keys.
(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?
Yes, ~/.yt/my_plugins.py will be executed at startup. -Matt
Thanks~
Elizabeth _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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 <tasker@astro1.sci.hokudai.ac.jp> wrote:
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
participants (2)
-
Elizabeth Tasker -
Matthew Turk