Config Procedures for Initial Calibration Runs

Tracking a Config

This is MOOT's core function. Everything else flows from this.

Ideal procedure

• Something (probably associated with or initiated by FASTCopy) will skim the data stream for configuration records. These contain logical ids (aka keys), assigned by fmx as a consequence of the fmx add function, of binaries composing the configuration of the LAT (indirect in some cases, but that's a technical detail). The something will call a MOOT service, passing it the logical ids. The service will update MOOT's History table and perhaps add or update other database entries of various kinds.
• When a program needs to know what configuration was in effect when some event was take, it will call a MOOT service, supplying a timestamp and a parameter class (corresponding, e.g., to Calorimeter thresholds, TKR masks, etc.). The service will determine which binary files were active for the configuration by looking up the logical ids in its History table. Then it will use other information it has stored to trace back to the source for the requested parameter file.

Short-term alternative

To start we probably will not be extracting the logical ids from the data stream, however requests to upload, start runs, etc, will be reasonably synchronous. By noting what files are requested as part of start-run command, we'll have essentially equivalent information; that is, a way to identify which binaries are active. The details are slightly different. The start run command uses a different sort of id—call it a file id—for the files. One would need a way to recover the logical id from this file id. (For sib files fmx can do this). Then the remainder of the procedure would be as above.

In either case, MOOT needs to be able to relate the logical ids to information identifying the sources for the binaries, and even back to precursors of those sources. To do this, MOOT must be involved in the forward chain: sources to binaries to uploadable.

Building a Config

Background

The config will consist of LATC input files, LCI input and perhaps (but probably not, to start) one or more software configuration files. Each input file will be registered (a row will be created for it) in the MOOD's Parameters table; somewhat different information about the same entity will be kept in a row in the FSW_inputs table (this table is somewhat superfluous here, but won't be in the more sophisticated system envisioned for later, when the partition of configuration information into the parameter files will be done from the operator's perspective). The Configs table will have one row per config. Other tables will keep track of relations among these objects (parameters, FSW_inputs, and configs).

Procedure to create

Use Byron Leas' translator to get from Latte4-type xml to LATC-type xml (single file).

Use Jim's splitter to produce up to 15 LATC files, each handling a distinct component and hence having a different "Parameter_class" value (one of the strings "GEM_parm", "AEM_parm", and so forth). Recent news from Neil: Might have to be more than 15 to ensure that broadcasts are used whenever possible.

  // when the print gets small and ugly like this you can probably skip it
  // calculate a checksum. This will help when looking for duplicates

  search Parameters table for match of Parameter_class value and checksum value;
  If (find any)  {
    bool match=false;
    for each found  entry {
       retrieve file corresponding to the db entry, do diff against our file
       if match {
         handleMatch(...  );  // gets and saves information about existing entry
         match=true;
         break;
       }
    }
  }
  if (!match) {
      makeNew(.. ); // makes a dbs entries, creates binary, does fmx add
  }
  Make entry in Config_FSW table so we know which files belong to this config;  

Other files belonging to the configuration (LCI and possibly software configuration files) have to be processed similarly, except things are considerably simpler since there is no master which has to bind together information about other files.

End-products of Create Step

All input source files (except LATC master) are registered with MOOT; binaries for them exist and are known to FMX. (It might be convenient to make a entry for the LATC master also, but it will be mostly empty at this stage.) There is an entry for the new config as well. From it, one can determine which source files and which binaries belong to this config, and there should be enough descriptive information available that one can determine what the config is for.

Transporting a Config

SIB case

Major steps are:

• get file_id for each binary. Query FMX to see if it already exists; if not, do fmx upload.
• make LATC master; get file_id for it. May be possible to detect whether or not it already exists and avoiding building a duplicate, but a LATC master is small and this isn't very likely to happen; might not be worth the trouble. Fill in remaining information for LATC master, including FMX logical_id and file_id, in MOOD tables.
• determine which of these has already been transported
• present this list (files still requiring transport), and perhaps also other information from FMX dbs, to LICOS.
• LICOS does the transport, followed by fmx commit so that FMX is aware the upload is complete.

RAM case

Should be analogous to SIB case, but there will be a different mechanisms (to be supplied by Online, probably) for

• assigning the file_id-like thing, the function handled by fmx upload
• keeping a record of whether a given file has been uploaded, the function of fmx commit for files destined for SIB.

End-products of Transport Step

By the end of all this, LATC master will exist and MOOT should have stored the file_ids (including the one for LATC master) or equivalent which will be needed as arguments to a start-run for this config. The entry for the config will be marked as ready for use though this is no guarantee, since files can get wiped out subsequently.

Use a Configuration

• LICOS should be able to ask MOOT for a list of available configs, with enough descriptive information that an operator can choose intelligently among them.
Once one is selected MOOT determines list of file_id's (or RAM equivalent) belonging to this config and checks, insofar as it's possible, that they all have been transported to their proper destination. If not, procedure aborts and operator is informed what step(s) have not yet been accomplished.
• LICOS uses some of the file_id's as parameters to a start-run.

Data returned by the run will include logical_ids for files used. Offline users will be able to find out from MOOT which configuration the files belong to.

Initial draft: 30 September 2005 Last revised:

J. Bogart