Scheduler Concepts

Observing Request Structure
Observing Run (Night) Time Line
Dispatcher Modes
Weather Interrupts

ACP Scheduler is a dispatch scheduler. It does not plan out the entire night. Instead, it looks for the "best" Observation to make, sends it to the sequencer (ACP), waits for the image(s) to be acquired, then repeats this over and over throughout the night. The details of the Schedule Cycle will give you additional insight into its decision making.

The keys to ACP Scheduler's success are (a) its definition of "best", and (b) its ability to automatically reschedule observations that failed. For an in-depth description of the Scheduler and its theory of operation, see the paper Dispatch Scheduling of Automated Telescopes (PDF).

ACP Scheduler uses a relational database to hold your observing requests. Once entered, request data remains permanently until you remove it.

It may not be clear from the Scheduler paper that multiple Plans may be running in parallel. This is critical to the success of the Scheduler. Plans with multiple Linked Observations can have those Observations interleaved, with single Observation Plans running in any time gaps available.

Observing Request Structure

Observing requests are organized hierarchically as follows:

Observer

Multiple Observers are supported. Each observer gets to use their own priority levels. Observer information is embedded into all image FITS headers by ACP.

Project

A Project is used to represent an entire observing project, which may consist of data to be gathered over multiple nights. The time span of a Project can be days, weeks, months, or even years. Projects belong to Observers.

Plan

The Plan is the schedulable unit of ACP scheduler. A plan must complete in a single night. Each plan has its own priority level. A Project can consist of multiple Plans, each of which can (if needed) run on different nights. A Plan can be forced to run within a given time span. If any Observation in a Plan fails, the entire Plan fails (since it must run as a unit in one night). A failed Plan can be automatically rescheduled to run again in the same or another night. Plans belong to Projects.

Observation

An Observation specifies a target and constraints. Images for the Observation's target will be acquired only if all of the constraints are met. A Plan will be started only if its first Observation's constraints are met, along with other considerations (see the Schedule Cycle page).

Multiple Observations (spaced apart in time and for different coordinates) may be specified for a Plan, creating linked observations. A Plan will be started only if all of its linked observations can be done without clashing with those of already-running Plans. Observations belong to Plans.

ImageSet

An ImageSet specifies one or more images to be acquired through a given filter and for a given exposure interval and binning. If the repeat count is greater than one, it is possible to specify that the individual images be stacked to form one composite image. ImageSets belong to Observations.

Observing Run (Night) TimeLine

Scheduler is designed to be left running 24/7, with ACP also left running 24/7 (ACP provides web access and the engine for running scripts). Beginning with late afternoon, assuming good weather, here is the time line that Scheduler uses:

  1. Some time before astronomical sunset (configurable, 90 minutes default): Run the StartupObs script if available. If the user adds the needed custom code, this will power up the observatory. In any case, it will start the needed support software (MaxIm, FocusMax, TCS software, etc.) and connect to the telescope camera, focuser, rotator, etc.
  2. If dusk flats are requested, they will be started in ACP when the Sun reaches 0° altitude. If ACP is configured for sky flats, the ACP AutoFlat script will then wait until the sky brightness is "right" then run the SchedulerDuskFlats flat plan. The starting time is configurable in ACP (AutoFlatConfig file). With ACP configured for panel/screen flats, the flat acquisition process will be started without delay.
  3. At astronomical twilight (configurable in Scheduler), observing will begin and will continue until astronomical twilight at dawn. If the option Close-If-Idle is set to a number greater than zero, the dome/roof will be closed if it appears that there will be no eligible Plans to be started and there are no running plans.
  4. If dawn flats are requested, they will be started in ACP immediately after observing ends. If ACP is configured for sky flats, the ACP AutoFlat script will then wait until the sky brightness is "right" then run the SchedulerDawnFlats flat plan. The starting time is configurable in ACP (AutoFlatConfig file). With ACP configured for panel/screen flats, the flat acquisition process will be started without delay.
  5. If dawn calibration frames are requested, they will be started in ACP, using the DawnCalFrames.txt observing plan, which can start with #domeclose if desired.
  6. Finally, run the ShutdownObs script if available. If the user adds the needed custom code, this will power down the observatory. In any case, it will disconnect the telescope camera, focuser, rotator, etc., then shut down unneeded software (MaxIm, FocusMax, TCS software, etc.), leaving only ACP and Scheduler running, ready for the next night (back to step 1).

Dispatcher Modes

On the scheduler main window is a control to select between three modes.

Weather Interrupts

Scheduler watches the "weather safe" output from ACP. The dispatcher will not start any new Observations if the weather is unsafe. If an Observation is currently running, ACP will detect a weather-unsafe condition and immediately stop observing. Whether or not an Observation is currently running, ACP will then safe the observatory as set up in ACP. Scheduler assumes that ACP has done this and does nothing more. The scheduler will sleep until the weather becomes safe.

When the weather becomes safe again, Scheduler runs the StartupObs script, then opens the dome or roof (if present). Thus, this script must run successfully even if the power is already on for the mount, camera, etc. and the various programs (MaxIm, FocusMax, etc.) are already running. After this, the dispatcher resumes its normal activities. As usual, the observations that are run are the "best" for the time (see Schedule Cycle).

TipScheduler requires weather from ACP to remain safe for an uninterrupted 10 minutes before deciding that the weather is indeed safe and taking action. This is an absolute requirement for Scheduler. Any ACP weather server must absolutely provide for a minimum of 10 minutes of weather unsafe time! You can add to this time delay in the Scheduler configuration settings for the ACP Sequencer. It is called Weather Latch Time. Any latch time you configure in Scheduler adds to that provided (and required) in ACP. To disable the latch in Scheduler, set the weather latch time to 0.