NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Dynamic > DynamicSchedulingOverview

Changes | Index | Search | Go

2. Overview

2.1. Abstract

This document describes a proposed long-term vision to dynamically schedule and execute science projects on the GBT, which improves upon the manual dynamic scheduling approach which has been used to schedule GBT projects in the past.

2.2. Introduction

The GBT spans a larger range of frequencies than other comparable millimeter/sub-millimeter single-dish telescopes, and is located in a continental, mid-latitude region where weather is dominated by water vapor and small-scale effects. As a result, weather suitable for executing high-frequency observations is at a premium.

In 2006 and in previous years, the GBT has employed a very simple form of dynamic scheduling in which two projects, one high frequency and one low frequency, are scheduled together in two sessions (spaced typically by two days). The high frequency observer is allowed to choose which of the sessions they would like to use. The second is used by the low frequency observer. This scheme often results in high frequency observers receiving little or no time if they wait for truly high frequency weather, which compromises the ability to discharge these projects, and also delays completion of low frequency projects if high frequency observers choose substandard conditions to execute their observations.

An improved scheme for dynamically scheduling science on the GBT is required to make the most efficient use of telescope time which is in high demand, and to define the foundations for the use and customization of new and existing software systems to enable these processes as effectively as possible. The following sections present concepts only, and assume that all software and systems will be in place to support the desired processes when improved dynamic scheduling is launched.

2.2.1. Goals

• Optimize use of high-frequency weather, maximizing the probability that high-frequency observations will be performed under good weather.
• Enable timely completion of projects.
• Achieve efficient fixed scheduling of crucial maintenance activities, VLBI/bi-static radar (or other observations that require coordination with other facilities), and monitoring projects.
• Increase the efficiency of telescope scheduling through ensuring that Sessions are scheduled with a minimum amount of down time (e.g. to ensure Sessions are not given telescope time before their desired LST).

Furthermore, by requiring that all investigators have previously defined their desired Sessions, which includes not only the LST range and weather criteria which is desired but also the basic hardware, we will be able to prevent observations from going on the telescope when they can not be executed by the control system as needed (for example, if a needed receiver is down for maintenance). Finally, we will be able to capitalize on dynamic scheduling to readily avoid situations in which time is currently occasionally lost on the GBT, such as when RFI is present in the desired band, preventing successful observations of a given Session.

Additionally, while the Dynamic Scheduling Software (DSS) as currently envisioned will not interact with an investigator's Observing Blocks (OBs), we do strongly encourage the advance preparation of OBs to both minimize time-to-startup at the beginning of an observation and eliminate preventable configuration and syntax errors.

2.2.2. Overarching Requirements

1. Project scheduling data must be prepared in advance. A limited subset of the project scheduling data can be modified in real time as observations proceed.
2. The observer will be able to observe interactively - following the progress of an observation's execution in real-time, subjectively evaluating the data, and making changes to subsequent Observing Blocks in response.
3. The observer retains control of his/her scheduled telescope time, meaning that he/she can observe interactively or non-interactively (queuing a list of OBs to be run), and if interactively, can choose to continue to observe at high frequency in less than ideal weather for some time if he/she wishes.
4. Observers must be able to get feedback about the execution state of their science program (in terms of percentage complete), how their observations fit into the schedule, and the execution state of individual Sessions within their projects
5. The scheduling strategies and processes should not negatively impact data quality. That is, data quality shall be at least comparable to what might be expected from a classically scheduled approach.
6. Process for scheduling and observation execution should not place an undue burden on support staff, for example, requiring them to be present to actively configure or perform detailed data quality assessments. The project investigators are always responsible for the data quality of the project.
7. Process for scheduling should readily accommodate GBT maintenance and repair activities.

A more detailed list of project requirements can be found at the Astronomy Requirements Page.

2.3. Key Terms

All terms associated with the Dynamic Scheduling System (DSS) are defined in the Dynamic Scheduling Glossary. Here we give a few of the key definitions needed to understand the DSS. More complete definitions and examples of these words can also be found in the Dynamic Scheduling Glossary.

2.3.1. Dynamic Scheduling System (DSS)

2.3.2. Fixed Session

2.3.3. Observation

2.3.4. Observing block

2.3.5. Project

2.3.6. Proposal Submission Tool (PST)

2.3.7. Scheduler

2.3.8. Segment

2.3.9. Session

2.3.10. Telescope Period

2.3.11. Windowed Session

