Search NASA⌕ Search

Engineering topics

Shortridge, K.

Publications and source records attributed to Shortridge, K..

The evolution of the FIGARO data reduction system

The Figaro data reduction system originated at Caltech around 1983. It was based on concepts being developed in the U.K. by the Starlink organization, particularly the use of hierarchical self-defining data structures and the abstraction of most user-interaction into a set of 'parameter system' routines. Since 1984 it has continued to be developed at AAO, in collaboration with Starlink and Caltech. It was adopted as Starlink's main spectroscopic data reduction package, although it is by no means limited to spectra; it has operations for images and data cubes and even a few (very specialized) for four-dimensional data hypercubes. It continued to be used at Caltech and will be used at the Keck. It is also in use at a variety of other organizations around the world. Figaro was originally a system for VMS Vaxes. Recently it was ported (at Caltech) to run on SUN's, and work is underway at the University of New South Wales on a DecStation version. It is hoped to coordinate all this work into a unified release, but coordination of the development of a system by organizations covering three continents poses a number of interesting administrative problems. The hierarchical data structures used by Figaro allow it to handle a variety of types of data, and to add new items to data structures. Error and data quality information was added to the basic file format used, error information being particularly useful for infrared data. Cooperating sets of programs can add specific sub-structures to data files to carry information that they understand (polarimetry data containing multiple data arrays, for example), without this affecting the way other programs handle the files. Complex instrument-specific ancillary information can be added to data files written at a telescope and can be used by programs that understand the instrumental details in order to produce properly calibrated data files. Once this preliminary data processing was done the resulting files contain 'ordinary' spectra or images that can be processed by programs that are not instrument-specific. The structures holding the instrumental information can then be discarded from the files. Much effort has gone into trying to make it easy to write Figaro programs; data access subroutines are now available to handle access to all the conventional items found in Figaro files (main data arrays, error information, quality information etc), and programs that only need to access such items can be very simple indeed. A large number of Figaro users do indeed write their own Figaro applications using these routines. The fact that Figaro programs are written as callable subroutines getting information from the user through a small set of parameter routines means that they can be invoked in numerous ways; they are normally linked and run as individual programs (called by a small main routine that is generated automatically), but are also available linked to run under the ADAM data acquisition system and there is an interface that lets them be called as part of a user-written Fortran program. The long-term future of Figaro probably depends to a large extent on how successfully it manages the transition from being a VMS-only system to being a multi-platform system.

Shortridge, K.↗

The data acquisition system for the Anglo-Australian Observatory 2-degree field project

The Anglo-Australian Observatory (AAO) is building a system that will provide a two-degree field of view at prime focus. A robot positioner will be used to locate up to 400 optical fibers at pre-determined positions in this field. While observations are being made using one set of 400 fibers, the robot will be positioning a second set of fibers in a background field that can be moved in to replace the first when the telescope is moved to a new position. The fibers feed two spectrographs each with a 1024 square CCD detector. The software system being produced to control this involves Vaxes for overall control and data recording, UNIX workstations for fiber configuration calculations and on-line data reduction, and VME systems running VxWorks for real-time control of critical parts such as the positioner robot. The system has to be able to interact with the observatory's present data acquisition systems, which use the ADAM system. As yet, the real-time parts of ADAM have not been ported to Unix, and so we are having to produce a smaller-scale system that is similar but inherently distributed (which ADAM is not). We are using this system as a testbed for ideas that we hope may eventually influence an ADAM II system. The system we are producing is based on a message system that is designed to be able to handle inter-process and inter-processor messages of any length, efficiently, and without ever requiring a task to block (i.e., be unresponsive to 'cancel' messages, enquiry messages), other than when deliberately waiting for external input - all of which will be through such messages. The essential requirement is that a message 'send' operation should never be able to block. The messages will be hierarchical, self-defining, machine-independent data structures. This allows us to provide very simple monitoring of messages for diagnostic purposes, and allows general purpose interface programs to be written without needing to share precise byte by byte message format definitions. Programs in this system have interfaces defined simply in terms of named actions and their parameters. Real-time control programs are required to be able to handle a number of such actions concurrently; data reduction programs will normally only need to handle one action at a time ('process an image', 'display a spectrum', etc).

Shortridge, K.↗