yt-dev May 2016

yt-dev@python.org

17 participants
36 discussions

Fwd: [glue-viz-dev] ANN: glue-vispy-viewers v0.4 released!

by Matthew Turk

Seems interesting. ---------- Forwarded message ---------- From: Thomas Robitaille <thomas.robitaille(a)gmail.com> Date: Wed, May 25, 2016 at 11:07 AM Subject: [glue-viz-dev] ANN: glue-vispy-viewers v0.4 released! To: glue-viz(a)googlegroups.com, glue-viz-dev(a)googlegroups.com Hi everyone, With the glue v0.8 release out of the door, we are happy to also let you know that the plugin with the experimental 3D viewers for glue – glue-vispy-viewers – also has a new release (v0.4). Since the last time I advertised these plugins, there have been a number of improvements, including: The ability to select data in the 3D viewers The ability to save and restore Glue sessions with 3D viewers Optimizations of the panels on the left hand side of the application for small screens The ability to save static views of the 3D viewers to files A toolbar icon to continuously rotate the view A toolbar icon to record an animation to a GIF file (this requires the imageio package to be installed) A number of bug fixes that affected usability The ability to switch between an orthogonal and perspective projection This plugin can now be installed using Anaconda: conda install -c conda-forge glue-vispy-viewers or if you use pip: pip install glue-vispy-viewers --upgrade --no-deps Please note that the package should still be considered experimental. If you run into any issues or have any requests, we would love to hear from you - you can either send a message to the glue-viz(a)googlegroups.com mailing list, or open an issue on GitHub in the following repository: https://github.com/glue-viz/glue-vispy-viewers/issues Thanks! Tom Robitaille and Penny Qian -- You received this message because you are subscribed to the Google Groups "Glue development discussion" group. To unsubscribe from this group and stop receiving emails from it, send an email to glue-viz-dev+unsubscribe(a)googlegroups.com. To post to this group, send email to glue-viz-dev(a)googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/glue-viz-dev/CAGMHX_1qqQwJWsWtN49D5QbtPX%…. For more options, visit https://groups.google.com/d/optout.

5 years, 6 months

Issue #1224: test_grid_arrays_view fails on Windows (yt_analysis/yt)

by John ZuHone

New issue 1224: test_grid_arrays_view fails on Windows https://bitbucket.org/yt_analysis/yt/issues/1224/test_grid_arrays_view-fail… John ZuHone: It looks like the type conversion in `grid_container.pyx` is failing here, but I haven't the foggiest idea why: ```pycon ====================================================================== FAIL: yt.geometry.tests.test_grid_container.test_grid_arrays_view(array([[ 0.00000000e+000, 0.00000000e+000, 0.00000000e+000], ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\jzuho\Miniconda3\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 296, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 787, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 713, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 77.77777777777777%) x: array([[ 0.000000e+000, 0.000000e+000, 0.000000e+000], [ 2.121996e-314, 4.940656e-324, 2.500000e-001], [ 3.125000e-002, 3.125000e-002, 4.243992e-314],... y: YTArray([[ 0. , 0. , 0. ], [ 0.25 , 0.25 , 0.25 ], [ 0.25 , 0.25 , 0.375 ],... ====================================================================== FAIL: yt.geometry.tests.test_grid_container.test_grid_arrays_view(array([[ 1.00000000e+000, 1.00000000e+000, 1.00000000e+000], ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\jzuho\Miniconda3\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 296, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 787, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 713, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 77.77777777777777%) x: array([[ 1.000000e+000, 1.000000e+000, 1.000000e+000], [ 2.500000e-001, 2.500000e-001, 7.500000e-001], [ 9.881313e-324, 2.500000e-001, 2.500000e-001],... y: YTArray([[ 1. , 1. , 1. ], [ 0.75 , 0.75 , 0.75 ], [ 0.5 , 0.5 , 0.625 ],... ====================================================================== FAIL: yt.geometry.tests.test_grid_container.test_grid_arrays_view(array([[ 0, 0, 0], ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\jzuho\Miniconda3\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 296, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 787, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 713, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 100.0%) x: array([[ 0, 0, 0], [-1247088400, 396, 8], [ 0, 1071644672, 0],... y: array([[16, 16, 16], [16, 16, 16], [16, 16, 16],... ====================================================================== FAIL: yt.geometry.tests.test_grid_container.test_grid_arrays_view(array([ 0, 1068498944, 0, 0, 0, ---------------------------------------------------------------------- Traceback (most recent call last): File "C:\Users\jzuho\Miniconda3\lib\site-packages\nose\case.py", line 198, in runTest self.test(*self.arg) File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 296, in assert_equal return assert_array_equal(actual, desired, err_msg, verbose) File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 787, in assert_array_equal verbose=verbose, header='Arrays are not equal') File "C:\Users\jzuho\Miniconda3\lib\site-packages\numpy\testing\utils.py", line 713, in assert_array_compare raise AssertionError(msg) AssertionError: Arrays are not equal (mismatch 83.33333333333333%) x: array([ 0, 1068498944, 0, 0, 0, 1071775744], dtype=int32) y: array([0, 1, 2, 2, 3, 3]) ``` Responsible: MatthewTurk

