[AstroPy] Co-ordinating Python astronomy libraries?
Sun Jul 18 19:30:25 CDT 2010
On 18/07/10 9:16 PM, Erik Tollerud wrote:
> 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)
> or just
> im = CCDImage('myamazingdata.fits')
> 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 agree with that. That's what I meant by baseclasses. At some stage we
should think about metadata being embedded in these CCDImage objects.
That would contain among other things a wcs object.
> 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
I agree and disagree. I think that we need to have a strict API, that
assures compatibility between the different tools. Even if we improve
the coordinate objects, then this should still work. On the other hand,
I think we should strive for wide acceptance, as more users means more
developers and less time for each individual. And thus a user wanting to
use the astropy time objects, may want to only install this time object
and not a big package. Also if someone has a better time object with the
same API it is easy to replace the old one.
I for one think that for this opensource and multiuser development small
packages (that speak the same parameter language of course) is better
suited for the task than monolithic development.
> 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.
That's what I think as well.
> 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
Well as I said before for now pure python is probably a good idea.
That sounds all very exciting let's see what happens.
> On Fri, Jul 16, 2010 at 5:35 AM, Perry Greenfield<firstname.lastname@example.org> 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.
>> 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?
More information about the AstroPy