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).
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
// 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,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
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.
(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?
Need details for ram procedure for analogs to FMX functionality: fmx upload and maintenance of file_id
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.
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. Bogart | |