[AstroPy] Co-ordinating Python astronomy libraries?

[Wolfgang Kerzendorf]

  Hello guys,

I think astropysics looks like a very good start for the coordinate class.
As you said we should at the moment focus on having python-only classes 
for the base-level. That makes it easy to distribute. Once a good API 
has been established and there's complaints about speed, we can switch 
over to c or fortran implementations with the same API.

A monolithic distribution is not so good. I think these baselevel 
classes should, be very modular. We can probably achieve the best 
exceptance when these base classes are lean and mean. Like the unix 
tools, each one of them should only provide a very limited set of 
functionality. A good start might be pyAstroTime and pyAstroCoords or 
so. That's where raiding and plundering the existing code base comes in. 
We can use some of Erik's and Brandon's stuff and others. I think we can 
easily make a working prototype and the build from there.

As suggested, we need to be careful not to ignore anyone. But I think 
that's easily done by making groups from this community, that take care 
of a single implementation. Everyone who's interested in contributing, 
can join. That way the workload is shared and it is build by the 
community for the community.

What do you guys think?

Cheers
     Wolfgang

On 16/07/10 4:49 AM, Erik Tollerud wrote:
> Hi James and Wolfgang,
>
>> Classes and data structures seem to be another common theme in this
>> thread that probably deserve more discussion. A few people have
>> mentioned time and co-ordinates. I was wondering whether Anne or
>> someone else has been following the NumPy datetime discussion and
>> whether that's at all relevant (since I know she is more active on
>> that list than I am)?
> I definitely agree classes like this are a good way to make scientific
> codes much easier to work with and cleaner to manage.  I would also
> like to note that I've already implemented a pretty complete and
> documented set of coordinate classes, transforms between them, and the
> related time-keeping in astropysics (see
> http://packages.python.org/Astropysics/coremods/coords.html and
> http://packages.python.org/Astropysics/coremods/obstools.html).  This
> is in pure python (with numpy arrays, of course) and are ready to be
> subclassed right now if you want to use them.   It's also dead-trivial
> to write transforms back to standard coordinate types.  It's not as
> full-featured as pyephem right now, but is pure python, which makes
> installation/distribution easier, and crucially in my view, easier to
> extend.  (To be clear this is not intended at all as a bash against
> pyephem - just a different design choice, as Brandon himself pointed
> out)
>
> As for the question, I'm pretty sure the datetime enhancements are
> supposed to go into numpy 2.0, because it requires an ABI change...
> I've never been clear on exactly when that's going to be released as
> it's been "soon" for some time, but I think they're shooting for
> end-of-summer or fall? (note that numpy 2.0 will also support python
> 3.0 along with a paralell scipy release).  But I don't quite
> understand what the connection is between that and
> coordinate/time-keeping classes...?  The datetime class in standard
> python works just fine for individual objects...
>
>
>> That sounds convenient. Apparently several people/groups are working
>> on these kinds of high-level objects and some standardization may
>> indeed be helpful, otherwise I'll be using AstroData for part of my
>> processing and then find I need to pick apart my object to construct
>> your 1D spectrum from pyspec, then do something different again from
>> Astropysics or PyEphem and so on. A few standard classes would
>> probably help significantly in providing a good focal point.
> Agreed completely on this, and that was my motivation behind making
> astropysics as an integrated set of packages... For example, the
> spec.Spectrum class in astropysics uses phot.Band objects
> (representing photometric bands) to do various calibrations (and
> optionally vice versa), and that's not possible if there isn't a
> well-documented API (hence I had to write them both along with their
> API).
>
> The main problem is how to integrate the base classes in a way that
> makes everybody happy and doesn't leave anyone thinking their work is
> ignored or uncredited, as perhaps shown by my perhaps not-so-subtle
> advertisements in the comments above... I can definitely see ways to
> integrate, say, pyspec with the astropysics Spectrum class, but it
> would be a fair bit of work given the rather different internals.  Or
> would it be better to initially ignore all previous work, settle on a
> simple API, and then leave it to packages to implement the details?
> Although that seems problematic to me as the details are a lot of what
> matters in this sort of highly numerical work...
>
>
>