[yt-users] updated examples for 3.0 volume rendering

Michael Zingale michael.zingale at stonybrook.edu
Fri Mar 28 16:26:37 PDT 2014


I made a bit more progress here, but I get an error in

amr_kdtree/amr_kdtree.py

in line 257, it does

        dds = grid.dds.ndarray_view()

but grid.dds is already an ndarray, so this should be

        dds = grid.dds

still not through the cam.snapshot() part of my script, but I got
everything up to there working.



On Fri, Mar 28, 2014 at 4:23 PM, Michael Zingale <
michael.zingale at stonybrook.edu> wrote:

> On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum <nathan12343 at gmail.com>wrote:
>
>> Hi Mike,
>>
>> You've hit a bunch of big changes we've been making recently.  If you
>> want to get back to the version of yt before we merged these big changes
>> in, you'll need to update to the 'development' bookmark.  Right now you're
>> on the 'experimental' bookmark.
>>
>>
> Oh... lucky me.
>
>
>>
>> On Fri, Mar 28, 2014 at 12:10 PM, Michael Zingale <
>> michael.zingale at stonybrook.edu> wrote:
>>
>>> Is there any updated examples for using the yt 3.0 volume rendering?
>>>
>>> For instance, looking at this:
>>>
>>>
>>> http://yt-project.org/docs/dev/cookbook/simple_plots.html#simple-volume-rendering
>>>
>>
>> We haven't finished updating the docs yet.  In-development docs
>> (including some out-of-date information that we need to update) are
>> available here: http://yt-project.org/docs/dev-3.0/
>>
>>
>>>
>>> The field name is no longer simply "Density", but now, for my data, I
>>> need to use a tuple like:
>>>
>>> field =  ('boxlib', 'magvel')
>>>
>>
>> We no longer have a 'Density' field, since this introduces ambiguities
>> for Enzo data and to create a consistent naming scheme for fields.  The new
>> name is 'density'. See:
>> http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html
>>
>
> thanks for the list.  Maestro has it's own fun with variables (two
> definitions for temperature, several pressures, etc., magvel above is not
> simply the vector magnitude of x_vel, y_vel, z_vel, etc), so I'll pay
> attention to these definitions.
>
>
>
>
>>
>>> And then when I look at the extrema, I no longer take the [0] index, as
>>> that just gives the min, but instead if I look at:
>>>
>>>
>> That true, we've simplified the derived quantity API somewhat.  This
>> fixes a long-standing issue at the cost of breaking some old user scripts.
>>  As you can see we are planning to break backward compatibility somewhat
>> for the final yt 3.0 release.
>>
>>
>>> dd.quantities["Extrema"](field)
>>>
>>> I get:
>>>
>>> (124.858613718 dimensionless, 18061918.0546 dimensionless)
>>>
>>
>>
>>> (not sure why they are dimensionless, but that's a different problem).
>>>
>>>
>> If you do
>>
>> type(dd.quantities["Extrema"](field)[0])
>>
>> you will see that it is a new type, YTQuantity, which is a new class
>> we've defined to handle units for scalar data.  YTArray does the same thing
>> for array data.  More detail here:
>> http://yt-project.org/docs/dev-3.0/analyzing/units/index.html
>>
>> These are 'dimensionless' because the boxlib frontend does not know what
>> the appropriate units are for the 'magvel' field.  It may be the case that
>> we could modify the frontend to detect the units
>>
>>
>>> Finally, if I try to make a transfer function, like:
>>>
>>> tf = ColorTransferFunction((mi, ma))
>>>
>>> I get:
>>>
>>> NameError: name 'ColorTransferFunction' is not defined
>>>
>>
>> I think this was an oversight on Matt's part.  Thanks for the report!
>>  For now you should be able to import ColorTransferFunction from
>> yt.visualization.volume_rendering.api, but this should be fixed soon.
>>
>> The reason this happened is that we've changed the way imports work in
>> the top-level yt namespace in the interest of yt behaving more like a
>> 'normal' scientific python package.  More detail is available here:
>>
>> http://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0019.html
>>
>> as well as in the following pull request:
>>
>> https://bitbucket.org/yt_analysis/yt/pull-request/729/ytep-0019/diff
>>
>>
>>>
>>> I just synced up with the development version today.
>>>
>>> Mike
>>>
>>>
>>>
>> We're working hard to update the docs and get the code into shape to
>> release.  If you're ok with dealing with not having fully up-to-date docs,
>> we'd really appreciate you trying out the changes to the code, letting us
>> know what you think, and reporting any bugs you find.
>>
>>
> yeah, I'm happy to keep playing with this version if it helps.  The reason
> I updated today is because Matt told me that he had incorporated the
> Maestro field info that I sent him.
>
>
>
>>
>>>
>>> --
>>> Michael Zingale
>>> Associate Professor
>>>
>>> Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY
>>> 11794-3800
>>> *phone*:  631-632-8225
>>> *e-mail*: Michael.Zingale at stonybrook.edu
>>> *web*: http://www.astro.sunysb.edu/mzingale
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> Michael Zingale
> Associate Professor
>
> Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY
> 11794-3800
> *phone*:  631-632-8225
> *e-mail*: Michael.Zingale at stonybrook.edu
> *web*: http://www.astro.sunysb.edu/mzingale
>



-- 
Michael Zingale
Associate Professor

Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY
11794-3800
*phone*:  631-632-8225
*e-mail*: Michael.Zingale at stonybrook.edu
*web*: http://www.astro.sunysb.edu/mzingale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20140328/760288d7/attachment.htm>


More information about the yt-users mailing list