yt-dev April 2014

yt-dev@python.org

14 participants
42 discussions

Issue #837: Deposited Particle filter fields do not show up in derived_field_list (yt_analysis/yt)

by Nathan Goldbaum

New issue 837: Deposited Particle filter fields do not show up in derived_field_list https://bitbucket.org/yt_analysis/yt/issue/837/deposited-particle-filter-fi… Nathan Goldbaum: Take the following example script: ``` #!python import yt import numpy as np import pprint from yt.data_objects.particle_filters import add_particle_filter from matplotlib import pyplot as plt def star(pfilter, data): filter = data["all", "particle_type"] == 2 return filter add_particle_filter("star", function=star, filtered_type="all", requires=["particle_type"]) filename = "IsolatedGalaxy/galaxy0030/galaxy0030" ds = yt.load(filename) ds.add_particle_filter("star") pprint.pprint(ds.derived_field_list) ``` While the particle fields for the "star" particle types do show up, only the deposit fields for `"io"` and `"all"` show up under the deposit ptype. The deposit fields for the `"star"` ptype can be accessed through a data object, so the issue seems to be with the way deposit fields are added to the `derived_field_list` rather than the deposit fields themselves.

7 years, 1 month

Issue #836: Compound units in PlotWindow don't have the correct spacing. (yt_analysis/yt)

by John ZuHone

New issue 836: Compound units in PlotWindow don't have the correct spacing. https://bitbucket.org/yt_analysis/yt/issue/836/compound-units-in-plotwindow… John ZuHone: See the IPython notebook here, the colorbar units and the units representations at the bottom: http://nbviewer.ipython.org/gist/anonymous/11311205 There should either be a space, a dot, or a "times" sign between the "pixel" and the "s" in the latex representation.

7 years, 1 month

Bitbucket pull request update

by Nathan Goldbaum

Hi all, It looks like bitbucket has adjusted the way updating pull requests works. Now, if you have an open pull request, if you push changes to the head corresponding to the open pull request, the PR will be updated automatically. More detail here: http://blog.bitbucket.org/2014/04/22/bitbucket-now-auto-updates-pull-reques… I think this is a good change for the most part, but it's something to keep in mind when pushing to your repositories. Happy hacking, Nathan

7 years, 1 month

3.0 sprint

by Matthew Turk

Hi all, We're getting perilously close to a beta release of 3.0 -- I think at this point we have most major functionality in place, answer testing is back online, and the number of cards left for a release is dropping precipitously. The *major* thing holding us back is documentation. I'd like to have a "virtual sprint." This would be where people can drop in at any time during the day, for however long they can stay, and we chat about things and knock a few items off the todo list. Mostly -- it's a time when people can spend ten minutes reading docs and making some edits. I've set up a doodle here: http://doodle.com/7ymg5bw7nq5mrmxg If you want to participate, fill out which days work for you. I'll set up the hangout on the day of and keep it going as long as people are around. I've added a list to the board for sprints about this: https://trello.com/b/FH69aXps/sprints-and-workshops -Matt

7 years, 1 month

Issue #835: Field detection issue for Tipsy datasets (yt_analysis/yt)

by Nathan Goldbaum

