Configuration History & MOOT

Database Considerations

The GLASTOPS_ACQSUMMARY table in the ISOC_FLIGHT database (see this description for details) is a superset of information of interest to MOOT clients. Possibilities are

1. Move the entire table out of ISOC_FLIGHT and into MOOD
2. Invent a new table in MOOD containing just the items of interest. It would be updated immediately following the update of GLASTOPS_ACQSUMMARY.

The only reason to prefer 1. would be if there were danger of the duplicated information getting irremediably out of sync, but that is not a concern in this case, so we (Bryson and Joanne) intend to implement 2. The new Acq_summary table in MOOD will have approximately the following structure:

* may change after initial insert of row

A separate table, Acq_mode, will be needed to log filter configurations for runs of type LPA since these can vary on a per-mode basis (mode in this context is one of normal acquisition, TOO or ARR). Certain additional configuration keys, including at a minimum the one for GRB algorithm configuration, will also be kept here, regardless of whether they ever vary on a per-mode basis.

Might also add some of the usual boilerplate columns, such as creation_time and uid. There is no need to include update_time since rows in this table should never be modified after the initial insert.

There will be a uniqueness requirement on the triple (acq_summary_fk, mode, fmx_file_key)

Access

Routine to write to the tables.

updateAcqSummary will insert or update a row in the main table and optionally add rows to the Acq_mode table. Same routine can be used for both insert and update since startedAt and scid values will be among the input arguments).

and will cause both tables to be modified as appropriate. Call interface could be something like

unsigned updateAcqSummary(unsigned long startedAt, /* seconds from mission start */
                          unsigned long scid, /* source id */
                          unsigned long configKey, /* Refers to presumed MOOT config for this acq */
                          const std::string& acqType,  /* enum */
                          const std::string& analysis,
                          double evtutc0, /* ts of 1st evt decoded so far; secs since 1/1/1970 */
                          double evtutc1, /* ts of last evt decoded so far; secs since 1/1/1970 */
                          unsigned long nEvt, /* #events decoded so far for this acq */
                          unsigned long hwKey, /* LATC master key */
                          unsigned long swKey, /* LCI script or SBS key */
                          const std::string& mode, /* normal acq, TOO or ARR */
                          const std::vector<unsigned long>& moreKeys) /* other fmx log. keys */

where returned value is a code for status of the update.

Routine or routines to check consistency

bool MootQuery::consistentKeys(unsigned long configKey, const std::vector<unsigned long>& logicalKeys)

Return true if all the logical keys "belong" to the specified config; else false.

unsigned MootQuery::findConfigCandidates(std::vector<unsigned long>& candidates,
                                         const std::vector<unsigned long>& logicalKeys, 
                                         const std::string& activeState="ACTIVE", 
                                         const std::string& status="CREATED")

Takes as input a set of fmx logical keys and (optionally) cuts on status. Returns a list of configs in the candidates argument which use all files represented by the keys and satisfy the conditions on status.

Various queries, TBD

For example

• Return MOOT config key in effect at a particular time, specified by acquisition or by event timestamp
• Find filter configurations (fmx logical keys) used during a particular acquisition; for each also return mode(s) for which it is in effect.
• When full support of filter configuration/GRB algorithm configuration is in place (see working document) could also return reference to ascii source or other form of intent information for these configurations.

Mode history

The above scheme will not provide a record of exactly which mode was in effect when. This information is already available in the data for those processes reading data event by event. Conceivably it might be of interest for simulation or to generate reports, in which case it should be stored and made accessible by MOOT. It's not easy to keep track of this as the data come in but it is readily available once a run is declared complete.

Proposal

If it seems advisable to keep track of mode history, a table (call it Acq_mode_history), will be added to MOOT and access routines provided. The table can be written by a job which will be handling other tasks at run-complete time. This work (finalizing design of tables and access routines, implementing) is not especially onerous and can be deferred until needed.

Initial draft: 11 Jan 2008 Last revised: Wednesday, 06-Feb-2008 15:33:55 PST

J. Bogart