Keywords: standards, algorithms, software
``... new arrangements to establish and maintain an accessible and authoritative set of constants, algorithms and procedures that implement standard models used in fundamental astronomy.''
The four elements of the scheme were (i) a Maintenance Committee, (ii) a Relativity Subgroup, (iii) a Reviewing Board and (iv) the SOFA Center. The present paper deals with the last two, the SOFA Reviewing Board and the the SOFA Center.
In the intervening period, the Reviewing Board has been created and is active, the SOFA Center has been set up and algorithms for a first release have been drafted.
The limited funding available to Board members for overseas travel makes it difficult, if not impossible, to hold meetings of the whole Board, and so almost all business has to be conducted via e-mail. However, there have been meetings of subgroups and between individuals, and these have been an invaluable supplement to the e-mail correspondence.
Wim Brouw Australia Telescope National Facility Anne-Marie Gontier Paris Observatory Catherine Hohenkerk Rutherford Appleton Laboratory Wen-Jing Jin Shanghai Observatory George Kaplan United States Naval Observatory Zinovy Malkin Inst. Appl. Astron., St Petersburg Dennis McCarthy United States Naval Observatory Jeffrey Percival University of Wisconsin Patrick Wallace Rutherford Appleton Laboratory
The Center is now awaiting the first release of software. Distribution of software and other products will be through a Web-based self-service ``software store'', and will draw on the experience and techniques of the Starlink Project.
The SOFA policy is to organize the calculations so that the machine accuracy is fully exploited. The gap between the precision of the underlying model or theory and the computational resolution has to be kept as large as possible, hopefully leaving several orders of magnitude of headroom. This point needs careful attention, especially in cases involving epochs and cyclic phenomena. The draft SOFA routine for converting Universal Time into Greenwich Sidereal Time is a good example. Firstly, the epoch, which is a Julian Date, is supplied as two double precision numbers, apportioned in any way the caller wishes. If maximum accuracy is desired, the caller provides a Part~1 that is an integer, which in practice all floating-point architectures encode without error, and a Part~2 that is small and therefore relatively immune from rounding errors. Secondly, the canonical algorithm is organized so that integer and fractional parts are kept separate as far as possible. Integer multiples of one day are omitted from the calculation and never deplete the available precision.
One of the difficulties in designing the SOFA routines is that there is an inevitable compromise between rigor and ease of use (and also speed, though nowadays this is seldom a major concern). There will inevitably be some calculations where multiple routines have to be provided, each offering a different trade-off.
Each SOFA routine consists of an ample set of preamble comments, followed by the code itself, followed by a lengthy set of standard comments setting out the copyright and disclaimer conditions. In most cases the code, which often is only a few lines, is dwarfed by the commentary. However, this is of little consequence as far as the user is concerned. The preamble includes comprehensive instructions on how to use the routine, the code is clearly set off and can be quickly found, and the formalities are left until last.
As well as ordinary 3-vectors, which are referred to as ``p-vectors'' (p standing for position), there is support for 6-element ``pv-vectors'' (v standing for velocity). The six elements are, in fact, expressed as two successive groups of three, to highlight the relationship between the respective Cartesian components. The order of the elements, (3,2) in Fortran and [2][3] in C, enables each triple to be used in its own right as a 3-vector, which makes for neater coding.
The only matrices which it has been so far necessary to use are ordinary 3 x 3 real orthogonal ``rotation'' matrices, referred to as ``r-matrices''. Routines also exist which support a second 3 x 3 layer containing the derivative of the corresponding r-matrix element. Such matrices are called ``rs-matrices'', where rs stands for rotation/spin. However, these have yet to be used, and so are being held in reserve until they are needed. For expressing spins, it has so far proved most convenient to specify the axis of rotation directly as a 3-vector, the Euler axis scaled by the Euler angle in radians.
Positional calculations are all vector based of course; spherical coordinates are used only for purposes involving the interface to users or catalogs.
The 52 routines offer a wide range of operations on and between these entities: initialize, copy, build rotations, rotate, add, subtract, products, spherical to/from Cartesian, range normalization, separation, position-angle, r-matrices to/from spin vectors, and so on.
To be of any value as standards, SOFA routines must be correct at their first release and may not subsequently be revised. This is a heavy responsibility for the SOFA Reviewing Board and cannot be rushed. If an routine was found to deliver imperfect results, the only recourse would be to issue a new, additional, routine under a different name, a laborious exercise leaving an ugly and potentially confusing result.
In any case, designing a system which is comprehensive, integrated and rigorous, yet easy to use, is a difficult task.
Most of the the 70-odd routines developed so far do familiar things in a conventional way, and their counterparts exist in many existing collections of software. Nevertheless, the routines still have to be designed, documented, written, tested.
From the start, Board decisions have been made, whenever possible, on the basis of consensus. Debates on every aspect of the work have been permitted and indeed encouraged, so that consensus can emerge and be embraced. There have, for example, been lengthy exchanges about programming style as well as more fundamental issues such as choice of programming language. The Board membership was chosen on the basis of interest and expertise, and it would be worrying if such debates did not arise! Reaching a consensus is an annealing process, and cannot be rushed: discussions must be allowed run their course. Sometimes a majority view emerges but fails to convince all Board members; when this happens, there is no choice but to hold a vote, which again takes time.
All of the Board members are busy people, under heavy pressure from their other work. Formal funding for their participation in SOFA exists only in a minority of cases, and then covers only a small fraction of their time. (These difficulties are not confined to SOFA of course but must afflict many other IAU projects.) Moreover, the available time is patchy, and Board members may not be in a position to react promptly to a new development.
In their special fields of expertise, researchers in the fundamental-astronomy community are, by definition, ahead of SOFA and indeed are, in effect, working on the next generation of SOFA algorithms. Under these circumstances, the SOFA routines are of little relevance. Even away from their specialist topics, these potential users are working at the highest levels, and they need to understand every detail of their calculations. This means that they are unlikely to want to use fundamental-astronomy software from an outside source. However, they may find SOFA routines useful as style templates for new algorithms, and for comparison purposes.
This class of user wants practical tools that are easy to use. They want to be confident that the answers are right, but are not particularly interested in minutiae or issues of principle. They are already well served by several existing packages. However, there is no reason why a well-written SOFA Software Collection could not offer an attractive alternative to established tools in the areas where their functions overlap.
Those developing stand-alone astronomy applications may find the SOFA software a useful resource. The key advantages will be accessibility, long-term support and trustworthiness. These characteristics may even appeal to the developers of existing subroutine libraries, who may wish to replace the lower levels of their packages with calls to the SOFA routines. And for all such users, the SOFA software should be an invaluable resource for testing and validation.
The hobbyist user is in a similar position to the professional astronomer in wanting practical tools that are straightforward to apply. However, there is an even greater demand for simple, clear documentation, and ease of use has much greater weight than milliarcsecond accuracy. Such users are likely to be best served by book-based solutions such as those provided by Meeus and Duffett-Smith. However, SOFA routines may still be of interest in some cases.
The SOFA acceptance procedures must be careful and thorough, and hence take time. Combined with the shortage of effort, it is not feasible to support a collection of more than a few dozen astronomy routines.
Rigor and ease of use may not always be achievable in one and the same routine. It is dangerous to give the impression of great accuracy if the user has supplied too little information for this to be possible. Hidden defaulting rules or silent correction of errors are also ruled out.
It is necessary to make the minimum of assumptions about the user's environment. This precludes techniques such as graphical user interfaces and even access to files.
It is important to the astronomical community in general that there be an IAU-approved way of performing all the key calculations, even if not state-of-the-art.
Computer code is the only practical way to pin down an algorithm unambiguously. A written description can only go so far, and it is all too easy to omit a small detail that then leaves the procedure open to multiple interpretations. Computer code (as long as it is properly written and platform-independent) defines exactly what happens, in what order.
Packages such as NOVAS (Kaplan 1996) and SLALIB (Wallace 1997) have shown that it is possible to design tools that are precise and rigorous and yet straightforward to use. Documentation is obviously an important factor, but a number of other aspects must be right as well:
Many fine implementations of all the key fundamental-astronomy algorithms exist. But only a few are widely used outside the group that developed them, because correct behaviour and high standards of coding are only part of the story. To be attractive to outsiders, the routines also have to downloadable from an easy-to-find place, be in an integrated and consistent form, and come with documentation. And there has to be some guarantee that the user will be able to get help if at any point the routine stops working properly. All of this requires effort and planning.
The key problem is a mismatch between the fundamental-astronomy and the potential user community. All suppliers of new algorithms (and most Board members) are still Fortran-based (and Fortran 77 rather than Fortran 9X). Many astronomy institutes remain Fortran-based. But most potential users are C-based, and many are using C++ and other Object Oriented (OO) languages such as JAVA. Two members of the Board never use Fortran.
There is little to choose between Fortran 77 and C for expressing astronomy algorithms, especially if some of the almost universally-available extensions to Fortran 77 are used. There are differences, certainly, affecting certain types of calculation, but in most cases either language will do. On balance, Fortran 77 offers rather less freedom than C, but this can even be an advantage to the SOFA Reviewing Board by reducing the scope for debate and focusing the discussion on the core functionality.
The choice faced by the Board is either to use Fortran and limit the appeal of the result to a wider audience, or to use C and break the link with the algorithm suppliers.
The obvious solution to this dilemma is not to limit the SOFA Software Collection to just one language, but to provide multiple implementations. However, during the initial period of trial and error, only one language is being used, and that is Fortran. Once the Collection has stabilized, a C version will be produced. The SOFA routines are very straightforward and self-contained---they do not even use input/output---and producing a C routine starting from Fortran is an easy process which several Board members have considerable experience in. There are even some benefits from the translation task. The process involves close scrutiny of the code, offering a further opportunity of spotting errors, and comparing the results of running the two versions can sometimes expose problems.
The dialect of Fortran being used is ANSI Fortran 77 (American National Standards Institute 1978), the lowest-common-denominator choice. The standard is strictly complied with, except for the >6-character routine names and the use of IMPLICIT NONE. The long names (for example iau_PREC76) are designed so that the prefixes can be eliminated by a global edit without affecting the result. The IMPLICIT NONE statements will be commented out in the released code.
Once the Fortran and C versions are stable, it is safe to begin looking at the prospects for OO-based products involving C++ and JAVA. Because the SOFA routines avoid the use of context that persists between calls, a C++ or JAVA class that simply provided all the SOFA calls as methods would offer little more than the original C code. However, the OO languages allow new and more sophisticated tools to be developed, based on the core algorithms, and this possibility will be studied. Finally, users of interactive languages such as Perl and Tcl can be provided with SOFA functionality simply by writing the appropriate set of wrappers.
The SOFA routines so far developed contain very little that is new, and no-one is anxiously waiting to begin using them. On the face of it, this is not a very encouraging start, but in fact it is to be expected, because the first generation of SOFA routines is in many respects merely a dress rehearsal. Once the routines have been brought to the state where they can be released, they can act as a framework, ready to accept new algorithms. This should prove a much quicker process than it has been getting the first generation together.
The intention is to make the first release at the end of 2000, possibly including some extra routines to fill in gaps in timescale and catalog conversions and to provide apparent place capabilities. It will then be possible to develop the C version and begin looking at the possibility of C++ and JAVA products. The first new astronomy algorithms will implement the revised precession/nutation models and other algorithms by then adopted by the IAU. At that stage the SOFA Software Collection should have become an important resource.
American National Standards Institute, ANSI X3.9-1978
Fukushima, T. 1995, ``Report of the IAU WGAS Subgroup on Standard Procedures'', in Highlights of Astronomy, vol. 10
IAU Information Bulletin 79, January 1997, 4.2, 13
Kaplan, G. H. 1996, Naval Observatory Vector Astrometry Subroutines
Wallace, P. T. 1997, SLALIB -- Positional Astronomy Library, Starlink User Note 67.36