[yt-users] updated examples for 3.0 volume rendering

Nathan Goldbaum nathan12343 at gmail.com
Fri Mar 28 16:52:28 PDT 2014


Hi Mike,

On Friday, March 28, 2014, Michael Zingale <michael.zingale at stonybrook.edu>
wrote:

> 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()
>

That line indicates that it should be a YTArray, or at least it is for the
other frontends.

I've issued a PR for an alternate fix here:
https://bitbucket.org/yt_analysis/yt/pull-request/779/ensure-griddds-is-a-ytarray-for-the-boxlib/diff

Thanks for the testing, I don't think the boxlib frontend has seen much use
since we ported it to use the new field and unit system.

You might also be interested in fields.py in the boxlib frontend.  You
should be able to edit the tuples that define "known" on-disk fields to
include the ones in your dataset.  The tuples look like this:

("eden", (eden_units, ["energy_density"], None))

The format is the boxlib field name in the first entry, and then a
three-element tuple in the second entry, containing the units of the field,
a list of aliases to 'universal' yt fields defined in the yt.fields
namespace (you can take a look at the field definitions in the yt/fields/
folder), and a display name.  If the display name is None, plot labels will
be automatically generated based on the field name.


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


More information about the yt-users mailing list