Hi yt users, I have some basic questions about the units. I'm trying to follow through the cookbook and help site, but some of it isn't working. Namely, the part about having it tell me what units some of the fields are in. When I follow the commands on the page: http://yt.enzotools.org/doc/howto/objects.html This is what happens: In: pf=load("EZ2_0000") In: print(pf.h.field_list) Out: ['z-velocity', 'Temperature', 'Density', 'particle_velocity_z', 'TotalEnergy', 'Dark_Matter_Density', 'particle_position_z', 'x-velocity', 'particle_position_y', 'y-velocity', 'particle_index', 'particle_position_x', 'particle_mass', 'particle_velocity_x', 'particle_velocity_y'] So, I see DM particle fields, which is what I'm interested in. However, when I try to find their units, I get: In: print(pf.field_info["particle_velocity_x"].units) Out: --------------------------------------------------------------------------- AttributeError Traceback (most recent call last) /home/adavis/Research/YT/src/yt-1.7-svn/scripts/iyt in <module>() ----> 1 2 3 4 5 AttributeError: 'DerivedField' object has no attribute 'units' I get the same error for the following fields: [xyz]-velocity, particle_velocity_[xyz], particle_position_[xyz], Density, TotalEnergy, Dark_Matter_Density, and particle_index (ok, this shouldn't have units) When I try the other method of getting at the units: pf.field_info["particle_velocity_x"].get_source() , there is nothing there that says anything about units. Out: def _Particles(field, data): io = data.hierarchy.io if not data.NumberOfParticles > 0: return na.array([], dtype=dtype) try: return io._read_data_set(data, p_field).astype(dtype) except io._read_exception: pass # This is bad. But it's the best idea I have right now. return data._read_data(p_field.replace("_"," ")).astype(dtype) And, while field_info["Density"].get_source() works, the same command for Temperature tells me that the units are g/cm^3, which is obviously wrong. So, my major question: particle positions seem to be in the [0-1] unit system, so conversion is simple for them. Particle velocities, however, are unclear. They look like they're in cm/s, but I'd like to be sure. thanks! Andrew ************************************************************* ** Andrew J. Davis andrew.davis@yale.edu ** ** Dept. of Astronomy 203-432-5119 ** ** Yale University www.astro.yale.edu/adavis ** *************************************************************
Hi Andrew, I'm not sure about the output from get_source, so I'll let someone else comment on that. In general, the units of the fields are in cgs. The exceptions to this are positions, both grid cell and particle positions, and any field that has units implied by the name, such as CellMassMsun. There is a units conversion dict, pf.units, that you can use to convert positions into usable units. For example, multiply position by pf.units['mpc'] to get proper Mpc. Britton On Wed, Aug 25, 2010 at 9:47 AM, Andrew Davis <andrew.davis@yale.edu> wrote:
Hi Andrew, Yes, the particle_velocities_[xyz] are in cm/s, as you guessed. The units definitely need to be included, but as you point out, they aren't. The way to get the string I see now is to actually call: In [3]: pf.field_info["particle_velocity_x"].get_units() Out[3]: '' but as you can see this is empty. Could you fill out a ticket: http://yt.enzotools.org/newticket (you can log in with any OpenID) so that this gets handled? I can't handle it just now, but I'm happy to make sure this is fixed. As to the issue of the positions of the particles -- you raise a good point. As of right now, the positions in yt are mostly done with respect to whatever the code (Enzo, Orion, etc) uses as a natural normalization. For Enzo, this typically means that it's 0..1 in all dimensions. The reason for this is that it was never clear to me when I got started what the "right" thing to do was. It didn't make sense to convert them to some arbitrary normalization, but now it seems to me that it would be and was the right thing to do. I'll say off the bat, I think I like the convention that the lowercase values (particle_position_[xyz]) are in the domain units. This could still be used for things like the kD-tree and whatnot, where the values are easier if kept in some normalized fashion. But then the uppercase: "ParticlePositionX" could be in cm, where the 0,0,0 point is the standard 0,0,0 of the cube. (We could do the same for the field "x", "y", "z", which are currently in domain units, but then "X", "Y", "Z" could be in cm.) What do you, and the others, think? I'd like to move away from domain units on the whole except where explicitly asked for; it requires knowing too much about yt internals to write fields and to handle data. Additionally, in the future I anticipate we'll be modifying the mechanism for accessing particles to allow for accessing directly by particle type. -Matt On Wed, Aug 25, 2010 at 6:57 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi Matt, I like your proposal to have the lower-case coordinate fields to be in the [0,1] domain and the CamelCase in cm. Mainly because I'm used to particle_position_[xyz] being in code units :) I'm willingly to help with the reading specific particle types. I have a standalone parallel Python code that reads only the star particles when OutputParticleTypeGrouping is turned on in Enzo. John
I was wondering if anyone ran into the problem where the angle you view an simulation would ruin the image? I know this is still in beta but just want to know if this is an known issue, or if there's something wrong with what I am doing, or with my YT and I need to reinstall it or something. Specifically, when I try to render an image using an image plane perpendicular to the vector L=[1,1,1] and center [0.5,0.5,0.5] everything looks fine, but if I want a head on view from the x axis of the y,z plane and setting L=[1,0,0] the image is just gibberish. Any thoughts on what I might have done wrong? I was just using the sample script from the cookbook and changing L only, with both the "Simple Volume Rendering" and "Camera Interface" From G.S.
I did an svn up, then python setup.py install yesterday trying to see if an update would fix it, so I was at svn version 1810 yesterday, today it's 1811, even after the yt instinfo -u the problem persists. Do I need to do a new install of YT for the new release or is SVN still keeping me up with latest? From G.S.
Hi G.S., Are you on trunk or 1.7? I thought I fixed both... Rick Wagner was also looking at this a while back and I think he said it was working for him after being broken. You can try a fresh install, but I don't think that would work if updating didn't. :) Are you sure it's updating the right place? -Matt On Wed, Aug 25, 2010 at 1:52 PM, <gso@physics.ucsd.edu> wrote:
Hi Matt, Actually, I think that the last changes you made fixed some cases, but not all of them. Before I went on vacation I was trying to learn how the rendering was implemented, so that I could suggest a fix, rather than just a bug report. My memory is that orthogonal projections may still be having problems. --Rick On Aug 25, 2010, at 1:58 PM, Matthew Turk wrote:
Hi Matt, I made a quick example that produces fine images from an off-axis view, and rather cubist results along x, y or z. The script is posted at http://paste.enzotools.org/show/1120/ and the dataset is RD0007 from the Enzo cookbook. Thanks, Rick On Aug 25, 2010, at 2:34 PM, Matthew Turk wrote:
I was making a movie of rotation about the z axis then the y axis, but got truncated image for the rotation around y. I was going to write a message claiming that I found a bug when I realized what I did wrong: For the first rotation about z, I rotated the camera in the x, y plane and defined -z (0,0,-1) as up, or the "north_vector" to have consistent images as my x-axis YT projections (apparently -z was up in those images). But when I rotated around the y axis I still kept -z as up, and that got me the wrong images because I needed to rotate the camera's up along to stay perpendicular to the line of sight and parallel to the image plane this time. Here's the working version of the script modified from cookbook http://paste.enzotools.org/show/1129/ From G.S.
I think I was using the trunk, because the python I have installed is MacPython2.6, and the MacPython from the 1.7 installation script is 2.5.4. I renamed the old trunk installation script before I downloaded the 1.7, so should I just use the old trunk installation script that uses MacPython 2.6 or switch to 1.7, or get a new trunk installation script from you? From G.S.
I think I was using the trunk, because the python I have installed is MacPython2.6, and the MacPython from the 1.7 installation script is 2.5.4. I renamed the old trunk installation script before I downloaded the 1.7, so should I just use the old trunk installation script that uses MacPython 2.6 or switch to 1.7, or get a new trunk installation script from you? From G.S.
I think I was using the trunk, because the python I have installed is MacPython2.6, and the MacPython from the 1.7 installation script is 2.5.4. I renamed the old trunk installation script before I downloaded the 1.7, so should I just use the old trunk installation script that uses MacPython 2.6 or switch to 1.7, or get a new trunk installation script from you? From G.S.
Hi Andrew, I'm not sure about the output from get_source, so I'll let someone else comment on that. In general, the units of the fields are in cgs. The exceptions to this are positions, both grid cell and particle positions, and any field that has units implied by the name, such as CellMassMsun. There is a units conversion dict, pf.units, that you can use to convert positions into usable units. For example, multiply position by pf.units['mpc'] to get proper Mpc. Britton On Wed, Aug 25, 2010 at 9:47 AM, Andrew Davis <andrew.davis@yale.edu> wrote:
Hi Andrew, Yes, the particle_velocities_[xyz] are in cm/s, as you guessed. The units definitely need to be included, but as you point out, they aren't. The way to get the string I see now is to actually call: In [3]: pf.field_info["particle_velocity_x"].get_units() Out[3]: '' but as you can see this is empty. Could you fill out a ticket: http://yt.enzotools.org/newticket (you can log in with any OpenID) so that this gets handled? I can't handle it just now, but I'm happy to make sure this is fixed. As to the issue of the positions of the particles -- you raise a good point. As of right now, the positions in yt are mostly done with respect to whatever the code (Enzo, Orion, etc) uses as a natural normalization. For Enzo, this typically means that it's 0..1 in all dimensions. The reason for this is that it was never clear to me when I got started what the "right" thing to do was. It didn't make sense to convert them to some arbitrary normalization, but now it seems to me that it would be and was the right thing to do. I'll say off the bat, I think I like the convention that the lowercase values (particle_position_[xyz]) are in the domain units. This could still be used for things like the kD-tree and whatnot, where the values are easier if kept in some normalized fashion. But then the uppercase: "ParticlePositionX" could be in cm, where the 0,0,0 point is the standard 0,0,0 of the cube. (We could do the same for the field "x", "y", "z", which are currently in domain units, but then "X", "Y", "Z" could be in cm.) What do you, and the others, think? I'd like to move away from domain units on the whole except where explicitly asked for; it requires knowing too much about yt internals to write fields and to handle data. Additionally, in the future I anticipate we'll be modifying the mechanism for accessing particles to allow for accessing directly by particle type. -Matt On Wed, Aug 25, 2010 at 6:57 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi Matt, I like your proposal to have the lower-case coordinate fields to be in the [0,1] domain and the CamelCase in cm. Mainly because I'm used to particle_position_[xyz] being in code units :) I'm willingly to help with the reading specific particle types. I have a standalone parallel Python code that reads only the star particles when OutputParticleTypeGrouping is turned on in Enzo. John
I was wondering if anyone ran into the problem where the angle you view an simulation would ruin the image? I know this is still in beta but just want to know if this is an known issue, or if there's something wrong with what I am doing, or with my YT and I need to reinstall it or something. Specifically, when I try to render an image using an image plane perpendicular to the vector L=[1,1,1] and center [0.5,0.5,0.5] everything looks fine, but if I want a head on view from the x axis of the y,z plane and setting L=[1,0,0] the image is just gibberish. Any thoughts on what I might have done wrong? I was just using the sample script from the cookbook and changing L only, with both the "Simple Volume Rendering" and "Camera Interface" From G.S.
I did an svn up, then python setup.py install yesterday trying to see if an update would fix it, so I was at svn version 1810 yesterday, today it's 1811, even after the yt instinfo -u the problem persists. Do I need to do a new install of YT for the new release or is SVN still keeping me up with latest? From G.S.
Hi G.S., Are you on trunk or 1.7? I thought I fixed both... Rick Wagner was also looking at this a while back and I think he said it was working for him after being broken. You can try a fresh install, but I don't think that would work if updating didn't. :) Are you sure it's updating the right place? -Matt On Wed, Aug 25, 2010 at 1:52 PM, <gso@physics.ucsd.edu> wrote:
Hi Matt, Actually, I think that the last changes you made fixed some cases, but not all of them. Before I went on vacation I was trying to learn how the rendering was implemented, so that I could suggest a fix, rather than just a bug report. My memory is that orthogonal projections may still be having problems. --Rick On Aug 25, 2010, at 1:58 PM, Matthew Turk wrote:
Hi Matt, I made a quick example that produces fine images from an off-axis view, and rather cubist results along x, y or z. The script is posted at http://paste.enzotools.org/show/1120/ and the dataset is RD0007 from the Enzo cookbook. Thanks, Rick On Aug 25, 2010, at 2:34 PM, Matthew Turk wrote:
I was making a movie of rotation about the z axis then the y axis, but got truncated image for the rotation around y. I was going to write a message claiming that I found a bug when I realized what I did wrong: For the first rotation about z, I rotated the camera in the x, y plane and defined -z (0,0,-1) as up, or the "north_vector" to have consistent images as my x-axis YT projections (apparently -z was up in those images). But when I rotated around the y axis I still kept -z as up, and that got me the wrong images because I needed to rotate the camera's up along to stay perpendicular to the line of sight and parallel to the image plane this time. Here's the working version of the script modified from cookbook http://paste.enzotools.org/show/1129/ From G.S.
I think I was using the trunk, because the python I have installed is MacPython2.6, and the MacPython from the 1.7 installation script is 2.5.4. I renamed the old trunk installation script before I downloaded the 1.7, so should I just use the old trunk installation script that uses MacPython 2.6 or switch to 1.7, or get a new trunk installation script from you? From G.S.
I think I was using the trunk, because the python I have installed is MacPython2.6, and the MacPython from the 1.7 installation script is 2.5.4. I renamed the old trunk installation script before I downloaded the 1.7, so should I just use the old trunk installation script that uses MacPython 2.6 or switch to 1.7, or get a new trunk installation script from you? From G.S.
I think I was using the trunk, because the python I have installed is MacPython2.6, and the MacPython from the 1.7 installation script is 2.5.4. I renamed the old trunk installation script before I downloaded the 1.7, so should I just use the old trunk installation script that uses MacPython 2.6 or switch to 1.7, or get a new trunk installation script from you? From G.S.
participants (6)
-
Andrew Davis -
Britton Smith -
gso＠physics.ucsd.edu -
John Wise -
Matthew Turk -
Rick Wagner