---------- Forwarded message ----------
From: Erik Tollerud <erik.tollerud(a)gmail.com>
Date: Tue, Jun 19, 2012 at 2:51 AM
Subject: [astropy-dev] ANN: Astropy v0.1
To: astropy-dev(a)googlegroups.com, astropy(a)scipy.org
On behalf of the Astropy team, I'm excited to announce the first
release of the Astropy core package: v0.1!
The Astropy core package is intended to provide much of the common
functionality and tools needed for performing astronomy and
astrophysics with Python.
This release should be thought of as a "developer preview" - it has
much of the packaging and data handling framework in place, but the
actual astronomy functionality and frameworks are still incomplete.
Nevertheless, you can already make use of the existing functionality,
which is fully tested. Key features include:
* Standard cosmological distance calculations (astropy.cosmology)
* Data Tables (astropy.table) including a wide variety of ASCII
formats common in astronomy (astropy.io.ascii)
* FITS File handling - formerly PyFITS (astropy.io.fits)
* VOTable parser and writer (astropy.io.vo)
* WCS representations - formerly pywcs (astropy.wcs)
* Consistent documentation style
* Utilities to ease creation of new, independent packages (affiliated packages)
* A dedicated logging system
The package can be downloaded from
http://github.com/downloads/astropy/astropy/astropy-0.1.tar.gz . More
information is available at the Astropy site ( http://astropy.org ),
the package documentation ( http://docs.astropy.org ), and the
github repository ( http://github.com/astropy/astropy ).
We also encourage developers writing new packages to begin writing the
code against this version. Packages making use of Astropy should feel
free to join up as affiliated packages and begin transitioning to the
affiliated package template
( https://github.com/astropy/package-template ). In the next version,
we hope to implement a working affiliated package installer, so it will
be worth your while!
For the Astropy developers,
I'm having some problems with clump finder.
Specifically, it gets to this point:
yt : [INFO ] 2012-06-13 02:10:34,119 Getting field TotalEnergy from 1
yt : [INFO ] 2012-06-13 02:10:34,139 Getting field x from 1
yt : [INFO ] 2012-06-13 02:10:34,147 Getting field y from 1
yt : [INFO ] 2012-06-13 02:10:34,155 Getting field z from 1
yt : [INFO ] 2012-06-13 02:10:34,159 Adjusting clump for periodic boundaries in dim z
and then stops (no error).
My region actually isn't periodic and this must be a memory intensive step that isn't appropriate. Does the clump find tools/wrapper have a switch for non-periodic regions?
Using an Enzo dataset, I have written a function to find the derivative in
the x-direction of a field. When I try to plot the derivative, I see lines
that throughout the plot that I'm guessing are due to the edges of cells.
The attached plot is a slice of the x-direction derivative of the
PotentialField viewed down the x-axis, but this error appears in plots for
density and pressure as well. I am new to using yt, and I am not sure what
is causing this.
I have a smoothed covering grid object:
In : print scg
AMRSmoothedCoveringGrid (GR_Enzo2_128amr5_zeus_turb_psupp_rr_0001): level=3, left_edge=[ 0. 31. 0.], right_edge=[ 64. 33. 64.], ActiveDimensions=[2048 64 2048]
which should have dims [2048, 64, 2048] as it claims above. Yet:
In : print scg["Density"].shape
(256, 8, 256)
Any idea why it's downsized?
Oddly, this code (that creates the above) worked fine on a different machine but unfortunately, I inadvertently trashed it's OS earlier in the week. Both systems (i.e. this system that did the above and the one that is now a deadman) are linux.
is it possible to produce a slice of fixed resolution data, extracted
with covering_grid? I tried the following:
pf = load(file)
cube = pf.h.covering_grid(0, ...)
pc = PlotCollection(cube)
But this produces again a slice from the multi-level data as if I had
used pc = PlotCollection(pf).
Hello dear yt-users!
I'm new to yt and am having some initial problems getting it up and
running. I would be glad if you guys could help me.
The installation script ran fine, but apparently some modules for python
like tcl/tkinter coudn't be built. It seems to be a similar problem to
that Chris Malone had, though it wasn't solved in the mailing list:
I have installed python2.7, tlc8.5 tk8.5 and the developement packages,
but the installation script seems not to be able to find the tcl/tk headers.
The error message in the logfile is:
Python build finished, but the necessary bits to build these modules
were not found:
_bsddb _curses _curses_panel
_tkinter bsddb185 dbm
dl gdbm imageop
To find the necessary bits, look in setup.py in detect_modules() for the
INFO: Can't locate Tcl/Tk libs and/or headers
In setup.py I have found detect_modules() and detect_tkinter*()
functions, but I am at a loss which part(s) I should edit. I am running
Thank you for any help!
I'm creating a slice image but it's refusing to tick mark my colour
pc = PlotCollection(pf, center=position)
p = pc.add_slice("NegEscapeVelocity", 2,
Is there something simple I've done wrong? I tried rearranging the
last 3 lines, but to no avail!
Hi, sorry for asking a dumb question, but when I do a projection of density
field = "Density"
proj = pf.h.proj(direction, field, weight_field=field)
the numbers I get are ~1e-28
but when I do
proj = pf.h.proj(direction, field, weight_field=None)
the numbers become ~1e-4
this is a 64 cube simulation, if I were to multiply 64 * 1e-28 for a
projection with no weighting, shouldn't I still get numbers on the order of
1e-26 or 1e-27? I'm guessing there's something I've misunderstood about
pf.h.proj. Am I missing like a CGS conversion factor when I don't weight
it by some field?