New issue 835: Field detection issue for Tipsy datasets https://bitbucket.org/yt_analysis/yt/issue/835/field-detection-issue-for-ti… Nathan Goldbaum: The following script: ``` #!python from yt.mods import * ds = load('TipsyGalaxy/galaxy.00300', n_ref=8) ds.derived_field_list dd = ds.all_data() xcoord = dd['Gas','Coordinates'][:,0].v ycoord = dd['Gas','Coordinates'][:,1].v slc = SlicePlot(ds, 'z', ('gas','density'), width=(40, 'kpc'), center='m') slc.save() ``` Produces the following traceback: ``` #!python traceback Traceback (most recent call last): File "test.py", line 7, in <module> slc = SlicePlot(ds, 'z', ('gas','density'), width=(40, 'kpc'), center='m') File "/Users/goldbaum/Documents/yt-hg/yt/visualization/plot_window.py", line 1749, in SlicePlot return AxisAlignedSlicePlot(pf, normal, fields, *args, **kwargs) File "/Users/goldbaum/Documents/yt-hg/yt/visualization/plot_window.py", line 972, in __init__ (bounds, center) = get_window_parameters(axis, center, width, pf) File "/Users/goldbaum/Documents/yt-hg/yt/visualization/plot_window.py", line 166, in get_window_parameters center = get_sanitized_center(center, pf) File "/Users/goldbaum/Documents/yt-hg/yt/visualization/plot_window.py", line 146, in get_sanitized_center v, center = pf.h.find_max("density") File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/static_output.py", line 533, in find_max source.quantities["MaxLocation"](field) File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 527, in __call__ rv = super(MaxLocation, self).__call__(field) File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 59, in __call__ sto.result = self.process_chunk(ds, *args, **kwargs) File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/derived_quantities.py", line 538, in process_chunk if data[field].size > 0: File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 205, in __getitem__ f = self._determine_fields([key])[0] File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 453, in _determine_fields finfo = self.pf._get_field_info(ftype, fname) File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/static_output.py", line 493, in _get_field_info raise YTFieldNotFound((ftype, fname), self) yt.utilities.exceptions.YTFieldNotFound: Could not find field '('all', 'density')' in galaxy.00300. ``` When I remove the call to `ds.derived_field_list` I get a different failure: ``` #!python traceback Traceback (most recent call last): File "test.py", line 4, in <module> xcoord = dd['Gas','Coordinates'][:,0].v File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 212, in __getitem__ self.get_data(f) File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 556, in get_data self.index._identify_base_chunk(self) File "/Users/goldbaum/Documents/yt-hg/yt/geometry/particle_geometry_handler.py", line 140, in _identify_base_chunk self.regions.identify_data_files(dobj.selector)] File "/Users/goldbaum/Documents/yt-hg/yt/data_objects/data_containers.py", line 512, in selector self._selector = sclass(self) File "selection_routines.pyx", line 626, in yt.geometry.selection_routines.RegionSelector.__init__ (yt/geometry/selection_routines.c:9845) File "/Users/goldbaum/Documents/yt-hg/yt/units/yt_array.py", line 753, in __getitem__ ret = super(YTArray, self).__getitem__(item) IndexError: 0-d arrays can't be indexed ``` Finally, when I remove the lines that create and access data inside the `all_data` object, the script runs successfully and the plot is saved to disk. This uses the TipsyGalaxy dataset which will be uploaded to yt-project.org/data shortly.

7 years, 1 month

single-precision instead of double precision

by Michael Zingale

Are there any plans to natively support single-precision datasets? (sometimes we store 32-bit instead of 64-bit to save space). If I access my data and then create a covering grid, in the YTCoveringGridBase code, when it makes the grid for the data, it hardcodes in "float64" -- ideally it would keep the precision of the dataset all the way through. Mike -- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale(a)stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

7 years, 1 month

yt-3.0 parallel_capable

by Britton Smith

Hi all, I don't recall when I first noticed this, but I'm finding that the parallel_root_only decorator doesn't seem to be working. A simple test is to run a script that only loads a dataset. The print_key_parameters function is inside of a parallel_root_only decorator, so all that should only be printed by the root processor, but when I run that script in parallel it is printed by all processors. I am still looking into this, but so far I have found that printing the value of parallel_capable inside this decorator always gives False even when running in parallel. Can someone confirm this? If so, does anyone know what's going on? Britton

7 years, 1 month

Issue #834: Off-axis slices and projections made with PlotWindow don't recognize 'code_length' as a unit (yt_analysis/yt)

by John ZuHone

New issue 834: Off-axis slices and projections made with PlotWindow don't recognize 'code_length' as a unit https://bitbucket.org/yt_analysis/yt/issue/834/off-axis-slices-and-projecti… John ZuHone: Example notebook: http://nbviewer.ipython.org/gist/anonymous/11193110 I do not see a similar problem with their on-axis counterparts.

7 years, 1 month

Issue #833: parallel_capable getting reset to False running in parallel (yt_analysis/yt)

by Britton Smith

New issue 833: parallel_capable getting reset to False running in parallel https://bitbucket.org/yt_analysis/yt/issue/833/parallel_capable-getting-res… Britton Smith: The parallel_capable global variable is getting reset to False somewhere, causing decorators like parallel_root_only not to work correctly. This can be reproduced by either of the following scripts run in parallel: ``` #!python import yt yt.enable_parallelism() pf = yt.load("DD0064/DD0064") from yt.mods import * pf = load("DD0064/DD0064") ```

7 years, 1 month

Issue #832: In Enzo data 'dynamical_time' field returns inconsistent results (yt_analysis/yt)

by jmoloney

New issue 832: In Enzo data 'dynamical_time' field returns inconsistent results https://bitbucket.org/yt_analysis/yt/issue/832/in-enzo-data-dynamical_time-… jmoloney: For Enzo datasets, using the field name 'dynamical_time' instead of the full field ('all', 'dynamical_time'), ('io', 'dynamical_time'), or ('gas', dynamical_time') produces inconsistent results. As far as I can tell, this is because it is the only field that is defined with the same name for both particles and gas. Depending on which fields have been called previously, the field returned by 'dynamical_time' may be either one or the other. I haven't been able to figure out a clear pattern for when each is returned. The attached example.py should help illustrate what I mean as long as you have an Enzo dataset to give it. When I run this, using 'density' vs 'Density' produces consistently different results, while the first use of 'cooling_time' is different than subsequent calls.

7 years, 1 month

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev April 2014