[evla-sw-discuss] Scheduling system project manager

[Barry Clark]

The scheduling system consists of three main parts.  First is the Scheduler, 
which makes the just-in-time decision about what observe file to run on the 
array.  The second is the Project Manager, which maintains a larger view of 
the work queue than just scheduling blocks.  It interacts with the Scheduler 
by adjusting priorities associated with the scheduling blocks.  The third 
is the system of ancilliary programs that create and manipulate scheduling
blocks and projects.  We currently have a Scheduler, which works, though 
it really needs a little tweaking.  We have programs that create scheduling
blocks from observe files (again needing just a little tweaking).  I am 
now about to address the Project Manager.  We will likely need a fourth 
major piece, in effect a simulator, which runs the Scheduler and Project
Manager with reasonable weather guesses to be able to answer an observer
when he asks "When is my project likely to be run?"  But this, fourth, piece
can wait a while.

I describe below the design I have in mind for the Project Manager, in terms
of its input parameters (which will be read from a file in case somebody
wants to muck with them, and the types of projects I am contemplating 
supporting.

Project manager parameters:

Parameter relating length to priority
Incremental priority for observing at the right time
Incremental priority for multiconfiguration projects
Relative priority of observing bands
Most difficult LST
When to redo things if there's nothing better to do

A 'project' is defined by the following SQL.

create table project (
    proposal varchar2(12) not null,
    project  varchar2(4)  not null,
    type     varchar2(20),
    aparm    float,
    bparm    float,
    cparm    float,
    dparm    float);

Project types I propose to support are given below, along with the
meaning of the aparm, etc. for that type.

SIMPLE

MONITOR
aparm is the desired interval in days

PERIODIC
aparm is the Local sideral day of one epoch of the desired phase of the phenom
bparm is the period in sidereal days
cparm is how close to the desired phase you must be

TIMELY
aparm is the earliest possible Local Sidereal Day
bparm is the latest possible Local Sidereal Day

LARGE
aparm governs spacing so that it doen't swamp the LST
bparm governs willingness to chance not finishing

ADJUST
(priority decreases as observing time is accumulated)
aparm is number of accumulated hours to decrease priority by one unit

MULTICONFIG
aparm, bparm, cparm, dparm are the times needed in A, B, C, D configurations