[yt-users] Trouble projecting a derived field

Matthew Turk matthewturk at gmail.com
Thu Sep 8 11:44:27 PDT 2011 

Hi Nathan,

On Thu, Sep 8, 2011 at 3:43 AM, Nathan Goldbaum <goldbaum at ucolick.org> wrote:
> 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?

We do something similar when calculating SpecificAngularMomentum[XYZ]
quantities.  (Note that "SpecificAngularMomentum" by itself is a
vector field and will probably throw an error if you do anything other
than access it directly.)  There's a helper routine in
yt.data_objects.universal_fields called obtain_rvec:

http://hg.yt-project.org/yt/src/fe04156a8573/yt/data_objects/universal_fields.py#cl-569

which we use:

http://hg.yt-project.org/yt/src/fe04156a8573/yt/data_objects/universal_fields.py#cl-593

This might be useful for you, as it is designed to be neutral.
Alternately, the ticket we filled out together last night will address
ensuring spatial *and* parameters.

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

You can access it in this manner:

L = some_data_object.quantities["AngularMomentumVector"]()
L.set_field_parameter("angular_momentum_vector", L)

Now inside your field you can access it.

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

Awesome, and you're welcome.  Keep in touch, it would be good to hear
how things go.

Best wishes,

Matt

>
> 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 at 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 at 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 at ucolick.org
>>>> http://www.ucolick.org/~goldbaum
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>> !DSPAM:10175,4e67128a9212068012397!
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>> !DSPAM:10175,4e674dd0583428639898!
>>
>
> _______________________________________________
> 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