MOOT in June 06

The short-term goal is to provide help in tracking configurations during thermal vac.

Here configuration can consist of

Elements of MOOT

The actual situation is complicated somewhat by multiplicities in two dimensions:

  1. There will be three distinct databases (mood, mood_user, mood_test) at SLAC, each with its own archive.
  2. At least the production database, mood, will be replicated as needed (e.g., to the Mobile Rack). Such replicated databases will be pure slaves; users may only initiate writes or updates on the master at SLAC.

Supported functions to date

The following describes version 1.6.0 of MOOT (tag v1r6 of users/jrb/MOOT)

Build
Input is a list of source files comprising the configuration and other information used to label the configuration. Build
  1. archives the source files in afs space at SLAC managed by MOOT, checking first to see if a copy of the source is already archived
  2. converts (new) files to binary form
  3. registers (new) files with fmx
  4. creates and registers LATC master*
  5. returns id for the new configuration if successful
* The LATC master is just a list of the LATC binary files. Then the whole collection can be identified from the master.

Note MOOT does not actively participate in uploading binaries to the instrument, or even in preparing the binaries is creates for upload. [In fmx speak, MOOT deals only in logical files, not physical files.]

Query fmx paths
Given Config id (or, alternately, Config name or Config algorithm + step) return the list of fmx archive base-relative paths. These can then be passed to
fmx upload
Query LATC sources
Given the fmx key for a LATC master file, return paths in MOOT's archive to all the LATC sources the master references. Note the LATC master file key can be found in context records in the data stream.

All of these are callable from C++ or from python. It is also possible to browse the database using an rdbGUI look-alike called rdbBrowse. It has its own documentation. It differs from rdbGUI in that it only provides read access to the database and therefore the connection procedure is slightly simplified. Much of this code only needs to run on Linux; some of it only can run on Linux. MOOT query functions will be available on both Linux and Windows.

Using MOOT

Periodically I make a new distribution which includes shared libraries, the rdbBrowse executable, and a few other necessary files. The contents of the distribution is described in the file http://www.slac.stanford.edu/~jrb/glast/MOOTdoc/howto.html, included in the doc directory of the distribution.


J. Bogart
14 June 2006