[AstroPy] Including kcorrect as a astropy affiliated package?

Taro Sato taro at ap.smu.ca
Tue Jan 17 11:48:55 EST 2012


On Fri, Jan 13, 2012 at 10:14 PM, Erik Tollerud <erik.tollerud at gmail.com> wrote:
> (Sorry for the delay in responding - AAS was rather hectic...)

I'm sorry for the delay in response... something came up and got tied
up, and I wasn't even in the AAS meeting...

>> Right, IDL isn't necessary at all to run the Python version, and
>> that's the reason for working on the port.  The original kcorrect
>> isn't a very thin wrapper around its C library, so in order to have
>> the full functionality that the IDL version currently has, all the
>> .pro scripts still need to be translated (I've only done what I have
>> needed for myself so far).  But that isn't so bad. (it's just that IDL
>> codes are not very fun to read.............)
> It's not clear to me that we even want/need to translate many of the
> IDL pieces (e.g. all the various survey-specific helper procedures) -
> probably just a few functions that do the relatively standard things
> is good enough for most purposes.  Eventually it'd be good to include
> some an interface that accepts astropy photometry objects or
> something.  But given the requisite astropy objects are not
> implemented yet, that's probably a ways down the road.

No, we don't really need to translate the survey specific routines.
Mostly all they are doing is to define a filter set specific to the
survey, and convert whatever photometry it uses into AB maggies with
which all the internal computations are done.  I believe this two-step
process needs to be manually done (i.e., call a survey specific
converter routine, and then call a fitting routine, etc.).

One of my motivations for porting kcorrect, however, was that I wanted
to hide the conversion process (honestly, who want to learn another
obscure photometric system....).  I'm not sure if it should eventually
be done that way, but the way I'm implementing right now is to define
KCorrect (base) class, which does all the internal work in AB maggies,
which you subclass to override the photometry conversion method,
filter set property, etc., for a specific survey.

I'm not sure that particular design is solid (I'm not a software
engineer), but at least it allows me to do the same thing you can do
with the IDL version with much less typing.

In any case, how we go about those issues, we should just try to come
up with whatever that makes sense as a sub-package of the whole thing.
 At least the boring extension wrapping part has been done mostly...
(though I'm actually not sure including a SWIG interface is something
desired for distribution).

>> I browsed through the astropy website and the affiliate thing, hence
>> my inquiry.  So I'd happy to contribute the whole thing, according to
>> whatever suggestion that astropy community makes.  I'm looking for a
>> repository anyways.... it's about 185 MB right now, most auxiliary
>> data included.
> This is a perfect candidate for the data framework (see the
> astropy.config.data package and associated documentation) - you could
> include just the code itself in a github repo, and the auxiliary data
> can be downloaded directly via URL, and the data package then caches
> the download for you and uses the local version on later accesses.
> Once we have a data server up and running, I'm sure we could host the
> auxiliary data there, as well.

I'll respond to your message about this.



Taro Sato
Department of Astronomy & Physics
Saint Mary's University             email: taro at ap.smu.ca
Halifax, NS B3H 3C3                 phone: (902)420-5018
Canada                                web: http://ap.smu.ca/~taro

More information about the AstroPy mailing list