Ok, I think I finally have this figured out. My field definition needs to be agnostic to the dimension of the array that is being passed to it. I'm not sure how to implement this in all generality, but in practice my definition is only passed two kinds of data: flattened 1D grid values as well as 3D chunks of grids, so I just hard-code those two cases. Does anyone know of a better way to take care of this? The code I'm pasting below correctly (as far as I can tell) defines a CylinderRadius field. Right now the cylinder is defined by a had-coded axis of symmetry, but I'd like to make it detect the angular momentum vector in the data object I pass to it and use that instead. I'm also curious if anyone knows how to get access to the AngularMomentumVector quantity. Hopefully, now that I know what I'm doing, generating maps of the Toomre Q shouldn't be too hard. Thanks to Matt Turk and Sam Skillman for the suggestions you gave to me over IRC today. def _CylinderRadius(field, data): center = data.get_field_parameter("center") coords = na.array([data['x'] - center[0], data['y'] - center[1], data['z'] - center[2]]) J = na.zeros(coords.shape) if len(coords.shape) == 4: J[0,:,:,:] = -1 else: J[0,:] = -1 JCrossR = na.cross(J,coords,axis=0) return na.sqrt(na.sum(na.square(JCrossR),0)) def _ConvertCylinderRadiusCGS(data): return data.convert("cm") add_field("CylinderRadius", function=_CylinderRadius, validators=[ValidateParameter("center")], convert_function = _ConvertCylinderRadiusCGS, units=r"\rm{cm}") On Sep 7, 2011, at 3:55 AM, Matthew Turk wrote:
Hi Nathan,
On Wed, Sep 7, 2011 at 3:30 AM, Nathan Goldbaum <goldbaum@ucolick.org> wrote:
Hi Andrew, Thanks for the idea. Unfortunately, that doesn't seem to be the problem. I just tried taking the absolute value of R cross V before taking the square root and got the exact same results.
Your script actually did not work for me on a standard AMR dataset. The axes of the result of the cross product were transposed from what they should be; my script died on a grid of size (18, 16, 16) because the result of the cross product was (16, 16, 18) and the CylinderRadius variable was (18, 16, 16). Naively applying a transpose (although I am not sure why I had to do this) and Andrew's suggestion of na.abs produced plots that looked vaguely correct. I recognize this is perhaps not a satisfying answer, but I would encourage you to investigate how the axes in the na.cross function are modified and returned; I also noted that only specifying "axis=0" instead of "axisa=0" and "axisb=0" got me the same result. I suspect that not specifying "axisc=0" is the cause of the problem. Another note is that I end up with a singularity at the y=z line.
If you end up wanting to do this *not* aligned with the axes, the off-axis projection method will probably be of some help. It would be very nice if we had some kind of recipe or script for calculating Toomre Q; I have done it myself, but unfortunately the script I used to calculate it was not backed up and was wiped out in a colossal and deep-cutting hard drive failure at SDSC, and so I am unable to share it.
Best,
Matt
-Nathan On Sep 6, 2011, at 11:43 PM, Andrew Myers wrote:
Hi Nathan,
This is just a guess, but do you really mean to be taking the square root of R cross V, at line 30? That quantity could potentially be negative, depending on the sense in which the fluid is spinning.
-Andrew Myers
On Tue, Sep 6, 2011 at 5:54 PM, Nathan Goldbaum <goldbaum@ucolick.org> wrote:
Hello all, Right now I'm trying to generate maps of the Toomre Q in an isolated galaxy simulation. To do so, I'm using yt to generate maps of the gas column density as well as density-weighted projections of the sound speed and orbital frequency, which I'm using as a proxy for the epicyclic frequency. Unfortunately, I'm having some trouble making projected maps of the orbital frequency. I've defined two new derived fields, CylinderRadius and AngularVelocity (http://paste.yt-project.org/show/1784/). When I try to project the AngularVelocity field, I get what looks like garbage: http://i.imgur.com/PkYhe.png However, slices work just fine: http://i.imgur.com/NnEbq.png I've written the derived fields in a coordinate-dependent way, since I'll always be doing projections down a fixed axis. Is that where my problem lies? My understanding of how yt does projections is too shallow to figure out exactly what's going wrong here, so I'm hoping the collective wisdom of the yt developers and user base can come to the rescue. Best regards, Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
!DSPAM:10175,4e67128a9212068012397!
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
!DSPAM:10175,4e674dd0583428639898!