Physically, an event is the result of a single readout of the detector electronics and the signals that will (in general) have been generated by particles, tracks, energy deposits, present in a number of bunch crossings. The task of the online Trigger and Data Acquisition System (TriDAS) is to select, out of the millions of events recorded in the detector, the most interesting 100 or so per second, and then store them for further analysis. An event has to pass two independent sets of tests, or Trigger Levels, in order to qualify. The tests range from simple and of short duration (Level-1) to sophisticated ones requiring significantly more time to run (High Levels 2 and 3, called HLT). In the end, the HLT system creates RAW data events containing:
Original Source: TriggerSystem
The HLT contains many trigger paths, each corresponding to a dedicated trigger (such as a prescaled single-electron trigger or a 3-jets-with-MET trigger). A path consists of several steps (software modules), each module performing a well-defined task such as unpacking (raw to digi), reconstruction of physics objects (electrons, muons, jets, MET, etc.), making intermediate decisions triggering more refined reconstructions in subsequent modules, or calculating the final decision for a trigger path. The CMSSW Framework/EDM ensures that if an intermediate filter decision on a trigger path is negative, the rest of the path is not executed (skipped) and the specific trigger is regarded as rejecting the event. In order to save CPU time, each reconstruction step is followed by a filter in order to avoid running time-consuming reco code if it is already clear it will not be needed.
In general it is expected that all HLT trigger paths are run, even if the event is already accepted by a path. In case this turns out to be too time-consuming, a truncated mode of HLT operations should be foreseen where the HLT short-circuits after the first accept (and after the triggers needed to classify the event for a primary data set and output stream are computed) and does not run the rest of the triggers. Presumably, the triggers not run online could be run in the offline reconstruction step to compute all trigger bits (for events written out) in order to get a complete trigger picture allowing trigger efficiency studies.
Each HLT trigger path must be seeded by one or more L1 trigger bit seeds: the first filter module in each HLT path is looking for a suitable L1 seed (consisting of L1 bit[s] and L1 object[s]) as a starting point for that specific HLT trigger.
Original Source: SWGuideHighLevelTrigger
Two persistent HLT products are available:
TriggerResults: (subclassed from
HLTGlobalStatus object), containing
all the usual decision bits.
TriggerResults product (available for events written to output)
allows access to the configuration and trigger decisions, i.e.,
all the usual "trigger bits", including:
TriggerEvent: summarising the "L3" trigger collections and "L3" filter decisions.
The corresponding code can be found in DataFormats/HLTReco/interface/TriggerEvent.h
Additionally, the package HLTrigger/HLTcore contains several
analyzers pulling out the trigger information.
You can use the corresponding analyzers directly - see their
cfi files in
the python subdirectory - or copy relevant code pieces into your modules.
TriggerSummaryAnalyzerAOD: analyser printing the content of the
HLTEventAnalyzerAOD: analyser combining the information from TriggerResults and TriggerEvent products
Note: this helper class must be initialised calling it's
beginRun() method of your plugin using this helper class. The reason
that it has to be (re-)initialised in
beginRun() is that the HLT
configuration can (only) change at the boundary between runs.
Original Source: Persistent Trigger Results Objects
Find the software and usage instructions in