Hi all,
I'd like to ask if there are any plans on organizing 2nd yt workshop?
It's this time of the year when I need to apply for grants at my
university and I'd very much like to include such event in the
application :)
Cheers,
Kacper
Hello yters,
Is there already code that can be used to draw or display an AMR grid on
the plot itself? Or is this an annotation that I should write ;)?
Be Well
Anthony
Hi all,
Is there a reason the install script is still on python 2.7.2? If not, I think we should move to 2.7.3 which fixes several bugs. See: http://www.python.org/download/releases/2.7.3/
I would do this myself but I don't have access to the place where we store the bundled distributions on the yt-project website.
Cheers,
Nathan
Hi all,
We got an anonymous bug today. My guess is this is related to the
transpose in write_image.
-Matt
---------- Forwarded message ----------
From: Anonymous <issues-reply(a)bitbucket.org>
Date: Fri, Sep 28, 2012 at 7:32 AM
Subject: [yt_analysis/yt] annotate_image (issue #430)
To: matthewturk(a)gmail.com
--- you can reply above this line ---
New issue 430: annotate_image
https://bitbucket.org/yt_analysis/yt/issue/430/annotate_image
Anonymous:
Text is transposed with annotate_image.
--
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 (but especially Casey and Tom Robitaille if he's still subscribed :),
Andrew Myers found a very nice solution to issue #414:
https://bitbucket.org/yt_analysis/yt/issue/414/orion-ghot-zones-not-gener...
which he's put in this PR:
https://bitbucket.org/yt_analysis/yt/pull-request/275/reading-in-dds-for-...
I have only limited access to Nyx / Orion data with subgrids, so I
can't test this appropriately. I think the changes look good,
however, so if I can get from any other boxlib user that they still
produce good results, I will accept them. This is also a good time to
mention that going forward I hope to consolidate the various boxlib
readers.
Best,
Matt
Hi all,
As some of you have seen (at least Stephen), I filed a ticket this
morning about increasing testing coverage. The other night Anthony
and I met up in NYC and he had something of an "intervention" about
the sufficiency of answer testing for yt; it didn't take too much work
on his part to convince me that we should be testing not just against
a gold standard, but also performing unit tests. In the past I had
eschewed unit testing simply because the task of mocking data was
quite tricky, and by adding tests that use smaller bits we could cover
unit testable areas with answer testing.
But, this isn't really a good strategy. Let's move to having both.
The testing infrastructure he recommends is the nearly-omnipresent
nose:
http://nose.readthedocs.org/en/latest/
The ticket to track this is here:
https://bitbucket.org/yt_analysis/yt/issue/426/increase-unit-test-coverage
There are a couple sub-items here:
1) NumPy's nose test plugins provide a lot of necessary functionality
that we have reimplemented in the answer testing utilities. I'd like
to start using the numpy plugins, which include things like
conditional test execution, array comparisons, "slow" tests, etc etc.
2) We can evaluate, using conditional test execution, moving to nose
for answer testing. But that's not on the agenda now.
3) Writing tests for nose is super easy, and running them is too. Just do:
nosetest -w yt/
when in your source directory.
4) I've written a simple sample here:
https://bitbucket.org/yt_analysis/yt-3.0/src/da10ffc17f6d/yt/utilities/te...
5) I'll handle writing up some mock data that doesn't require shipping
lots of binary files, which can then be used for checking things that
absolutely require hierarchies.
--
The way to organize tests is easy. Inside each directory with
testable items create a new directory called "tests", and in here toss
some scripts. You can stick a bunch of functions in those scripts.
Anyway, I'm going to start writing more of these (in the main yt repo,
and this change will be grafted there as well) and I'll write back
once the data mocking is ready. I'd like it if we started encouraging
or even mandating simple tests (and/or answer tests) for functionality
that gets added, but that's a discussion that should be held
separately.
The items on the ticket:
* kD-tree for nearest neighbor
* Geometric selection routines
* Profiles
* Projections -- underlying quadtree
* Data object selection of data containers
* Data object selection of points
* Orientation class
* Pixelization
* Color maps
* PNG writing
Is anyone willing to claim any additional items that they will help
write unit tests for?
-Matt
Dear all,
Hi. My name is Hsi-Yu Schive. I'm the main developer of the GAMER code,
which is a GPU-accelerated AMR code for astrophysical simulations.
I'm very interested in adding support of GAMER in yt!
I appreciate if anyone has any suggestion about the best way to initialize this work!
The AMR implementation of GAMER is very similar to FLASH. The AMR hierarchy
is composed of cell blocks, and each of which has a fixed number of cells (e.g., 8^3 cells per block).
An octree data structure is adopted to maintain the AMR hierarchy.
I'll start with following the suggestions given in the "Adding Support for a New Code"
section in the bitbucket yt page and also looking into the Enzo output style.
Any suggestion/comment is more than welcome : )
Sincerely,
Hsi-Yu
Can somebody address this? I'd like to ensure we can continue keeping
up with IPython (especially since a bunch of us are investing in it
quite heavily for our own workflows) but I can't add this to my queue
this at the moment. I think the best way to do this is probably to
add an IPython compat layer to yt/utilities/ that handles higher-level
functionality, since we use relatively little of the IPython API.
-Matt
---------- Forwarded message ----------
From: Anthony Scopatz <issues-reply(a)bitbucket.org>
Date: Tue, Sep 25, 2012 at 3:49 PM
Subject: [yt_analysis/yt] show() failure due to IPython API changes (issue #428)
To: matthewturk(a)gmail.com
--- you can reply above this line ---
New issue 428: show() failure due to IPython API changes
https://bitbucket.org/yt_analysis/yt/issue/428/show-failure-due-to-ipytho...
Anthony Scopatz:
Reporting that the Plot.show() method seems to fail on IPython
0.14-dev because of an API change. The send_figure function is no
longer where yt thinks it is.
{{{python
ImportError Traceback (most recent call last)
<ipython-input-2-4804b2a8abc5> in <module>()
4 p.annotate_flash_ray_data(pf, 'jet', 10)
5 p.annotate_timestamp(0.2/z, 0.2/z, pf, units="days", size=24)
----> 6 p.show()
/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/visualization/plot_window.pyc
in show(self)
788 """
789 if "__IPYTHON__" in dir(__builtin__):
--> 790 self._send_zmq()
791 else:
792 raise YTNotInsideNotebook
/home/scopatz/.local/lib/python2.7/site-packages/yt-3.0dev-py2.7-linux-x86_64.egg/yt/visualization/plot_window.pyc
in _send_zmq(self)
763
764 def _send_zmq(self):
--> 765 from IPython.zmq.pylab.backend_inline import \
766 send_figure
767 for k, v in sorted(self.plots.iteritems()):
ImportError: cannot import name send_figure
}}}
--
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,
(This is preliminary! I would love to hear about problems or other
issues you end up having with it!)
Nathan, Sam and I were chatting today about IPython notebooks.
IPython has a really neat Notebook Viewer at nbviewer.ipython.org
which accepts a URL and then renders that in the browser. After we
played a bit with the pastebin (unsuccessfully) I added a "notebook"
type to the Hub. So if you have a Hub user and your API key is set
correctly, you can navigate in your filesystem to an .ipynb file and
do:
yt upload_notebook that_notebook.ipynb
This will not only toss it up on the Hub (where you can download it or
pass around the URL) but it also will set up a nice little URL
redirector to pass it to the nbviewer. So earlier I uploaded one of
Sam's notebooks and yt spit this back out at me:
--
Upload successful!
To access your raw notebook go here:
https://hub.yt-project.org/go/i7u32m
To view your notebook go here:
https://hub.yt-project.org/nb/i7u32m
--
If you click on that second one you can see how it gets rendered.
Pretty cool! Anyway, let me know if it works for you or if you run
into problems.
-Matt
Hello All,
I am writing to let you know that I have (finally) built the
underlying function for the cylindrical ray tracer which
solves for the time, distance, location, and grid indices
of the ray. The reason that I opened a PR rather rather
than just pushing is that I would appreciate some feedback.
First note that you can play around with this functionality
using the following ipython notebook [1], though you will
also need 2D R,Z data to point it at.
The first question I have is that the rays, unless they begin
or end on a cell boundary, do not include the start or stop
points. This seems like the correct behavior to me, but is
this consistent with the rest of yt?
The second, weirder point is as follows. For 2D R,Z data,
the cell crossings that are calculated *should* be rotationally
invariant. Take p1 and p2 to be two points in r, z, theta s.t.:
p1 = (r1, z1, theta1)
p2 = (r2, z2, theta2)
Then the ray should pass through the same cells if instead
we take q1 and q2 as:
q1 = (r1, z1, theta1 + dtheta)
q2 = (r2, z2, theta2 + dtheta)
for any constant dtheta and r1, z1, theta1, r2, z2, and theta2
at the same values in p1 and p2. However, this does not seem
to be the case. Play around in the notebook and you'll see what
I mean.
The shape of the r, z and theta components as a function of t
are all the same. That is good news in that the algorithm is
working. However, not even the same number of cells are being
picked up.
This seems wrong. But I can't figure out what is the cause, so I
was hoping other sets of eyes could take a gander. Additionally,
all solutions that I could think of - such as adding the *'best'* dtheta
and then transforming back prior to returning - would break the
3D version of this function.
I don't think either of the above are deal breakers, but I would like to
hear other people's thoughts. I will work on integrating this with the
rest of yt-3.0 next week.
Be Well
Anthony
1.
https://bitbucket.org/MatthewTurk/yt.milestones/raw/7d64152de2e1/cylindri...
