yt-dev August 2014

yt-dev@python.org

21 participants
43 discussions

Issue #886: ReadTheDocs docs are still at 2.6 (yt_analysis/yt)

by John ZuHone

New issue 886: ReadTheDocs docs are still at 2.6 https://bitbucket.org/yt_analysis/yt/issue/886/readthedocs-docs-are-still-a… John ZuHone: Not sure if we were planning to update them there or not.

6 years, 6 months

docker builds

by Matthew Turk

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

6 years, 6 months

How to install yt 2.6 in a computer without internet?

by Reju Sam John

Dear all, How to install yt 2.6 in a computer without internet? -- Reju Sam John

6 years, 6 months

Difference between the fields "Mach" and "MachNumber"

by Reju Sam John

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

6 years, 6 months

Issue #883: 1D Enzo data is incorrectly parsed (yt_analysis/yt)

by Nathan Goldbaum

New issue 883: 1D Enzo data is incorrectly parsed https://bitbucket.org/yt_analysis/yt/issue/883/1d-enzo-data-is-incorrectly-… 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')] ```

6 years, 6 months

Issue #882: BoxLib frontend does not deal with 1-d data properly (yt_analysis/yt)

by Michael Zingale

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-dea… 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

6 years, 6 months

Differences between on-axis projections and off-axis projections

by Cameron Hummels

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

6 years, 6 months

yt 3.0.1 release?

by Nathan Goldbaum

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

6 years, 6 months

Issue #881: yt is unable to read outputs created by enzo 2.4 (yt_analysis/yt)

by Nathan Goldbaum

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-outputs… 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/d10fc823d618cd9930b0a44fa09f43d… 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.

6 years, 6 months

Issue #880: Infinite recursion when plotting unit'd things (yt_analysis/yt)

by Adam Ginsburg

New issue 880: Infinite recursion when plotting unit'd things https://bitbucket.org/yt_analysis/yt/issue/880/infinite-recursion-when-plot… 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

6 years, 6 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev August 2014