NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > DynamicSchedulingSummary
   Changes | Index | Search | Go

1. Summary of GBT Dynamic Scheduling Project

The goal of the Dynamic Scheduling Project is to increase the scheduling efficiency of the Green Bank Telescope (GBT) by allowing the telescope schedule to be optimally matched to both the current weather and the available instrumentation, while retaining observer control of each observation.

It is critical that Observers retain control of their observation in order to fully realize the scientific flexibility of the GBT. Therefore, the GBT's Dynamic Scheduling System will not run in a hands-off, queue observing mode but instead, once the telescope has been handed over to a given project, the Observer will have complete control over the GBT in the same manner as is currently done.

The deliverables of the Dynamic Scheduling Project include all of the tools necessary to make dynamic scheduling the GBT possible. While developing these deliverables, we will strive to keep ease of use high for observers, investigators, and support staff.

To use the GBT's dynamic scheduling system(DSS), an investigator first must break his/her observations into discrete sessions, each of which is defined by a unique set of data, such as LST range, weather, needed hardware, etc. These data will be supplied by the project investigators and, while the DSS may recommend default values for that data (e.g. given the desired frequency range and right ascension/declination the DSS could recommend a certain LST or weather values), the data entered for each session will be set be the investigators, observers, and proposal selection committee, and not by the DSS itself. (Note that these sessions may be associated with specific observing blocks, but that association is known by the investigator(s) only and is not taken into account by the DSS in any form.)

A number of weather queues (conceptually "excellent", "fair" and "poor") will be defined, and the potential sessions will be placed into the appropriate queue as defined by the requested weather criteria. Each session will be ranked in its specific queue on the basis of its associated data (e.g. is this session associated with a proposal that has already been started? what is its LST range?). At any time, the investigators will be able to see where their project sessions stand in the queue. Each project will have a web page associated with it, and any changes in the status of a session will be reflected in both the web page and via an email to the investigators. As an investigator's project sessions gets close to the top of the queue, the web page will be updated, and the investgators will be emailed to inform their project has a high probability of being run in the next few days. Note that one item which will strongly affect the project session's priority is whether an observer for the project is currently on-site, or has indicated that they will be available to observe remotely in the near future.

The Dynamic Scheduling System has the concept of a Telescope Period - a period of typically four hours during which the expectation is that a single observer will have control of the telescope. Telecope Period boundaries will be flexible, but generally chosen to match natural changes in observing capability - e.g. a Telescope Period might start at the end of a fixed maintenance day, and continue until late evening (when observing would typically switch to proposals which require benign night-time conditions). Approximately half an hour prior to the start of Telescope Period the Operator will run the DSS software. This will compare the short-term weather predictions, time, and hardware availability with the available sessions' data, and select subset of the highest-priority sessions in the relevant queue(s). The DSS will then display these candidate sessions in an easily readable form to the GBT Operator, who ultimately chooses the next Project session. Once that project is chosen, the operator will contact one of the project's ObservingContacts and inform him or her that his/her project will be running next and request that the observer begin preparations to run his/her observations. Once that project's Telescope Period is nearing completion, the operator will again consult the DSS in order to choose the next project/session. Note that in addition to listing the sessions which can be run based on the current weather, the DSS needs to be able to provide a look ahead probability to allow observers to know the probability of their sessions being run within the next few days/week(s).

In addition to the policies, algorithms, and scheduling software needed to select candidate sessions for observing, the DSS also needs to provide a suite of support software which will ease the use of the DSS for both observers and Green Bank staff. This suite of software is primarily geared toward satisfying all of the support operations that go with dynamic scheduling. Most importantly, this suite of software should engage the observer in the dynamic scheduling process and ensure that he/she knows what is happening with his or her project at any given moment. This software suite includes, but is not limited to: a means for an investigator/observer to know the probability of his/her project being run in the near future, a means of ready communication between the observer, operator, scheduling software, and investigator regarding ongoing, future, and past observations, and easy means for observers to change their contact information and availability.

Topic DynamicSchedulingSummary . { Edit | Attach | Ref-By | Printable | Diffs | r1.11 | > | r1.10 | > | r1.9 | More }
Revision r1.11 - 01 May 2007 - 21:27 GMT - KarenONeil Content copyright © 1999-2007 by the contributing authors.
All material on this collaboration platform is the property of the contributing authors.