[AstroPy] Co-ordinating Python astronomy libraries?

[Erik Tollerud]

I definitely agree that settling on a standard WCS library is a very
good idea, and PyWCS seems the natural choice as the base to merge
other work into.  But I also think there's two levels to think about
for a WCS library - there's the level that has already been
implemented in a few different places as essentially python wrappings
around other WCS libraries  But then on a higher level, there's tying
this into other classes so that, if you don't want to think about WCS,
you shouldn't have to.  You should be able to do something like

wcs = WCS('myamazingdata.fits')
im = CCDImage(wcs)
im.plot()

or just

im = CCDImage('myamazingdata.fits')
im.plot()

or the like, and have the WCS class automatically take care of
figuring out everything about the coordinates of the resulting plot.
The user should be able to access the WCS details if they want to, but
it shouldn't be necessary, assuming the file matches the WCS standard.
Now this could well be two seperate independent packages (the
ccd-related one, and the WCS library), but I think it's important to
consider this as a major target for the interface at the WCS level.


I also think (along with other cases) show why it is not necessarily
good enough to think of these tools as unix-like/fully modular
separate pieces that can operate independent of each other. To make a
really useful class-based library, the classes need to all recognize
each other when they naturally should.  E.g. you should be able to use
spectrophotometric data to calibrate photometry, if you want, or use
photometric results to calibrate your spectra.  Hence, they can't live
in totally segmented worlds.  Further, you get a lot of user-level
gains by using consistently the same tools to do similar tasks.  For
example, I wrote a "models" module in astropysics to do all
function-fitting, and a "fitgui" to go along with it, so whenever you
need to fit a 1D function, it always uses the same class to do it, and
the user in principle only needs to learn the interface to that class
once.

Now it might be that it's a better solution to write very simple
interfaces for classes like spectra and images with essentially only
low-level access to the data, and leave it to other packages to do all
the thinks I'm talking about above that inter-link them.  But at some
level, the constructs are all going to need to be linked together for
many astronomical applications.

And as for the pure python vs. C wrapping question:  I definitely
agree that if there is a pre-existing non python module out there to
do the task, wrapping is much easier and there's no reason not to use
it if it can be reasonably easily wrapped in python.  But if there
exists a pure-python version that is comparable in speed for the
typical applications, I would say that's a better choice, because it
allows for much greater flexibility.  If you want to subclass
something based on a C library, the subclass will almost always be
useless because it will be far too slow in python because the rest of
the module is built in C and the translation to python constructs will
either slow things down, or just not be available to optimize a python
subclass. But the optimizations of a pure-python module have to be in
place for it to work at all.  Of course, it's absolutely right that
there has to be careful checks that everything was done correctly in
the python implementation before it can actually be released as
official, but I think pure python is the goal, given enough time or
effort.



On Fri, Jul 16, 2010 at 5:35 AM, Perry Greenfield <perry at stsci.edu> wrote:
> I'd like to tackle the WCS issue first since there are already several
> flavors out there and I really wonder if that is necessary. Mike Droettboom
> is going to take a look at the others and see what the differences are in
> the next week. It would be good to get some convergence on that.
>
> But I don't think that can stop others from surveying and comparing what is
> out there with regard to coordinates or time.
>
> As far as the pure python aspect goes, I don't know if I would be so
> definitive on that. If there is already a good time or coordinates library
> in C that has been very well tested, it might make sense to use that. It
> isn't usually a big deal to distribute C code if it has no other
> dependencies. Fortran is a different issue. And there are many tricky issues
> with regard to coordinate systems. If reimplemented in  pure python I'd
> suggest that we do a exhaustive test comparison (mostly automatically
> generated if possible) with a well tested library to make sure that it was
> well validated.
>
> Perry
>
> On Jul 16, 2010, at 5:01 AM, Wolfgang Kerzendorf wrote:
>
>>  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
>
>



-- 
Erik Tollerud