Alan Bridger & Gillian Wright
Royal Observatory, Blackford Hill, Edinburgh, EH9 3HJ, United Kingdom
Frossie Economou
Joint Astronomy Centre, 660 North Aohoku Place, University Park, Hilo, HI 96720
Visiting observers at the United Kingdom Infra-Red Telescope already automate much of their data taking via the use of predefined Configs and EXECs. Using an off-line preparation system to create these has significantly improved observing efficiency, as also has the automatic, on-line data reduction system in use by one of the main instruments. Experience with the system and also the possibility of changes in the observing practices at UKIRT (an experiment in reactive scheduling is in progress on UKIRT, Davies 1996) make it seem natural to improve the present system, taking advantage of recent developments in software technology. This paper outlines the project (ORAC - ``Observatory Reduction and Acquisition Control'') that has been formed to implement this evolution. After briefly describing the existing system an overview of the new system is presented and a short description of each component given.
The UKIRT control system consists of three main elements, the telescope control system, the instrument control system and the on-line data reduction system (Daly, Bridger & Krisciunas 1994 gives more details). The instrument control system controls the instrument via its use of Configs and the observing sequence via EXECs. Although most high-level telescope control is performed by the telescope operator (TO) the instrument control task also performs some telescope control ( e.g. ``nodding'') via the EXECs.
A Config is a user-defined description of an instrument setup, stored as an ASCII file. It includes items such as the filter required, exposure time, etc for both the target and related calibration observations. An EXEC is another ASCII file containing a user-defined sequence of observing commands which control both the instrument and the telescope, e.g. configure the instrument, take a dark frame, take an object observation, "nod" the telescope to sky, etc. EXECs may also call other EXECs, allowing the reuse of standard EXECs and the modular building of more complex observing sequences. Both Configs and EXECs are defined using the UKIRT Preparation System. This presents a simple menu-based interface and in the case of Configs greatly simplifies the creation of the files, especially by automating some of the selections (though the user may override). Observers are encouraged to prepare Configs and EXECs before reaching the telescope, usually at the JAC.
For the CGS4 near-infrared spectrometer there is also automatic data reduction - as soon as a new data frame is stored the data reduction system will reduce it, combining it where required with other data frames. This gives a rapid feedback of the true data quality to the observer as well as producing (in many cases) the final reduced data.
Despite its success there are a number of limitations in this system. Bridger and Wright (1996) proposed to evolve this system into a more fully automated version. Since then a project has been created with the stated aim `To increase the observing efficiency and publication rate of UKIRT'. The approach is based around making it easier, friendlier and more efficient to observe at UKIRT: by providing an easy to use remote preparation system; by providing a more powerful and flexible on-line data reduction system; and by further automating the acquisition of data at the telescope. A long-term goal is to produce a system capable of fully queue-scheduled observing, should UKIRT implement it.
The design is based around the idea that an observation may be defined as consisting of an Instrument Configuration, which tells the instrument how it should be setup for an observation, a Target Description, to inform the telescope where to point, and an Observing Sequence, which describes the sequence of telescope movements and data acquisition commands required collect the observation. These components are modular and may be used in multiple Observation Definitions. Thus Target Description BS623 may be used with Instrument Configuration Std_H_Band and Sequence Bright_Star in one observation, and combined with My_K_Band and Std_Jitter to form a different observation. To this basic definition of an observation are added further components which describe the data reduction Recipe to be used on the observation and Scheduling Information which may be used in a more sophisticated observation scheduler.
These components, and the full Observation Definitions, may be prepared ahead of time (off-line) or at the telescope. In operation the Observatory Control System will read them and distribute the components to the various subsystems, to configure and control the acquisition and the reduction of the data.
The Observation Preparation System is a replacement for the existing UKIRT Preparation System. Observers must be able to run it from their home institution, without the need for detailed software installations. The system will need to change to reflect changing instrument availability. Both of these suggest a web-based application. However, speed of the web, and the loading on the server might be problems. Use of mirror sites could help with this, but the use of automatic software installations and internet push technology to keep them up to date might be a better solution. This is the approach taken by the Gemini group with their Observing Tool (Wampler et al, 1998).
The output of the preparation system will be one or many files forming an Observation Definition that can be stored along with similar definitions from the same or different observing programmes to form the telescope's observation `database'. Initial versions of the database will probably use the existing combination of ASCII text files and a directory tree structure, for backwards compatibility. Possible future use of a commercial database will be considered.
It is likely that much observation verification will be done by this system - the output of the preparation system should be guaranteed to be able to be performed by the instrument, to eliminate errors at the telescope. The preparation system will present the user with an astronomer-oriented interface, although its output may well be at a lower level. It is anticipated that the system's understanding of the instruments will be codified by a set of rules which will be maintained by the instrument support scientist, adding to the system robustness.
The Observatory Control System performs the sequencing role between the instruments and telescopes and optionally also some of the scheduling of individual observations. The way the components of the Observation Definitions are to be handled is still to be determined, but the likely approach is to leave the reading and parsing of a component to the system that requires it - for example an Instrument Configuration will be read and interpreted by the Instrument Control System. This considerably simplifies the logic of the higher system. Other approaches are possible and will be considered.
The Observatory Control System consists of two main components:
This performs automatic on-line data reduction after the raw data frames are stored. Its current design is based on the concepts of Recipes and Scripts:
The user will request a particular reduction sequence by drawing from a series of observatory defined Scripts and Recipes. Advanced users will be able to provide their own Recipes and Scripts to reduce particular aspects of their observations, but it is expected that they will all use standard Recipes to remove specific instrument dependencies. It is anticipated that the Scripts will be coded in a standard scripting language, and hoped that the actual data reduction algorithms will be provided by standard data reduction packages. The aim of this is to reduce the support effort at the Observatory, concentrating it on the automatic aspects of the reduction system. As a side effect all of the actual algorithms used by the system should already be available to the community, and users may be provided with the actual Scripts used to reduce their data. The data reduction system is described in more detail in Economou et al. (1997)
A constant driving force on the UKIRT control system is the desire of observers for greater efficiency. The ORAC project aims to achieve greater efficiency whilst retaining the flavour and flexibility of current observing practices.
We would like to acknowledge the scientists and software groups at UKIRT and ROE, and the UKIRT telescope operators for many helpful discussions, and of course the input of many UKIRT observers.
Observing Control at the UKIRT
This document was generated using the LaTeX2HTML translator Version 95.1 (Fri Jan 20 1995) Copyright © 1993, 1994, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
The command line arguments were:
latex2html -split 0 -no_navigation -t Observing Control at the UKIRT bridgera.tex.
The translation was initiated by Alan Bridger on Mon Nov 17 15:00:51 GMT 1997