Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/institute/software_hardware/spike/documents/chavana.pdf Дата изменения: Unknown Дата индексирования: Tue Feb 5 20:27:28 2013 Кодировка: Поисковые слова: внешние планеты

Nightly Scheduling of ESO's Very Large Telescop e

A. M. Chavan European Southern Observatory, D 85748 Garching, Germany G. Giannone Serco D. Silva European Southern Observatory T. Krueger, G. Miller SpaceTelescope Science Institute

Abstract.

A key challenge for ESO's Very Large Telescope VLT will be responding to changing observing conditions in order to maximize the scienti c productivity of the observatory. For queued observations, the nightly scheduling will be performed by sta astronomers using an Operational Toolkit. This toolkit consists of a Medium- and a Short-Term Scheduler, 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 di erentscheduling criteria. There may be di erent queues based on seeing", or priority, or any other criteria that is selected by the sta astronomer. An MTS queue is then selected and supplied to the STS for detailed nightly scheduling. The STS uses the Spikescheduling engine, whichwas originally developed by STScI for use on the Hubble Space Telescope.

1. Introduction
An Operational Toolkit OT is being developed at ESO. A front-end component of the Data Flow System DFS Quinn 1997, 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 time, with the goal on maximizing the observatory's scienti c return. While it is aimed at supporting service mode operations, the toolkit will can be used by Visiting Astronomers as well. The toolkit will make all observation preparation data available to the operator, and will allow the de nition of queues and timelines of Observation Blocks OBs. The OT will also interface to the VLT Control Software, providing ob1


servation 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 ob jects, joining target information with the description of the technical setup of the observation. OBs are created byinvestigators using another DFS front-end tool, the Phase II Proposal Preparation System P2PP; Chavan 1996, then checked into the ESO repository, where they are veri ed for correctness by ESO. The operations team then uses the Operational Toolkit to browse the repository and build queues, based on ob ject visibility, expected observing conditions, and user-de ned 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 de ned for the same night e.g., based on di erent expectations on weather, or equipmentavailability. An OB can belong to more than one queue at the time. Later, as the observing night begins and progresses, the sta 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 | like a change in the current seeing conditions, the termination of an OB, an instrument con guration 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 uni ed set of commands and display widgets. However, several independent components will cooperate behind the scenes to provide such features, as shown in Fig. 1. 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 assure 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 MediumTerm Scheduler MTS. The browser will enable the OT user to select OBs from the repository, based on target coordinates, ob ject status, requested instrument and instrumental con guration like lters and grisms and scheduling constraints see below. OBs can also be selected according 2


STS

OB queues

Queue timelines

GUI

MTS

Observing Programmes

OB Repository

Figure 1.

System architecture of the OT

to observation type like imaging, spectroscopy, or calibration and speci c observing programmes or users. The amount of information to be displayed in the browser per 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 exibility, queues will normally oversubscribe the available time by a factor 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 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 and 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 con gurable resources: an OB can not be scheduled if, e. g., it needs a lter 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 like seeing, sky transparency and IR emissivity and moon-related constraints like fractional lunar illumination and moon angular distance. 3


Several scheduling strategies will be available, based on a combination of factors like 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 di erent strategies, and chose the one optimizing the current queue. A number of di erent metrics and GUI tools will be available to build and compare schedules, including a graphic display of the set of scheduling constraints. As we said, 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 maychange dynamically during the night, due to weather evolution or programmes nearing completion, and the scheduling engine needs will 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 over which OB to execute, and when, rests with the VLT Data Flow operations sta . 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
Aversion 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 rst prototype of the STS was released in November 1997 for in-house testing, with eld tests at the NTT foreseen for the beginning of 1998. We plan to have a fully operational OT by the time service observing at the VLT will start.

References
Chavan, A. M. and Albrecht, M. 1997, in ASP Conference Series, Vol. 125, Astronomical Data Analysis and Software Systems VI, ed. G. Hunt& 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. Quinn, P. 1997, The VLT Data Flow System: A Progress Report", in this volume. 4