Re: Observational session control

[Stupendous Man <richmond@a188-l009.rit.edu>]

  Rob wrote:

> Indead, the BAIT looks interesting (snicker).  I poked around, but couldn't
> find any mention of source being available or not.  Do you know if/where we
> could get the BAIT/KAIT software?

        http://spiff.rit.edu/tass/bait/bait.tar.gz

  This contains most of the high-level software used on BAIT: not the 
code which talks to motors, but the code which does the scheduling
(listgen.c and associated files), reads/writes the request files
(pf_io.c and associated files), figures out when objects are visible
in the sky, etc.  

  It's not documented, unfortunately, and much of it hasn't been
compiled since 1992 or so, but it might be useful in limited ways.

> How's this for an outline:

  I'll give a brief description of the equivalent step in the
BAIT system.

> 1) A set of XML files is created somehow which contain the desired observing
> targets, both present and future

  A human being writes a short text file with 5-10 lines, describing
his targets.  He E-mails his file to the BAIT control system.

> 2) Using gnu make, these files (with 1 or more observing protocols per file)
> are "compiled" by a program which basically filters out stuff which cannot
> be observed for the night or isn't scheduled yet, and reduces the XML into
> either a XML subset, or a tabular format, or something else, which is the
> "object" file.

  The BAIT "accepter" program did a bit of this -- it mostly kept checked
for new E-mails, verified their syntax, and dropped them into a
directory with all the other requests.

> 3) The "object" files are then "linked", which actually accomplished the
> scheduling of the observations.
> 4) A real time process "executes" the resultant file, which contains what
> you indicated below, except I would add an expected time stamp to each
> expose image.

  The BAIT "listgen" program did these two steps.  It was able to 
figure out which requests should be ignored for the current night, 
ranked the remaining requests by priority, and scheduled them.

> 5) After the observing run, a cleanup is run which manages completed,
> ongoing and bad observations for the next night

  We used a set of CSH scripts, most of which called XVista programs.
One could substitute the Mark IV pipeline to do most of this.

> The reason I add the expected time stamp in 4, is that during scheduling, we
> need to estimate the time it takes to move from the current field to the
> next.  If we under estimate that time, we may run out of night to take
> pictures, or bump observations needed at a specific time.  If we over
> estimate, then we may be idle for a few seconds before taking the exposure.
> Would there be any need for this, or would that just be adding complexity
> needlessly? 

  My solution to this was to re-run the scheduler each time one 
observation finished.  It would figure out the very best thing to 
observe next, and also create a list of objects to be observed
subsequently.  A human could read that list and see when some
particular object was likely to be observed, or check to make
sure that a particular target WOULD be observed (and not ignored
for the night).  But the code would not necessarily stick to the
plan -- it would re-evaluate each time.

  Sounds complex, but actually simplifies things -- the code always
faces the same task.  It gets rid of this problem, too:

>  If you were off in your move estimates by 2 second per
>  observation, 360 seconds off by the end of the session.  Maybe not big
>  enough to worry about.

because it re-writes a schedule based upon the actual time
the last target finished -- not the time the last target was
EXPECTED to finish.  Plus, it allows one to insert new targets
during the middle of the night which can be observed immediately
(if they are given high priority).

                                          Michael Richmond