The Long and Short Term Scheduling Tools (respectively, LTS and STS) are part of the ESO Observation Handling Subsystem (OHS), a collection of tools for processing and managing observing proposals, observing schedules, and observation sequences in the form of Observation Blocks (OBs) (Chavan et al. 1998). The LTS is used twice a year to analyze the characteristics of an accepted set of observing proposals and to produce a six month (``period'') schedule. On the other hand, the STS is used nightly to produce OB execution sequences (timelines) that minimize operations overheads against a user selectable set of weather conditions, instrument configurations, and scientific priority.
Scheduling the programs for all ESO telescopes is difficult. The LTS has to take into account telescope availability limitations, Principal Investigator (PI) defined observation scheduling constraints, and the scientific priority assigned by peer-review. The telescope availability limitations include technical time periods that have to be reserved at regular intervals, instrument availability and instrument change overhead. There are several PI defined scheduling constraints, all of which can be entered on the revised ESO proposal form first introduced in late 1998. Users define a set of targets to be observed - this target set is used to construct a Target Visibility function. For each target, a Piecewise Continuous Function (PCF) histogram is constructed with highest value during the nights when the target is best visible and value 0 when it is not visible at all. The target visibility function for the whole program is the merger of the individual target PCFs. Required Moon Phase is also specified - the user can choose among three values: dark, gray, no restriction. Links between different observing runs are also allowed. Very often a program must be split into two or more separate, but linked, observing runs with a fixed temporal intervals. Such links (or chains) can also be defined between observing runs of different programs (e.g. on different telescopes). Time Intervals to avoid (i.e. periods during which observations should not be scheduled) can optionally be specified by PIs. The PI can require that the program has to be allocated only during a specific Night Fraction, i.e. during first or second half of the night. Finally, users can specify Preferred Month(s). Usually such preferred months should overlap the best target visibility period, but some times they do not. Scientific priority is always given highest weight.
The LTS is used to analyze the accepted programs and to create the six month schedule for all ESO telescopes. To analyze the submitted programs, a program browser was implemented. The LTS user can select and sort the programs with a number of criteria, such as telescope, instrument(s), service/visitor programs, program rank, requested moon phase, and requested seeing. Tabular and graphical reports can be generated for the selected programs. Example reports include RA distribution vs requested Moon phase, targets distribution, instrument distribution, requested seeing or operations mode (Service or Visitor).
Since it is impossible to satisfy all constraints and links for all programs when constructing the schedule, the LTS user can relax certain constraints for any given program, i.e. the PI defined constraints and the amount of time allocated.
Once a complete set of programs (and possibly sub-programs) have been selected and their constraints modified, the actual schedule is constructed using a GUI. This timeline GUI displays a six month time range showing the sequence of scheduled programs. Selecting a program displays its constraints over the six month period, i.e. all the useful information is displayed simultaneously. Although the LTS can schedule programs automatically, user specified programs (e.g. technical time) can also be scheduled manually at fixed times, and then the automatic scheduling algorithms can be run to complete the schedule. Since it is rare that the automatic scheduling algorithm produces a completely acceptable schedule, the LTS user is also allowed to change the schedule by dragging and dropping programs along the timeline widget.
The STS is used during science operations to support service observing. Before a six month observing period begins, PIs with approved Service Mode programs must submit a detailed description of their observation program in the form of Observation Blocks (OBs). An OB is considered to be the smallest schedulable unit. In preparation for a service observing run (typically two weeks long), the set of all schedulable OBs are selected by the ESO operations staff and the STS is used to construct a series of reports about instrument configuration, scheduling constraints, and target visibility. This pre-selected set of OBs and its associated report set is collectively known as the Medium-Term Schedule (MTS). During the actual service observing run, the STS is used nightly to construct OB execution sequences (timelines), using the MTS as input. These timelines attempt to minimize operations slack-time vs expected (or actual) observing conditions and available instrument configurations.
Although similar, the STS problem is more difficult than the LTS problem because of the more detailed scheduling constraints. Target visibility takes into account not only the target RA, but also declination. The moon constraints include not only moon phase, but also the moon rise/set times and the moon-target distance. Weather constraints include sky transparency and seeing. Two kinds of timing constraints are allowed: links (chains) of OBs and Absolute Time Intervals during which an OB must be executed. Obviously, scheduling objectives can be both complex and contradictory. Although the main goal is to maximize the telescope utilization, it is also a high priority to schedule OBs with high scientific priority even if that would decrease telescope efficiency in an absolute sense. Similarly, minimizing the instrument setup time implies grouping and executing OB sequences with the same instrument configuration, but that often means that some OBs will not be executed at their optimal airmass. Having these multiple objectives means that we need multiple algorithms with different weights for different objectives. For example, some algorithms cover the ranking and the airmass, rather then the instrument setup. These algorithms could be used if all OBs have similar instrument configuration. Conversely, if all OBs have the same scientific priority, it makes no sense use algorithms that give great importance to scientific priority (Chavan et al. 1998).
The most important STS component is a timeline GUI that uses Universal Time and Local Sideral Time as its timescales. This widget shows the OB execution sequence of the currently selected schedule. When an OB is selected, its constraints are displayed along the time scale. As in the LTS the user can pre-assign some OBs at certain times and lock them. The scheduling algorithms can be run to complete the timeline. Drag-and-drop functionality allows the user to move OBs to revise the automatically generated schedule. The final timeline can than be accepted and stored for later execution, or sent to the telescope for immediate execution. If weather conditions change or some unexpected event happens during the night, the STS user can easily change the scheduling parameters (like sky transparency and seeing) and reschedule the rest of the night with the not yet executed OBs.
The LTS was used to schedule two telescopes out of seven during the current ESO semester. As expected, experience shows that it is never possible to satisfy completely all a priori constraints. The scheduling process is an iterative process: (1) identify constraints that cannot be respected; (2) edit the program constraints; and (3) run the scheduling algorithm. If it is still impossible to complete the schedule, then iterate this process until a satisfactory schedule is produced. For the current semester, two days were needed to schedule two telescopes. At that time, the released LTS did not yet display and manage links and timing constraints. Most of the time was spent analyzing the proposals and revising these input constraints. Having all program constraints displayed in the tool and editable would save a lot of time. The next release, scheduled for December 1999, will display all constraints. The ESO scheduling expert, who has been doing this job for almost 20 years, needs about two weeks to schedule seven telescopes. Our hope is that the LTS will allow even an astronomer with relatively little scheduling experience to complete the entire ESO period schedule for 7 - 9 telescopes in one week.
Our STS experience has been more limited. The VLT science operations staff is using the STS as a support tool, but not yet to schedule OBs on a regular basis. STS reports and the program constraints plots are used to organize OB information and decide which OBs to execute, but OB execution sequences are constructed manually outside of the STS. Two chief lessons have been learned: we need to deliver a good STS user manual, because of complexity of the problem/tool; and that the transition from manual scheduling to semi-automatic scheduling with a tool like the STS is slow and often implies also an organizational change which is not easy to adopt. Therefore we are going to deliver a complete STS release at VLT-UT1 and VLT-UT2 with a complete and detailed user manual and we are planning to assist the Paranal users more closely, directly at the telescope as time and resources permit.
Chavan, A. M., Giannone, G., Silva, D. R., Krueger, A. P., & Miller, G. E. 1998, in SPIE Proceedings Series Vol. 3349, Observatory Operations to Optimize Scientific Return, ed. P. J. Quinn, 97
Johnston, M. & Miller, G. 1994, in Intelligent Scheduling, ed. M. Zweben & M. S. Fox (San Francisco, Morgan Kaufmann), 391