The process for planning and scheduling parallel observations is thus quite different from the process for primary science. In the past, custom crafting rules for each parallel program were necessary, requiring full-time support from a software developer. In addition, because POMS ran as a standalone system, its ability to model how long parallel SUs would take was limited, especially with the flexible buffer-management schemes used for the second-generation SIs.
A new version of POMS was developed in 1997. This version uses a formal proposal syntax (the same used for primary observations) for parallels, so that different proposals can be handled uniformly and without the need for customized ``crafting rules.'' In addition, POMS is integrated with the Transformation (TRANS) planning system in order to give it full knowledge of overheads within an SU, eliminating the need for ad hoc modeling. The power and versatility of this approach has paid off in improved utilization of parallel opportunities, greatly reduced maintenance costs, and an ability to gracefully handle new parallel proposals and new SIs with minimal software effort.
This paper discusses the requirements, design, and operational results of the new POMS.
The first step in this process is to structure the calendar into a set of slots where parallel alignments (uninterrupted pointings) can go. Oversimplifying somewhat, a slot for a given parallel SI is an interval on the calendar during which there is target visibility, no use of that SI by primary alignments, no spacecraft maneuvers or SAA passages, no loss of pointing control, and no primary alignments marked as non-parallel-able.
For each parallel visit, POMS then structures the slots into a collection of parallel fields. Whereas a slot is a place where a parallel alignment can go, a field is a place where an entire parallel SU can go. An SU consists of a set of alignments, but there may be gaps between the alignments (to allow for occultations, for instance), so a parallel SU can extend over many orbits. A field is a set of adjacent slots that (a) all fit within the same primary SU (no major slews within a field), (b) are all scientifically compatible with the parallel visit under consideration (the primary pointing must satisfy any pointing constraints of the parallel), and (c) do not differ in pointing by more than the tolerance specified in the parallel proposal. In order to allow for internal alignments (to do ``clean-up'' commanding and dump the SI buffers) at the end of a parallel SU, a field is allowed to extend past the end of the last slot in it, until an event is encountered that violates one of the above constraints.
Field sizes provide an upper bound on the size of SUs that can be crafted in them. (In POMS, unlike in primary HST scheduling, there is a difference between the term visit and SU: a visit refers to the set of exposures submitted by the observer, while the SU is the entity actually scheduled from that visit. Individual visits can be instantiated into parallel SUs many times, whenever POMS finds a suitable opportunity.) Depending on the calendar structure, there will be a distribution of fields of various sizes. The longest opportunities (fields) are considered most valuable scientifically. Normally, parallel proposers are advised to provide a range of visits of various sizes, with the longer ones given higher priority so that POMS will consider them first. If it proves infeasible to craft an SU for a long visit in a field, a shorter visit may be tried in the same place later. If an SU only fills part of a field, the field may be reused for the same visit, as well as for lower-priority visits. Thus the visit sizes act as a sieve, which produces smaller and smaller holes as the shorter visits are encountered. For each SI, at least one low-priority ``sponge'' visit is provided to fill all the remaining fields that are large enough to allow science that might be conceivably useful.
In order to determine whether crafting is feasible for a particular visit in a field, POMS must compare the field size to the duration of the SU the visit would produce. The duration of an SU includes overheads such as filter wheel motions, cleanup commanding, and buffer dumps. In addition, exposure durations are adjustable within limits provided by the observer. Therefore POMS faces an overhead inversion problem. For efficient crafting, it must determine the maximum exposure durations which, after overheads are added, would produce an SU that comes as close as possible to filling the field without exceeding it. However, POMS itself has no knowledge of SI overheads.
This problem was one of the main reasons POMS was redesigned for greater integration with TRANS, the planning subsystem that, among other things, computes SI overheads and also has an algorithm for inverting them to optimize primary observations. The old system attempted to ``model'' what TRANS would do, an approach that became untenable with the complexities of buffer management that were added to TRANS to support NICMOS and STIS. Instead, POMS now calls TRANS directly each time it attempts crafting. TRANS returns either the longest suitable visit that may be crafted in the field (taking advantage of its ability to adjust exposure durations) or an indication of failure, meaning that even with the minimum exposure durations, the field was still too short for the visit.
One major problem with the crafting approach is performance. Crafting attempts to take advantage of late information - the structure of the primary calendar - in order to optimize efficiency for parallel SUs. The disadvantage is that this creates a real-time process. Adding parallels is only one small step in the larger process of building a calendar for a week's worth of HST science, and normally only a few hours are allotted for it. TRANS was designed as a batch process that does planning for an entire visit, and had never been run in a real-time environment before. Calls to TRANS are computationally expensive. In the POMS environment, a typical TRANS call takes anywhere from 10 seconds to several minutes, depending on the size and complexity of the visit. To cut down on the number of futile TRANS calls, POMS uses a heuristic which identifies cases where crafting is bound to fail and gives up immediately, but there are still several hundred TRANS calls in the course of crafting for a typical calendar. POMS provides an escape hatch whereby crafting can be terminated after a specified time limit, even if not yet complete. Performance considerations have limited the number of visits, especially long visits, that can be specified per parallel SI. There are plans to address this problem by partitioning the calendar and distributing the load among many machines.
POMS is written in Common Lisp using the Common Lisp Object System (CLOS). The main classes in POMS are as follows:
The algorithm POMS uses to craft parallels is as follows:
The redesigned POMS was installed for operational use at the start of 1998. Prior to this installation, old POMS had been used only for WFPC2 parallels and a set of operational tools based on static (rather than crafted) parallel SUs had been used for NICMOS and STIS. An analysis of parallel performance based on the first four months of operations showed an improvement in total parallel time of about 16%, attributable both to improvements in POMS and to operational improvements during this period. Working under very tight real-time constraints, POMS has crafted about 100 parallel SUs per week, including a substantial number of long SUs (three orbits or more), and is averaging about 48 hours of parallel alignment time per week over the three parallel-able SIs. (Analysis shows that this is still only about 43% of the total potential for parallel time, due to various inefficiencies in the system.) After a few startup glitches, operational performance of POMS has been reliable. An average of 5-10% of parallel SUs produced by POMS have failed to schedule, for reasons that are complex and rooted in the imperfect model of the scheduling system used by POMS and TRANS. Holding the run-time down has been a persistent challenge for the operators.
The main objective of the redesign, however, was not to improve performance but to support the new SIs and reduce maintenance costs. By these measures POMS has been an outstanding success. The integration with TRANS has enabled POMS to incorporate the complex overhead models with the newer SIs, and the formal proposal syntax has greatly reduced the effort needed to support new proposals. POMS no longer requires the support of a full-time developer. Nearly all SI-specific code has been removed from POMS, so that few if any changes will be necessary to support future SIs.