New issue 680: Current stable release of yt has an incorrect version string.
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.
New issue 676: set_center does not do the right thing with a three-tuple
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.
p1 = ProjectionPlot(pf, "y", "Density")
center = halo.center_of_mass()
p1.set_center( center )
This takes items 0 and 1 from the center of mass, but it should be taking items 0 and 2.
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:
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
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?
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!
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 
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
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.
New issue 674: Error when importing from yt.analysis_modules.api
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.