The programs used in this book, and those you will write yourself in the same style, make use of the ADAM software environment. In a nutshell, this is a mechanism for bringing lots of different facilities and giving the result a common look and feel.
ADAM does a lot more than make things look pretty, but you’ll be glad to know that there is no need to understand ADAM inside out to use this book. In fact, we’ll hardly discuss ADAM at all. Suffice it to say that ADAM is there, providing the infrastructure you need to manipulate data files.
A program using the ADAM environment is usually referred to as an ADAM task. In practice, there are two types of ADAM task. I-tasks are used to perform jobs such as instrumentation control. They will not be referred to again in this book. A-tasks are concerned with data reduction and analysis. It is these we will be concentrating on.
A-tasks are often also called applications. This is the convention we will use for the rest of this book. After all we are in the business of writing software which does stuff .
It is possible to group a collection of applications together in a single package known as a monolith. Starlink packages are often made in this way (e.g. Figaro). This helps to keep related applications together. In the above example, one could package both the log and alog applications together into a simple package called logarithms. Both log and alog would be used separately in the same way that each application in Figaro (or KAPPA etc.) is run separately. We will return to monoliths in part two of this book.
Most of the applications you write will require information to be given them by you or another user. Each piece of information required by the code is called a parameter.
Every ADAM application requires an interface file to provide information about the parameters required to perform the job requested. This file also specifies the prompts the user receives when asked to input parameter values, and the type of value required.
The name of the interface file for an application ends with the extension .ifl. In other words, an application called prog has a source code file prog.f and a corresponding interface file prog.ifl.
ADAM A-tasks are easily compiled with the facility alink. A typical use of alink might be:
This command compiles and links the application source code. It also makes use of a Starlink library (in this case the IMG library). It’s not too important that you understand how all this works just now.
We’ve covered quite a bit of terminology in this section, so rather than allow confusion to set in, let’s review what’s essential to know in what we’ve seen so far: