Mailman 3 October 2013 - yt-dev

Issue #680: Current stable release of yt has an incorrect version string. (yt_analysis/yt)
by Nathan Goldbaum 20 Oct '13

20 Oct '13

New issue 680: Current stable release of yt has an incorrect version string. https://bitbucket.org/yt_analysis/yt/issue/680/current-stable-release-of-yt… Nathan Goldbaum: Even though we're on yt 2.5.5, the version string says it is yt-2.5dev. I would interpret yt-2.5dev as a version of yt from before the 2.5.0 stable release. This leads to confusion when people report their yt version on the mailing list or IRC. @MatthewTurk, as you were in charge of the releases, was this done on purpose? To fix this, we just need to adjust the version string in `yt/__init__.py`. I'll happily fix this if it turns out to have been an oversight.

1 0

Issue #679: Narrative docs for radmc3d exporter. (yt_analysis/yt)
by Nathan Goldbaum 20 Oct '13

20 Oct '13

New issue 679: Narrative docs for radmc3d exporter. https://bitbucket.org/yt_analysis/yt/issue/679/narrative-docs-for-radmc3d-e… Nathan Goldbaum: Currently the only documentation for the exporter is the docstrings. @atmyers do you think you could handle this?

1 0

Issue #678: SlicePlots don't work for ART in 3.0 (yt_analysis/yt)
by Nathan Goldbaum 18 Oct '13

18 Oct '13

New issue 678: SlicePlots don't work for ART in 3.0 https://bitbucket.org/yt_analysis/yt/issue/678/sliceplots-dont-work-for-art… Nathan Goldbaum: Just tried to make a SlicePlot and ran into what looked like an API incompatibility error. Sorry for not pasting a traceback but unfortunately I found this error while working with someone else so I don't have access to their data.

1 0

Issue #677: Wrong scale in fixed_resolution_buffer (yt_analysis/yt)
by Kacper Kowalik 18 Oct '13

18 Oct '13

New issue 677: Wrong scale in fixed_resolution_buffer https://bitbucket.org/yt_analysis/yt/issue/677/wrong-scale-in-fixed_resolut… Kacper Kowalik: Following code: ``` #!python import yt from yt.mods import load from matplotlib.pyplot import figure # bbox = [[-1.5, 1.5], [-1.0, 1.0], [-1.0, 1.0]] # density blob: radius = 0.25, r_0 = [-0.5, 0.0, 0.0] pf = load('blob.h5') if yt.__version__.startswith('2'): proj = pf.h.proj(2, "denn") else: proj = pf.h.proj("denn", 2) frb = proj.to_frb(1.0, (200, 200), center=[-0.5, 0, 0]) fig = figure() ax = fig.add_subplot(111) ax.imshow(frb['denn']) fig.savefig('proj_%s.png' % yt.__version__[:3]) ``` yields different results for 2.x: ![blob in 2.x](http://i.imgur.com/nXn3T8O.png) and 3.0: ![blob in 3.0](http://i.imgur.com/ptUbIyK.png)

1 0

Issue #676: set_center does not do the right thing with a three-tuple (yt_analysis/yt)
by Matthew Turk 17 Oct '13

17 Oct '13

New issue 676: set_center does not do the right thing with a three-tuple https://bitbucket.org/yt_analysis/yt/issue/676/set_center-does-not-do-the-r… Matthew Turk: If I create a plot window and set the center to a 3-length tuple using set_center, it takes the first two items from the tuple and does not correctly set the center. ``` #!python p1 = ProjectionPlot(pf, "y", "Density") center = halo.center_of_mass() p1.set_center( center ) p1.show() ``` This takes items 0 and 1 from the center of mass, but it should be taking items 0 and 2.

1 0

A "taxonomy" for fields
by Matthew Turk 16 Oct '13

16 Oct '13

