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

[Erik Tollerud]

Well, the only module name I see that's the same is "coords" and as
I'm sure you can imagine that's a pretty common name when dealing with
astronomy.  There's no namespace collision, though, because all of the
astropysics modules are modules within the astropysics package, while
the STSci stuff are each separate packages.  So you never directly
"import coords" when using astropysics - instead you "import
astropysics.coords" or "from astropysics import coords" .

On Sun, Jul 4, 2010 at 12:30 AM, Johann Cohen-Tanugi
<cohen at lpta.in2p3.fr> wrote:
> 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.
>>
>>
>