Some NDFs contain information about axes other than just the pixel coordinate numbers of each pixel in the image, e.g. the wavelength scale of a spectrum. The issue of manipulating axes is complex and somewhat beyond the scope of this cookbook. There are already applications in existence which modify axis scales for tasks such as wavelength and flux calibration (such as those in Figaro).
It is suggested that the reader who really needs to manipulate axes consults the NDF programming manual directly (SUN/33).
One of the reasons Starlink came into existence was to try to reduce the duplication of effort amongst astronomers. Why should there be an individual flat fielding routine for every astronomer? One of the best ways to reduce the amount of duplication of effort is by using software libraries. These contain large amounts of code already written for you. For example, if you need to write a code which works out the Julian Date of an object, you can use the SLALIB Library.
You can think of these libraries as a bunch of subroutines scrunched up together in one big file. All you have to do to use them is to write a “top layer” of Fortran (or sometimes C) code to call them. In fact, this is what you’ve been doing throughout this book. The IMG and NDF libraries are called by the top layer of code which you write.
Just like you had to link your application to the NDF and IMG libraries, you also have to link to any other libraries you call. Check the reference manual of the libraries you need to use to find out how to use alink appropriately.
There are a number of libraries available for you to use when writing your applications or packages. Starlink provides access to a number of them not covered in this book and they are listed in Appendix A of this book.
Note that Starlink no longer uses NAG libraries. The reason for this is that NAG is a commercial package and as such, cannot be freely distributed. The PDA library can be distributed freely. If you intend to pass your software on to other users, you might need to take the same approach.
There are two groups of people you need to think about in writing a “public” application. The first group is the most obvious: the people who are going to use it. A code containing the slickest algorithms ever seen is no use to anyone if they can’t understand the instructions! This can be avoided by paying attention to both your run time prompts and user documentation.
The second, less obvious, group of people you need to cater for are those who support the code. If that person is you the author, then it is all too tempting not to comment your code adequately. On the other hand the code might need to be passed on to a colleague. There is nothing worse for the useful lifetime of a package than giving the support team thousands of lines of uncommented, poorly structured code. Write your code to be as friendly to the programmer as it is to the user.
There are three ways to document a code. Firstly, write a manual or manuals. You certainly need a “User Guide” telling the user how to use the package, what it does, and to some small extent how the inner workings function. If the latter is getting too technical i.e. full of “this algorithm incorporates bivariate Chebyshev polynomial solutions”, perhaps it’s time to write the “Reference Guide”. There’s no hard and fast rule as to how to do this. It’s partly a matter of taste but more a case of knowing your audience. Some advice is given in SGP/28.
Secondly, comment the source code. Firstly and most importantly, the programmer must be shown how the code works, i.e. “what goes where”, “this line does” and “this piece of code is commented out because it was both too slow and unaesthetic”. Don’t be verbose (like some of the examples in this book have been), but make sure it’s clear.
Thirdly, there is online help. There are a number of Starlink facilities to help implement this. The HLP package helps develop your online support facilities.
At the time of writing, Fortran 90 is not yet easily portable from one platform to the next. It is recommended that the established Fortran 77 is used for writing applications for the time being.
Starlink welcomes software contributions from the astronomical community. If you feel you may have software to contribute to the Starlink Project, please contact the Starlink Librarian (starlink@jiscmail.ac.uk) who will be glad to hear from you.