yt-dev November 2014

yt-dev@python.org

16 participants
28 discussions

by Cameron Hummels

Fellow yt users: We at the yt development team want to make yt better for you, the user. We have prepared a short survey to gain your valuable feedback to help us understand what is working in yt and what is not. Could you please spare 2 minutes to fill out our survey below? We plan to collect responses and make available a selection of results by December 10, so please let us know what you think at the following URL: http://goo.gl/forms/hRNryOWTPO On behalf of the yt development team, Cameron -- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

5 years, 7 months

Issue #946: Covering grid doesn't set "center" field parameter (yt_analysis/yt)

by Kacper Kowalik

New issue 946: Covering grid doesn't set "center" field parameter https://bitbucket.org/yt_analysis/yt/issue/946/covering-grid-doesnt-set-cen… Kacper Kowalik: This simple script: ``` #!python import yt ds = yt.load("Sedov_3d/sedov_hdf5_chk_0003") data = ds.covering_grid(1, left_edge=ds.domain_left_edge, dims=[32,32,32]) data["radial_velocity"] ``` yields rather confusing traceback: ``` #!text Traceback (most recent call last): File "bug.py", line 4, in <module> data["radial_velocity"] File "yt/src/yt-my/yt/data_objects/data_containers.py", line 249, in __getitem__ self.get_data(f) File "yt/src/yt-my/yt/data_objects/construction_data_containers.py", line 531, in get_data if len(gen) > 0: self._generate_fields(gen) File "yt/src/yt-my/yt/data_objects/data_containers.py", line 719, in _generate_fields fd = self._generate_field(field) File "yt/src/yt-my/yt/data_objects/data_containers.py", line 286, in _generate_field tr = self._generate_fluid_field(field) File "yt/src/yt-my/yt/data_objects/data_containers.py", line 306, in _generate_fluid_field rv = finfo(gen_obj) File "yt/src/yt-my/yt/fields/derived_field.py", line 184, in __call__ dd = self._function(self, data) File "yt/src/yt-my/yt/fields/vector_operations.py", line 109, in _radial theta = data['index', 'spherical_theta'] File "yt/src/yt-my/yt/data_objects/data_containers.py", line 249, in __getitem__ self.get_data(f) File "yt/src/yt-my/yt/data_objects/construction_data_containers.py", line 531, in get_data if len(gen) > 0: self._generate_fields(gen) File "yt/src/yt-my/yt/data_objects/data_containers.py", line 719, in _generate_fields fd = self._generate_field(field) File "yt/src/yt-my/yt/data_objects/data_containers.py", line 286, in _generate_field tr = self._generate_fluid_field(field) File "yt/src/yt-my/yt/data_objects/data_containers.py", line 306, in _generate_fluid_field rv = finfo(gen_obj) File "yt/src/yt-my/yt/fields/derived_field.py", line 184, in __call__ dd = self._function(self, data) File "yt/src/yt-my/yt/fields/geometric_fields.py", line 104, in _spherical_theta coords = get_periodic_rvec(data) File "yt/src/yt-my/yt/fields/field_functions.py", line 51, in get_periodic_rvec coords = obtain_rvec(data) File "yt/utilities/lib/geometry_utils.pyx", line 89, in yt.utilities.lib.geometry_utils.obtain_rvec (yt/utilities/lib/geometry_utils.c:2228) TypeError: 'NoneType' object has no attribute '__getitem__' ``` `covering_grid` should either set sane default for *center* or fields using `ValidateParameter()` should catch this earlier and more gracefully.

5 years, 7 months

Issue #945: Adding multiple sets of annotations to a slice is slow (yt_analysis/yt)

by Daniel Fenn

New issue 945: Adding multiple sets of annotations to a slice is slow https://bitbucket.org/yt_analysis/yt/issue/945/adding-multiple-sets-of-anno… Daniel Fenn: If I open a large dataset and create a slice, then add density contours, followed by text annotations, the text annotations take a very long time to add. If I add the text annotations before adding the contours, it's much faster. If I add multiple sets of density contours, each set takes progressively longer. Nathan Goldbaum has suggested that implementing caching would alleviate the issue. Responsible: yt_analysis

5 years, 7 months

Issue #944: Slices of fields that need ghost zones are slow for patch AMR data (yt_analysis/yt)

by Nathan Goldbaum

New issue 944: Slices of fields that need ghost zones are slow for patch AMR data https://bitbucket.org/yt_analysis/yt/issue/944/slices-of-fields-that-need-g… Nathan Goldbaum: On my laptop, the following script: ``` #!python import yt import time def test(field): slc = yt.SlicePlot(ds, 2, field) if __name__ == "__main__": ds = yt.load("GasSloshing/sloshing_nomag2_hdf5_plt_cnt_0150") ds.periodicity = (True, True, True) setup = "from __main__ import test" t0 = time.time() test('density') tden = time.time() - t0 t0 = time.time() test('velocity_divergence') tdiv = time.time() - t0 print tden, tdiv ``` shows that it takes about 3.5 seconds to do the density slice and 63 seconds to do the velocity_divergence slice.

