# Presentation: 228509

## Anatomy of a Global Trigger List

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

- High Level Trigger Jamboree
- August 4, 2003

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger Fundamentals

- Effect of the ‘Trigger’ system
- given over a million opportunities for collisions (‘events’ per second)
- choose <50  to record for later analysis
- Selecting events:
- Some fraction of these events are not ‘rare’ (but still useful):
- Low energy jet production via QCD ...
- Measure luminosity ...
- Detector monitoring ...
- The study of rare processes and the discovery of unknown phenomena require maximal ‘exposure’ to the beam
- Need well designed triggers that can remain unprescaled at the highest luminosity
- The trigger system is designed to
- Record the wide variety of processes that D0 physicists are interested in looking at
- It does this using a ‘trigger menu’ (or Trigger List)which is complex by necessity

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

**Notes:**
Its not possible to talk about the trigger database without talking first describing the trigger itself

## Trigger System Design

- Fast, complex, high rate,...,multi-level
- Level 1 - electronics and firmware
- reduce 1 MHz  to 10 kHz by looking for interesting signatures (high Pt tracks, high Et energy deposition)
- Level 2 - firmware and software
- 10 kHz to 1kHz by refining L1 objects, match objects found by different detectors
- Level 3 - software
- 1kHz to 50 Hz - execute streamlined versions of offline reconstruction programs to select events.
- Programmable !
- through the ‘trigger configuration’ generated from Trigger Lists stored in      the Trigger Database
- and online resource allocation by COOR

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

**Notes:**
Its not possible to talk about the trigger database without talking first describing the trigger itself

## Trigger Database Purpose

_**Generate**_:
- precise programming for trigger configuration
- 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 Trigger Lists used online in Run 2
- Bench march Trigger Lists 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 !** **

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## 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 December 2001
_**Documentation**_:
- Specifications from
- COOR document (Scott Snyder)
- D0 Trigger/Online Groups
- Trigger Database
- see Entry Interface ‘help’ button

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## 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**

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## 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)**
**...**

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## 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
- t_name/t_version

- 1
- N2

- L3 Filter
- t_name/t_version

- 1
- N3

- NAME/VERSION scheme is repeated throughout the design.
- The name is intended to reflect the conditions in that definition

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger Nomenclature – L1

- NEOTYPE – an L1 detector class
- Group NEOTERMS which shares common download mechanisms
- Examples: ctt, fpd, fps, muo, emcount, jetcount ... specterm
- NEOTERM – the “And/Or terms”
- For any event: result is TRUE or FALSE
- Map into the L1 And/Or Framework
- Combine one/more to form a Level 1 Script decision
- Examples:  TTK(1,1.5), Afastz ...
- L1 Script decision
- Logical AND of one/more NEOTERMS

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Level 1 Trigger Systems

- C -- Calorimeter -- based on Calorimeter “trigger towers”
- emcount / CEM(n,Et[,Hv]) – Cal EM TTower
- jetcount / CJT(n,Et) – Cal Jet (tot) TTower
- misspt / CME(MEt) – near future
- M -- MUON – based on Muon system scintillator, PDT,MDT and CFT
- muo / MUO(n,Pt,eta,scint,wire,option)
- T -- CFT/CPS
- ctt / TTK(n,p) – CFT track
- ctt / TIS(n,p) -- Isolated track
- ctt / TIQ(n,p,q) -- Isolated tracks in a quadrant
- ctt / TIL - Isolated track(s) with low home-sector occupancy.
- A -- Special (L1 Framework terms)
- constructed from signals from: the Accelerator, Luminosity Monitor, Trigger Timing and Control
- Afastz, ALiveBX, ASkip0 ...

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## DØ: Calorimetry

_**DØ: Calorimetry**_

- Features
- Projective geometry
- Cell size: 0.1 x 0.1 in eta x phi
- L1 Cal Trigger exploits features
- Fast summing of Cal cell energies in towers (called Trigger Towers  or TT)
- 0.2 x 0.2 in eta x phi
- CEM TT sums EM section (optional veto on HAD)
- CJT TT (TOT) sums projective tower exclude CH

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

**Notes:**
The primary instrument for the id and measurement of jets in both Run I and Run II is in D0’s Calorimetry.

It is primarily a liq ar sampling calorimeter with Uranium absorber
contained in 3 cryostats surrounding the central tracking system which encloses the interaction region.
It is uniform and hermetic with full coverage to an angle of 2 degrees with the beamline.

Single particle energy resolutions was measured in a calibration beam to be
15 and 45% over root E for electrons and hadrons, respectively.
It has around 50k readout channels available in the precision readout
and a separate readout chain summing channels longitudinally and by .2 in pseudo-rapidity and phi
in order to enable trigger decisions in the high rate environment at the first and second levels of the trigger.

