CMSPublic Web>SWGuide>SWGuideOnSel>SWGuideL1Trigger>SWGuideL1Extra (revision 29)~~EditAttachPDF~~

L1Extra Classes

Complete:

Contents:

Introduction

For the HLT and subsequent offline analysis, it is convenient to deal with physical representations of the hardware trigger objects, rather than the hardware representations themselves. In other words, one would like physically meaningful values of phi, eta, transverse energy, etc., not the integer values used in the trigger hardware. The L1Extra classes, defined in DataFormats/L1Trigger and contained in the l1extra namespace, provide these physical representations.

Class Definitions

The following classes inherit from LeafCandidate (found in DataFormats/Candidate). Thus, all the L1 objects are represented by a Lorentz vector, electric charge, and vertex position. One can therefore access directly, for instance, the f, or E_T of each object (via the phi() and et() member functions). The vertex is always set to the origin (0,0,0), and the charge is set to 0 for e/g, jet, and MET objects; it is only meaningful for muons. There are also accessors for the corresponding hardware objects. The f and h values assigned are the average of the two bin boundaries. So, for h, this is not the mechanical center of the h bin. For E_T, the assigned value is the low edge of the bin.

For an example of how to access these objects, see L1Trigger/L1ExtraTestAnalyzer. In releases prior to CMSSW_1_3_0_pre3, check out tag V01-04-03 to get the .cfi file in the example below.

L1EmParticle
- Enum describing whether the object is isolated or non-isolated (use the type() member function).
- Corresponding hardware class: L1GctEmCand (in DataFormats/L1GlobalCaloTrigger).
L1JetParticle
- Enum describing whether the object is central, forward, or t (use the type() member function).
- Corresponding hardware class: L1GctJetCand (in DataFormats/L1GlobalCaloTrigger).
L1MuonParticle
- Status of isolation and MIP bits (use the isIsolated() and isMip() member functions).
- Corresponding hardware class: L1MuGMTCand (in DataFormats/L1GlobalMuonTrigger).
L1EtMissParticle
- Even though EtMiss is really only a 2-vector, it is represented by a 4-vector for uniformity. The etMiss() member function gives the magnitude of the 2-vector.
- Other global energy sums (use the etTotal() and etHad() member functions).
- Corresponding hardware classes: L1GctEtMiss, L1GctEtTotal, and L1GctEtHad (see DataFormats/L1GlobalCaloTrigger/interface/L1GctEtSums.h).

In addition, there is a class that provides lists of objects and object combinations that fired a given trigger:

L1ParticleMap
- Name of trigger (string). This string is not stored; instead, the trigger index, which is stored, is mapped to the name via an enum and a static array of strings.
- Lists of objects that fired the trigger, either by themselves (for single-object triggers) or in combination with another object (for multi-object triggers). The lists of e/g, jet, and m candidates are stored separately.
- A reference to the global L1EtMissParticle object. This reference is null if the global quantities were not used in the trigger.
- A list of object types (i.e. {e/g, t jet, non-t jet, m, MET, total E_T, and hadronic E_T}, indexed by an enum) used by the trigger.
- A list of object combinations (e.g. m-pairs) that fired the trigger. Each combination is given by a vector of indices into the particle lists. The list of object types described in the previous bullet tells which particle list to use for each index. For global objects (MET, total E_T, and hadronic E_T), the index is always 0.
- Functions for navigating this list of object combinations, returning pointers to the L1Extra objects, of type L1PhysObjectBase or its subclasses.
- The index of each L1ParticleMap in the L1ParticleMapCollection corresponds to the enum L1ParticleMap::L1TriggerType (defined in DataFormats/L1Trigger/L1ParticleMap.h).
- Example usage:

         // Check if the double tau trigger fired.
         Handle< L1ParticleMapCollection > mapColl ;
         iEvent.getByLabel( particleMapSource_, mapColl ) ;
         const L1ParticleMap& doubleTauMap = ( *mapColl )[ L1ParticleMap::kDoubleTau ] ;
         bool singleTauFired = doubleTauMap.triggerDecision() ;

         // Get the tau candidates that are part of a successful pair.
         const L1JetParticleVectorRef& triggeredTaus = doubleTauMap.jetParticles() ;

         // Get the successful *pairs* of tau candidates.
         const L1IndexComboVector& triggeredTauPairs = indexCombos() ;

         // Loop over successful tau pairs.
         int pairCounter = 0 ;
         for( L1ParticleMap::L1IndexComboVector::const_iterator pairItr = triggeredTauPairs.begin() ;
               pairItr != triggeredTauPairs.end() ;
               ++pairItr )
         {
             cout << "Pair #" << pairCounter++ << ": " << endl ;

             // Each pair is a vector of indices into the jetParticles() vector.
             for( L1ParticleMap::L1IndexCombo::const_iterator indexItr = pairItr->begin() ;
                   indexItr != pairItr->end() ;
                   ++indexItr )
             {
                 cout << "   Jet #" << *indexItr << ", ET = " << triggeredTaus[ *indexItr ]->et() ;
             }
          }

How To Produce `L1Extra` Objects

MC truth emulation

For immediate HLT development using CSA06 MC, follow these instructions for running L1ExtraFromMCTruthProd, which makes objects of the above classes, based on 4-vectors at generator level. The actual EDProducts that are generated depend on code version and are listed on the respective instructions pages.

Hardware emulation

Beginning with the CMSSW_1_2_0 series, it is possible to run both calorimeter and muon trigger emulators and produce L1Extra objects from their output. The whole emulation chain is controlled by a single master .cff file, L1Trigger/L1ExtraFromDigis/data/l1extra.cff.

Example .cfg file:

   process TRIG = {
      source = PoolSource {
         untracked vstring fileNames = { 'file:myFile.root' }
         untracked int32 maxEvents = 500
      }

      include "L1Trigger/L1ExtraFromDigis/data/l1extra.cff"
      include "L1Trigger/L1ExtraTestAnalyzer/data/l1extratest.cfi"

      path l1Emulator = {l1emulator,l1extra,l1extratest}
   }

Along with the hardware objects, the following EDProducts are put into the event. All the collections are disjoint, as in the hardware; any given trigger object appears in only one collection. So, for instance, non-isolated EM candidates do not include isolated EM candidates. However, so-called "RelaxedEM" triggers act on the logical OR of the Isolated and NonIsolated collections, which are concatenated by hand. Similarly, "Jet" triggers act on the logical OR of the Forward, Central, and Tau jet collections.

L1EmParticleCollection with instance label "Isolated", module "l1extraParticles"
L1EmParticleCollection with instance label "NonIsolated", module "l1extraParticles"
L1JetParticleCollection with instance label "Forward", module "l1extraParticles"
L1JetParticleCollection with instance label "Central", module "l1extraParticles"
L1JetParticleCollection with instance label "Tau", module "l1extraParticles"
L1MuonParticleCollection, module "l1extraParticles"
L1EtMissParticle, module "l1extraParticles"
L1ParticleMapCollection (one L1ParticleMap per L1 trigger), module "l1extraParticleMap"
L1GlobalTriggerReadoutRecord (defined in DataFormats/L1GlobalTrigger), which gives the global L1 decision, module "l1extraParticleMap"

Please see the calorimeter emulator page for the most up-to-date calorimeter tags.