New issue 1185: data wrapping error when altering slice axes
When creating sliceplots, I've been experiencing an effect in which some hdf5 data that is cutoff by the set width of the plot is added on or wrapped onto the remaining space at the other end of the plot. This can be fixed by increasing the width of the plot along the axis for which the wrapping is occuring, but clearly shouldn't be happening so I thought I'd let you know. :)
The wrapping effect can be seen on the left side of the first plot along the white line. In the next plot I've increased the width along the problematic axes and the problem goes away.
I've attached as simple a notebook as possible which shows this. I did not attach the dataset here due to its size, but I'd be happy to provide it as well as the geometry facets which may help to show this more clearly. yt is great and I hope to keep using it in the future!
Some time ago Bitbucket introduced build statuses .
From the point of view of our development process they're ill-designed
as they requires testing infrastructure to have repo:write access to
each and every fork of yt_analysis/yt. Nevertheless, I updated fido to
use that functionality as an *opt-in* feature.
You can see how it looks like on PR 2036.
If you'd like to have fancy icons indicating test results nicely
attached to your commits on a pull requests, you can do it by adding
write access for user: 'yt-fido' to your yt fork . This will also
*disable* regular yt-fido comments.
Please bear in mind that it's equivalent to giving *me* write access to
your yt fork. If you feel uncomfortable with that, *DO NOT* do it.
I am Wasim Thabraze, a Computer Science Undergraduate. I have thoroughly
gone through the GSoC ideas page and have narrowed down my choices to the
project 'Web Development for Gammapy'.
(www.openflock.co) is one of such projects I built using Python. I have
also contributed to couple of Open source projects (Openhatch and Mozilla
Looking at the TeVCat website, I have got a rough idea on how the website
of Gammapy should work. I have started working on a demo web app of Gammapy
and will report the link to the app in this mailing list in a couple of
days so that I can get feedback about it.
GitHub : https://github.com/waseem18
Portfolio : http://www.thabraze.me
I hope I can code with Astropy this summer, and I really appreciate your
as you may have noticed I've recently introduced new test runner (PR
1893 and PR 2010). It allows to keep testsuite defined as a part of main
yt repository. Each test run parses 'tests/tests_2.7.yaml' and creates a
set of nose tasks out of it. The aforementioned 'tests_2.7.yaml' looks
where each element in 'answer_tests' defines answer name
(local_artio_270 in above snippet) and specifies a list of
files/classes/methods that will be validated
(yt/frontends/artio/tests/test_outputs.py in above snippet).
As a result:
1) You can easily add new answer tests, by adding:
2) You can easily generate new answers to existing tests by e.g.
renaming local_artio_270 to local_artio_271.
I'd encourage people with open pull requests that are waiting for
regeneration of answer tests to merge with current tip of yt_analysis/yt
and start using this. You can safely ignore 'tests/test_3.4.yaml' for now.
I'll update the part of the documentation describing how to write answer
tests with more detailed description asap.
as most of you know, we have an official Debian package for yt
I used to maintain it, but nowadays I don't have enough spare cycles to
do that anymore.
I'd like you to ask if someone is willing to maintain it in my place.
We have a very friendly contact downstream: Ole Streicher, whom I've
cc'ed in this mail. I'm sure he'll be an invaluable help to anyone
wanting to keep this work going.
New issue 1184: Datasets are recognized as orion2 if an "orion2.ini" file exists
So for some reason my test data directory has an "orion2.ini" file in it. This means that any data directories I try to load are getting recognized incorrectly as orion2 datasets.
I think the orion2 frontend should be smarter about this, maybe by checking if other files exist before returning from `_is_valid`.
@atmyers do you have thoughts about this?
I'm curious what people think about switching the default camera lens from
"plane-parallel" to "perspective".
Perspective cameras are more intuitive - it makes sense to talk about a
camera position and orientation, since all the rays originate from a single
The last time this came up, the major concern was that perspective renders
were not as performant as plane-parallel renders.
Today Kacper submitted a PR that substantially improves the performance of
the perspective camera:
If we benchmark and find that the plane-parallel camera is competitive with
the plane-parallel camera in terms of speed, would it be ok to switch to
perspective for the default camera?