[yt-users] updated examples for 3.0 volume rendering

Nathan Goldbaum nathan12343 at gmail.com
Fri Mar 28 12:37:21 PDT 2014

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.

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:

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

> 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


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:

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:


as well as in the following pull request:


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

That said, if you want a lower-friction option, 'downgrading' to the
development bookmark should go a long way.

To do that, navigate to your checking of the yt mercurial repository and
issue the following sequence of commands:

hg up development
python setup.py develop

Hope that's helpful.  Please let us know if you have any further questions
or concerns.


> --
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-users-spacepope.org/attachments/20140328/a227be64/attachment.html>

More information about the yt-users mailing list