Starlink’s main software environment.
It has many aspects which, taken together, provide users with a coordinated environment for analysing data and writing programs. ADAM software also controls many telescopes and instruments at observatories.
In the minds of users doing data analysis, ADAM is usually identified with its application programs, such as KAPPA and CCDPACK. However, it is really just the kernel of the system, in other words, the subroutine libraries. Many of the libraries associated with ADAM are also available as stand-alone libraries, thereby making it easier to take code to non-Starlink computers. Some of the libraries used in ADAM programs are Starlink libraries that predate ADAM, while others are commercial packages. In fact, it is impossible to have a perfect definition of what is or is not an ADAM program. The best one seems to be ‘an ADAM program is one that uses the ADAM parameter system to interact with the user.’ The fact that different groups of users have different ideas of what constitutes an ADAM program is not a failing of ADAM; it demonstrates the different ways in which it can be used.
As mentioned above, ADAM applications are really distinct from the ADAM kernel. However, without application programs, ADAM would only be half a system. Most of the packages described in this note are ADAM programs. There are also software tools to aid in writing ADAM programs, and data analysis tools to browse data files.
One of ADAM’s most important features is that it provides a standard method of data storage called NDF (extensible n-d data format). NDF files have standard components that all programs recognise, while also allowing for any extensions that may become necessary for particular applications. Use of NDF means that data files can be exchanged between different packages without the need to convert file formats. This is very useful, as having to change file formats is very annoying and takes up extra disk space. NDF is layered on HDS, the hierarchical data system. By using HDS (version 4.0 or later), it becomes possible to read and write data files on different computer systems completely transparently, so no explicit data conversion needs be done, even when moving from one computer to another.
ADAM programs can generally be run either from the command language of the host, or from the ICL command language. ICL is a simple programming language in itself, somewhat along the lines of BASIC. It can be quite useful for doing simple operations, but is not fast enough for any major processing. Use of ICL makes it easier to build sequences of operations into ICL procedures. It is generally quicker to run ADAM programs from ICL if they are to be run several times, since the programs only have to be activated once. On the other hand, the ability to run ADAM programs from the shell is very useful for debugging.
One of the most distinctive features of ADAM is the parameter system. This provides a method whereby a program can interact with a user, or with other programs. For a single program, a series of write and read statements could sometimes be used instead, but for anything more complex this becomes unacceptable. It is particularly difficult to maintain a standard style, and ad hoc fixes to problems abound. Use of the parameter system provides a consistent user interface, a means of storing the value of a parameter between invocations of a program, and the facility to pass the values of parameters from one program to another.
From the perspective of a programmer, ADAM provides many subroutine libraries that perform common functions. They provide such diverse functions as character handling, access to hierarchical, relational, and simple data, graphics, the parameter system, error and message reporting, numerical calculations, etc. Some of these libraries are provided purely for use in ADAM programs, whereas others, such as the NAG library and graphics libraries, have a much wider use.
Although any subroutine library can be used in an ADAM program, those that have been written specifically with this in mind are much easier to use. ADAM libraries conform to the Starlink standard on the use of inherited status, which greatly reduces the amount of code needed to test for error conditions. They also report any error conditions via the error message service. This lets the programmer get at the error messages as well the error code, to see if the error can be handled internally or whether to send the error report on to the user.
By using the facilities provided in a consistent manner, simple programs can be easily linked together to perform complex operations. In particular, programs from packages written to do completely different things can process each other’s data, thereby avoiding unnecessary duplication of software, with the attendant waste of effort, both in writing the program and in maintaining it.
Finally, it should not be forgotten that ADAM originated as a telescope and instrument control system. The way that ADAM programs are written when used in these circumstances is rather different from when they are used for data analysis. Use of ADAM for instrument control is not the province of this document. However, it is interesting to note that programs written for data acquisition tasks are rather like windows programs, which have become common.
Emulate a user sitting at a terminal.
When combined with TK, it can put a GUI in front of an existing application without modifying it.
A programmable user interface to an astronomical data reduction or data acquisition system.
It is one of the main user interfaces for the ADAM software environment. In some ways it is similar to a high level programming language such as Fortran or Pascal, but it has some important differences:
A grouping of the Starlink login resource files and other associated bits and pieces.
The .cshrc
and .login
files are now handled like standard packages and are edited by the install procedure to
contain the correct root path for the USSC set. This allows easy installation on systems where the directory
/star
does not exist.
Starlink application environment.
INIT gathers together the global include
and error
files needed by the infrastructure and applications. It is
purely an administrative grouping.
Extend TCL and TK.
A public domain utility called TCL/TK is in wide use as a command language and user interface builder. STARTCL comprises three extensions to TCL and the TK Toolkit that enable TCL/TK applications to cooperate with Starlink applications. These are:
Control and extend applications using a scripting language.
TCL stands for Tool Command Language.
MUD/164 Build GUIs.
An X window toolkit for use with TCL and EXPECT. It can build Motif-like user interfaces using TCL scripts instead of C code.