Документ взят из кэша поисковой машины. Адрес
оригинального документа
: http://www.adass.org/adass/proceedings/adass97/chavana.html
Дата изменения: Fri May 15 22:17:26 1998 Дата индексирования: Tue Oct 2 02:00:30 2012 Кодировка: Поисковые слова: п п п п п п п п п п |
Next: VLT Data Quality Control
Up: Dataflow and Scheduling
Previous: Dataflow and Scheduling
Table of Contents -- Index -- PS reprint -- PDF reprint
A. M. Chavan, G. Giannone1 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
1Serco GmbH, at the European Southern Observatory
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.
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.
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.
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.
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
Next: VLT Data Quality Control
Up: Dataflow and Scheduling
Previous: Dataflow and Scheduling
Table of Contents -- Index -- PS reprint -- PDF reprint