MootSvc Job Options

MootSvc can retrieve two kinds of configuration information:

LATC (hardware) configuration. The information flows from the LATC master key (aka hardware key) stored in the data and also retrievable from the Moot key since the Moot key normally has a reference to a hardware key.
Filter configuration. The palette of available filters may be determined from the software key, stored directly in the data and also retrievable from the Moot key. The filter associations (which configuration is to be used by which handler for a particular mode) can only be determined from the Moot key.

What to use when

Use case	Job options	Behavior
Real data, complete half-pipe processing as spec'ed	All default values	Uses production archive and MySQL db. Determines hardware key (used for LATC config, such as GEM) directly from data. Determines Moot key indirectly from data: look it up in Acq_summary table using source id and start time acquired from event.
Real data, incomplete half-pipe processing (meta event not completely filled in data or acquisition not registered in Acq_summary ).	If correct Moot key is known, specify with MootSvc.MootConfigKey.	Moot key will be used to determine both hardware and filter configuration.
Real data, incomplete half-pipe processing (meta event not completely filled in data) but config is registered in Acq_summary ).	If correct Moot key is known, specify with MootSvc.MootConfigKey as above. If Moot key is not known but start time and scid are, set values for MootSvc.StartTime and MootSvc.scid. These will be used to look up Moot key.	Moot key will be used to determine both hardware and filter configuration.
Real data, Moot config unknowable but hw key properly stored in data	Set MootSvc.ExitOnFatal = false;	LATC configuration will be accesible in the usual fashion. Filter configuration will not be accessible. Attempts to retrieve it will not cause crash, but will return null rather than pointer to config.
MC data	Set MootSvc.noMoot = true;	MootSvc will not attempt to connect to database. Moot services invoked subsequently will return with error (but will not crash).

MootArchive: Default of empty string will cause production archive to be used
MootConfigKey: Defaults to 0; i.e., determine moot config from StartTime and scid. If MootConfigKey is set to a non-zero value, that config will be used and values for job options UseEventKeys, StartTime and scid will be ignored.
UseEventKeys: Defaults to 'true'; that is, use event keys in data
StartTime: Default of 0 means use value in the data. StartTime and scid may be used to look up corresponding MOOT configuration for an acquisition.
scid: Source id for data. Defaults to 77, value for flight data. Special value of 0 means look it up in the data.
ExitOnFatal: Defaults to "true". Causes job to exit in various circumstances where config keys of one sort or another are absent, inconsistent, etc.
noMoot: Defaults to "false". If true, MootSvc will not attempt to connect to Moot archive and db. Subsequent calls to MootSvc functions will fail with error. One can query the value of this variable via function IMootSvc::noMoot()
Verbose: Determines whether informational messages will be printed, including all details of MOOT database transactions. Defaults to false.

Created: 16 June 2008
Last revised: Monday, 16-Jun-2008 14:57:15 PDT

J. Bogart