yt-dev February 2013

yt-dev@python.org

12 participants
42 discussions

[yt_analysis/yt] fKDpy.so should be built automatically (issue #506)

by Kacper Kowalik

--- you can reply above this line --- New issue 506: fKDpy.so should be built automatically https://bitbucket.org/yt_analysis/yt/issue/506/fkdpyso-should-be-built-auto… Kacper Kowalik: If there are no apparent reasons against that idea, I think it would be convenient if `fKDpy.so` was built while running `python setup.py build` or `install` -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 1 month

[yt_analysis/yt] Plot window answer tests (issue #505)

by Nathan Goldbaum

--- you can reply above this line --- New issue 505: Plot window answer tests https://bitbucket.org/yt_analysis/yt/issue/505/plot-window-answer-tests Nathan Goldbaum: The correctness of many of the plot callbacks and modifications can be easily evaluated by looking at the plot but are difficult to evaluate in an automated, non-visual way. We should add some tests that create plot window plots, modify them, run callbacks on them, and then save them to disk. We can then store the old images, which can be verified visually by a human, and then every time the answer tests get run, compare the new plots to the known good plots stored in the answers by doing a bitwise diff or some other automated comparison procedure. Responsible: ngoldbaum -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 1 month

[yt_analysis/yt] Plot window axes labels and tick labels should have the same font by default. (issue #504)

by Nathan Goldbaum

--- you can reply above this line --- New issue 504: Plot window axes labels and tick labels should have the same font by default. https://bitbucket.org/yt_analysis/yt/issue/504/plot-window-axes-labels-and-… Nathan Goldbaum: Right now the axes labels and tick label fonts are chosen by matplotlib. Since we use mathtext to generate the axes labels, they get a serif font while the tick labels are sans serif by default. We should figure out a way to force the two fonts to be the same. I'd prefer to use the font the axes labels currently use, as it looks similar to publication fonts. Responsible: ngoldbaum -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 1 month

Avoiding roundoff errors in comparison of floats

by Kacper Kowalik

Hi All! I've been recently struck by roundoff errors in yt. AFAIR some variants of such bugs have been already reported from time to time on #yt or mailing lists and I'd like to propose a general solution that should solve this. The problem can be seen here: http://imgur.com/oIaarPR It's a dense blob (\rho = 2) moving diagonally across uniform medium (\rho = 1). As you can see there are blueish stripes on the few block boundaries. They're caused by yt thinking that blocks on n+1 refinement level overlap with those regions in blocks on "n" level. It all happens here: (yt/data_objects/object_finding_mixin.py) ObjectFindingMixin::get_box_grids ... grid_i = np.where( (np.all(self.grid_right_edge > left_edge, axis=1) & np.all(self.grid_left_edge < right_edge, axis=1)) == True ) The problem is that comparing floats is *not* accurate. What should be done: instead of "a > b", we should do e.g. "(a - b) > eps", where eps is small number grater than machine precision. I've fixed this particular bit as follows: ... dx = self.get_smallest_dx() * 0.1 grid_i = np.where( (np.all(self.grid_right_edge > (left_edge + dx), axis=1) & np.all(self.grid_left_edge < (right_edge - dx), axis=1)) == True ) 10% of the smallest cell size seems to be good approximation of eps at this point. As a result I've got: http://imgur.com/vCGQUKv Still one artifact remained. It was caused by exact the same issue in other place in the code (utilities/lib/geometry_utils.pyx:get_box_grids_level) Using similar trick there yielded: http://imgur.com/wpOCGaf \o/ Sorry for the long mail, but I wanted to share this so we could inspect other place that could suffer from similar issues too. Cheers, Kacper P.s. Nice animations are available here: http://tinyurl.com/aw2tbof http://tinyurl.com/amp7noc http://tinyurl.com/arnqmfw

8 years, 1 month

[yt_analysis/yt] pmods.py broken (issue #503)

by Cameron Hummels

--- you can reply above this line --- New issue 503: pmods.py broken https://bitbucket.org/yt_analysis/yt/issue/503/pmodspy-broken Cameron Hummels: I get a failure, when I try to run a yt script in parallel using the header line: from yt.pmods import * while executing as: mpirun -np 2 python script.py --parallel The traceback is here: http://paste.yt-project.org/show/3171/ I do this to follow the prescription in http://yt.readthedocs.org/en/latest/advanced/parallel_computation.html -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 2 months

2.5 release next Thursday

by Matthew Turk

Hi all, Okay, after a discussion in IRC about releasing 2.5, we've decided to just start pushing ahead. I'd like to propose ([+-][01]) that we set a hard cutoff of a week from today, Valentine's day. If anything doesn't make it in, that's fine. We just put out a release without it and wrap it up in 2.6. (Yeah, we probably need a 2.6.) The remaining blockers: * I want Andrew's pull request to make it in. This is a huge win for everyone. Once it's in, we can add documentation about it, and then it'll be a big feature. * John ZuHone has an outstanding piece of code that builds Enzo data from in-memory hierarchies. I would like to see this make it in, but it is worth a release all by itself. * The remaining tickets are mostly all documentation based. We need: bootcamp in the docs, rotation information in the docs, offaxisprojection in the docs. * We have a need for answer testing for Orion, FLASH, NYX and optionally GDF datasets. I have been the bottleneck here. If you have pinged me in the past, ping me again and I will do this with you. If we don't get to this by 14th, this will be bumped. However: after 2.5 goes out, I would like for us to stop doing *major* features on the 2.x branch and try to focus on 3.0. This may not be possible for all things, but I would like to try to push for that. At a bare minimum, every new feature in 2.6 should be well-tested enough that we can run those tests on 3.0 to determine if it is directly portable. And future-compatible requirements will be in place for new features in 2.6. Also, I'd like to nominate John ZuHone to send out the release announcement, particularly since he has worked so hard to put together initial conditions generation in this release. -Matt

8 years, 2 months

[yt_analysis/yt] Slices in GDF no longer respect data ordering (issue #502)

by Kacper Kowalik

--- you can reply above this line --- New issue 502: Slices in GDF no longer respect data ordering https://bitbucket.org/yt_analysis/yt/issue/502/slices-in-gdf-no-longer-resp… Kacper Kowalik: Recent changes in [gdf/io.py](https://bitbucket.org/xarthisius/yt/commits/e1b7792e680790618385… result in plots being transposed when column-ordered data is being used. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 2 months

[yt_analysis/yt] Install failure with >=cython-0.17 (issue #501)

by Kacper Kowalik

--- you can reply above this line --- New issue 501: Install failure with >=cython-0.17 https://bitbucket.org/yt_analysis/yt/issue/501/install-failure-with-cython-… Kacper Kowalik: I have weird issue, probably related to >=cython-0.17: ``` #!bash cythonc:> yt/utilities/lib/grid_traversal.c Error compiling Cython file: ------------------------------------------------------------ ... np.float64_t right_edge[3] np.float64_t dds[3] np.float64_t idds[3] int dims[3] ctypedef void sample_function( ^ ------------------------------------------------------------ yt/utilities/lib/grid_traversal.pyx:70:0: 'sample_function' redeclared error: 1 errors while compiling 'yt/utilities/lib/grid_traversal.pyx' with Cython ``` Doing s/sample_function/sampler_function/ fixes it. PR will follow shortly. -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 2 months

[yt_analysis/yt] HydroMethod etc (issue #500)

by Matthew Turk

--- you can reply above this line --- New issue 500: HydroMethod etc https://bitbucket.org/yt_analysis/yt/issue/500/hydromethod-etc Matthew Turk: All of the parameters `HydroMethod` `EOSType` `DualEnergyFormalism` are proxies for actual information about the dataset. We should make those actual pieces of information available, instead. And then, get rid of these. Responsible: MatthewTurk -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

8 years, 2 months

Answer testing

by Matthew Turk

Hi all, Currently we run all unit and answer tests on every push. Running answer testing, particularly with FLASH data, takes a long time. (Sidenote: FLASH in 2.x is particularly bad for large data objects, which answer testing does.) This will get worse once Orion and Chombo have been added. I think we're looking at up to 15 minutes per run. This has two effects: 1) Changes which break unit tests take longer to get reported. 2) We'll go through our ShiningPanda monthly allocation quite quickly. There are two solutions that I see: 1) Buy more time on ShiningPanda 2) Only run answer testing at most once a day, but still run unit tests on every push. My proposal is to go with #2 with the backup of #1 as needed. Can I get [+-]1 on this? -Matt

8 years, 2 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

yt-dev February 2013