Making my software open

After thinking  about software development in astronomy and talking about it with friends at work and on this blog, I thought it was about time I put my money where my mouth is. I too write software – in fact, the bulk of my work here in Leiden has been based around code I’ve written over the past 2 years for the METIS project (in IDL). The code basically calculates the sensitivity of METIS on the E-ELT, or the minimum flux it will be able to detect at a particular signal to noise (S/N) in a given exposure time over its wavelength range,  in various modes of observation. You can find the full package with background info on my brand-new github page, and a paper is in preparation (to be presented at SPIE 2010) for your referencing pleasure.

The equations governing instrumental signal to noise are essentially quite simple: calculate the signal from the astronomical source arriving at the detector, compare to the different sources of noise in the system, and bob’s your uncle. As you dig into the details, however, you find that there’s obviously a little more to it than that. For a known and built instrument, calculating the S/N, exposure time or sensitivity to a reasonable accuracy is not too bad. Observatories around the world offer online exposure time calculators to their community of observers to help prepare proposals – and these do exactly that.

Developing such a piece of code for a future instrument is a different matter, particularly when both the instrument and the telescope are being designed in parallel. In this case, the code is both a point of reference and a validation tool. It requires a continuous iterative process of integrating design changes as they arise, checking the likely impact on performance, making sure this still allows us to reach our science targets, adjusting the science case according to latest performance estimates, and so on. So that was my job, which put me right at the heart of the project – a very interesting and often fun (and maybe sometimes not fun) position to be in.

Now that the Phase A study for this instrument has been concluded, I felt it was time to release my work to the world wide interweb, for the following reasons:

• to show others facing similar tasks how this work can be done. There’s no one perfect method to do these calculations but here’s one example that works.
• to advertise the instrument to the community. Do the calculations, and start dreaming of the mid-infrared science you may be able to do with a 42-m telescope. Excited? Go tell your local friendly ESO representative or council member that you really want and need METIS on the E-ELT.
• to give inspiration to astronomers doing mid-IR science right now. Why not include a section in your next paper on what you can expect to do with the E-ELT? The sooner you start thinking about it, the better your chances to be a successful observer when the telescope is in operation.
• to provide a tool that allows others, observers or instrumentalists, to see how certain environmental or design parameters are likely to affect a mid-IR instrument’s performance. Some things I looked at specifically during were atmopsheric transparency and radiance at different sites, telescope emissivity, spectral line sampling – but you can tweak any number of parameters and check the outcome.

I should point out that whatever you do with this code is at your own risk. This is not some black-box that will give you “the right answer” – when in doubt, get in touch with me. I’m happy to help, though if you require a lot of hand-holding I will want to be a co-author on any resulting papers. Just saying.

On a practical note, setting this up with git was a nice experience, and I realise that I should have been using at least a local version-controlled repository all the way through. Now that I’ve learned that lesson, I will be more organised in the future. I also hope that this experience will give me some insight into some of the issues being discussed on the software post…