# Presentation: 063394

## The Trigger Database

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

- DØ Collaboration Meeting
- February 15, 2002

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## Trigger Database Implementation

**Fermilab Computing Division**
- _developers_:
**Elizabeth Gallas**
**Jeremy Simmons**
**Rich Wellner**
- _with support and design input from:_
**Vicky White, Ruth Pordes, Matt Vranicar, Julie Trumbo and the d0db support group**
- Specifications from
**D0 Trigger/Online Groups,**
**COOR document (Scott Snyder)**

**IN USE for all global **
**trigger configurations **
**since early December.**

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## What does the trigger do ?

- ‘TOOL’ to find a needle in the haystack
- given a million of collisions per second
- choose ~50/sec to record for later analysis

- We have umptillions  of haystacks each containing millions of bits which we must scan thoroughly and decide quickly which bits to save for analysis later.

- We don’t have one beautiful haystack that contains all the rich physics we want to explore and an infinite time to pick through it and analyze it

- Why not reduce the rate ???
**NO !!!** This is what we want and
- what the system is designed to do !

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

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

## Needles and Hay - Past Experience

- Hay is not uniform
- but previous hay studies/theories have led to the ‘Standard (Hay) Model’ (SM)
- Some people still prefer looking at hay
- helps us measure a ‘hay profile’ to compare to the SM
- Needles and hay share many attributes.  The trigger must be smart enough to see the difference between needles and hay
- If we can’t trigger on some type of interesting physics, we will never see it.
- Some needles look like some rare types of hay
- but occur more frequently than our ‘hay profile’ allows  evidence of needles beyond the SM

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## 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 the Trigger Database
- and online resource allocation by COOR

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

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

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

- Feb 15, 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

- Feb 15, 2002

## Trigger Db stores Trigger Lists

**Design**:
- 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. The trigger configuration file (‘xml’) is generated from the same information you see on the web interfaces.
**Function**:
- _Generate_ ‘xml’ for online and/or simulation
- _Store_ global triggerlists used online in Run2
- _Report_ trigger configuration settings
- for use by offline analysis programs
- Et thresholds, eta ranges ...
- to the collaboration, with some documentation features
- not intended as a substitute for trigger subsystem documentation !

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## Web access to physics TL info

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

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## Trigger Database Links

_**Trigger Database Links**_

- Each interface uses a different mode of accessing information in the trigger database:
**Entry Interface:**  db server to enter and modify data.
**Report Interface:**  Read only.  More flexible queries to get relationship between trigger elements.
**MISWEB interface:**  displays all records in particular tables.  May not be useful to casual user.

- Elizabeth Gallas/Trigger Database

- Feb 15, 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

- Feb 15, 2002

## Trigger Database Report Interface

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## Report: global_CalMuon-4.00 (1)

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## Report: global_CalMuon-4.00 (2)

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## Report: Trigger EM_LO

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

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

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

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

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002

## Trigger Database - Status/Review

- My apologies for any features not yet implemented or ‘perfected’:
- reminder ...this is working system but is in many ways work in progress ...
- Status flags (Current or Used) - design issue
- ‘Option not Implemented’ messages
- Documentation is in development
- Trigger/Online/Software groups will be reviewing the Trigger Database Project soon
- Address current/future functionality/schedule.
- what is missing ?
- Trigger Lists / release compatibility
- Streaming
- Simulation/Trigger_configuration evolution.
- Identify additional interfaces needed.
- Identify manpower.

- Elizabeth Gallas/Trigger Database

- Feb 15, 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 through web interfaces.
- We are looking for additional manpower to create more graphical displays of TL info !!
- We’re witnessing exciting improvement in our triggering capabilities bringing the system closer to the design specs
- factor of 4 throughput to L3, making rejection at L3 now critical for data quality
- certified: EM, JET, Tau
- soon: muon, vertexing, global tracking, missinEt
- L2 within a month
- Muon, EM or JET, with tracking to follow later
- 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

- Feb 15, 2002

## 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 now without TM help.  This feature is in the design,  partly implemented (phase 2)
- The TM are ready to help you enter lists and generate/modify ‘xml’ in the meantime.

- Elizabeth Gallas/Trigger Database

- Feb 15, 2002