vObserver Loops

Using the "loop" concept as put forward earlier for the vObserver design, below are the 5 main loops of the system. Each runs separately but obviously they are inter-dependent.

Schedule Loop

The Nightly Planner creates lists of planned observations. These are stored in an Observation DB. From preliminary discussions with Marc White it seems that this will be an SQL database of some kind. This consists of possibly one table per night, but one giant table containing planned observations for all nights may be OK (the size of such a table including referenced tables is dominated by at most 4 double-precision numbers [coordinates, magnitude and colour] for 4 million targets, with about 2 attempts per target). The QA loop updates the status of observations in this database so that it can be determined which have been successfully observed in the past. The Scheduler uses the database to decide what observations will be performed on the current night. It creates an html output of the current schedule; this can be used for a quick confirmation that it is making sensible choices. Met data is used as an input to the Scheduler. It is shown as a database in the diagram, but it is TBD as to how this would be implemented. When the Observe loop is ready, the Scheduler feeds it the next observation. Depending on the structure of the Observation DB it may be sensible to have a flag to indicate that an observation has moved from being planned to being scheduled.

Note that there is no interactive control of the Scheduler in this design. If it is required then we need to consider how it would work.

"Nightly Planner" : extension of tiling code. "Scheduler" as a baseline just takes the next line from the Nightly planner.
vObserver Schedule Loop

Observe Loop

When the vObserver task is ready, it requests the next observation from the Scheduler. It is responsible for maintaining the status of the observation in the Observation DB. There will probably be states for the various stages of execution. Once the observation has been received, the vObserver task is responsible for coordinating the actions of the Telescope, Guider, Instrument, Starbugs, Calibration System, and Data Acquisition. A more formal timing diagram should be developed to describe exactly how an observation is executed. The vObserver task could be responsible for collating status from all the other subsystems, and storing it in a database (of unspecified format at this stage). Alternatively each of the tasks that interfaces with hardware could update the database themselves. This vObserver State database can be used to view a snapshot of the status of the system. It is also used by the Archive loop as the source of FITS headers.
The Observe loop is complete once the Data Acquisition task indicates that it has started reading out.
vObserver Observe Loop

Archive Loop

The Archive loop begins when the Data Acquisition task starts reading out. The data produced by this task (probably a FITS file on disk) is fed into the Archiver, which attaches relevant FITS headers to create a final FITS file for archiving. It is important to be clear about when the data for the FITS headers is collected from the vObserver State database. Typically this would be triggered at the start of an observation, but it may also be important to collect information at the end of the observation as well. The Archive is quite likely just a directory on disk, but it may be necessary to consider other options. The Archiver should update the observed_fields table in the Observation DB with the status of the observation once it has been archived. This table should have one row per field observed, should indicate if the field is FunnelWeb, TAIPAN (or potentially other types) and if the QA loop has been run on the field. The Archiver also generates a summary of its activities that can be viewed as a web page.


QA Loop

The QA loop could run as soon as an observation has been archived. Alternatively it could run during the day time. There is no need for it to run at the same speed at which observations are occurring, but it would be frustrating if it were so slow that it couldn't process a whole night of data during the following day. A set of appropriate calibration data is required - this could be configured manually, or it could be updated using calibration frames as they are taken. The aim of the QA loop is to update the observed_fields table in the Observation DB, flagging that QA has been done, then update separate TAIPAN/Funnelweb per-object tables with the status of each completed observation, indicating whether it has been successfully observed or whether it needs to be reobserved. Ideally, these tables sit within the ObservationDB. Note that the design of the tables for FunnelWeb and Taipan must be such that they can cope with repeated observations of the same target. A QA summary is generated so that the status of the QA loop and of each night's observing can quickly be determined.

For TAIPAN, the QA Loop contact is Dilyar Barat. For FunnelWeb this contact is Mike Ireland.
vObserver QA Loop

Status Loop

The Status loop provides a means for viewing the various databases within the system. A web interface has been chosen as the most easily accessible. There are many ways that this could be implemented, depending on the design and structure of the databases.
vObserver Status Loop