[AstroPy] [SciPy-User] Co-ordinating Python astronomy libraries?

James Turner jturner@gemini....
Mon Jul 12 14:53:12 CDT 2010


Hi Erik,

I almost overlooked your first email in my SciPy folder...

Astropysics is certainly looking interesting. As regards the code
structure, I would not personally expect AstroLib to be limited to a
collection of functional library routines. I'm particularly keen to
use classes to present data processing code in a more accessible way,
with the algorithmic structure exposed at the top level and the
bookeeping details hidden (but accessible) underneath. Within Gemini,
we already have a not-quite-released AstroData class on top of PyFITS
that understands astronomical data at a higher level (currently it
mainly acts as a generalized interface to metadata). I'd like us to
extend that functionality to operators and transformations, but we're
always a bit underresourced, so things get done on an as-needed basis.

Cheers,

James.


> For the last couple years I (and a few others) have been working on
> Astropysics (http://packages.python.org/Astropysics/ and source code
> at https://launchpad.net/astropysics).  This initially spun out of my
> personal need for some of the utilities these other projects discussed
> (e.g. IDL astron-like functions), but I've been turning it in a
> slightly different direction.  Astropysics now is being written as a
> more "pythonic" way of doing the same tasks instead of starting from
> cloning IDL procedural techniques.  I'm trying to leverage all the
> existing tools that have been written in python for other domains
> (e.g. Enthought Traits to easily make good GUIs, sphinx to make useful
> documentation, distribute to make packaging easier).  Further, where
> useful, I use object-oriented techniques instead of the procedural
> approach people familiar with IDL and IRAF are used to.  The idea is
> to start doing things on "Spectrum" and "CCDImage" objects instead of
> passing arrays into functions and so on, and each astronomer can then
> sub-class these classes to do whatever they want.  The aim here is to
> eliminate the tendancy for people to take public codes and change them
> internally, leading to some very painful efforts in disentangling
> versions.
> 
> So far, Astropysics includes the following modules:
> * constants – physical constants and cosmological calculations
> * coords – coordinate classes and coordinate conversions
> * models – model and data-fitting classes and tools
> * objcat – flexible, dynamically updated object catalog
> * ccd – image processing tools
> * spec – spectrum and SED classes and tools
> * phot – photometry/flux measurement classes and tools
> * obstools – miscellaneous tools for observation
> * io – data input/output classes and tools
> * plotting – astronomy-oriented matplotlib and mayavi plotting tools
> * pipeline – classes for data reduction and analysis pipelines
> * utils – utility classes and functions
> 
> And these GUI tools, which require Enthought Traits (and Enthought
> chaco for plots in the GUI):
> * Spylot – Spectrum Plotter
> * Fitgui – Interactive Curve Fitting
> * Spectarget – MOS Targeting
> 
> I'm making a concerted effort to document everything in a consistent
> manner using sphinx (http://sphinx.pocoo.org) - the resulting
> documents (http://packages.python.org/Astropysics/) end up being much
> more useful.
> 
> I also try to bind in python wrappers around external tools like
> sextractor, Mike Blanton's kcorrect, MOS mask design tools, and
> galfit (planned) ... this happens mostly as I need them for my own
> science.  But this cuts down on the time re-implementing standard
> programs that aren't necessarily worth re-working.
> 
> There are two main things left before I consider it "releasable" in
> terms of the baseline functionality: First, it needs WCS support to be
> integrated in the coords framework, and second, the objcat package
> should have a web server module that lets you show/edit the catalog
> over the internet instead of within python.  Another major goal I'd
> like to do when I or someone else gets a chance is something like ATV
> (http://www.physics.uci.edu/~barth/atv/) utilizing the same TraitsGUI
> framework that the other gui tools are written in.
> 
> I hope this explains the direction I have in mind for astropysics.  As
> far as I can tell, I have a slightly different philosophy - I'm trying
> to set up something of a framework of my design, rather than a
> function library.  This is why I have not been working on adding it to
> astropy, because astropy seems much more like the traditional
> library... That and I'm not a fan of the Trac project management
> system.  At any rate, I think there's definitely room for all in the
> community.  And if anyone likes what they see, feel free to drop me a
> line if you want to contribute.



More information about the AstroPy mailing list