Next: The Ground Support Facilities for the BeppoSAX Mission
Up: Dataflow and Scheduling
Previous: The NOAO Web-based Observing Proposal System
Table of Contents -- Index -- PS reprint -- PDF reprint
A. Bridger and G. Wright
Royal Observatory, Blackford Hill, Edinburgh, EH9 3HJ, United Kingdom
F. Economou
Joint Astronomy Centre, 660 North Aohoku Place, University Park,
Hilo, HI 96720
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 to execute 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 in which 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 it is 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)
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.
Bridger, A. & Wright, G. S. 1996, in New Observing Modes for the Next Century, ASP Conf. Ser., Vol. 87, eds., T. A. Boroson, J. K. Davies & E. I. Robson (San Francisco, ASP), 162
Daly, P. N., Bridger, A. & Krisciunas, K. 1994, in Astronomical Data Analysis Software and Systems III, ASP Conf. Ser., Vol. 61, eds. D. R. Crabtree, R. J. Hanisch, & J. Barnes (San Francisco, ASP), 457
Davies, J. K. 1996, in New Observing Modes for the Next Century, ASP Conf. Ser., Vol. 87, eds., T. A. Boroson, J. K. Davies & E. I. Robson (San Francisco, ASP), 76
Economou, F., Bridger, A., Wright, G. S., Rees, N. P. & Jenness T. 1997, this volume
Wampler, S., Gillies, K., Puxley, P. & Walker, S. 1998, in SPIE vol 3112, in press.
Next: The Ground Support Facilities for the BeppoSAX Mission
Up: Dataflow and Scheduling
Previous: The NOAO Web-based Observing Proposal System
Table of Contents -- Index -- PS reprint -- PDF reprint