--- 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.
--- 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.
--- 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.
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/aw2tbofhttp://tinyurl.com/amp7nochttp://tinyurl.com/arnqmfw
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
--- 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.
--- 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.
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
