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

[Johann Cohen-Tanugi]

Hi Erik, this is completely independent from the STS software, that 
shares some modules' name with you : 
https://www.stsci.edu/trac/ssb/astrolib  ?
Johann

On 07/04/2010 01:14 AM, Erik Tollerud wrote:
> Dear AstroPy list and James,
>
> Thanks for your efforts to do this coordination - clearly there's
> quite a bit out there doing similar work.
>
> 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.
>
>