New issue 1185: data wrapping error when altering slice axes
https://bitbucket.org/yt_analysis/yt/issues/1185/data-wrapping-error-when-a…
Patrick Shriwise:
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!
Hi all,
Here's some information for prospective summer of code students.
If you're applying to work with yt, we'd appreciate it if you post your
application to our wiki:
https://bitbucket.org/yt_analysis/yt/wiki/GSoC-2016-Student-Applications
Please let me know if you're having trouble editing the page.
-Nathan
---------- Forwarded message ----------
From: DVD PS <dps.helio(a)gmail.com>
Date: Sun, Mar 13, 2016 at 4:03 PM
Subject: [OpenAstronomy] GSOC students - application form
To: OpenAstronomy <openastronomy(a)googlegroups.com>
Hello candidates!!!!
>From tomorrow you can upload your application, at the moment I don't know
how this will be (a web form or a file you will have to upload) in any case
I can provide you with the questions that we are asking.
You can find the template in this google document [1] (which you can copy
to your own account and updated it accordingly). Alternatively, you can
download the markdown from the wiki [2] fill it up with your favourite text
editor and create a pdf using pandoc [3]:
$ pandoc -o myname_application_suborg.pdf student_application.md
Remember that some sub-orgs require you post them in their wiki!!
Have a very good week! and good luck for everyone!!
David
[1]
https://docs.google.com/document/d/1bYhpVL3DfMEficzE9oUhn-s0HsKriwZVUkKtzat…
[2]
https://github.com/OpenAstronomy/openastronomy.github.io/wiki/Student-Appli…
[3] http://pandoc.org/
--
You received this message because you are subscribed to the Google Groups
"OpenAstronomy" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to openastronomy+unsubscribe(a)googlegroups.com.
To post to this group, send email to openastronomy(a)googlegroups.com.
To view this discussion on the web, visit
https://groups.google.com/d/msgid/openastronomy/CAD0QkqXCVM0VNhHVbwe27-gZ75…
<https://groups.google.com/d/msgid/openastronomy/CAD0QkqXCVM0VNhHVbwe27-gZ75…>
.
For more options, visit https://groups.google.com/d/optout.
Hi all!
Some time ago Bitbucket introduced build statuses [1].
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 [2]. 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.
Cheers,
Kacper
[1]
http://blog.bitbucket.org/2015/11/18/introducing-the-build-status-api-for-b…
[2] https://bitbucket.org/{user}/{yt_fork_slug}/admin/access
Hello everyone,
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'.
I have experience in web development using Python and Javascript. Openflock
(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
Marketplace).
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
comments.
Regards,
Wasim
Hi,
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
like this:
answer_tests:
local_artio_270:
- yt/frontends/artio/tests/test_outputs.py
...
other_tests:
unittests:
- '-v'
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:
my_answer_name_123
- yt/frontends/blah/tests.py
- yt/frontends/blah/tests2.py:my_special_func
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.
Cheers,
Kacper
Hi!
as most of you know, we have an official Debian package for yt[1]
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.
Cheers,
Kacper
[1] https://anonscm.debian.org/cgit/debian-astro/packages/yt.git
New issue 1184: Datasets are recognized as orion2 if an "orion2.ini" file exists
https://bitbucket.org/yt_analysis/yt/issues/1184/datasets-are-recognized-as…
Nathan Goldbaum:
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?
Hi all,
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
point.
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:
https://bitbucket.org/yt_analysis/yt/pull-requests/2028/
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?
-Nathan