Last revised:
Currently (19 Sept. 2006, MOOT distribution 1.16.1) Configs can only be built from source files which correspond one-to-one to the binaries to be uploaded. In particular, each binary LATC file must be created from a single XML source. This document outlines a plan for a next-generation MOOT which will support builds of Configs without such tight constraints on the form of the sources. With this greater freedom comes a greater need for bookkeeping and query tools so that clients can make informed selections easily.
Define a table for Conditions (a replacement, in a way for CalibSet) as an attempt to capture the conditions under which a collection of ancillary files and associated parameter files were created.
Byron's file createCalibSet.sql is consistent with this definition. In addition to a bunch of boilerplate columns for the CalibSet table there were enum columns "legain" and "hegain". I can imagine also adding an energy column and perhaps others (temperature?). That would be for the CAL Delegate; other Delegates (TKR, ACD, Trigger, Timing) might need other additional columns. Assume there is also a Delegates table, associating names like CAL with keys and also containing an entry for a generic delegate or for cases when delegate is not relevant. The a row in Conditions could reference Delegates. Delegate. Depending on the value of the dyelegate some of the other columns would be used and others wouldn't.
One significant difference between this idea of a Conditions Set and the earlier concept of Calib Set is that the latter (I think) was meant to bind together a set of files which were created more or less at the same time, as the result of a procedure or collection of related procedures. Such a set contains at most one Parameter or Ancillary file of a given type describing settings for some part of the LAT (e.g., CAL dacs for tower 2). In contrast, a Conditions Set might be associated with several such sets of files, generated at different times. Typically, at build time, one would want to select the most recent valid file of each relevant type associated with a specified Conditions Set.
There would be createCALConditions, createTKRConditions, etc. routines which would create a new row in Conditions, filling the appropriate columns for the Delegate, and return the key. If the values for the row to be created matched an existing row (equal or, in the case of floating point values, perhaps within a tolerance) the key to the existing row would be returned instead, along with some indication that no new row had been created.
A column for a Conditions foreign key would be added to both Parameters and Ancillary. Also a column for Delegate would be added to Parameter_class and Ancillary_class.
Variants of the (already existing) registerParm function would take either a Conditions key or Conditions name (if name, the most recent Conditions with that name would be used); similarly for registerAncillary.
To find appropriate Parameters to pass to buildFromParm, the client needs to specify a Conditions row per Delegate (either by name or by key). Also a collection of Parameter classes needed for each Delegate (or maybe Delegate/mode combination) needs to be specified somehow. It could be in a database table if it's relatively static, or it could be specified by the client. Then, for each Delegate, a routine could look up the most recent set of Parameter files belonging to the Conditions specified for that Delegate. In other words, at config-build time, in the simplest case, one just needs to know a collection of Conditions names (one per Delegate) and a mode. In support of this, MOOT should provide a function or functions to query the Conditions table subject to various cuts, returning descriptions, names or any other information in the table which would aid a user in determining which Conditions were appropriate for the new config being built.
|
Initial draft: 19 Sept 2006 Last revised: |
J. Bogart | |