[yt-users] Deprecation Woes

Nathan Goldbaum nathan12343 at gmail.com
Tue Oct 7 11:35:23 PDT 2014


On Tue, Oct 7, 2014 at 11:22 AM, Munier Azzam Salem <
msalem at astro.columbia.edu> wrote:

> Thanks guys! Definitely helps. The changes definitely seem like a big
> improvement.
>

Just in case you want to switch back to the yt-2 branch, here are some
instructions on how to do that in the docs:

http://yt-project.org/doc/installing.html#switching-between-yt-2-x-and-yt-3-x

yt-3 has lots of cool stuff, as you discovered, but this might be the path
of least resistance if you just want to redo an old plot or something like
that.

Best,

Nathan


>
> On Tue, Oct 7, 2014 at 2:11 PM, Britton Smith <brittonsmith at gmail.com>
> wrote:
>
>> Hi Munier,
>>
>> It sounds like you have just made the leap from yt-2.x to yt-3.0.  You
>> may find the following page helpful:
>> http://yt-project.org/doc/yt3differences.html
>>
>> One of the biggest improvements of yt-3.0 is the new units system in
>> which all quantities within yt have units associated with them which can be
>> converted easily.  If you have done the following:
>>
>> import yt
>> ds = yt.load(some_data)
>>
>> Then, doing the following with give you the width of the simulation box:
>> ds.domain_width
>>
>> Note that it will most likely show you something like this:
>> YTArray([ 1.,  1.,  1.]) code_length
>>
>> You can convert that into any other unit like the following
>> ds.domain_width.in_units("cm")
>> YTArray([  1.40258072e+26,   1.40258072e+26,   1.40258072e+26]) cm
>>
>> Britton
>>
>> On Tue, Oct 7, 2014 at 1:54 PM, Munier Azzam Salem <
>> msalem at astro.columbia.edu> wrote:
>>
>>> Hey Guys,
>>>
>>>          A false sense of complacency / hubris led me to update my dev
>>> version of yt ... I thought "how much damage could this do?" ... well ...
>>> After updating 50 derived fields in my analysis scripts, I have learned a
>>> valuable life lesson. Well played yt. Well played. But I digress ...
>>>
>>>         One of the deprecated usages I couldn't figure out how to fix
>>> involves pulling units from a pf object. Specifically I'd like to do this:
>>>
>>>        pf.units['cm']
>>>
>>>        Alternatives I could live with: finding the length of a side of
>>> the simulation box in CGS, some way to convert between code and physical
>>> units, etc ...
>>>
>>>        I'm working with enzo, if that matters.
>>>
>>>           cheers,
>>>                 Munier
>>>
>>>
>>> --
>>> Munier A. Salem // 845.489.6450
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Munier A. Salem // 845.489.6450
>
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20141007/e1468e69/attachment.htm>


More information about the yt-users mailing list