yt-dev August 2015

yt-dev@python.org

17 participants
38 discussions

by Nathan Goldbaum

Hi all, I'd like to spend some time in the next week or two doing some cleanup and tidying up on the yt repo. This comes in two flavors: removing dead code and adding basic linting tests. Dead Code --------------- There are still a number of big chunks of legacy code in the codebase that aren't called by anything, including: * boolean data objects * reason / reason plot widgets (yt.gui) * two scripts in the top-level "scripts" directory (pyro_queue.py and yt_lodgeit.py) * the top-level "tests" directory * possibly some of the analysis modules? (star_analysis and two_point_functions) I'm curious what others think about removing some or all of this code. I'd particularly like to hear if I'm wrong about the code in the list above or if I've missed any chunks of unused code. I do understand the desire to keep the code in the repository in the hopes that one day someone might make it functional, but I think this consideration is balanced by how confusing it can be to come across dead code and then get frustrated after finding weird incompatibilities. Basic Linting Tests ------------------------- I'd like to catch as many errors as possible by doing basic static analysis of the yt codebase using pyflakes and flake8. We already have coverage with both tools run as part of the test suite, but introducing errors detected by these tools does not fail the build. I'd like to add a few of the errors caught by these tools to the test suite itself, making the tools optional dependencies for the tests. Hopefully these new tests will be useful and not obnoxious: I'm not talking about enforcing pep8 as part of the test suite. To do this, I think the biggest change necessary is to get rid of all instances of "import *" throughout the codebase. This will allow us to test for unused imports (probably shouldn't fail the build) or missing imports (definitely should fail the build). Again, I'd appreciate any comments or objections to this general approach. Thanks for your attention! Sorry for the long e-mail... -Nathan

5 years, 3 months

Issue #1060: yt relies on private API in matplotlib write_png (that changed) (yt_analysis/yt)

by Anonymous

New issue 1060: yt relies on private API in matplotlib write_png (that changed) https://bitbucket.org/yt_analysis/yt/issues/1060/yt-relies-on-private-api-i… Anonymous: Refer to the following: https://bitbucket.org/yt_analysis/yt/src/57abf679467c2b46098177a6662cc507c1… In matplotlib 1.5.dev1, the signature of `write_png` is `write_png(buffer, file, dpi=0)`.

5 years, 3 months

Issue #1059: Enzo nuclei density does not precisely equal sum of species densities in python 3 (yt_analysis/yt)

by Nathan Goldbaum

New issue 1059: Enzo nuclei density does not precisely equal sum of species densities in python 3 https://bitbucket.org/yt_analysis/yt/issues/1059/enzo-nuclei-density-does-n… Nathan Goldbaum: John ZuHone offers this repro script that illustrates the issue: ``` #!python 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 from __future__ import print_function import yt from yt.testing import assert_array_equal import numpy as np from IPython import embed ecp = "enzo_cosmology_plus/DD0046/DD0046" ds = yt.load(ecp) dd = ds.all_data() a = dd["He_nuclei_density"] b = dd["He_number_density"] + dd["He_p1_number_density"] + dd["He_p2_number_density"] err = np.abs(a-b)/a print(np.max(err)) assert_array_equal(a,b) ``` This is currently causing one of the Enzo answer tests to fail on python3.

5 years, 3 months

Issue #1058: [BUGFIX] ART star particle creation time field (yt_analysis/yt)

by Kenza Arraki

New issue 1058: [BUGFIX] ART star particle creation time field https://bitbucket.org/yt_analysis/yt/issues/1058/bugfix-art-star-particle-c… Kenza Arraki: dd[('stars', 'particle_creation_time')] fails ``` #!python YTUnitOperationError: The <ufunc 'subtract'> operator for YTArrays with units (dimensionless) and (code_time) is not well defined. ``` The 'particle_creation_time' field has been incorrectly given 'code_time' units. The 'current_time' attribute needs to return a time with physical units. Responsible: karraki

5 years, 3 months

Nightly dev builds

by John Zuhone

