The UKIRT Observatory Reduction and Acquisition Control (ORAC) Project

Gillian Wright¹, Alan Bridger¹, Frossie Economou² and Malcolm Currie¹

1 : Royal Observatory Edinburgh, Blackford Hill, Edinburgh EH9 3HJ, UK

2 : Joint Astronomy Centre, 660 N. A'ohoku Place, Hilo, Hawaii 96720, USA

1. Introduction

The project team consists of Alan Bridger (Project manager, software design), Gillian Wright (project scientist), Frossie Economou, and Malcolm Currie.  In addition the Michelle and UIST teams at ROE are contributing software, and the UKIRT support scientists and project scientists are participating the specification.  The external project scientist is Andy Adamson of the University of Central Lancashire. All of the documentation for the ORAC project, including scientific and technical specifications, is publically available on the WWW at: http://www.roe.ac.uk/abwww/orac/, with a mirror site on the UKIRT software group pages at /UKIRT/software/orac/.

The project has three main components: a new observation preparation system; a new overall observatory control system; and a new flexible on-line data reduction system. The figure shows schematically how the new system will look when it is completed, and in the following sections we describe very briefly what the new components will do. The system is based around the concept that an observation can be described by an "Observation Definition" that consists of:
 

1. an instrument configuration (much like a current "Config")
2. a target description (source position, cross-head offsets)
3. an observing sequence (a generalised "EXEC", that describes the sequence of telescope moves and exposures needed)
4. a data reduction recipe (the steps for reducing the data)
5. scheduling information (e.g. seeing, priority)

2. Observation Preparation System.

The system will be based on the Gemini Phase-2 Observing Tool (which will provide remote observation preparation for Gemini).  We are collaborating with the Gemini team to produce a UKIRT version of their system.  The idea is that although the menu choices presented to you will be UKIRT specific (e.g. CGS4 items), much of the underlying software will be in common between the two systems, and the overall "look and feel" will be the same (e.g. the same icon will be used for instrument configuration in both cases).  Obviously this might mean some stylistic compromises for UKIRT, but there are many advantages. For example, the Gemini observing tool has a very powerful and useful position editor for defining mosaics, guide-star selection, etc., which could not be recreated for UKIRT within the effort available to the ORAC project.

The top level of the user-interface will be very astronomically orientated, allowing auto-selection of instrument parameters if desired. There will be libraries of standard instrument configurations and observing sequences to select from.  The output will be checked for inconsistencies and errors and the software will warn you of potential problems. For example it will check that CGS4 grating orders are suitable for the selected wavelength.  Once created the programme file will be stored in (submitted to) the UKIRT observing database.
 

3. Observatory Control System

The function of the Scheduler is to determine which observation to perform next and to provide this information to the sequencer. The initial version of the Scheduler will be a simple user interface that allows you to list the available Observation Definitions and select which one to do next.  Eventually the Scheduler could maintain a queue of Observation Definitions, and you would manipulate the queue to control the system for normal observing.  A fully developed Scheduler would automatically create the queue, based on the scheduling information provided in your Observation Definitions, so that the system could be used for queue-scheduled observing.

The Observation Sequencer can be thought of as broadly equivalent to the EXEC handling portion of the current software, with some enhancements. It informs instruments of their required configuration and sequences a set of operations to generate a particular observation - e.g. set to the configuration, take an exposure, offset the telescope, take another exposure etc.
 

4. Data Reduction System

The design is based on the concept of Recipes and Scripts.  A Recipe is a series of high level instructions detailing how to perform a complex series of data reduction operations.  A Script is a set of instructions (code) implementing a particular recipe in a given data reduction package.  The user will request a particular reduction sequence by drawing from a series of pre-defined Recipes.  Standard observing sequences such as photometry jitter patterns and nodding along the slit will have corresponding standard reduction Recipes. The name of the Recipe to use will be obtained by the Observatory Control System from the Observation Definition, and written into the data file header.  A pipeline manager will detect the arrival of new data on disk, read the Recipe name from the header, send the necessary messages to run the scripts for the appropriate data reduction package and hence reduce the data.  Initially the data reduction will be carried out by the major packages supported by Starlink (KAPPA, FIGARO, CCDPACK, PHOTOM) and the data format will be NDF.
 

5. Timescales

Back to the Contents