Hi all,
I've put a docker repository into yt_analysis/yt-docker . Not 100%
sure I've named it all correctly. Anyway, we've also got a group on
hub.docker.io, and it's building images as:
ytproject/yt-stable
ytproject/yt-stable:jiffylab
the latter one is for using inside jiffylab.
-Matt
Dear all,
In one of my user defined field, I have to do a multiplication with Mach
number.
I found that, I can use both * data["Mach"]* and *data["MachNumber"]. *What
is the difference between "Mach" and "MachNumber".
Thank you
--
Reju Sam John
New issue 883: 1D Enzo data is incorrectly parsed
https://bitbucket.org/yt_analysis/yt/issue/883/1d-enzo-data-is-incorrectl...
Nathan Goldbaum:
For some reason the on-disk hydrodynamic fields are interpreted as particle fields and given field type 'io' instead of 'enzo'. This uses the attached 1D sod shock dataset.
```
#!python
import yt
import pprint
ds = yt.load('DD0001/data0001')
pprint.pprint(ds.field_list)
```
This outputs:
```
#!
[('io', 'y-velocity'),
('io', 'x-velocity'),
('io', 'Density'),
('io', 'z-velocity'),
('io', 'TotalEnergy'),
('all', 'z-velocity'),
('all', 'y-velocity'),
('all', 'x-velocity'),
('all', 'TotalEnergy'),
('all', 'Density')]
```
New issue 882: BoxLib frontend does not deal with 1-d data properly
https://bitbucket.org/yt_analysis/yt/issue/882/boxlib-frontend-does-not-d...
Michael Zingale:
In the BoxLib frontend, around line 572, we do:
```
# Skip timesteps per level
header_file.readline()
self._header_mesh_start = header_file.tell()
header_file.next()
next_line = header_file.next()
if len(next_line.split()) == 1:
coordinate_type = int(next_line)
else:
coordinate_type = 0
```
This code is supposed to skip over all the lines the give the timestep per level, but the boxlib format actually writes out the dx's per left here, in the format
dx dy dz (level 0)
dx dy dz (level 1)
...
when it is over, it will print out an integer flag that represents the geometry. But for 1-d, it seems that this `len(next_line.split()) == 1` clause is catching a single dx as the geometry, at we crash.
Responsible: mzingale
Hey everyone,
Now that the righthandedness has gone into the PlotWindow objects, making
slices and projections of isolated disk galaxy simulations yields the
y-projection having a vertically oriented disk as seen here in an image
generated by Mike Butler:
http://www.ics.uzh.ch/~butler/Enzo_nofeedback_1000Myr_Sigma.png
I suppose we could modify the ProjectionPlot framework to allow a keyword
to specify the x-axis and y-axis vectors, but I was just trying to make
equivalent projections using the OffAxisProjectionPlot object since that
allows for one to explicitly specify a north_vector. Unfortunately, I'm
finding some inconsistencies between the ProjectionPlot (on-axis) images
and the OffAxisProjectionPlot images (specifying vectors to be on-axis).
This simple script demonstrates what I'm talking about:
http://paste.yt-project.org/show/5049/
Running this script yields 4 images:
off_axis_proj.png - http://i.imgur.com/CKbq5iO.png
on_axis_proj.png - http://i.imgur.com/2iBucuv.png
off_axis_weighted_proj.png - http://i.imgur.com/RQV2REP.png
on_axis_weighted_proj.png - http://i.imgur.com/CNWHyQS.png
As you can see, the off_axis_proj is using significantly different limits
than the on_axis_proj, which makes me think it isn't doing a true line
integral, but I haven't investigated this closely. While the weighted
projections are better, they still have slight differences in their limits.
Is this expected and I'm just messing something up here, or is this a true
bug?
Cameron
--
Cameron Hummels
Postdoctoral Researcher
Steward Observatory
University of Arizona
http://chummels.org
Hi all,
There have been a number of bugfixes since the yt 3.0 release - I think it
would be a good idea to to issue a minor point release sooner rather than
later so these bugfixes can be released to anaconda, pypi, and people who
are on the stable branch.
+/- 1?
-Nathan
New issue 881: yt is unable to read outputs created by enzo 2.4
https://bitbucket.org/yt_analysis/yt/issue/881/yt-is-unable-to-read-outpu...
Nathan Goldbaum:
As part of the enzo 2.4 release, I was told to increment the VERSION typedef to 2.4:
https://bitbucket.org/enzo/enzo-dev/commits/d10fc823d618cd9930b0a44fa09f4...
Unfortunately, this seems to have caused some breakage on the yt side of things. In particular, the `VersionNumber` parameter written to output files is now 2.4. This causes the data dumps to be incorrectly identified as enzo 3.0 outputs, which causes breakage when yt tries to parse the data dumps for active particle parameters.
I'm not sure how to fix this without also breaking i/o for enzo 3.0.
I've attached a data dump from the MHDCTOrszagTang test. To reproduce, do `yt stats` on the data dump.
New issue 880: Infinite recursion when plotting unit'd things
https://bitbucket.org/yt_analysis/yt/issue/880/infinite-recursion-when-pl...
Adam Ginsburg:
When attempting to plot a `TransferFunctionHelper`, I ran into an infinite recursion error:
```
tfh.plot(fn='tf.png')
File "/Users/adam/anaconda/envs/astropy27/lib/python2.7/site-packages/yt/units/yt_array.py", line 1135, in __new__
if not isinstance(input_scalar, (numeric_type, np.number, np.ndarray)):
File "/Users/adam/anaconda/envs/astropy27/python.app/Contents/lib/python2.7/abc.py", line 132, in __instancecheck__
if subclass is not None and subclass in cls._abc_cache:
File "/Users/adam/anaconda/envs/astropy27/python.app/Contents/lib/python2.7/_weakrefset.py", line 75, in __contains__
return wr in self.data
RuntimeError: maximum recursion depth exceeded in cmp
```
@ngoldbaum tells me this is a matplotlib 1.3.1 issue.
Responsible: ngoldbaum