5 years, 7 months

prettying up the field list

by Michael Zingale

I've been looking over the field list: http://yt-project.org/docs/dev/reference/field_list.html#field-list At the bottom of that page, we list the fields specific to each frontend/code. I'd like to make the presentation for each frontend a table, with columns for the name, units, what its aliases to, and whether it is a particle -- these are what we currently list, and perhaps show the display name. Showing it as a table for each frontend would be more compact than the list, and I think it would be clearer for people to read. Before I hack the script that writes that page, I wanted to see if there are any objections. Also, a minor point, there is a _dynamical_time() field which I assume is the free-fall timescale assuming uniform density throughout the collapse. I've always seen a '32' not '16' in the denominator (see, e.g. Carroll & Ostlie, Eq. 12.26 or Kippenhahn & Weigert Eq. 27.10). -- 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

5 years, 7 months

PlotWindow show() outside of notebook

by John ZuHone

Hi gang, I got an inquiry about using the PlotWindow plot show() method outside of the notebook. How hard would it be to extend this to other matplotlib backends, so that a window pops up on the screen when you want to see a plot, but aren't in the notebook? Obviously matplotlib does this already, so it's a matter of figuring out how to get it hooked up. Best, John Z Sent from John ZuHone's iPad

5 years, 7 months

Issue #943: Derived fields not properly recognized in create profile (yt_analysis/yt)

by Hilary Egan

New issue 943: Derived fields not properly recognized in create profile https://bitbucket.org/yt_analysis/yt/issue/943/derived-fields-not-properly-… Hilary Egan: When creating a profile plot of a derived field, you can't access the derived field unless you originally defined it as ('gas', 'my_field') or ('index', 'my_field'). This is confusing, and I don't think it's supposed to work this way. Example script that does not work: http://paste.yt-project.org/show/5226/ Traceback: http://paste.yt-project.org/show/5227/ Script that fixes the problem: http://paste.yt-project.org/show/5228/

5 years, 7 months

Doc build timeouts//failures

by Nathan Goldbaum

Hi all, If anyone has some time this week, it would be great if you could take a look at the latest docs builds: http://tests.yt-project.org/job/yt-docs-3.0/395/console Some of the recipes seem to be triggering tracebacks and the total docs build time now regularly exceeds the 200 min timeout. It would be great if we could bring the total docs build time down - I bet there are a few recipes that are dominating the build time. Thanks for your help getting yt 3.1 out the door. -Nathan

5 years, 7 months

A plea for failing tests

by Matthew Turk

Hi all, Cameron and I were chatting, and it looks like only 5/19 of the analysis modules have tests. I think it would be really valuable to have tests -- even failing ones -- so that we can start finishing the job of porting to yt-3.0 all of the analysis modules. So what do you think -- should we start writing some tests designed to fail? -Matt

5 years, 7 months

Issue #941: CutRegionSelector doesn't work with some data types (yt_analysis/yt)

by Nathan Goldbaum

New issue 941: CutRegionSelector doesn't work with some data types https://bitbucket.org/yt_analysis/yt/issue/941/cutregionselector-doesnt-wor… Nathan Goldbaum: It turns out the `CutRegionSelector` I recently added doesn't work so well for FLASH data: ``` #!python import yt ds = yt.load("GasSloshing/sloshing_nomag2_hdf5_plt_cnt_0150") dd = ds.all_data() dd = dd.cut_region("obj['density'] > 1e-27") slc = yt.SlicePlot(ds, 2, 'density', data_source=dd) slc.set_zlim('density', 1e-30, 1e-25) slc.set_figure_size(5) slc.save() ``` ![sloshing_nomag2_hdf5_plt_cnt_0150_Slice_z_density.png](https://bitbucket.org/repo/BXbAb/images/3572484347-sloshing_nomag2_hdf5_plt_cnt_0150_Slice_z_density.png) This is happening because `CutRegionSelector` is using a fragile exact comparison between floats. It does this to take advantage of an efficient hashing algorithm, but it looks like this comes at the cost of maintaining bitwise identicality between two different ways of calculating cell positions. The fix is either: 1. Figure out why the FLASH cell position fields are not bitwise identical to the cell positions calculated inside `SelectorObject.fill_mask`. It seems Enzo data is unaffected by the round-off artifacts we see with FLASH data, so we know that means it is possible to rely on the cell positions matching exactly at some level. 2. Use a more forgiving data structure to retrieve matching cell positions. A KD-tree seems like a natural choice, but I'm unsure if there's a ready-to-use KD-tree library available. Responsible: ngoldbaum

5 years, 7 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev November 2014