Hi all, Nathan and I have been doing some work on units recently, and how to handle on-disk fields, derived fields, and so on came up a little bit. I speculated a little bit about this and was wondering if this is a good enough idea to propose a modification to YTEP-0003: https://ytep.readthedocs.org/en/latest/YTEPs/YTEP-0003.html Basically, what about having a taxonomy of fields? What this would be: * An enumeration of the fields that yt may call upon that it may expect to find in a dataset. * Explicit translations, rather than de facto/implicit translations. * Calling on-disk fields by a fluid name other than "gas" So what I mean here is, right now we have support for multiple "fluids", but the only ones we have are "gas" and "deposit". I'm proposing that code frontends: * Define their own fluid types that mean, fields on disk. These will by default be in code units. So you could access dataobj["enzo","Density"] and it will return a YTArray by default in code units that is the "Density" field. * Frontends provide translations of these to yt-specific fields. This would mean, for the example above, ["gas","density"]. (Note that by default the search process would be "gas", then "enzo" in this case, so you could still ask for "Density" but it would default to a unitful code-unit array, and yt knows how to convert all of that.) * Somewhere (YTEP?), enumerate the fields that yt knows how to manage and operate on. This way we can also more easily detect derived fields, and indicate to frontend developers how to hook their code up to yt. In the unit_refactor I've started working toward this by adding: field_info.add_output_field( ... ) field_info.alias( ... ) to set these things up a bit more clearly. It also devises a different way of doing field plugins, to make it more deliberate and reduce a LOT of the nastiness of the process. So what I'm looking for feedback on: * What about new fluid type for on-disk datasets? * What about enumerating field names that yt knows about? -Matt PS I know 3.0alpha4 was scheduled for yesterday. I was a bit jet-lagged, but I'll put out what I can as soon as I can for a release announcement. But, the recent changes are in yt_analysis/yt now!

2 2

cython debugging?
by Chris Malone 15 Oct '13

15 Oct '13

Hi all, I'm trying to extract some data for a surface, but am getting a segfault in the `YTSurfaceBase.get_data` method - probably the same thing as this [1] yt issue. I've tracked it down to the `FillTriangleValues` call in `march_cubes_grid` with a combination of pdb and gdb. I can't figure out what is wrong, however, because all the variable values are optimized out. So my question: anyone know how to re-run setup.py and turn on debugging flags for cython code? I've found information about cygdb, which would probably be easier than pdb+gdb. Their documentation says to rebuild with the --pyrex-gdb flag to setup.py, but that doesn't seem to be recognized by setuptools. Other webpages say to set the "-g" or "--cython-gdb" flags, but those also do not work. Chris [1] https://bitbucket.org/yt_analysis/yt/issue/633/vertices-not-correctly-creat…

2 4

Issue #675: Document how to do VRs with multiple fields (yt_analysis/yt)
by Cameron Hummels 15 Oct '13

15 Oct '13

New issue 675: Document how to do VRs with multiple fields https://bitbucket.org/yt_analysis/yt/issue/675/document-how-to-do-vrs-with-… Cameron Hummels: Perhaps adding a script to the cookbook on how to incorporate multiple fields as sources to a single rendering (a la Stella Offner's stuff on the yt gallery page), or a full script using the MultiVariateTransferFunction.

1 0

Get rid of hdf5_light_reader and freetype
by Matthew Turk 10 Oct '13

10 Oct '13

Hi all, One of the biggest pain points in our distribution is linking against external libraries. We do this in three places by default: * HDF5, for the hdf5_light_reader * libpng, for write_png * freetype, for freetype_writer hdf5_light_reader was originally written (by me) something like five years and change ago, because at the time PyTables was slower than I wanted. I've been working on improving IO and found that we can get nearly the same speed from h5py; when combined with overall performance improvements in yt-3, this still translates to faster speeds for very large datasets. On small to medium datasets, the performance is not noticeably different. I'd like to propose that we stop using hdf5_light_reader, which may result in a slight degradation of performance for (only) Enzo IO. Additionally, I don't think *anyone* uses the freetype writer, and I'd like to remove it. I'm actually not sure if anyone has ever used it. I think with these two changes we can likely improve our packaging situation by a good amount, as hdf5 specifically is the main problem with distribution in Conda. These changes would only be in yt 3.0, and would not affect 2.x. [+-][01]? -Matt

5 7

Issue #674: Error when importing from yt.analysis_modules.api (yt_analysis/yt)
by Devin Silvia 08 Oct '13

08 Oct '13

New issue 674: Error when importing from yt.analysis_modules.api https://bitbucket.org/yt_analysis/yt/issue/674/error-when-importing-from Devin Silvia: Right now, if you try to import from yt.analysis_modules.api, you get an error that SZpack is needed and not available. I don't believe that SZpack should be a requirement and since it does not come with the yt install bundle, it should probably be dealt with more gracefully.

1 0