Overview

26/05/09 (esaunders): This page is DEPRECATED. Please refer to the Mediawiki page here for current information on this project.

 

 

Name

Adaptive Scheduler.

Team members

Eric Saunders (lead), Martin Norbury .

Synopsis

The Adaptive Scheduler reads a night's worth of observations from the Database when instructed to by the Monthly Planner. It determines a schedule for the current night taking into account site status, and dispatches observing lists to each site. When expected variations such as telescope downtime, ToOs or reactive 'this night' observations occur, the schedule is recomputed and redispatched. As observations are completed, it propagates this information back to the Database.

Input

• A set of observations to be considered for scheduling.
• A trigger to check the database for observations added by the Monthly Planner, a ToO request, or a 'this night' observation.
• Feedback from Site Agent regarding success or failure of observations.
• Config DB data - Information about what is available at each site/instrument.

Output

• Observing lists for each site.
• Updated status for observations as they are completed sent back to the Database.

Use Cases

There are three principal use cases, illustrated in the diagram below. The architecture is explicitly designed to handle all of these cases similarly.

1. The Monthly Planner would like some observations to be performed. It places those observations (henceforth known as The New Plan) into the Database, and pings the AS to go and get them. The AS takes The New Plan from the Database, and calculates a schedule based on the current site conditions. This schedule is broken up and dispatched to each site. The sites perform the observations, and let the AS know as they are done.
2. A ToO observer would like a ToO to be performed. They submit the ToO via the Observatory Portal, which adds the ToO to the Database, and pings the AS to go and get it. The AS takes The New Plan from the Database, and calculates a schedule based on the current site conditions. Naturally, the ToO falls at the top of one of the site queues within the schedule. This schedule is broken up and dispatched to each site. The sites perform the observations, and let the AS know as they are done.
3. An observer submits a 'this night' observation, defined as an observation that is dynamically allocated. Examples are reactive eSTAR-like observations, or users with flexible requests (for example, an unexpected engineering session). The observation is submitted via the Observatory Portal, which adds the observation to the Database, and pings the AS to go and get it. The AS takes The New Plan from the Database, and calculates a schedule based on the current site conditions. The 'this night' observation might or might not be considered important enough to be added to the schedule. The schedule is broken up and dispatched to each site. The sites perform the observations, and let the AS know as they are done.

Authors: Eric Saunders , Martin Norbury

Date: 28 January 2009

Overview diagram

Authors: Eric Saunders , Martin Norbury

Date: 28 January 2009

Assumptions

The model explicitly assumes:

• ToOs may be submitted via the Database, i.e. the same path as all other observations. This implies the latency for this process is acceptable.
• The existence of a site agent for direct communication with the NetworkMonitor. If site information was being fed back to a database, the arrows to site would point to that database instead.
• The AdaptiveSchedulerKernel is located on the same CPU as the UpdateManager. If this is not the case, then the functional calls should be modified to reflect a remote message passing scheme.
• The telescopes are very simple sequencers, incapable of performing local optimisations.
• ToO and other users receive feedback from a monitor process attached to the database. Unlike an HTN-type system, we therefore do not reply directly, and this isn't our problem.

Questions

1. If telescopes are very simple, then they can't do local optimisations such as slew time or filter change time minimisation (they simply pop the next target off the queue). But if they are allowed to optimise, they not only become more complex, they could make decisions that would be detrimental to the overall plan of the Adaptive Scheduler. Not sure what the best answer is here.
2. We expect that the Adaptive Scheduler only requires a small subset of the total scheduling information available to the Monthly Planner. This needs to be defined, although we are not dependent on it to proceed with infrastructure.
3. The AdaptiveSchedulerKernel is a black box, and has not been defined here. It therefore represents an unknown risk.
4. What network availability should the adaptive scheduler be designed to? An adaptive scheduler could send smaller observation queues to telescopes if we are designing to a high-availability network, whereas larger queues would be required if we wanted to plan for periods of network outage (MN). There are two numbers we can use to measure network uptime: average uptime, and maximum single-event downtime. These numbers need to be estimated. It simply isn't productive to talk about huge architecture changes to protect ourselves from enormous network outages that may happen so rarely they aren't an issue (ES).