Specification for Global Parameters in Trigger DB ------------------------------------------------- Version 1.2 12 Mar 2002 Compiled by Peter Wilson for TDBWG Description of Global Parameters and their usage ------------------------------------------------ There are several parameters of the Trigger hardware that should be tracked globally within the Trigger DB. They easily separate into 2 classes: 1. Rare if ever change (Once or twice per year or less) o L1_TOWER_GRANULARITY (previously known as DIRAC_GRANULARITY in old L1 Calorimeter specific options). This can take on two values: 0.5 GeV (currently hardwired) or 0.25 GeV. We do not expect to ever use 0.25 but the option is there. o L1_HADEM_GRANULARITY (previously HADEMSEL in old L1 Calorimeter specific options). This can take on two values: 0.125 GeV or 0.250 GeV (currently hardwired). We do not expect to ever us 0.125 but the option is there. o XFT_BIN_SET - would refer to a list of Pt values to associate with the XFT bins. The set should be stored in the Calibration Database and have a set number in that Database. The number here would refer to one of the sets in the Calibration database. So far we have only had one set of XFT road PT values. We would like to have this here in case there is a need to have different set in the future. In the case of the CFT (Run 0, 1) the Pt values were changed in Run 1B. o SVT_ROAD_SET - similar to XFT_BIN_SET but for use with the SVT. o L1_MUON_FPGA_VERSION - The functionality of the Muon Matchbox hardware can be changed by creating new FPGA code for the Match Cards and the Muon Trigger Summary card. These have a single version number which is incremented together for the two boards. When the FPGA version changes the L1 Muon validation and download code often has to change. This version number will be used in switch statements to use the correct code. It will also be used to verify that the FPGA version of the Trigger Table is the same as is loaded into the hardware. This FPGA code has changed once (twice?) since the commissioning run. Another 1-2 changes are anticipated in the next year. o Implementing Global Parameters for all of the above will allow testing a switch to a new version while keeping existing Trigger Tables working. It will also allow us to switch back to an older version in the case of problems. o For all of the above it makes sense to have a "Default" value stored in the database. This would be picked up by the GUI when making a table and used unless the user specificly overrides it. 2. Could be different for any given table o SPIKE_KILLER - this is used to enable (1) or disable (0) the spike killer functionality of the ADMEM trigger tower summing algorithm. For most trigger tables the value would be set to 1 to enable the Spike Killer. Since the default value is not expected to change we would have it hard coded in the GUI. Implementation: -------------- We would add a new table, GLOBAL_PARAMETERS, which will have a one to many relationship with Physics_Tables. Below the type for each item is listed along with an initial value which should be used to enter data for old physics tables. We would add two new columns to PHYSICS_TABLES: * GLOBAL_PARAMETER_SET (INTEGER) (Note that the L2 Tagset spec will add a third: L2_TAGSET) The structure of the GLOBAL_PARAMETERS table will be: # GLOBAL_PARAMETER_SET (INTEGER) - initial value 1 * L1_TOWER_GRANULARITY (FLOAT x.yyy) - initial value: 0.50 * L1_HAMEM_GRANULARITY (FLOAT x.yyy) - initial value: 0.25 * XFT_BIN_SET (INTEGER) - initial value: 1 * SVT_ROAD_SET (INTEGER) - initial value: 1 * L1_MUON_FPGA_VERSION (INTEGER) - initial value: 5 * SPIKE_KILLER (INTEGER, range 0 to 1) - initial value 1 o Retired We would also add a GLOBAL_PARAMETERS_DEFAULTS Table which would contain one default value for several parameters that are contained in GLOBAL_PARAMETERS and another named L2_TAGEST_DEFAULTS for those contained in L2_TAGSET. It is not clear what the primary key is since this is not associated with a particular trigger table. it is merely a convenient place to store the default values so that the GUI can get them. The structure of the GLOBAL_PARAMETER_DEFAULTS table will be: # ? * GLOBAL_PARAMETER_SET (INTEGER): initial value 1 * L1_TOWER_GRANULARITY (FLOAT x.yyy): initial value 0.50 * L1_HAMEM_GRANULARITY (FLOAT x.yyy): initial value 0.25 * XFT_BIN_SET (INTEGER): initial value 1 * SVT_ROAD_SET (INTEGER): initial value 1 * L1_MUON_FPGA_VERSION (INTEGER): initial value 5 * SPIKE_KILLER (INTEGER, range 0 to 1): initial value 1 The structure of the L2_TAGSET_DEFAULTS table will be: # ? * CVS Package 1 Tag (VARCHAR) * CVS Package 2 Tag (VARCHAR) * CVS Package 3 Tag (VARCHAR) * NUMBER_OF_ALPHAS (INTEGER): initial value 1 How do we use the global parameters? 1. SPIKE_KILLER - On the main Physics Tables page of the GUI there would be a button much like the one for coupled trigger tables that would be used to TURN OFF the SPIKE Killer. This would be nice as a 2 position pull-down with the top being "ENABLE" and the bottom "DISABLE" 2. Also on the main page there would be a selection for the GLOBAL_PARAMETER_SET. This would start out displaying the default number. If user does nothing the default set would be used. The user could enter a different value OR could hit an edit button which would bring up a window that would allow you to select a different existing set or edit/create new set. The set selected in this edit would then be used. When editing the set the GUI would again use the defaults as preliminary values that user can edit. Open questions: Do we want to implement a scheme to provide a range of allowed values for a parameter that the GUI could use? Could this be done with a table similar to the GUI_DEFAULTS. This could be useful for the L2_TAGSETS because you could provide a list of good CVS tags for the user to choose from. It could also be used for the GLOBAL_PARAMETERS where there is a small number of reasonable values.