## L1 Muon Trigger

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## L1 CTT Trigger

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Audience Participation @ L1!

- Decode L1 neoterm name:  CEM(1,5)
**Starts with a “C” -- Calorimeter **
**CEM (Sum Electromagnetic Trigger Towers)**
**CEM(n,Et[,Hv])**
**N = 1 – Requires ONE EM TT with**
**Et > 5 GeV and**
**No Hv – NO Hadronic veto**
- Decode L1 neoterm name:  mu2pt3wtlx
**Starts with a “m” – Muon / (maybe CTT)**
**MUO(n,Pt,eta,scint,wire,option)**
**N = 2 – DIMUON **
**Pt3 – requires pt > 3****rd**** CTT threshold**
**Region = ‘w’ – WIDE region (CFT coverage)**
**Scint = ‘t’ – TIGHT req. on muon scintillator**
**Wire = ‘l’ – LOOSE req. on muon PDT/MDT’s**
**Option = ‘x’ – no additional options**
- Decode L1 Script Name (seen in DAQmonitor)
- TTK(2,3.)TTK(1,5.)_CEM(2,3)CEM(1,6)_ncu

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## L1:  Whaaaaat’s that ?

- ‘_ncu’ – started appearing in L1 Script names for global_CMT-11.00
- Cal_unsuppressed / 1
- New trigger in it’s own exposure group
- Read out all Calorimeter cells unsuppressed
- All other triggers were changed to veto on that L1 condition
- Other ‘short names’ used in L1 Scripts:
- ‘_fz’ – requires Afastz
- ‘_nfz’ – veto on Afastz

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger Nomenclature – L2, L3

- OBJECT
- Has a distinct name
- At Level 2:  EM, JET ... or at Level 3: L3TEle
- Has a distinct set of parameter definitions
- Name, type, default, min, max, description
- Has a distinct type
- TOOL or FILTER
- Basis for all TOOL and FILTER TERMs (below)
- Associated with one/more L2/L3 ‘releases’
- TOOL TERM
- An instance of a TOOL type OBJECT giving values to each parameter
- Aside: At L2, TOOLS depend on getting input from the L2 preprocessors in the Run
- Can depend on other tools
- Example:  Jet finding TOOL uses clusters from a Cal Cell Clustering TOOL which uses Cell Energies unpacked by a Cal Unpacking TOOL
**Finds candidates** for other tools, filters
- FILTER TERM
- An instance of a FILTER type OBJECT giving values to each parameter
- Can depend on other filters
- May find candidates for higher level filters
**Makes cuts on candidates**
- For any event: result is TRUE or FALSE
- L2,L3 Script decision
**Logical AND of one/more FILTER TERMS**

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## 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’**
- P15.02.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

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger Database Interfaces

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

_**Trigger Database Interfaces**_

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## 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

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger Database Report Interface

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Report: global_CalMuon-12.20 (1)

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Report: global_CalMuon-12.20 (2)

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Report: global_CalMuon-12.20 (3)

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Two Triggers in every physics Trigger List

- zero_bias
- Level 1 only trigger
- Requiring NEOTERM ALiveBX
- An accelerator based trigger
- true on each of the 36 beam crossings of a single turn of the accelerator
- About 1.7 M times per second
- Used to cross check the luminosity measurement and trigger system functionality
- Really is unbiased
- min_bias (‘minimum biased’)
- Level 1 only trigger
- requiring NEOTERM ‘Afastz’
- (and ALiveBX and ASkip0) – every trigger
- Based on Luminosity monitor:
- North, South scintillator array on beamline
- Requires N and S pulse heights above threshold in timing coincidence
- Gives a quick measure of the z vertex
- Necessary to measure luminosity
- Is undoubtedly biased physics-wise

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Example:  Trigger MWTL_M3_IMM_2T / 2

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Example:  Trigger MWTL_M3_IMM_2T / 2

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## List Current L2 TOOLS/FILTERS

- In Entry OR Report Interface:
- Select ‘current’ status
- Select ‘L2 tools’ or L2 filters
- Click on ‘OBJECT’ button
- Get a Report of all objects with descriptions and parameters...
- L2 Tools:
- COMMISSION, EM, JET, MET, MJT, MUON
- L2 Filters:
- EM, ETA, ETAPHISEP, HT, JET, MJT, MUON, PHISEP, RANDOMPASS, TIMEDELAY

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Current L2 TOOLS/FILTERSfrom Trigger Database

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## List Current L3 TOOLS/FILTERS

