Re: ALMA Science Software Requirements - an alternate spin

[Steve Scott <scott@ovro.caltech.edu>]

Barry's email two weeks ago courageously ventured into the area of specifics 
for the operational plan. On the topic of "Scheduling tools - detailed 
scheduling" (Barry's item #5), I'd like to present a different viewpoint for 
consideration. 

A sequential flow of commands to the various parts of the system is the final 
atomic view of the scheduling of the telescope. However, at the macroscopic 
end of the instrument (the scientist), the observations are represented by an 
observing block, perhaps broken into Barry's chunks, containing instrument 
setup, constraints, flow control and looping, and finally collection of data. 
The block is best represented as a hierarchical collection of blocks and 
primitives, and sequences of blocks and primitives, with some of the 
contained elements reused in different parts of the tree. An observing 
preparation tool can be used to graphically create the observations, but it 
need not stop there. This observation block, and its graphical 
representation, can move through the system as it was conceived, without 
conversion to scripting. The scheduling of the instrument is just a sequence 
of blocks, or continuing the metaphor, it a sequence of blocks inside the 
master block, with a realtime pointer descending the hierarchy into the 
current block pointing at the executing primitive. The "treeview" model, with 
the expansion/hiding of detail common to many file viewers provides the 
interface for the scientist, the scheduler, and the operator. The realtime 
program and a simulator may be the same except for handling of the primitives 
and how fast to run the clock.

There are several advantages to the above approach:
o Defining and reusing blocks throughout an observation increases 
  the level of abstraction, allowing complex programs to be 
  constructed more easily.
o One set of tools can be used from preparation to running the 
  instrument. This should include viewing the log or history of
  what has been done with the instrument. Note the utility of the
  hierarchical approach for this particular task.
o Reduce cut and paste errors common to scripting.
  
This scheme is more than just a visit to the object versus procedural debate. 
It represents how we actually use instruments today, blocks defined (perhaps 
as functions or macros), inside of other blocks, executed in sequence with 
flow control constructs. An advantage to using "blocks" over straight 
scripting is that all blocks and primitives have properties (imagine a right 
click) that are always present and defined, albeit usually with default 
values. And this is where having objects and inspection methods pays off, by 
eliminating hidden assumptions that are difficult to see in a script.

The Gemini folks have taken these ideas quite a bit farther and have an 
implementation called the Observing Tool that looks very promising. I think 
ALMA should investigate this unified approach to the scheduling of the 
instrument.

Cheers,
Steve