# Presentation: 252047

## Trigger DatabaseTutorial

**Elizabeth Gallas**
**Fermilab Computing Division**

- DØ Collaboration Meeting
- April 22, 2002

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Trigger Database Purpose

_**Generate**_:
- precise programming for trigger configuration, determining which events are recorded and which are thrown away.
- ONLINE
- SIMULATION
- The configuration format: ‘xml’, Extensible Markup Language (XML) universal format for structured docs and data on the web
- The trigger ‘xml’ does not contain all the information stored in the trigger database, specifically wrt versioning, how one trigger list relates to another triggerlist,  or descriptions.
_**Store**_
- all global triggerlists used online in Run 2
- benchmarch triggerlist for simulation
_**Report**_
- trigger configuration settings
- for use by offline analysis programs
- Et thresholds, eta ranges ...
- to the collaboration (web), with some documentation features
- not intended as a substitute for trigger subsystem documentation !** **

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Trigger Database Implementation

_**Design**_:
- Three levels of decision making
- Level 1 - hardware, firmware
- Level 2 - firmware, software
- Level 3 - software
- complexity is a reflection of the complexity of the trigger
- symmetry/commonality is taken advantage of wherever possible
- seemingly cryptic nomenclature reflective of trigger programming.
_**Implementation**_:
- IN USE for all global trigger configurations since early December.
_**Documentation**_:
- Specifications from
- COOR document (Scott Snyder)
- D0 Trigger/Online Groups
- Trigger Database
- see Entry Interface ‘help’ button

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## A Trigger is a Logical Condition

- identified by a _**trigger name**_
- with a set of criteria called a Script at Level 1, Level 2, and Level 3
- each of which is satisfied if all of its logical conditions or _**TERMS**_ is satisfied
- satisfied (true) for an event if all 3 Level Scripts are true for that event

**2EM_HI_Z**

**CEM(2,10)**
**TTK(2,pt3)**
**Afastz**
**2EM(.9,10.,.trk)**

**ele(2,.95,glob,..)**
**InvMass(ele1,ele2,75,100....)**

_**Trigger Name**_

_**Script**_

_**Terms**_

**L1**

**L2**

**L3**

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## A Trigger List

- identified by Triggerlist Name/Version
- contains one or more triggers
- like a tree with Triggers as branches
- if any trigger is satisfied, the event is recorded and the trigger bit for that trigger name is set to TRUE in the event record

**global_CalMuon-?.??**

**2EM_HI**

**EM_MAX**

**3JET_HT**

**MU_JET_HI**

**L1Script**
**L2Script**
**L3Script**

_**Example:**_

**...**
**logical**
**TERMS**
**(yes/no)**
**...**

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Trigger Database Design

- Trigger List
- tl_name/tl_version

- Trigger Name
- tn_name/tn_version

- 1
- N

- L1 Script
- l1s_name/l1s_version

- L3 Script
- l3s_name/l3s_version

- L2 Script
- l2s_name/l2s_version

**NEOTERM**
- And/Or Term

- 1
- N1

- 1

- 1

- 1

- 1

- 1

- 1

- L2 Filter ‘Term’
- t_name/t_version

- 1
- N2

- L2 Tool ‘Term’
- t_name/t_version

- 1

- 1

- N2f

- N2t

- 1

- N2ft

**L2 Object**
- O_name/O_version
- (set of parameters,
- types, defaults,
- min, max)

- Based on

- Based on

**‘****Release Version’**
- p11.01.00 or **pseudoversion**

- L2 Preprocessor
- pp_name/pp_version

- 1

- Npp

- L3: same as L2
- without preprocessors

- A ‘Term’ is a tool or filter with a distinct set of parameter = value pairs

## Web access to TrigDb Triggerlists

- From ‘D0 at work’
- Trigger Board
- TriggerMeister HomePage
**http://www-d0.fnal.gov/trigger_meister/www/**

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Trigger Database Interfaces

**http://www-d0.fnal.gov/trigger_meister/****trigdb****/**

_**Trigger Database Interfaces**_

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Trigger Database Entry Interface

