Hi Mike,

On Friday, March 28, 2014, Michael Zingale <michael.zingale@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@stonybrook.edu> wrote:
On Fri, Mar 28, 2014 at 3:37 PM, Nathan Goldbaum <nathan12343@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@stonybrook.edu> wrote:
Is there any updated examples for using the yt 3.0 volume rendering?

For instance, looking at this:


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)