New issue 950: get_smallest_appropriate_unit is defined twice
https://bitbucket.org/yt_analysis/yt/issue/950/get_smallest_appropriate_u...
John ZuHone:
`get_smallest_appropriate_unit` is defined as a method of `Dataset`, but there is also a version of it in `yt.visualization.plot_modifications`. Worse yet, the answers don't agree. I ran the following script:
```
#!python
import yt
from yt.visualization.plot_modifications import get_smallest_appropriate_unit
parameters = {"length_unit":(1.0,"Mpc"),
"time_unit":(1.0,"Myr"),
"mass_unit":(1.0e14,"Msun")}
ds = yt.load("MHDSloshing/virgo_low_res.0054.vtk", parameters=parameters)
print "domain width = ", ds.domain_width[0].in_units("Mpc")
print "from Dataset method = ", ds.get_smallest_appropriate_unit(ds.domain_width[0])
print "from plot_modifications = ", get_smallest_appropriate_unit(ds, ds.domain_width[0])
```
which gives:
```
#!
domain width = 4.0 Mpc
from Dataset method = pc
from plot_modifications = Mpc
```
I have seen other bizarre behavior of this nature as well. We should remove this duplication, in favor of the version in `plot_modifications`, since it seems to give the more sensible result. I can work on a PR.
Responsible: jzuhone
Hi all,
We have a working docs build, yay!! Even better, it now only takes an hour
and 20 minutes to finish due to the new parallel reading capabilities in
sphinx 1.3!
The build is here:
http://yt-project.org/docs/dev/
It would be great to get eyes on it, especially with an eye towards broken
formatting, typos and bugs in example scripts.
Now that the docs build is working, I think we're in shape to do a release.
There will still probably be bugfixes doc fixes, and performance
improvements incoming, but I don't think we should merge in any new
features until we do the release.
There are also some open pull requests, it would be great if we got eyes on
them and started merging them in. We had tests shut off for a little while
the other day while we resolved issues with the docs build, so if you
notice a PR where tests weren't run, poke me or kacper and we can trigger a
new build.
We could probably also do an official release candidate, but I'm not sure
how useful that will be given our normal distribution channels.
What do you all think about cutting a release Monday Dec. 15?
-Nathan
New issue 948: FITSProjection fails with ValueError: 'code_length' did not parse as fits unit
https://bitbucket.org/yt_analysis/yt/issue/948/fitsprojection-fails-with-...
Kacper Kowalik:
Following script:
```
#!python
import yt
from yt.utilities.fits_image import FITSProjection
ds = yt.load("MHDSloshing/virgo_low_res.0054.vtk",
parameters={"length_unit": (1.0, "Mpc"),
"mass_unit": (1.0e14, "Msun"),
"time_unit": (1.0, "Myr")})
prj_fits = FITSProjection(ds, "z", ["temperature"], weight_field="density")
```
yields
```
#!text
Traceback (most recent call last):
File "foo.py", line 8, in <module>
prj_fits = FITSProjection(ds, "z", ["temperature"], weight_field="density")
File "yt/utilities/fits_image.py", line 474, in __init__
image_res=image_res)
File "yt/utilities/fits_image.py", line 358, in construct_image
w.wcs.cunit = cunit
File "/usr/lib64/python2.7/site-packages/astropy/units/core.py", line 1735, in __call__
raise ValueError(msg)
ValueError: 'code_length' did not parse as fits unit: At col 0, Unit u'code_length' not supported by the FITS standard.
```
I'm using *astropy-0.4* and *yt* rev: 09a0a10893ef
Responsible: jzuhone
New issue 947: Consistent field naming for spherical and cylindrical fields
https://bitbucket.org/yt_analysis/yt/issue/947/consistent-field-naming-fo...
Cameron Hummels:
The issue of consistent field naming came up in Pull Request #1308, and further discussion occurred on the yt development sprint for yt 3.1 on 12.2.14.
Right now there are two somewhat inconsistent field naming schemes associated with non-cartesian position and velocity fields.
In particles, we have these:
*Cartesian*
```
#!python
('all', 'particle_position_x')
('all', 'particle_position_y')
('all', 'particle_position_z')
('all', 'particle_velocity_x')
('all', 'particle_velocity_y')
('all', 'particle_velocity_z')
```
*Spherical*
```
#!python
(‘all’, ‘particle_spherical_position_phi’)
(‘all’, ‘particle_spherical_position_radius’)
(‘all’, ‘particle_spherical_position_theta’)
(‘all’, ‘particle_spherical_velocity_phi’)
(‘all’, ‘particle_spherical_velocity_radius’)
(‘all’, ‘particle_spherical_velocity_theta’)
```
and (after PR #1308):
*Cylindrical*
```
#!python
(‘all’, ‘particle_cylindrical_position_z’)
(‘all’, ‘particle_cylindrical_position_radius’)
(‘all’, ‘particle_cylindrical_position_theta’)
(‘all’, ‘particle_cylindrical_velocity_z’)
(‘all’, ‘particle_cylindrical_velocity_radius’)
(‘all’, ‘particle_cylindrical_velocity_theta’)
```
For gas fields, we have these:
*Cartesian*
```
#!python
(‘index’, ‘x’)
(‘index’, ‘y’)
(‘index’, ‘z’)
(‘gas’, ‘velocity_x’)
(‘gas’, ‘velocity_y’)
(‘gas’, ‘velocity_z’)
```
*Spherical*
```
#!python
(‘index’, ‘spherical_phi’)
(‘index’, ‘spherical_r’)
(‘index’, ‘spherical_theta’)
(‘gas’, ‘radial_velocity’)
(‘gas’, ‘radial_velocity_absolute’)
(‘gas’, ‘tangential_velocity’)
(‘gas’, ‘tangential_over_velocity_magnitude’)
```
*Cylindrical*
```
#!python
(‘index’, ‘cylindrical_r’)
(‘index’, ‘cylindrical_theta’)
(‘index’, ‘cylindrical_z’)
(‘gas’, ‘cylindrical_radial_velocity’)
(‘gas’, ‘cylindrical_radial_velocity_absolute’)
(‘gas’, ‘cylindrical_tangential_velocity’)
(‘gas’, ‘cylindrical_tangential_velocity_absolute’)
```
I would like to propose that we make new spherical and cylindrical gas fields that follow a similar naming convention to the explicit form of the particle fields. To make sure we're backwards compatible, we can just make field aliases from the field names above to the new fields. Or in the case of 'tangential_velocity' (and 'cylindrical_tangential_velocity'), it can remain, since it seem like the superposition of phi_velocity and theta_velocity.
An absolutely *fascinating* paper: http://arxiv.org/abs/1412.0510
This is similar, but not identical, to our contour finder, which is
also a parallel segmentation algorithm, but without any of the
watershed analysis or noise removal. (h/t John Wise's astro-ph blog)