5 years, 6 months

Issue #1223: annotate_mesh_lines and annotate_cell_edges should be combined. (yt_analysis/yt)

by Andrew Myers

New issue 1223: annotate_mesh_lines and annotate_cell_edges should be combined. https://bitbucket.org/yt_analysis/yt/issues/1223/annotate_mesh_lines-and Andrew Myers: Currently, these are two different plot callbacks that do similar things, but only work for certain dataset types. They should be combined into a single callback that does thing right thing under the hood. Responsible: atmyers

5 years, 6 months

Issue #1222: Many plot callbacks do not work with non-cartesian datasets (yt_analysis/yt)

by John ZuHone

New issue 1222: Many plot callbacks do not work with non-cartesian datasets https://bitbucket.org/yt_analysis/yt/issues/1222/many-plot-callbacks-do-not… John ZuHone: A number of callbacks do not work properly with non-cartesian datasets: * Anything that does vectors, i.e. `QuiverCallback`, `VelocityCallback`, `MagFieldCallback`, etc. * Drawing grid or cell lines, i.e. `GridBoundaryCallback`, `CellEdgesCallback` * Contouring This will take a substantial, focused effort on the part of one or more people to get working properly. I'm marking this 3.3 but I'm not sure if that's what we want or not. Open to having it pushed back.

5 years, 6 months

Issue #1221: Improving docs for basic manipulation of halo catalogue data (yt_analysis/yt)

by Anonymous

New issue 1221: Improving docs for basic manipulation of halo catalogue data https://bitbucket.org/yt_analysis/yt/issues/1221/improving-docs-for-basic-m… Anonymous: As a new user of yt, I've found it exceedingly hard to find just basic examples of manipulating the halo catalogues. A lot of the examples, whilst great, are designed for more advanced users who are interested in doing renderings, halo profiles etc. which are usually stage 3 or 4 for the entry level user. The only place I can find information about accessing the actual halo catalogue content (e.g. halo masses, positions etc. from Rockstar) is here: http://yt-project.org/docs/dev/analyzing/analysis_modules/halo_transition.h… This simple example is actually confusing in and of itself as it isn't clear if this is the masses of the particles in the halo or just the halo masses themselves. I thought there would be just a simple way to access the halo catalogue information (e.g. hc['Rvir']) without doing anything more sophisticated like masking/filtering. It would be great if some new docs could be added for just really fundamental manipulation of the data loaded from the halo finder output. Responsible: yt_analysis

5 years, 6 months

Issues with accessing ActiveDimensions attribute?

by Rasmi Elasmar

