E/gamma HLT Offline Monitoring Strategy

The E/g HLT Offline Monitoring Strategy is described here. The goal of the E/g HLT monitoring is to ensure that good e/g are being triggered and the trigger is performing 'as advertised'. Only the 'physics' triggers are monitored in detail.

The four main tools used to achieve this are:

Trigger Efficiency w.r.t to another (looser) trigger

This is efficiency for an offline e/g to pass the specified trigger given it has already passed a looser trigger. This is done vs Et, eta, phi, charge (ele only) for all e/g and for e/g which pass offline cuts equivalent to the specified trigger. In early data the turn on curves can be measured using this technique by multiplying them with the (Monte Carlo derived) turn on curve for the looser trigger although this will be fairly background dominated. The idea is to have a chain of triggers with each trigger having a looser trigger. For the very loose triggers, these will have to be highly pre-scaled, eg prescaled L1 for the photon cluster only trigger.

Sensitive to:

  • incorrect trigger settings (eg wrong config loaded)
  • tracking problems (for electrons)
  • problems with advanced ID variables such as isolation, cluster shape (if filter uses them)
Insensitive to:
  • L1 problems (handled by L1 DQM)
  • problems occurring with the loosest possible E/g path
  • any signal specific problems (eg if somehow the trigger works fine for jets but not ele/phos)

Trigger Tag and Probe

The trigger tag&probe measurement can measure the efficiency of a reconstructed offline electron to pass the trigger. The tag in this case is a good electron which already passes the trigger in question and the probe is a reconstructed offline electron. The tag and probe are required to have an invariant mass similar close to the Z mass. The efficiencies are plotted vs Et, eta, phi, charge. This results in a acceptably pure measurement of the complete trigger efficiency for electrons. This of course requires a sufficient number of Z events (~0.5pb-1 EB, 1pb-1 EE).

Sensitive to:

  • overall trigger performance (including L1)
  • performance for signal events
Insensitive to:
  • everything with little data
  • photon problems that can not be picked up by electrons

Eta/Phi Occupancy

The eta/phi occupancy of all offline electrons which fire the specified trigger. Any areas with low occupancy are cause for concern. Most of the problems will be spotted by other dedicated DQM. For example, this will detect crude problems in e/g reconstruction which are invisible to the rest of the E/g HLT DQM. The dedicated E/g DQM can then be consulted to find the exact problem. The other issues it will pick up are problems in L1 and the loose trigger. While these will also be seen by the trigger tag& probe plots, in earily days trigger tag&probe is not available.

Sensitive to:

  • total trigger and reconstruction performance differences in different eta/phi regions
Insensitive to:
  • global problems affecting all eta/phi regions equally

Monitored Electron/Photon Variables

A final cross check are plots and N-1 efficiencies of the selected e/g. These monitor the overall health of the selected objects and consist of Et,eta,phi,charge, ID var, offline isolation, recalculated HLT isolations and invariant masses. The efficiencies plotted are N1 efficiencies for id and isolation variables. Changes in efficiency will indicate a change in the relative amount of background and signal and are indicative of a problem. This part does mix a little with the E/g Offline DQM proper but I feel it compliments it rather than replaces this

8E29 Scenario

A 8E29, we are expecting about 0.05 pb-1 of data per run with which a decision must be made. This precludes using real electrons from W/Zs. The primary strategy is therefore to perform a simple mechanical check that if an object reconstructed as an e/g is capable of passing the trigger cuts, it actually does. It does this by measuring the efficiency for a selected offline e/g to pass the trigger vs Et/eta/phi/charge. The selected offline e/g is required to pass a looser trigger and has cuts applied to ensure that it is capable of passing the trigger. Additionally the relative trigger efficiency is also calculated for a loose photon /robust electron. Finally the all the kinematic and identification variables as well as eta/phi occupancy and di-object invariant mass is plotted for all objects passing the trigger.


Looser trigger : HLT_Photon10_L1R (prescale = 25) HLT_L1SingleEG8 (prescale TBD) HLT_MinBiasEcal (prescale 50000, still to evaluate feasibility) HLT_L1DoubleEG5 (still to evaluate feasibility)


Looser trigger : HLT_Photon15_L1R


Looser trigger : HLT_L1SingleEG5 (prescale TBD) HLT_L1DoubleEG5

1E31 Scenario

We start to be able to do T&P on all triggers. Of course this only really works for electrons but I'll look into extending it to photons and see if it supplies any useful information. Electrons will therefore be used to check the performance of photon triggers as photon triggers should still trigger electrons in this menu.


Looser trigger: HLT_Ele10_SW_L1R (prescale = 100) HLT_Photon15_L1R (prescale = 5) HLT_DoublePhoton15_L1R


Looser trigger: HLT_DoublePhoton10_L1R (prescale TBD) HLT_Ele10_SW_L1R (prescale 100)



E/g HLT Offline DQM Code Guide

This is aimed at developers or users trying to make sense of the E/g HLT Offline DQM code. Normal users can safely skip it.

Like all DQM subsystems, the E/g HLT Offline DQM consists of source module which creates histograms from the data and a client module which does any post processing required to make more useful histograms such as efficiencies. The code can be found in DQMOffline/Trigger/ and all E/g HLT Offline DQM files start with EgHLT and live in the namespace egHLT. All python modules start with egHLTOff (although some may start with egHLT although this is being fixed when come across). The egHLTOff is chosen for the python modules to reduce the chance of clashes with the E/g HLT trigger code while the egHLT namespace is used as its shorter and isnt being used by the E/g HLT and is unlikely to be in the future. For the purposes of brevity, I will drop the egHLT namespace from most classes mentioned in this guide (unless the name potentially clashes with another class) as they are all in it.

