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

Nightly Scheduling of ESO's Very Large Telescope

A. M. Chavan, G. Giannone¹ and D. Silva
European Southern Observatory, Karl Schwarzschild Str-2, D-85748, Garching, Germany

T. Krueger, G. Miller
Space Telescope Science Institute, Baltimore, MD 21218, USA

¹Serco GmbH, at the European Southern Observatory

 

Abstract:

A key challenge for ESO's Very Large Telescope (VLT) will be responding to changing observing conditions in order to maximize the scientific productivity of the observatory. For queued observations, the nightly scheduling will be performed by staff astronomers using an Operational Toolkit. This toolkit consists of a Medium and a Short-Term Scheduler (MTS and STS), both integrated and accessible through a common graphical user interface. The MTS, developed by ESO, will be used to create candidate lists of observations (queues) based on different scheduling criteria. There may be different queues based on ``seeing'', or priority, or any other criteria that are selected by the staff astronomer. An MTS queue is then selected and supplied to the STS for detailed nightly scheduling. The STS uses the Spike scheduling engine, which was originally developed by STScI for use on the Hubble Space Telescope.

             

1. Introduction

  An Operational Toolkit (OT) is being developed at ESO as a front-end component of the Data Flow System (DFS). It is designed to react quickly to evolving weather, taking the best advantage of the current observing conditions. It will enable the observers to take the most valuable science data at any given time, with the goal of maximizing the observatory's scientific return. While it is aimed at supporting service mode operations, the toolkit can also be used by Visiting Astronomers.

The toolkit will make all observation preparation data available to the operator, and will allow the definition of queues and timelines of Observation Blocks (OBs). The OT will also interface to the VLT Control Software, providing observation instructions and recording OB-related run-time events. Finally, the toolkit will act as the interface to the OB repository for the whole Data Flow System.

2. Operating the front end of the Data Flow System

  Observation Blocks are modular objects, joining target information with the description of the technical setup of the observation. OBs are created by investigators using another DFS front-end tool, the Phase II Proposal Preparation System (P2PP; Chavan 1996), then checked into the ESO repository, where they are verified for correctness by ESO.

The operations team then uses the Operational Toolkit to browse the repository and build queues, based on object visibility, expected observing conditions, and user-defined scheduling constraints. A queue is a subset of the available OBs: it usually covers one to a few nights of observation, and several queues can be defined for the same night (e.g., based on different expectations of weather, or equipment availability). An OB can belong to more than one queue at a time.

Later, as the observing night begins and progresses, the staff observer can switch back and forth among the available queues, and build timelines (observing plans) for each individual queue. Timelines are based on the current weather conditions and OB priority, and can be built on several possible scheduling strategies.

Events originating from the VLT Control Software or other DFS subsystems -- such as a change in the current seeing conditions, the termination of an OB, an instrument configuration change, or a failure while reducing the science frames -- are also received by the OT, and fed back into the scheduling process and the OB repository.

3. Architecture of the Operational Toolkit

  Users of the OT will see a single graphical user interface, and access OT functionalities through a unified set of commands and display widgets. However, several independent components will cooperate behind the scenes to provide such features, as shown in Figure 1.

 

Figure 1: System architecture of the OT

• The OB repository will be implemented on top of a commercial DBMS, running on dedicated servers in Garching (Germany), La Silla, and Paranal (Chile). Database replication will be handled transparently to the users, and will ensure that the same up-to-date information is used for operations throughout the system.
• Repository browsing, queue management, and interaction with the VLT Control Software and other DFS subsystems will be provided by the
  Medium-Term Scheduler (MTS). The browser will enable the OT user to select OBs from the repository, based on target coordinates, object status, requested instrument and instrumental configuration (such as filters and grisms) and scheduling constraints (see below). OBs can also be selected according to observation type (such as imaging, spectroscopy, or calibration) and specific observing programmes or users. The amount of information to be displayed in the browser for each OB can be customized by the operator.

  OBs extracted from the repository will then be appended to queues (to provide a certain degree of scheduling flexibility, queues will normally oversubscribe the available time by a factor of two). The user will then be able to ``zoom'' in and out of the OBs, selectively displaying all the available information in a hierarchical fashion. Queues can be ordered according to a number of criteria, printed out, and sent to the STS for timeline computation. The currently selected OBs within a queue can be pulled over by the VLT Control Software for execution.

  Finally, the MTS will have (read-only) access to the ESO Programme (``Phase I'') database as well.

• Timelines will be computed by the Short-Term Scheduler (STS), a derivative of the scheduler used for the Hubble Space Telescope. The STS is based on the Spike core (Johnston & Miller 1994), adapted for use in ground-based observatories. It is being jointly developed by ESO and the Space Telescope Science Institute in Baltimore, MD. Timeline computation will based on scheduling constraints and strategies.

  OB scheduling is implicitly constrained by target visibility and availability of configurable resources: for example an OB cannot be scheduled if it needs a filter that is not currently mounted. OB authors will be able to further constrain execution by specifying exactly when and/or under which conditions the observations can take place: the scheduler will honor timing constraints, sequencing (``chains'') of OBs, weather constraints (such as seeing, sky transparency and IR emissivity) and moon-related constraints (such as fractional lunar illumination and moon angular distance).

  Several scheduling strategies will be available, based on a combination of factors including OB priority, weather evolution and a number of preference values: observations should be performed as close as possible to the zenith, away from the moon, etc. Operators will be able to compare schedules generated with different strategies, and chose the one optimizing the current queue. A number of different metrics and GUI tools will be available to build and compare schedules, including a graphic display of the set of scheduling constraints.

  OB priority is an important scheduling parameter. ESO observing programmes are ranked by ESO's Observing Programmes Committee (OPC); when creating queues, the computation of an OB's priority starts from the OPC rank of the programme to which the OB belongs. However, priorities may change dynamically during the night, due to weather evolution or programmes nearing completion, and the scheduling engine needs to keep track of them -- as a result, the schedule will be highly dynamical, and change several times during a night. This implies important performance requirements for the Short-Term Scheduler.

  Note that the STS is a support system, not an automatic scheduler: it can be used to compute several timelines, but the ultimate responsibility for which OB to execute, and when, rests with the VLT Data Flow operations staff.

• The usability of system as complex as the Operational Toolkit depends largely on the friendliness of its user interface. We'll try to make sure that (a) all OB and schedule information is readily available and easy to read, (b) the user is always able to override the system's suggestions, and (c) all of the tool's features are ``one click away'' (no double operations).

4. Perspective

  A version of the MTS has been in operations at ESO's New Technology Telescope (NTT) in La Silla since the beginning of 1997, including a large fraction of the above listed features; feedback from early users proved invaluable in shaping the tool's behavior and looks. The first prototype of the STS was released in November 1997 for in-house testing, with field tests (at the NTT) foreseen for the beginning of 1998. We plan to have a fully operational OT by the time that service observing at the VLT starts.

References:

Chavan, A. M. and Albrecht, M. 1997, in Astronomical Data Analysis Software and Systems VI, ASP Conf. Ser., Vol. 125, eds. Gareth Hunt and H. E. Payne (San Francisco, ASP), 367

Johnston, M. and Miller, G. 1994, in Intelligent Scheduling, ed. M. Zweben & M. S. Fox (San Francisco, Morgan Kaufmann), 391

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