Hi everybody (but especially Cameron), A while back I set up nightly dev binary builds for Anaconda and PyPI wheels--a month ago they stopped because something was wrong with the machine (right now these are Mac OS X only). I've restarted them on a different machine. We now have binary Anaconda builds made every night from the tip of the dev branch for Python 2.7 and 3.4. I'll try to set up PyPI wheels, and also set up the Windows builds, sometime this week. The files are hosted here: http://anaconda.org/jzuhone/yt/files Each file is tagged with the changeset that it was made off of. I'll need to figure out some way of managing them before they get too numerous. Here's how to install: conda install -c http://conda.anaconda.org/jzuhone/channel/dev yt and here's how to update: conda update -c http://conda.anaconda.org/jzuhone/channel/dev yt The key is to have the "dev" channel specified. Best, John

5 years, 3 months

Issue #1057: seg fault in particle_deposit.pyx (yt_analysis/yt)

by Brian O'Shea

New issue 1057: seg fault in particle_deposit.pyx https://bitbucket.org/yt_analysis/yt/issues/1057/seg-fault-in-particle_depo… Brian O'Shea: This script: http://paste.yt-project.org/show/5778/ running on this dataset: http://galactica.pa.msu.edu/~bwoshea/data/datasets/DD0013.tar is causing a segmentation fault in the tip of yt (changeset fffa77d2fdc2) using Cython 0.22 (and 0.22.1). When @ngoldbaum and I tracked it down, it seems to be crashing at line 375 in particle_deposit.pyx , where the value of the variable ii is being set to a large negative number. Note that this bug only seems to occur on some systems - I can get it to happen on my Mac desktop (OS X 10.9.5, LLVM v6) and also a Linux cluster (gcc/4.4.5 and gcc/4.8.3), but Nathan has one machine where it works and one where it doesn't. Nathan will follow this with a stack trace from his gdb bughunt. Responsible: MatthewTurk

5 years, 3 months

about alternative kernel functions

by Bili Dong

Hi all, Currently in yt, only the default cubic spline kernel function is provided and used for the smoothing. I’m thinking about adding more kernel functions, providing the possibility to choose from them and also the possibility for the users to provide their own ones. In my own research, a quintic spline kernel is used, for example. So I guess this functionality might also be useful for other users. My current plan goes like this: 1. Add several common kernel functions besides the current one. 2. Build a naming system. 3. Put a kwarg in appropriate places to pass the name of the kernel function. For now, I’m thinking about put it in the ParticleSmoothOperation class as a parameter of __init__. 4. Reserve a special kwarg value which can be used to pass the user-provided kernel functions. I’m not much experienced with yt. So correct me if there are any mistakes or omissions! Any suggestions are much appreciated! Thanks, Bili

5 years, 3 months

Issue #1056: yt version decode error (yt_analysis/yt)

by Anthony Scopatz

New issue 1056: yt version decode error https://bitbucket.org/yt_analysis/yt/issues/1056/yt-version-decode-error Anthony Scopatz: Minor issue on Python 3 with the yt version command. ```bash $ yt version yt module located at: /home/scopatz/.local/lib/python3.4/site-packages/yt-3.3.dev0-py3.4-linux-x86_64.egg The current version and changeset for the code is: --- Version = 3.3-dev Traceback (most recent call last): File "/home/scopatz/.local/bin/yt", line 9, in <module> load_entry_point('yt==3.3.dev0', 'console_scripts', 'yt')() File "/home/scopatz/.local/lib/python3.4/site-packages/yt-3.3.dev0-py3.4-linux-x86_64.egg/yt/utilities/command_line.py", line 1092, in run_main args.func(args) File "/home/scopatz/.local/lib/python3.4/site-packages/yt-3.3.dev0-py3.4-linux-x86_64.egg/yt/utilities/command_line.py", line 89, in run self(args) File "/home/scopatz/.local/lib/python3.4/site-packages/yt-3.3.dev0-py3.4-linux-x86_64.egg/yt/utilities/command_line.py", line 605, in __call__ print("Changeset = %s" % vstring.strip().decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ```

5 years, 3 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev August 2015