Äîêóìåíò âçÿò èç êýøà ïîèñêîâîé ìàøèíû. Àäðåñ îðèãèíàëüíîãî äîêóìåíòà : http://www.stecf.org/conferences/adass/adassVII/reprints/chavana.ps.gz Äàòà èçìåíåíèÿ: Mon Jun 12 18:51:44 2006 Äàòà èíäåêñèðîâàíèÿ: Tue Oct 2 03:25:13 2012 Êîäèðîâêà: Ïîèñêîâûå ñëîâà: ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï ï

Astronomical Data Analysis Software and Systems VII
ASP Conference Series, Vol. 145, 1998
R. Albrecht, R. N. Hook and H. A. Bushouse, e
Ö Copyright 1998 Astronomical Society of the Pacific. All rights reserved.
ds.
Nightly Scheduling of ESO's Very Large Telescope
A. M. Chavan, G. Giannone 1 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
Abstract.
A key challenge for ESO's Very Large Telescope (VLT) will be re­
sponding to changing observing conditions in order to maximize the scien­
tific 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
(MTS and STS), both integrated and accessible through a common graph­
ical user interface. The MTS, developed by ESO, will be used to create
candidate lists of observations (queues) based on di#erent scheduling cri­
teria. There may be di#erent queues based on ``seeing'', or priority, or any
other criteria that are selected by the sta# 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 compo­
nent 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 oper­
ator, and will allow the definition of queues and timelines of Observation Blocks
(OBs). The OT will also interface to the VLT Control Software, providing ob­
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.
1 Serco GmbH, at the European Southern Observatory
255

256 Chavan, Giannone, Silva, Krueger and Miller
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 inves­
tigators 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 repos­
itory 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 di#erent 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 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
--- 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 func­
tionalities 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.
. 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 sta­
tus, requested instrument and instrumental configuration (such as filters
and grisms) and scheduling constraints (see below). OBs can also be se­
lected 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 over­

Nightly Scheduling of ESO's Very Large Telescope 257
MTS
OB Repository
STS
Observing Programmes
OB
queues
Queue
timelines GUI
Figure 1. System architecture of the OT
subscribe 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 compu­
tation. 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 deriva­
tive 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 computa­
tion 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 pref­
erence 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

258 Chavan, Giannone, Silva, Krueger and Miller
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.
OB priority is an important scheduling parameter. ESO observing pro­
grammes 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, priori­
ties 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
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
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 ASP Conf. Ser., Vol. 125, Astronomical
Data Analysis Software and Systems VI, ed. Gareth 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