HLT Global Objects

Complete: 3


A general discussion of the HLT can be found here: HighLevelTrigger

The HLT consists of many independent triggers, logical OR-ed to give the final decision to accept or reject the event. For the subsequent discussion, let's assume we have O(200) trigger paths in the HLT, each path with several reconstruction and filter modules. A concrete example for a single trigger path is a hypothetical dijet-MET trigger, requiring two jets with Et>Etcut, invariant jet-jet mass>Mjjcut and also MET>METcut.

For the purpose of this discussion, this trigger could be implemented as the following path using the configuration syntax:

  prescJetMet  = ...         // config of prescaler module
  L1seedFilter = ...         // config of filter module
  jetReco      = ...         // config of reconstruction module
  dijetminvFilter = ...      // config of filter module
  metReco      = ...         // config of reconstruction module
  metFilter    = ...         // config of filter module

  path dijetMET = {prescJetMet, L1seedFilter, jetReco, dijetminvFilter, metReco, metFilter}

This path contains two modules performing reconstruction tasks (reconstruction of physics objects), and four filter modules, a prescaler, a module checking L1, and two HLT filters.

Each HLT trigger depends on various reconstructed physics objects, such as jets, muons, electrons, MET, ... which are reconstructed online. Any trigger decision involves just a few of those physics objects, eg, 2 jets and MET for a 2jet+MET trigger.

Persistent HLT trigger information

For events accepted to be written to file, a certain amount of HLT trigger information must be kept in addition to the detector read-out data. The amount of HLT generated information on file will depend on the data tier (RAW, RECO, AOD). Also, the amount will decrease strongly over the lifetime of CMS.

First, there are the usual trigger bits, indicating for each trigger its status: whether the trigger has been run, has accepted or rejected the event, or whether an error occured during processing (4 possible states). The user will be able to access and check the status of any trigger for any event, for example, trigger #78 (or the "2jet+MET" trigger using map like indexing). This status information is very compact, a four-state enum packed into just 2 bits for each trigger path. In addition, we keep the position of the module on the path in case it issues a Fail/Exception. All this information is packed into 1 byte per trigger path, so will be included for all triggers on all data tiers over the lifetime of CMS.

Second, there are the reconstructed physics objects used in any intermediate or final filter decision of a trigger path - this is the sole subject of this wiki from here onward. For the example of the 2jet+MET trigger, this would be the specific 2 jets (out of many) and the MET actually passing the trigger cuts.

To keep the detailed physics objects information for all triggers is very costly in terms of event size, only sustainable in early running and at low luminosity. Thus an evolution in the amount of detailed physics object information is foreseen, decreasing from "everything" during startup-phase and the first year(s) of running, to much reduced physics object information for an asymptotically well understood detector and triggers. Also, it depends on data tier (RAW, RECO, AOD).

In the start-up phase and first year, it is certainly needed to keep as much information as possible to check triggers and aid in trigger debugging and commissioning. Thus, initially, all physics objects reconstructed online will be kept, i.e., the original online collections, together with the raw and digi data from the detector. Later, the amount of online physics objects information will reduce a lot, toward keeping only the physics objects actually used in trigger decisions, and for those physics objects only a reduced set of variables, for example, besides physics type (e/mu/g/jet/met...) just energy, eta, phi, (ie, the Lorentz 4-momentum) sufficient for matching with the refined offline physics objects. Also, it depends on data tier (RAW, RECO, AOD).

For those triggers for which this physics objects information is kept, the user needs to be provided with the functionality to access the physics objects used in any trigger decision, only knowing the trigger (by number - #78 - or by name - "2jet+MET").


We adopt the candidate model for physics objects information storage as a simple and straight-forward solution. Our motivations for this choice are as follows:
  • The solution had to be flexible and generic in order to allow the continuous evolution from the start-up scenario to the asymptotic scenario, and from RAW to RECO to AOD data tier, taking into account the varying level of detailed physics object information kept as outlined above.
  • The solution provided also had to be persistable, without using new C++ data types for each trigger path.
  • the neccessary physics objects information had to be extracted from the original collections of online reconstructed physics objects, because in the later running conditions the original online collections would be dropped, and only a reduced amount of information, for only the subset of the online physics objects actually used by a trigger decision, will be kept.
  • The interesting part of the information for each physics object used by a trigger filter, as extracted from the original online collections, must be stored in data structures managed separately, to allow for selective dropping and reduction over time and/or when moving through data tiers.

Here we store only the Lorentz 4-momentum (plus perhaps the vertex for improved geometrical matching at the analysis stage), for example using Particle.h. The key point here is that all physics objects are stored as instances of the same C++ class, which allows them to be packed into a C++ vector. Each HLT filter would put an EDProduct of type HLTFilterObject, containing such a vector, into the event.

In case we also keep the Refs into the original collections, HLTFilterObject is subclassed to HLTFilterObjectWithRefs, containing in addition a vector of RefToBase (Candidate). The latter requires that all high-level reconstructed physics objects (e/mu/tau/g/jet/...) are stored in collections which are C++ vectors of objects derived from the same base class (Lorentz 4-momentum, eg, again the Candidate model).


The modules on a trigger path are arranged such that filters appear as early as possible in order to avoid as much as possible the running of time-consuming reconstruction modules. Recall the example from the introduction:

  path dijetMET = {L1seedFilter, jetReco, dijetminvFilter, metReco, metFilter}

Each filter on the path gets from the Event the required collections of reconstructed physics objects (in the example above the jet collection and the MET collection), iterates over the collections and correlates and applies cuts, and arrives at a decision. In case there is a combination of reconstructed physics objects which passes the filter cuts, an EDProduct of class HLTFilterObject is constructed and put into the event which contains the information of these physics objects. Each of the filters on a path puts such an associated EDProduct into the event.

After all trigger paths have been run, a special Producer HLTMakeSummaryObjects producer, run in an endpath, puts an HLTPathObject for each trigger path, each HLTPathObject containing Refs to the filter objects of that path. In addition, a single HLT global object is put into the Event, containing Refs to all the HLTPathObjects. This latter object is the starting point for (user) analysis.

Review Status

Reviewer/Editor and Date (copy from screen) Comments
HalilGamsizkan - 24 Sep 2012 updating content
JennyWilliams - 07 Feb 2007 editing to include in SWGuide
Main.gruen - 31 Mar 2006 page author

Responsible: MartinGrunewald
Last reviewed by: Reviewer

Edit | Attach | Watch | Print version | History: r26 < r25 < r24 < r23 < r22 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r26 - 2012-10-16 - HalilGamsizkan

    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback