Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.adass.org/adass/proceedings/adass97/bridgera.html
Дата изменения: Fri May 15 22:17:26 1998
Дата индексирования: Tue Oct 2 02:38:29 2012
Кодировка:
Поисковые слова: observatory

Table of Contents -- Index -- PS reprint -- PDF reprint

Astronomical Data Analysis Software and Systems VII
ASP Conference Series, Vol. 145, 1998
Editors: R. Albrecht, R. N. Hook and H. A. Bushouse

Observing Control at the UKIRT

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

 

Abstract:

Observing with the major instruments at the United Kingdom Infra-Red Telescope (UKIRT) is already semi-automated by using ASCII files to configure the instruments and then sequence a series of exposures and telescope movements to acquire the data. This has been very successful but the emergence of the World Wide Web and other recent software technologies have suggested that it could be developed further to provide a friendlier, more powerful interface to observing at UKIRT. A project is now underway to fully design and implement this system.

           

1. Introduction

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.

2. Background: The Current System

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.

3. ORAC: An Overview

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.

3.1. Observation Preparation System

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.

3.2. Observatory Control System

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:

• The Observation Sequencer. This task informs instruments of their required configuration and sequences a set of operations to generate a particular observation. This can include taking Object and Sky sequences, mosaicing, nodding and chopping etc. A key aspect is that it will define a standard, but general, instrument interface to which all UKIRT instruments will need to adhere.
• The Scheduler. This new component in the system is a higher level system that maintains a queue of Observation Definitions prioritised according to their scheduling information. Its goal is to intelligently and automatically handle the correct and efficient scheduling of the observations, informing the observation sequencer of the next observation. It will also provide for monitoring and direct manipulation of the observing queue. The scheduler is likely to be delivered as a later upgrade to the new system.

3.3. Data Reduction System

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:

• A Recipe is a series of instructions detailing how to perform a (potentially complex) data reduction operation.
• A Script is a series of instructions on how to apply a Recipe to reduce an observing sequence using a particular data reduction package.

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)

4. Conclusions

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.

Acknowledgments:

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.

References:

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.

© Copyright 1998 Astronomical Society of the Pacific, 390 Ashton Avenue, San Francisco, California 94112, USA