Provide extremely accurate position and velocity data for any of the nine planets, the Moon, and the solar system and Earth-Moon barycentres (also nutation components) for any given epoch in the range of the ephemeris (1960 to 2025).
For many years, the Jet Propulsion Laboratory has distributed definitive solar system ephemeris tapes containing files of ephemeris data, plus Fortran programs to read them. The ephemerides come from direct numerical integration of the equations of motion of the large bodies in the solar system, subject to fitting to a variety of observations. For distribution they are expressed in terms of Chebyshev polynomials.
The version distributed by Starlink is the DE200/LE200, the one most consistent with the latest IAU resolutions. Users of the old (VMS-only) version should note that this new version differs in some important respects. Existing applications will need to be changed before they can be linked against the new library, and existing executable programs are not compatible with the new format of ephemeris file.
Quantified maximum entropy image reconstruction.
The MEMSYS libraries are commercial software and are licenced for UK Starlink sites only. MEMSYS is not distributed on Starlink CDs. Access restrictions apply at Starlink sites (see below).
Two versions are available: MEMSYS3 and MEMSYS5.
The algorithms used in both are similar, but the programming interfaces are quite different. New applications should be written using MEMSYS5, which provides more functionality than MEMSYS3. MEMSYS3 is retained primarily for the benefit of people who want to maintain old applications.
They find and use maximum entropy reconstructions of images, power spectra, and other such additive distributions from arbitrary sets of data. They were written by J. Skilling and S. Gull of Maximum Entropy Data Consultants Ltd, and embody their ‘Classic’ Maximum Entropy algorithm, described in more detail in the MEMSYS3 user’s manual.
The algorithms of both MEMSYS3 and MEMSYS5 differ greatly from their previous MEM algorithms, in that they are based on a fully Bayesian analysis of the image reconstruction problem. They provide the following extra functions:
MEMSYS deals with ‘data sets’ and ‘images’. A data set holds information corresponding to the available experimental data, and an image holds information corresponding to the ‘true’ image from which the data was generated. It handles problems where the relationship between data and image can described as follows:
| (1) |
where is the th data value, is the number of data values, is the th image value, is the response of sample to pixel , and is the noise on sample .
This is a linear relationship between data and image. It can also cope with non-linear data, so long as the data can be expressed as follows:
| (2) |
where is some known function with known derivative, and is linearly dependent on the data.
The image and data set are described as 1-d arrays purely for ease of access within the package. In fact, they could be of any dimensionality. The calling program needs to set up the correspondence between -d coordinates and the 1-d coordinate used above. For instance, for a 2-d image with coordinates the relationship may be
| (3) |
where is the number of pixels per line of the image.
A common use is to deconvolve a 2-d image, given a Point Spread Function (PSF). In this case, the data is linear and the matrix embodies the PSF.
Before using it you must sign a form (available from your Site Manager) accepting certain conditions.
Mathematical subroutine library.
The NAG libraries are commercial software and are licensed to UK Starlink sites only. The software is not distributed on Starlink CDs.
The Numerical Algorithms Group (NAG) library is commercial software. The current versions are Mark 18 for the Numerical library and Mark 4 for the Graphics library. Double precision versions of the Numerical Library are provided and, where available, single precision versions are also provided. The Graphics Library is in double precision form.
The routines cover a very wide area of numerical and statistical mathematics. They are extensively documented in a reference manual, guide, and introductory book. These are available at every Starlink site, and copies of the NAG newsletters are kept at RAL.
The standard library organises its routines into the following chapters:
Mathematical subroutine library.
This is intended to replace the NAG library in Starlink application code. It is coded in Fortran and has a Fortran 77 binding. The interface is mostly double precision, although the Fourier transform part provides for both double and single precision and the routines from DIERCKX exist only for single precision.
Positional astronomy library.
SLALIB makes accurate and reliable positional-astronomy applications easier to write.
Most of the routines are concerned with astronomical position and time, but some have wider trigonometrical, numerical, or general applications. ASTROM, COCO, and RV all make extensive use of SLALIB, as do several telescope control systems around the world. Current versions are written in Fortran 77 and run on VAX/VMS, several Unix platforms, and PC. A generic ANSI C version is also available from its author.
Its main functions are:
It gives programmers a basic set of positional-astronomy tools which are accurate and easy to use. It is:
Describe regions of a data array.
The Ascii Region Definition system provides a textual language for describing regions within a data array, together with software for converting a textual description into a pixel mask.
The textual language is based on a set of keywords identifying simple shapes (boxes, circles, lines, etc.). These can be combined using Boolean operators (AND, OR, NOT, etc) to create more complex shapes. Data arrays can be multi-dimensional.
Access Starlink ARRAY data structures built using HDS.
Details of these structures and the design philosophy behind them can be found in SGP/38, although familiarity with that document is not necessarily required in order to use the routines.
ARY is an essential component of the NDF system, which contains routines for accessing Starlink NDF structures.
The main reason for using it is to access ARRAY structures stored in NDF extensions. At present, it only supports the ‘primitive’ and ‘simple’ forms of the ARRAY data structure.
It can:
A library for handling World Coordinate Systems in astronomy
The AST library may be used for attaching world coordinate systems to astronomical data, for retrieving and interpreting that information and for generating graphical output based on it.
The programmer’s manual should be of interest to anyone writing astronomical applications which need to manipulate coordinate system data, especially celestial coordinate systems. AST is portable and environment-independent.
Create, read, and write astronomical catalogues and similar tabular datasets.
It supports the following formats:
Access FITS format files on disk.
This new library provides both a C implementation of a FITS i/o library and a Fortran wrapper for it. Thus one can use it from C or Fortran as required.
The CFITSIO library is written and actively maintained by William Pence of HEASARC (High Energy Astrophysics Science Archive Research Center) at the Goddard Space Flight Center, USA. It is fully compliant with the FITS Year 2000 directive. This is the recommended library for access to FITS files.
Access sequential and direct-access data files in a machine-independent way.
It consists of stand alone FIO and RIO routines, which can be used independently of the Starlink software environment, plus routines to interface to the Starlink parameter system.
Access FITS format files on disk.
This is a Fortran-only library for access to FITS files. It is no longer being developed and is not compliant with the FITS Year 2000 directive.
Users requiring a library for FITS access are recommended to use the CFITSIO library.
Handle groups of objects which can be described by character strings.
These objects can be things like file names, astronomical objects, numerical values, etc. It can store and retrieve such strings within groups, and pass groups of strings between applications by means of a text file. It can also create groups in which each element is a modified version of an element in another group.
Global Section Datafile (GSD) access library.
This library provides read-only access to Global Section Data files (GSD files) created at the James Clerk Maxwell Telescope. A description of GSD itself is presented in addition to descriptions of the library routines.
Its main use is in SPECX to read the GSD files created by the heterodyne instruments used on the JCMT.
Store and retrieve data flexibly.
The Hierarchical Data System is the basic Starlink data system and is of great importance to the Project. Its most significant features are the following:
More powerful data systems have been built on top of HDS in order to make specific types of data object easier to handle. These include ARY for handling arrays, and NDF for handling objects in the standard Starlink data format.
Easy access to astronomical image data and associated headers.
It is of most interest to astronomers who write their own software and require uncomplicated access to their image data. In this context, an ‘image’ may be an ordinary (2-d) image, but could also be a spectrum (1-d) or ‘data cube’ (3-d).
Because of Starlink’s automatic format conversion facilities, this library also gives programmers straightforward access to a wide range of astronomical data formats, including FITS and IRAF files as well as Starlink NDF data.
Handle magnetic tapes.
Astronomical data on magnetic tapes can be in many formats. The MAG library allows you to write programs to read this data on any type of computer and tape drive. It doesn’t interpret the data format – it deals in tape blocks, and knows nothing about FITS, VMS BACKUP, tar, etc.
MAG lets you write portable software. This is very useful since different computers can differ greatly in their facilities for handling magnetic tapes. For example, on VMS it is quite common to treat magnetic tapes as normal Fortran sequential files that can be opened, read, written, and closed using the Fortran statements OPEN, READ, WRITE, and CLOSE. On Suns, this is not the case, and special routines are provided for processing magnetic tapes. These differences are hidden from the programmer by the MAG package.
It can:
Not all operations are available on all types of tape deck. Also, the status values returned by different machines can differ.
Share data between processes.
NBS stands for Noticeboard System.
A given process may own many noticeboards and may access ones owned by others. Normally, the only process that writes to a noticeboard is its owner, but other processes subvert this rule if necessary.
Noticeboards are identified by name, and each can contain a hierarchy of items. Each item has a name, type, structure/primitive attribute, and, if primitive, a maximum number of dimensions, maximum number of bytes, current shape, and value. The type and shape are not used by the routines, but their values can be put and got, and they can be used when implementing higher-level routines on top of the noticeboard routines.
Noticeboards are self-defining – a process can find and access data from a noticeboard without knowing anything about what it contains.
Access data stored in NDF format.
The Extensible -Dimensional Data Format is the standard Starlink format for -d arrays of numbers, such as spectra, images, etc, and it forms the basis of most Starlink spectral and image-processing applications. A ‘stand-alone’ version is available for programs which do not use the Starlink software environment.
The main reason for using NDF is to simplify data exchange between applications. In principle, it should enable you to process the same data with any Starlink package. In practice, previous attempts to define a standard data format for this purpose have met with two serious obstacles. Firstly, different software authors have interpreted the meaning of data items differently, so that although several packages might be capable of reading the same data files, they actually perform incompatible operations on the data. Secondly, many authors have found a pre-defined data format to be too restrictive and have ignored it.
The NDF data structure has, therefore, had to satisfy two apparently contradictory requirements:
This problem has been solved by introducing the concept of extensibility, and by dividing the data structure into two parts – a set of standard components and a set of extensions – each of which individually satisfies one of the two requirements. The structure consists of a central ‘core’ of information, whose interpretation is well-defined and for which general-purpose software can be written with wide applicability, together with an arbitrary number of extensions, which may be used by specialist software but whose interpretation is not otherwise defined. Those who wish to know more of the background to this philosophy can find a detailed discussion in SGP/38.
Routines for Accessing Groups of NDFs.
The NDG package provides a means of giving the user the ability to specify a list (or “Group”) of NDFs as a reply to a single prompt for an parameter. NDG can process NDFs which are stored as components within an HDS container file, and can also process foreign data formats using the CONVERT utilities that the NDF library uses (as described in SSN/20).
Parameter system.
A convenient way for programs to exchange information with the outside world through I/O channels called parameters. These enable a user to control a program’s behaviour.
It supports numeric, character, and logical parameters, and is currently implemented only on top of the ADAM parameter system. Parameter values may be obtained, with or without a variety of constraints. Results may be put into parameters to be passed to other applications. Other facilities include setting a prompt string, and suggested defaults.
Process primitive data.
Does arithmetic, mathematical operations, type conversion, and inter-comparison of any of the primitive numerical data types supported by HDS. Provides:
A distinction is drawn between three classes of primitive data, which differ in their interpretation and in the algorithms best suited to processing them:
Handle references to HDS objects.
Stores references to HDS data objects in special HDS reference objects, and lets you obtain locators to reference objects. Helps make your software portable.
You can:
Its two main uses are:
Relate different coordinate systems.
Provides a standard, flexible method for manipulating coordinate transformations and for transferring information about them between programs. It can handle coordinate systems with any number of dimensions, and can efficiently process large (i.e. image-sized) arrays of coordinate data using a variety of numerical precisions.
No specific support for astronomical coordinate transformations or map projections is included at present, but routines for handling these should appear in future. The current system provides tools for creating a wide variety of coordinate transformations, so it should be possible to construct some of the simpler astronomical transformations explicitly, if required.
It can:
It uses HDS to store information in standard data structures for interchange between applications. These may be used as building blocks when constructing larger HDS datasets, and also when designing ‘extensions’ to the standard Starlink NDF data structure.
Graphics database.
Used in Starlink programs to store, between applications, information about the various plots on a graphics device. It records their position and extent. These can be recalled later either to overlay plots, or to recreate the picture.
Obvious uses are to align pictures, or to obtain cursor coordinates from an existing picture. But it has other uses, e.g. to slice up the screen into areas for subsequent plotting using more complicated patterns than just a regular grid; the areas can be different sizes or overlap.
Low-level graphics library.
The Graphical Kernel System is an international standard. The current version is 7.4 and this what you should use.
It has two major advantages over other graphics packages:
In addition, the Starlink implementation has several advantages of its own:
The advantages of GKS also apply to graphics software which use it, such as SGS.
Support names for GKS graphics devices.
Almost any graphics program requires you to identify a graphics device to use. When it uses GKS, they are identified by two integers: a ‘workstation type’ and a ‘connection identifier.’ (‘Workstation’ is GKS terminology for a graphics device of any description.) You can’t remember the workstation types of all Starlink’s graphics devices, so the Graphics Name Service has been provided to translate ‘friendly’ and easy-to-remember names into their GKS equivalents.
Most high level graphics packages, such as SGS and Starlink-PGPLOT, call GNS to do the required name translation when a workstation is opened, so unless you are writing programs that open GKS workstations directly, or need to make specialised device inquiries, you will not need to call GNS routines yourself.
It can:
It is used internally in IDI and AGI, but this isn’t normally apparent to the programmer.
Access the graphics libraries GKS, SGS, and Starlink-PGPLOT from Starlink programs.
These are the components of GKS, SGS and Starlink-Pgplot that provide the interface to the respective libraries from ADAM programs.
Create graphics windows on an X display that do not disappear when a program terminates.
X was designed to support GUIs and it has two properties that make an X window fundamentally different from a traditional graphics device. Firstly, windows ‘belong’ to application programs and are deleted when the application exits, unlike the picture on an image display which remains there until replaced by something else. Secondly, application programs are expected respond to ‘events’ occurring in their windows; things like key presses, mouse movements, etc. One event type that all applications must handle is the ‘window expose’ event which occurs whenever part of a window that was invisible – because another application’s window was obscuring it for example – becomes visible. The application is responsible for restoring the contents of the newly exposed part of the window, but only an application designed as an X application can do this; an application that is using X via a graphics package, such as GKS or IDI, but is otherwise a conventional application that knows nothing of X, cannot.
The X graphics window manager1 makes a window on an X display behave like a traditional graphics device by making the lifetime of the window independent of any applications program and by handling window expose events. Applications still send plotting commands directly to the window; they don’t have to go via a ‘server’ process, so there is no adverse impact on performance. All communication between the window manager and the application is via the X server, and the graphics window manager does not have to run on the same machine as the application.
An international standard for displaying astronomical data on an image display.
It is intended for programs that need to manipulate images to a greater extent than can be done with GKS and its offspring. Thus, it does not supersede GKS, but offers features not available in GKS. It is not as good as GKS for producing line plots or character annotation – it does have routines to draw lines and plot text, but these are primitive and offer you little control over how the result will appear in terms of character size, style of line width, etc.
Its major strength is its ability to perform many types of interaction using the mouse. Like GKS, it can display an image, move the cursor, and rotate the look-up table. However, it can also scroll and zoom, blink the memories, and read back a representation of the whole display, which can then be used to obtain hardcopy. It allows these functions to be programmed in a device independent way, so a program can use any device for which IDI has been implemented.
It is not possible, at present, to mix GKS and IDI calls on the same display because the two packages use completely different display models. However, it is possible to run the packages one after the other. For example, IDI could follow GKS, and the display could be opened without resetting it. However, this is an undesirable approach since the results could be unpredictable. A better solution is to use AGI to mediate between them.
High-level graphics utilities.
This extensive suite was obtained from the National Center for Atmospheric Research in Boulder, Colorado. (An associated software item called SNX contains some Starlink extensions to it.)
The routines are thoroughly documented and just a few simple calls will produce graphs of excellent appearance. They also very flexible, with dozens of plot details independently controllable to give you exactly the result required. The plots provided are:
A high-level graphics package for plotting x,y plots, functions, histograms, bar charts, contour maps, and grey-scale images.
Complete diagrams can be produced with a minimal number of subroutine calls, but control over colour, line-style, character font, etc. is available if required. It was written with astronomical applications in mind and has become a de facto standard for graphics in astronomy.
Native-PGPLOT is the original version from Tim Pearson at Caltech based on the low-level graphics package known as GRPCKG. It has the same user interface as Starlink-PGPLOT, and non-ADAM applications can be moved from one version to the other simply by re-linking using the appropriate libraries.
A high-level graphics package for plotting x,y plots, functions, histograms, bar charts, contour maps, and grey-scale images.
Complete diagrams can be produced with a minimal number of subroutine calls, but control over colour, line-style, character font, etc. is available if required. It was written with astronomical applications in mind and has become a de facto standard for graphics in astronomy.
Starlink-PGPLOT is the version based on the Starlink GKS library and has the same user interface as Native-PGPLOT. Non-ADAM applications can be moved from one version to the other simply by re-linking with the appropriate libraries.
This is the version supported by Starlink for its applications.
A friendly interface to a subset of GKS.
SGS stands for ‘Simple Graphics System.’
Many of its features are low-level (e.g. draw a line), but there are some routines of a slightly higher level (drawing arcs, formatted numbers, etc). It does not include routines for high-level operations like drawing annotated axes or complete graphs. Many plotting programs can be written entirely with SGS or higher-level calls. There will, however, be occasions when GKS routines are used as well; usually because a specialised feature of GKS is needed.
It can:
Starlink extensions to NCAR.
They provide more convenient access to certain features of NCAR without sacrificing flexibility. (Beginners may be daunted by the mass of features offered by NCAR, and unless they take the extreme step of reading the manual they may give up before realising what the package can do for them.)
The AUTOGRAPH part of NCAR, used in conjunction with SNX and SGS, offers an alternative to Starlink-PGPLOT for graphing one variable against another. SNX enhances the power of AUTOGRAPH and makes it easier for the beginner.
It can:
Augment the limited character handling facilities of Fortran 77.
Converts Fortran data types into text strings and the reverse, does wild card matching, string sorting, paragraph reformatting and justification. It can be used for building text strings for interactive applications, or as a basis for more complex text processing applications.
It can:
Mix program segments written in Fortran and C in a portable manner.
It provides:
Construct and store error messages for future delivery to a user via ERR.
ERR is the Starlink Error Reporting System, which is part of MERS. It can be regarded as a simplified version of ERR without the binding to any software environment (e.g. for message output or access to the parameter and data systems). It conforms to the error reporting conventions of MERS.
Retrieve named items from a hierarchical library of text.
Functionally, it is very similar to the VAX/VMS Help system. Major differences:
It is free-standing and does not call any other Starlink packages.
General purpose KAPPA libraries
KAPLIBS is a new package containing several Fortran subroutine libraries that were previously distributed as part of the KAPPA package. These libraries contain general purpose subroutines which may be of use to anyone developing their own KAPPA-like applications. SUN/238 contains brief documentation, but users of KAPLIBS will probably find it useful to examine the source code of relevant KAPPA commands.
Report messages and errors.
There is a general need for programs to inform the user about:
MERS comprises two libraries to help you do this:
Odds and Ends library
The ONE library is a small set of Fortran and C routines of a general nature and usefulness but which are not appropriate to be included in any of the more focussed Starlink libraries.
The routines are written in C but are callable direct from Fortran.
Parameter and communication system.
Application programs often need to obtain parameter values from a variety of sources and to communicate with other programs. The Parameter and Communication Subsystems (PCS) are a set of closely-related subroutine libraries which provide these facilities for many Starlink applications and associated user-interfaces.
These libraries will not generally be called directly by application programs, but form a basic part of ADAM, the Starlink Software Environment.
Use the POSIX and X/OPEN libraries.
Lets you use operating system facilities in a machine independent way.
1Not to be confused with the Window Manager which allows you to move windows around the screen, iconize them, etc.