**Entry Interface:**
- Used by experts to enter data.
- Used by anyone (on DØ) to read data.
- Currently the only interface with NEOTERM information (Level 1 And/Or Terms)
- Help button points to existing documentation.
- Has URL links into the Reporting Interface

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Trigger Database Report Interface

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Report: global_CalMuon-5.01 (1)

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## ‘Current’ version of ELE_LOOSE

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## ‘Current’ version of L3TEle

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Report: global_CalMuon-5.01 (2)

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Report: Trigger Name 2TAU_EM10_2CJT5 

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## TriggerList in ‘xml’

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## You can generate triggerlist ‘xml’(thanks Gordon)

- Get trigger list name / version
- On d0mino (clued0?):
- setup d0cvs
- cvs co trigdb_xmlclient
- cd trigdb_xmlclient
- gmake
- source bin/xmlclient_setup
- Run the program with desired options
- For help:
- xmlgen.py -h (for help)
- global_CalMuon-5.01 for ONLINE:
- xmlgen.py --tlist-name global_CalMuon             --tlist-version 5.01  --file --OneStream all            --PrescaleFile
- global_CalMuon-5.01 for Simulation:
- xmlgen.py --tlist-name global_CalMuon     --tlist-version 5.01  --file --Sim
- xmlgen.py in ‘development’.
- To get latest version.
- gmake clean
- gmake
**we hope to have a link on the web someday...**

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## xmlgen.py -h

- MANDATORY INPUT (wildcard %):
-  xmlgen.py --tlist-name listname --tlist-version version
- OPTIONAL SETTINGS (the first 2 are most often used for online lists):
-  --OneStream all (to write all events to one stream like 'all')
-  --file (writes the xml to file named listname-version.xml)
-  --debug 0 (0 for debug mode (all levels), 1 for L1, 2 for L2, 3 for L3) (put this argument first if you want other input arguments reported)
-  --Sim
-  Chooses set of options typicalin offline simulation: including
- --OneStream all
- --GetCrates
-  --SRDirective useL1=no uses L3 tools script SRtools_sim/1 for L3 instantiation of the L3 error handling tool to write a logfile (port 0) called testfile1with typical simulation use file and stats thresholds does not include &smt_monitoring; (inserted for all online xml)
- --UniqueL1L2 (generate unique L1/L2 names for all triggers, even if they share L1/L2 conditions)
- --PrescaleFile (writes a default prescale file named listname-version-default.prescales)
- --realNames (SR parser cannot handle realNames so use this option for testing only)
- --NumNodes (number of l3 nodes to be used, overriding value in database (usually 0))
- --SRDirective useL1=yes,monitorinfo=10,sendmoninfo=yes (is the current default)(enter a comma separated list of directives needed at top of the <triglist>)
- --GetCrates (will generate real cratelists rather than use allcrates_readout.xml)
- --Database (default is 'd0ofprd1')
- --help (this help)

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## xmlgen.py --tlist-name global_CalMuon     --tlist-version 5.01  --file --Sim

**Changes to ScriptRunner Directives:**
**useL1=no**
**do not initiate L3 monitor info**

**L3 ErrorHandling Tool**
**make a log file called test1**
**don’t send the log file to d0olc on port 52245**

**Inserts a cratelist**
**GUI Crater used online to make cratelists called allcrates_readout.xml and allcrate_novbd.xml **

**Removes the noVBD cratelist from all exposure groups**

**Use -OneStream all**

**Don’t start a SDAQ process for smt_monitoring**

- Elizabeth Gallas/Trigger Database

- April 22, 2002

## Trigger Database - Conclusion

- The Trigger database is being used to generate all online global trigger configurations (since early December)
- These trigger lists are available
- in ‘xml’ format for running/testing in simulation
- through web interfaces.
- We are looking for additional manpower to create more graphical displays of TL info
- New trigger lists, especially if there are new tools/filters, can be entered into the Trigger Database with the help of TM’s
- generate ‘xml’ for the simulator
- small changes in parameter values will always be easier to change in the ‘xml’
- hope for future:  triggerlist ‘xml’ modifier (xml was not intended to be changed by hand. ‘xml’ format was chosen because of it’s ability to store data in a structured format, easily passed between programs).
- We need to make informed choices about our triggering strategies -
- The trigger simulator has made huge strides -    LET’s USE IT !!!

- Elizabeth Gallas/Trigger Database

- April 22, 2002