• Monitor Project: a water maser observation where they must observe sometime during the first week of every month. So a fixed window is assigned for 1-7 Jan 2007. They can observe on any of these days between the hours of 8-12 when their source is visible. If they are not scheduled on days 1-6 then the fixed window converts to a fixed time for 7 Jan.
• Maintenance Day: an 8 hour maintenance day, 8 AM to 4 PM, must occur between Monday and Wed. for a given week. If this activity has not been scheduled by Tuesday, then it becomes a Fixed Time for Wed.
• PF Receiver Change: this activity must take place between 8 AM and 6 PM on a given day, and will take at least 2 hours to successfully complete. If this activity has not started by at least 4 PM, it becomes a Fixed Time for 4 - 6 PM.

2.4. Remote Observing

The DSS will rely heavily on remote observing for the system to work. We do not, however, wish to change the current GBT policies on remote observing, one of which is that the observer must have experience with observing on the GBT. At the same time, we do not wish to unduly punish observers whom have difficulty coming to Green Bank to observe. With this in mind, we will do the following:

• Flag any observers whom are not approved for remote observing. These observers names will not come up in the DSS as candidates for observing. As a result it is important to note that any project whose available observers are non-approved will not show up in the DSS list of possible observing projects unless an observer is on site. The telescope Scheduler will be responsible for adding and removing these flags.
• We will have a good observing simulator available for observers. In the cases where an observer comes to Green Bank and is unable to observe during the time he or she is on site (due to e.g. weather), the observer will be able to use the simulator to get approved for remote GBT observing.
• We strongly encourage the existence of GBT Observing Workshops that would be held on site and result in all participants becoming approved for GBT observing.

2.5. Weather Conditions

Weather must be appropriately defined for three purposes:

1. to associate an Session with optimal weather conditions under which it should be observed,
2. to be able to identify which Sessions are executable given current and projected weather conditions, and
3. to provide the GBT Proposal Selection Committee with enough information to allow them to fill but not overburden the GBT observing queues.

The weather definitions for the GBT Dynamic Scheduling Software (DSS) are being defined and will be explained in the WeatherQueue pages. For more current information, see the Memos on Scientific Requirements and Stringency.

2.6. Science Grades - The Working Hypothesis

2.7. RFI

2.8. Dynamic Scheduling Processes

2.8.1. Project Submission

The first step in GBT observing is to read the GBT proposal guide to determine the suitability of the GBT for the project in mind. Provided the GBT is a suitable telescope for a given project, the investigators need to determine the hardware needed for their project, as well as the weather restrictions, observing techniques, and total time needed for successful completion of their project.

Once the basic proposal information is determined, and the scientific justification is complete, the investigators will fill out the required information into NRAO's Proposal Submission Tool (PST). When the proposal is complete, it should be submitted for review. At this point, in addition to providing all the information needed for the referees and Proposal Selection Committee to determine the proposal's suitability to the GBT, much of the information from the PST will also be automatically used to fill out preliminary information in the Dynamic Scheduling Software (DSS) database. Note that as much of the information submitted at this time will be used by the GBT proposal referees and the proposal selection committee to determine the total amount of time rewarded to the proposal, much of the information submitted through the PSC will not be changeable by the project investigators. The exceptions to this rule include user availability and contact information, observing contacts, minimum and maximum session times, and session priority. If a field needs to be changed at a later date, the telescope scheduler can be contacted an a request to make this change can be made.

2.8.2. Time Allocation

After the proposal deadline is complete, all proposals will be sent to GBT referees, in the same manner as is currently done. Once the refereed proposals are returned, as well as any technical assessments necessary are done, the GBT Proposal Selection Committee (PSC) will meet. Before its meeting the Telescope Scheduler will know how much GBT time will be available for science in the context of the required Weather and LST range. The PSC and Scheduler will then sort the proposals into bins, based on the basic idea of the total percent of GBT time available to each bin. The exact bins used are up to the discretion of NRAO Scientific Policy, the PSC, and the Telescope Scheduler. Once binned, the PSC/Scheduler will categorize proposals in the manner defined by GBT policy. The results of the referee and PSC process will then be sent to the investigators. If the results of the PSC meeting include a change in any of the data for the proposed project (total number of allocated hours, required weather, etc) those changes will now be made to the projects data by the telescope scheduler. In addition, the project ranking will be put into the Dynamic Scheduling Software (DSS)? database.

2.8.3. Observation Preparation

Having been informed that their proposal has been accepted by the PSC, the investigators now need to fill out all information in the project database which was either not filled in by the PST or which has changed as a result of the PSC decision. All changes made to the database, as with all other changes to the project information, will generate an automatic e-mail to both all investigators which choose to remain informed about the project status (the project PI cannot opt out of receiving this information) as well as the GBT Project Friend.

Either at proposal creation time, or at this point, the investigators will break their proposal into one or more Sessions.

