The OLR procedure is similar to that of MET. It makes use of object containers with preselection criteria applied. The difference is that as an output, the OLR analysis sequence adds a decoration to every object, indicating whether it is removed or if it can be used in analysis.
The OLR procedure is analysis dependent and only needs to include objects that are needed for the analysis. In our case, the analysis does not use photons or tau leptons, so they are not included in the OLR procedure.
The OLR tool assumes all types of objects are used by default. If you want to skip any objects, they need to be turned off explicitly when calling
makeOverlapAnalysisConfig
.
It is sometimes necessary to include objects in OLR that are not part of the final state used in your analysis. If your analysis will be included in a combination, it is often necessary to implement vetoes on other types of objects to ensure orthogonality between channels.
Add the following code to config.yaml
:
# Apply overlap removal and specify what objects are used in the analysis
OverlapRemoval:
inputLabel: 'preselectOR'
outputLabel: 'passesOR'
jets: 'AnaJets'
electrons: 'AnaElectrons.loose'
muons: 'AnaMuons.medium'
The OLR and MET sequences are scheduled independently of one another. This is because the MET calculation uses a specific overlap removal that is done automatically by the MET tools.
The OLR decorations will now be propagated automatically to the object
selection used for filling the ntuples. Each object will gain a new
branch with the name *_select_or_NOSYS
, which is a flag that indicates
whether an object survives the OLR procedure. Can you think of some
reasons that the overlap removal depends on systematic uncertainties?
Rerun your job and check the output to make sure it behaves as expected. When you are satisfied that it is working properly, commit and push your changes.