Using Triggers in Analysis

Using the CP algorithms, it is simple to access trigger decision information, which should be sufficient for most analyses. If your analysis requires additional functionality, you may need to work with the trigger group to create algorithms to do it.

This analysis requires events to pass at least one of four different triggers (two electron triggers and two muon triggers) to ensure good coverage of the various final states we care about. In an actual analysis, you may need to use significantly more triggers, depending on your final state signature.

If you use two-lepton triggers, it is almost always a good idea to also include events selected by single lepton triggers. That helps ensure that if the trigger missed one of your leptons for any reason you can still pick up the event.

Add Trigger Analysis to your Job

To include trigger analysis for the electrons and muons in your job, add the following text to config.yaml:

# Add the trigger information here - the Trigger Chains for each year
# of data collection as well as the IDs, containers, and isolation IDs
# of the electrons and muons that are used in the analysis
Trigger:
    triggerChainsPerYear:
        '2015':
            - 'HLT_e24_lhmedium_L1EM20VH || HLT_e60_lhmedium || HLT_e120_lhloose'
            - 'HLT_mu20_iloose_L1MU15 || HLT_mu50'
        '2016':
            - 'HLT_e26_lhtight_nod0_ivarloose || HLT_e60_lhmedium_nod0 || HLT_e140_lhloose_nod0'
            - 'HLT_mu26_ivarmedium || HLT_mu50'
        '2017':
            - 'HLT_e26_lhtight_nod0_ivarloose || HLT_e60_lhmedium_nod0 || HLT_e140_lhloose_nod0'
            - 'HLT_mu26_ivarmedium || HLT_mu50'
        '2018':
            - 'HLT_e26_lhtight_nod0_ivarloose || HLT_e60_lhmedium_nod0 || HLT_e140_lhloose_nod0'
            - 'HLT_mu26_ivarmedium || HLT_mu50'
        '2022':
            - 'HLT_e26_lhtight_ivarloose_L1EM22VHI || HLT_e60_lhmedium_L1EM22VHI || HLT_e140_lhloose_L1EM22VHI'
            - 'HLT_mu26_ivarmedium_L1MU14FCH || HLT_mu50_L1MU14FCH'
    # Filter events that do not pass any triggers 
    # by setting 'noFilter' to False here
    noFilter: False
    # Add the IDs, isolation IDs, and containers of the electrons
    # and muons here
    electronID: 'Tight'
    electronIsol: 'Tight_VarRad'
    muonID: 'Tight'
    electrons: 'AnaElectrons'
    muons: 'AnaMuons'

Many parts of the configuration have been specified here - let’s examine them piece-by-piece.

We begin by defining the list of triggers that we want to check whether the events passed. The lists in triggerChainsPerYear, organized by year, contain the names of the triggers. Note the key/value format of this section with the year as the keys and the trigger names as the values.

We then specify whether or not the trigger cut will remove the events from our final ntuple using the noFilter selection. Currently, we set it to False to remove events that fail the triggers. If we set it to True, then all events would be kept so that we could see what events passed and failed the selection based on their selection flags and other properties.

For lepton and photon triggers, it is important to match reconstructed objects to objects identified by the trigger. The final part of the text specifies the objects that should be used. If the specified object ID and isolation working points match those of the triggers (given in the trigger names), such as Tight electron ID matching the lhtight triggers, trigger matching can be performed.

Rerun the code with the trigger information added. If you open the output data ntuple and check its contents, you should see a whole list of new branches that begin with trigPassed_ followed by a trigger name. There is one for each of the triggers specified in the configuration. These branches contain flags indicating whether an event passes the corresponding trigger.

Once your code is working properly, commit and push your changes.