Config Procedure for Initial Calibration Runs

Building a Config

Background

The Config will consist of LATC input files, LCI input and perhaps 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

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.

// Sliding into pseudo-code
Make a new row in MOOD Configs table; save resulting config_key;

For each LATC file created {
   // If it's a duplicate just retrieve relevant information, otherwise
   // have to make a bunch of entries in MOOD and invoke FSW services

  // 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;  

   // At this point, have key for this file in MOOD Parameters table,
   // MOOD FSW_input table, and have FMX logical_id
}

Next step is to make LATC master -- unless every single one of the LATC files above was a duplicate, in which case the master may already exist.


Open LATC master for write;
In sib case, for each file {
  Check with FMX if already uploaded (that is, if there has been an upload
      request);
  If not, do fmx upload;
  In either case retrieve file_id and write to LATC master;
}

ram case should be analogous, but there will be a different mechanisms for

// Then the LATC master file itself has to be processed:
  make entries Parameters, FSW_inputs, various relational tables;
  create binary suitable for upload;
  do fmx upload;
 

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.

By the end of all this, MOOD should have (somewhere) stored the logical_ids which will be needed as arguments to a start-run for this config. 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. Then (except I've left out the step to actually transport the files to sib or ram) LICOS could compose the correct start run command for that config.

Questions and Comments

  1. (For Jim) What's the output of the file splitter, exactly? Does it put all the output files in some pre-specified directory? How will the next stage of processing determine which type (e.g., GEM, AEM, TFE, DFT, etc.) of file each of the outputs is? Is there some method other than scanning the contents?

  2. Need details for ram procedure for analogs to FMX functionality: fmx upload and maintenance of file_id

  3. At what point should the transport of the file (as opposed to fmx upload which, as I understand it, is just preparation and request for upload) occur?

    The procedure, in particular the generation of the LATC master which requires file_id or equivalent, wants to do everything more or less at once, but the operational environment may not allow that.

  4. For calibration runs, do we need any software configuration files at all? If so, which?

    from James: At this time, no. Eventually, yes. The LCI package has an associated configuration DB, and calibration depends on most of the same stuff as regular data runs, so there are configuration files for PIG etc. The LCI configuration file is equivilant to JJ's filter software configuration files.


Initial draft: 30 September 2005
Last revised:
J. Bogartjumping