Queue Scheduling Program with CFH12k:
Outline of the Scheduling Software



Pierre Martin, Dennis Crabtree
March 1999

Introduction

The scheduling software (i.e. scheduler) is an integral part of the queue scheduling/service observing mode. Basically, its function is to provide a prioritized list for the observers according to a set of rules and the actual sky conditions. This program can work at many levels. It can only sort out programs from the database or delivers instead a very specific list for an observing period during a night. Ideally, the scheduler could also send the commands directly to 12k.com and TCSIV to execute the observations.

In the following, we only give a very brief outline on the selection criteria and algorithm that will be used to provide a list of prioritized programs to create the queue. There is no attempt here to describe the weight given to each criterion in the selection algorithm. What is described in this document is more for the ``beta'' version of the scheduler but represents the basis of the fully performant scheduler which will be tested with simulations. There is no doubt that the final version of the scheduler could be quite sophisticated if we want to take all the parameters into account. However, at the moment, a tool with the functionality dexribed below will already be very powerful.

Some Nomenclature. A program consists in a series of astronomical observations. Each program has been allocated a certain number of hours on the sky (integration time), has received a grade and a relative ranking from the Telescope Allocation Committee (TAC,), and is identified by an unique identification number. Each program is defined as a series of one or several observing blocks. An observing block, the smaller unit includes the intrumental configuration, target position, exposure time, priority, etc. The final queue of observations to be done is a prioritized list of observing blocks but the selection process is done from the requirements and specifications coming from both, the programs and the blocks.

A - Selection Algorithm

We propose that the creation of an observation queue should be done in three distinct steps:

1.

The selection of programs and observing blocks available in the queue according to instrumental constraints, sky conditions, position of objects, etc.

2.

The ordering of the programs and observing blocks following the TAC grades and ranks, priority given by observers, etc.

3.

The human filtering done by the observer after reviewing special conditions required by some programs. Outlines of these three processes are given below.

1) Selection

In this first step, the scheduler look through the entire database and select all the programs and observing blocks that could be executed during a given night according to these conditions (given in order):

1.

Filter. Only four filters can be mounted in the CFH12k filter wheel. At the moment, we assume that no filter changes will be allowed for a giving night in order to avoid flat-fielding effects and keep the observing efficiency as high as possible. The filters to be mounted will be selected by the queue coordinator after evaluating the programs in the database. After this selection, the scheduler selects all observing blocks that can be executed with the available filters. The list of the available filters is: B, V, R, I, Ha-on, Ha-off, TiO, Z', CN

2.

Sideral Time. The second parameter evaluated is the position of the objects of all the observing blocks in the database with respect to the sideral time (ST) at midnight (to design a queue for a given night) or the actual sideral time (during observing night). Selection should be done for a band of ST (e.g. 6:00 to 8:00)

3.

Image Quality. First, an image quality (IQ) value (or expected value) is entered as a parameter for the selection process and all the previous blocks are sorted out according to their requirements. Bands of IQ as defined in the R-band are as followed: IQ $\leq$ 0.55'', 0.55'' < IQ $\leq$ 0.65''; 0.65'' < IQ $\leq$ 0.80''; 0.80'' < IQ $\leq$ 1.0''; 1.0'' < IQ $\leq$ 1.2''; IQ > 1.2''; IQ = all

4.

Sky Brightness. The actual sky brigthness (or the expected value) is given in the scheduler algorithm and all the previous blocks are sorted out according to their requirements. As with the IQ, the sky brigthness will be defined wihtin specific bands but these bands have not been defined yet.

5.

Completeness. This allows the observers to sort out the programs according to their degree of completion (DC). The completeness is defined as the fraction of the integration time used to the integration time allocated by the TAC. The bands available to the observers as an entry field parameter in the scheduler would be: DC = 0%, 0% < DC $\leq$ 30% ; 30% < DC $\leq$ 60%; 60% < DC $\leq$ 90%; 90% < DC $\leq$ 100%; DC = all.

6.

Solar Ephemerids. This parameter basically sort out all observing blocks that can be executed in the time remaining for astronomical observations before sunrise. This parameter is entered by the observer (e.g. 45 minutes) and all the observing blocks that have a total integration time smaller than this field are selected. This constraint should not be applied if not required by the observer (in other owrds, we should be able to sort out the programs without this constraint.)

7.

Moon Ephemerids. This parameter sorts out all the observing blocks that can be executed in the time remaining before Monn rise (i.e. when the sky brightness will change significantly). This is entered by the observer and all observing blocks requiring the lowest sky brightness are selected if they can be executed in a total time smaller than this value. This constraint should not be applied if not required by the observer (for example in case of full dark nights).

2) Ordering

The second process produces a prioritized list according to these criteria:

1.

TAC Grade. TAC will classified all the proposals according to four specific classes, noted A,B,C,D, which means ``must do'', ``priority'', ``best effort'', ``rejected''. All the observing blocks previously selected will now be ordered according to the TAC grade given to their respective program in three lists according to these classes (calls D proposals are not included in the queue database).

2.

TAC Rank. All proposals in Class A have the same priority. However, programs of Classes B and C have an absolute ranking given by the QS/SO team according to their relative ranking in their own class. The observing blocks listed in class B and C are then ordered according to the respective ranking for the program for which they belong.

3.

Target Position. All the observation blocks inside a specific program are sorted out according to the position of the targets (from smaller RA to larger RA. For similar RA values (that is, smaller than 1hr, the blocks are ordered according to the DEC position, smaller values listed first).

4.

Priority. Finally, all the observing blocks inside a given program have received a priority from the investigators. The blocks (or those remaining if the program has been started) are ordered according to these priorities for a band of target positions.)

3) Human Filtering

The queue list prepared with the above selection and ordering algorithms will be constantly reviewed by the coordinator and the observer. However, it is sometimes very difficult to order a set of programs or observing blocks with, for example, specific time constraints. The observer will be able to manipulate the prioritzed list so that these programs can be scheduled according to their requirements.