The source module conceptually consists of an event format which creates and stores trigger DQM relevant quantities and classes which manage the DQM monitor elements (a DQM monitor element is a histogram, double, string which represents a quantity being monitored by the DQM and is abbreviated ME in the rest of this document). The event format also defines an electron and photon wrapper to insulate the DQM code from the E/gamma code changing as well as simplying the access to trigger specific quantities.

E/g HLT Offline DQM Event Format

The E/g HLT Offline DQM uses egHLT::OffEvt as the event format (stands for Offline Event). It is a design requirement that all the information that the DQM requires from the edm::Event can be directly accessed from this class. The class is designed to be minimal and contains a list of electrons, photons and jets in the event. It additionally contains a bitset representing which HLT paths fired in the event. The electrons and photons are stored in the E/g HLT DQM event format while the jets are accessed by a handle to the jets in the edm::Event. The class is designed to be extensible as needed and for this reason it is forbidden to store it in the event. The egHLT::OffEvt is created by a helper class egHLT::OffHelper. This class stores all the InputTags necessary to create an OffEvt and supplies a function to fill an OffEvt from a edm::Event. The advantage of this design is that if the E/g dataformats change (which they are prone to doing), only the EgHLTOffHelper.cc needs to be updated.

Electron/Photon Format

The E/g HLT Offline DQM for now wraps GsfElectrons or Photons in a custom format egHLT::OffEle / egHLT::OffPho. This is done to extend the GsfElectron/Photon class so all relevant variables are accessible via a simple function which is required by the ME filling code. It is similar in aim to the pat::Electron/pat::Photon however running the PAT is too much overhead for the DQM process. The major extensions beyond the GsfElectron/Photon is that it stores which cuts passed failed for various selections and which trigger paths have trigger objects which are matched in deltaR to the electron/photon.

Electron/Photon Selection

The results of the electron/photon selection is expressed as an int with each bit corresponding to whether a particular cut has failed or not. If a bit is set, the cut failed, so an int with value 0x0 indicates that all selected cuts passed, sadly opposite to intuition. The bits corresponding to each cut are defined in egHLT::CutCodes using an enum for fast access. For a slightly slower but still fast access, the cut bits can also be obtained by egHLT::CutCodes::getCode("cutString") where cutString is a ":" separated list of the cuts. Unlike the enum, they have normal capitalisation so ISOLPTTKS becomes isolPtTrks. The names are set in EgHLTEgCutCodes.cc.

The selection is performed by the class egHLT::OffEgSel. The values of the cuts are stored in egHLT::CutValues and are configurable via python, see EgHLTOffEleSelection_cfi.py as an example which defines electron barrel and endcap selections.

Currently two selections are supported, standard and loose which can be configured by changing the eleCuts (phoCuts) and eleLooseCuts (phoLooseCuts) parameter sets in EgHLTOfflineSource_cfi.py. The actual values are set in EgHLTOffEleSelection_cfi.py. Currently the loose and standard cuts are the same. Additionally all cuts are turned on for the selector and later masks are applied to only apply certain cuts. Additionally it is possible to specify arbitrary trigger cuts for the electron/photon to pass to mimic the HLT decision offline.

Trigger Format

The E/g HLT Offline DQM uses a bitset with each bit corresponding to whether the trigger was passed or not. A set bit means that it passed the trigger. Note that this is the opposite logic to the cut bits where a set bit means failed a cut (there are good reasons for this). Because CMSSW does not supply HLT bits, instead just very long strings with the names of the filter, we are forced to define our own. The class used is TrigCodes::TrigBitSet which is a typedef to std::bitset<64>. The decision to typedef was not taken lightly and in this case there is a real chance that number of required bits may increase above 64 and having it defined as a typedef makes it easy to make this change. The definition of each bit is only valid per job as the bits are dynamically defined at the beginning of each job. The bits are defined by passing in a vector<std::string> of all the HLT filter names you wish to assign a bit to to the function TrigCodes::setCodes(...). After this to obtain the bits corresponding to filters pass in a ":" separated string of the HLT filter names into the function TrigCodes::getCode. A set of bits can be converted to filter names by the function TrigCodes::getCodeName()

To obtain the bitset representing the triggers that fired for the event use the function [http://cmslxr.fnal.gov/lxr/source/DQMOffline/Trigger/interface/EgHLTTrigTools.h][egHLT::trigTools::getFiltersPassed()]]. For individual electrons and photons the function [http://cmslxr.fnal.gov/lxr/source/DQMOffline/Trigger/interface/EgHLTTrigTools.h][egHLT::trigTools::setFiltersObjPasses]] sets which triggers the electron passed. Note that both of these things are done automatically in egHLT::OffHelper when creating an egHLT::OffEvt.

Monitor Element Filling

MEs in the E/g HLT Offline DQM are designed to be "fire and forget". That is at declaration, (almost) all the information about what quantity is to be filled and what selection should be satisfied is set and then during the analysis phase, all MEs are looped over and filled by passing each one the event. Each ME then fills itself appropriately. This is achieved through a mixture of virtual functionoid like objects (basically a class which emulates a function, you pass in two arguments and then it returns the functions result, virtual as it uses pointers rather than templates to specify which function to use) to perform the selection and function pointers to fill the ME.

MEs are managed by classes deriving from MonElemManagerBase which defines the interface which consists of one function which fills the monitor element. The class is templated so it can take any object, in this case egHLT::OffPho and egHLT::OffEle.

-- SamHarper - 02 Apr 2009

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r8 - 2009-06-17 - SamHarper
    • 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