At this point the investigators should now also write the Observing Blocks (OBs) needed for their observations, and inform their Project Friend that the OBs are complete and should be reviewed. (Note that the Dynamic Scheduling Software (DSS) will not examine the OBs in any way, nor will it make any checks to see if the Project Friend has approved the OBs.)

Once a week, or as appropriate (the timescale is still TBD during the testing process) a program will be run which will determine if any accepted projects for the current semester lack the needed information within the DSS database to be observed. If a project or Session is lacking information an e-mail will be automatically sent out to all interested investigators as well as the Project Friend informing them that the project/session will not be considered for scheduling until that data is in place. This process should start approximately two weeks before the actual semester, to ensure sufficient projects are available for scheduling during the semester.

2.8.4. Dynamic Selection in Advance of Run-Time

Each time the Dynamic Scheduling Software (DSS) is run to determine the next project (no less than every eight hours), the DSS needs to determine the probabilities for a given project/Session to be run. As creating schedules may prove to be impractical even 24 hours in advance, due to the unpredictability of Green Bank weather (although this concept is being further explored at the moment), the DSS will simply rank the Sessions within each weather category as an aid to predicting when a project will be run. (Here a weather category is simply a useful grouping of different weather criteria, e.g. “wind < 5 kms” . The categorization is used only as an aid to predicting the next sessions and will not result in a change in the requested weather criteria of a project.) In this way, an observer will readily be able to see both how many sessions (and their length) have a higher priority of observing within her weather category and LST range, and also how many projects from other, neighboring weather categories may be run.

If a project's observing status (probability) changes due to the running of the DSS (e.g. observing or priority has changed), that change will be automatically reflected on the project's webpage, a page which provides or provides links to, all pertinent information for a given project and its sessions (and within a DSS database). As with all changes to the project web page, this change will generate an automatic e-mail to the interested investigators and to the Project Friend, informing them that there has been a schedule change and they should examine the project web pages to determine what the change is. It should also remind the investigators to update their contact information if it looks likely their project will be observed. The caveat is that the DSS should not overburden the investigators with e-mails due to small tweaks in the Session priorities. The exact mechanism for determining when an investigator/observer receives e-mail from the DSS will be determined through planned tests of the DSS.

Note that the investigators will have full access to the predicted Green Bank weather and can use that to help determine the probability of their project being scheduled on the GBT.

2.8.5. Dynamic Selection at Run-Time

30 minutes before the end of a given Telescope Period (TP), the operators will query the Dynamic Scheduling Software (DSS) to determine what the next Session should be. The basic rules which the DSS will follow are described completely in the Selection Rules, but are summarized here. First, all sessions are examined to see what can be run based off the current time (LST/UT), available hardware, observer availability (if no observer is available, a project cannot run), and to insure there is still allocated time left for the project/session. After this, the DSS looks to see if there are any fixed time or window projects which must be run at this time. If there are, then the fixed time or window project is run. If not, the weather and time of day (LST/UT) are examined to eliminate all sessions for which the weather is not good enough for the session to be run, and which the current time is inappropriate. Once these elimination rules are applied, the remaining sessions are ranked based on a number of criteria (the most important of which are the needed weather and the observer being on site versus observing remotely). The telescope operator is then presented with a ranked list of sessions from which to choose the next project/session to be observed.

Once an Session is chosen, the operator will call the contact person(s) for that Session (listed in the recently updated project/Session contact information) to inform the observer that the Session is in the queue. If the contact person(s) cannot be reached, a new Session will be chosen

Note that if an Session is rejected from the queue at this point due to a problem with the DSS data, the investigators and Project Friend will be notified of the problem.

The Dynamic Selection algorithm will follow the rules laid out in SelectionRules page.

2.8.6. Observation Execution

Once the Telescope Period (TP) begins for a project, the observer will begin the project session segment. The TP will then run until either (1) the observer deems the weather or RFI environment too poor to continue and concedes her time, (2) the TP ends. Once started, a TP will be not be interrupted by GBT staff, except for an equipment fault, weather stow condition, or in the rare case the observer wishes to continue observing but the weather has turned too poor for any science to be obtained from the observations. Once the TP is over, the operator will be asked by the Dynamic Scheduling Software (DSS) if the time was "successful". The operator, in consultation with the observer, will answer this and, if it is affirmative, the time will be deducted from the Session & project. If the operator responds negatively, he/she will have to record the reasons why the time was unsuccessful. In this case, the Telescope Scheduler will have to decide (at a later time) whether to mark the time as time lost or to bill it to the Session and project. Note, too, that if a TP was marked as successful but later the data was found to be inadequate, the project investigator(s) can contact the telescope scheduler and request that time not be billed to the project.