Hi all, I'm trying to create two derived fields (one for stellar density, and one for dark matter density) based on <https://bitbucket.org/yt_analysis/yt/src/cee2a160c5351c376afea65bea34627924…> these <https://bitbucket.org/yt_analysis/yt/src/cee2a160c5351c376afea65bea34627924…> from yt2. I'm running yt 3.2.3, and the star_density and dm_density fields seem to have been removed. So far, the yt2 code has transferred fine, with minimal changes: - amrutils.CICDeposit_3() -> amrutils.CICDeposit.CICDeposit_3() - np.float64(data['dx']) -> np.float64(np.ravel(data['dx'])[0] - (data['dx'] appears to be a multidimensional array of all the same values of dx, so I'm just taking the first one -- is there a better way to do this?) Besides those two quirks, the code runs (I'm able to add a field using ds.add_field), but I get an error when I try to access the data using ds.all_data()['star_density'] (it seems now is when the field is actually computed). I get the following error: > <ipython-input-5-1af8fbcb718a> in _spdensity(field, data) > 1 def _spdensity(field, data): > ----> 2 blank = np.zeros(data.ActiveDimensions, dtype='float64') > 3 if data['particle_position_x'].size == 0: return blank > 4 filter = data['creation_time'] > 0.0 > 5 if not filter.any(): return blank > AttributeError: 'YTRegion' object has no attribute 'ActiveDimensions' All the examples of ActiveDimensions that I saw in the docs and source accessed ActiveDimensions as a property of some grid (i.e. g.ActiveDimensions). Is there a simple way to access that from the data/YTRegion object that I'm missing? I can access ds.index.grids and take the first grid there, but ActiveDimensions differs across the grids (And when I try to do this from within _spdensity, data doesn't have an index.grids object, just fake_index (which can't access the grids)). Is there something I'm missing? Thanks, Rasmi

5 years, 6 months

Move minimum h5py version to 2.4.0?

by Nathan Goldbaum

Hi all, I just opened a PR that moves our minimum supported h5py version to 2.4.0: https://bitbucket.org/yt_analysis/yt/pull-requests/2188 See the pull request description for a justification and explanation. Since this might be disruptive I wanted to raise this here to get people's attention. If you have issues with this, please reply to this thread so we can discuss the pros and cons. -Nathan

5 years, 6 months

Fwd: [sympy] Feedback requested: The future of Python 2.7 support in SymPy

by Nathan Goldbaum

Since we directly depend on sympy at a low level, this is something we need to think about dealing with. ---------- Forwarded message ---------- From: Aaron Meurer <asmeurer(a)gmail.com> Date: Thu, May 19, 2016 at 10:51 AM Subject: [sympy] Feedback requested: The future of Python 2.7 support in SymPy To: "sympy(a)googlegroups.com" <sympy(a)googlegroups.com> Hi all. Some of us in the broader scientific Python community have been discussing the future of Python 2 support for various libraries. As you may know, Python 2.7 will cease to be supported by the core Python development team in 2020, meaning all updates to it will cease, including security updates. However, even though we are six major versions into Python 3, the larger community as a whole is still slow on uptake for supporting it. The proposal is for libraries to let the community know now when they plan to drop Python 2.7 support, so that they will better prepared for it, and hopefully so as an encouragement to start transitioning now, if they haven't already. *I propose that we put it on our roadmap to drop Python 2.7 support in 2019. *That is, the first release we do in 2019 will be the last to support Python 2.7. This is consistent with what we've done so far, which is to drop support for Python versions once they cease being supported by core Python. Other libraries, such as IPython and likely matplotlib, are also joining together to sign a formal statement about this, which is drafted at https://python3statement.github.io/. Some libraries, such as IPython and matplotlib, are proposing to support a patchfix branch for an older version that supports Python 2.7, but I am opposed to any plan for SymPy that means supporting more than one version at a time, as I don't think we have the development effort for it. *I would like to hear feedback on this, both positive and negative. It isn't an official decision yet, until the community agrees on it.* Here is my rationale for doing this. I also plan to publish a blog post about this soon, which goes into more detail: As you also probably know, SymPy, like other Python libraries, has done extra work to support Python 2 and 3 in the same codebase. While this work is easier than it used to be, it does put a maintainence burden on SymPy, and it prevents us from using language features which are Python 3-only. One language feature in particular that I would love to be able to use in SymPy is keyword-only arguments. This lets you write, for instance def function(x, y, *, flag=False): ... and then function(x, y, True) is a TypeError. Only function(x, y, flag=True) will work. This future-proofs the API, e.g., you can easily change it to function(x, y, z, *, flag=False) without any API breaks, and it forces explicitness in keyword arguments. That's one example. There are other Python 3-only features that we may or may not be able to make use of as well (like function annotations). And even without that, the maintenance burden of supporting both versions is nontrivial. It means all developers have to know about the quirks of Python 2 and 3, regardless of which one they use primarily. It means that we always have to remember to add all the right compatibility imports at the top of files, and avoid things which are one version-only. And it means extra builds in the test matrix. Aaron Meurer -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sympy+unsubscribe(a)googlegroups.com. To post to this group, send email to sympy(a)googlegroups.com. Visit this group at https://groups.google.com/group/sympy. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6Kc4QmJ2zso4JfdwVyebxq4NMZW… <https://groups.google.com/d/msgid/sympy/CAKgW%3D6Kc4QmJ2zso4JfdwVyebxq4NMZW…> . For more options, visit https://groups.google.com/d/optout.

5 years, 6 months

PR review hangout: Wednesday May 18, 1:00 PM CDT

by Nathan Goldbaum

Hi all, Here's the link for this week's PR review hangout: https://plus.google.com/b/107728486871834552760/events/c04tj7intp8o00a6hln6… -Nathan

5 years, 6 months

Issue #1220: sz_kinetic field fails on FLASH datasets for certain axes (yt_analysis/yt)

by John ZuHone

New issue 1220: sz_kinetic field fails on FLASH datasets for certain axes https://bitbucket.org/yt_analysis/yt/issues/1220/sz_kinetic-field-fails-on-… John ZuHone: The following simple script fails mysteriously when projecting `"sz_kinetic"` along either the y or z-axis, but not the x-axis: ```python import yt ds = yt.load("GasSloshing/sloshing_nomag2_hdf5_plt_cnt_0100") prj = ds.proj("sz_kinetic", 2) ``` ```pycon --------------------------------------------------------------------------- RuntimeError Traceback (most recent call last) <ipython-input-3-fec24ac2f48f> in <module>() ----> 1 prj = ds.proj("sz_kinetic", 2) /Users/jzuhone/Source/yt/yt/data_objects/construction_data_containers.py in __init__(self, field, axis, weight_field, center, ds, data_source, style, method, field_parameters, max_level) 260 261 if not self.deserialize(field): --> 262 self.get_data(field) 263 self.serialize() 264 /Users/jzuhone/Source/yt/yt/data_objects/construction_data_containers.py in get_data(self, fields) 334 self._initialize_projected_units(fields, chunk) 335 _units_initialized = True --> 336 self._handle_chunk(chunk, fields, tree) 337 # Note that this will briefly double RAM usage 338 if self.method == "mip": /Users/jzuhone/miniconda3/lib/python3.5/contextlib.py in __exit__(self, type, value, traceback) 75 value = type() 76 try: ---> 77 self.gen.throw(type, value, traceback) 78 raise RuntimeError("generator didn't stop after throw()") 79 except StopIteration as exc: /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in _field_parameter_state(self, field_parameters) 953 new_field_parameters.update(old_field_parameters) 954 self.field_parameters = new_field_parameters --> 955 yield 956 self.field_parameters = old_field_parameters 957 /Users/jzuhone/Source/yt/yt/data_objects/construction_data_containers.py in get_data(self, fields) 334 self._initialize_projected_units(fields, chunk) 335 _units_initialized = True --> 336 self._handle_chunk(chunk, fields, tree) 337 # Note that this will briefly double RAM usage 338 if self.method == "mip": /Users/jzuhone/Source/yt/yt/data_objects/construction_data_containers.py in _handle_chunk(self, chunk, fields, tree) 434 v = np.empty((chunk.ires.size, len(fields)), dtype="float64") 435 for i, field in enumerate(fields): --> 436 d = chunk[field] * dl 437 v[:,i] = d 438 if self.weight_field is not None: /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in __getitem__(self, key) 268 return self.field_data[f] 269 else: --> 270 self.get_data(f) 271 # fi.units is the unit expression string. We depend on the registry 272 # hanging off the dataset to define this unit object. /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in get_data(self, fields) 1182 1183 fields_to_generate += gen_fluids + gen_particles -> 1184 self._generate_fields(fields_to_generate) 1185 for field in list(self.field_data.keys()): 1186 if field not in ofields: /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in _generate_fields(self, fields_to_generate) 1240 for f in gip.fields: 1241 if f not in fields_to_generate: -> 1242 fields_to_generate.append(f) 1243 1244 @contextmanager /Users/jzuhone/miniconda3/lib/python3.5/contextlib.py in __exit__(self, type, value, traceback) 75 value = type() 76 try: ---> 77 self.gen.throw(type, value, traceback) 78 raise RuntimeError("generator didn't stop after throw()") 79 except StopIteration as exc: /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in _field_lock(self) 1245 def _field_lock(self): 1246 self._locked = True -> 1247 yield 1248 self._locked = False 1249 /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in _generate_fields(self, fields_to_generate) 1202 fi = self.ds._get_field_info(*field) 1203 try: -> 1204 fd = self._generate_field(field) 1205 if fd is None: 1206 raise RuntimeError /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in _generate_field(self, field) 308 if tr is None: 309 raise YTCouldNotGenerateField(field, self.ds) --> 310 return tr 311 312 def _generate_fluid_field(self, field): /Users/jzuhone/miniconda3/lib/python3.5/contextlib.py in __exit__(self, type, value, traceback) 75 value = type() 76 try: ---> 77 self.gen.throw(type, value, traceback) 78 raise RuntimeError("generator didn't stop after throw()") 79 except StopIteration as exc: /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in _field_type_state(self, ftype, finfo, obj) 965 else: 966 obj._current_fluid_type = ftype --> 967 yield 968 obj._current_particle_type = old_particle_type 969 obj._current_fluid_type = old_fluid_type /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in _generate_field(self, field) 305 tr = self._generate_particle_field(field) 306 else: --> 307 tr = self._generate_fluid_field(field) 308 if tr is None: 309 raise YTCouldNotGenerateField(field, self.ds) /Users/jzuhone/Source/yt/yt/data_objects/data_containers.py in _generate_fluid_field(self, field) 325 rv = self._generate_spatial_fluid(field, ngt_exception.ghost_zones) 326 else: --> 327 rv = finfo(gen_obj) 328 return rv 329 /Users/jzuhone/Source/yt/yt/fields/derived_field.py in __call__(self, data) 193 raise RuntimeError( 194 "Something has gone terribly wrong, _function is NullFunc " + --> 195 "for %s" % (self.name,)) 196 with self.unit_registry(data): 197 dd = self._function(self, data) RuntimeError: Something has gone terribly wrong, _function is NullFunc for ('flash', 'velz') ``` Responsible: jzuhone

5 years, 6 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev May 2016