- In Entry OR Report Interface:
- Select ‘current’ status
- Select ‘L3 tools’ or L3 filters
- Click on ‘OBJECT’ button
- Get a Report of all objects with descriptions and parameters...
- L3 Tools:
- L3T...BTagIP, _[ ](http://d0db.fnal.gov/trigdb/cgi/tdb_report_element.py?function=Trigger+Object&inname=L3TBTagIP&inversion=p15.02.00&tlevel=l3t)_CFTUnpack, CFTVertex, CalCluster, CalMEt, CalUnp, Ele, GlobalTracker, Jet, MuoCentralMatch, MuoLocal, MuoUnpack, Muon, NullVertex, CFTVertex, PhysTracker, SmtUnpack, XYVertex, TauHadronic
- L3 Filters:
- L3F...BID, CFTVertex, Ele, Ht, FIP, Jacop, Jet, Met, MHt, MarkAndPass, Muon, PassFraction, PreScale, Tau, Track, dR

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Current L3 FILTERSfrom Trigger Database

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## L3:  Whaaaaat’s that ?

- Mark and Pass (special filter)
- A Level 3 Filter designed to create samples for L3 trigger analysis      (not for physics analysis)
- Has one argument:  pass_1_of_n
- Action: puts 1 of every n events passing through it into the inclusive ‘monitor’ stream
- Events written to the monitor stream are not intended for physics analysis
- No luminosity accounting for monitor stream
- Events recorded exclusively to the monitor stream events
- do not get registered in the SAM event catalog
- Cannot use ‘pick events’ utility to get them
- Level 3 scripts using this filter have mp* in their name, where pass_1_of_n = *
- Other shortnames:
- ‘ps*’ -- for L3FPrescale, prescale = *
- ‘pf*’ -- for L3FPassFraction,  fraction = *

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## TriggerList in ‘xml’

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## You can generate TriggerList ‘xml’

- 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  (no arguments for help)
- global_CMT-12.20 for ONLINE:
- xmlgen.py -tlname global_CMT -tlversion 12.20  -file -OneStream all
- global_CMT-12.20 for Simulation:
- xmlgen.py -tlname global_CMT -tlversion 12.20  -file -Sim
- xmlgen.py in ‘development’.
- To get latest version.
- gmake clean
- gmake
**we hope to have a link on the web someday...**

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## 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)

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## 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**

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger List Rules ...

_**Trigger List Rules ...**_

**Examples of rules for valid Triggers, Lists...**
- all Trigger Names must
- be unique (in that Trigger List)
- len(TriggerName)  16 (thumbnail)
- cannot contain special characters
- cannot use more than 4 Level1 Calorimeter EM or JET thresholds
- cannot use more than 32 L1 muon terms from the set of 256 valid terms
- cannot use more than 128 unique L1L2 bits
- L3 filters and tools mustn’t use different versions of tools of the same name
- L3 filters and tools may call other tools, but tools may not call filters (not true at L2)
- L3 tool names must conform to SR parsing rules
- ...
**Many rules checked upon db entry, but the ‘xml’ generator checks many features as well ...**

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## What is the Trigger Db NOT?

**The Trigger Database is not designed to know about:**
- Runs
- Stores
- Magnet settings
- alignment
- calibration
- release version installed in L2 or L3
- (but may know about release compatibility)
- time
**Why not ?**
- These other aspects of a Run are recorded in other databases or using other methods
- The trigger database is an offline database
- including ‘real time’ information would be an expansion in scope of the project

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger Database - Conclusion

- My usual apologies for any features not yet implemented or ‘perfected’:
- reminder ...this is working system but is in many ways work in progress ...
- ‘Option not Implemented’ messages
- Documentation is in development...
- Elements of trigger configuration programming in many Trigger Lists are available via Trigger Db web interfaces.
- ALL Global Lists since December 2001
- MOST Special Run physics Lists
- An increasing number of
- Commissioning
- Calibration
- ...

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger Database - FAQs

- Why are there 3 interfaces ?
- there are different ways to access the database.  Each interface has a specific function and/or takes advantage of the features available in that access mode
- Why is the TriggerDb in offline ?
- needed in offline simulator and online
- online security/access
- design requires one repository because of the use of name/version convention at many levels
- limited manpower
- Can I enter my own triggerlist?
- Not without TM help.
- The TM are ready to help you enter lists and generate/modify ‘xml’.

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

## Trigger FAQs

- Why <50 ?
- Keep the online system stable
- Minimize dead time reduces complexity in luminosity measurement/accounting
- L1 FEB (front end busy)
- L2 Busy
- L3 Disable
- Absence of backlog/backpressure
- able to handle subsystem variations without crashing
- 50 is A LOT
- finite time to reconstruct/re-reconstruct
- Offline ‘skim’ uses only 30% of the data – why not throw away that 70% online?
- Trigger Board needs to be smarter

- ElizabethGallas / TriggerListAnatomy

- August 4, 2003

**Notes:**
Its not possible to talk about the trigger database without talking first describing the trigger itself