Jet Reconstruction in CMSSW 1_6_0

Complete: 5
Detailed Review status

Goals of this page

The purpose of this tutorial is to give an idea about what Jet objects are in CMSSW and how to work with them. CMSSW is in continuous development so the syntax for particular commands may change. To resolve this issue separate tutorial pages for different CMSSW releases is provided.
Other versions of this tutorial may be found on the primary Jet Reconstruction tutorial page WorkBookJetAnalysis.

Authors: Fedor Ratnikov and Robert Harris


Set up your Environment

Set your runtime environment (shown for release %WBRELEASENEW%):

No files need to be copied at this step - necessary files will be refered later.

Jet Reconstruction Basics

A few steps are necessary to walk from calorimeter digis (a.k.a. frames), which are essentially non-linear ADC counts, to Jet and MET objects:

Dataflow for Jet Reconstruction

  1. convert ADC counts to energy in one calorimeter cell
    • HcalSimpleReconstructor does this calculation for HCAL
    • ECAL does it in two steps
      • first produces uncalibrated hits: EcalWeightUncalibratedRecHitProducer
      • then calibrates hits: EcalAnalFitUncalibratedRecHitProducer
  2. combine ECAL and HCAL cells into projective towers corresponding to HCAL granularity
    • CaloTowersCreator does this operation
  3. convert CMS.CaloTowers into standard objects CaloTowerCandidateCreator (see more details in the next section)
  4. run clustering algorithm to produce Jets
    • Several basic algorithms and corresponding producers are currently implemented for CMS
      • Midpoint Cone algorithm: midpointJetProducer <-- used in this tutorial
      • Iterative Cone algorithm: iterativeConeJetProducer
      • KT algorithm: ktJetProducer
      • Seedless Infrared Safe cone algorithm: sisConeProducer

Different Jet Flavors

Jet clusterization algorithms are very generic and may run on any set of 4-momenta. This feature is used to separate the jet algorithm itself from the physical nature of the jet constituents. Before running jet algorithm on the set of objects, these objects may need to be converted into standard format a.k.a. Candidates, if not inherited from Candidate already.

Four jet flavors are supported:

  • CMS.CaloJets - jets produced from CMS.CaloTowers as described above.
  • GenJets - jets produced from generator level MC particles.
  • PFJets - jets produced from Particle Flow candidates.
  • BasicJets - jets produced from arbitrary collection of Candidate inherited objects.

In this tutorial we use two kinds of input objects for Jet analysis: CMS.CaloJets and GenJets

Jets of any flavor always contain generic jet information. In addition some extra information specific to particular jet flavors is also available.

Generic Jet Properties

Every jet contains information about its 4-momentum. This is the quantity to use for generic kinematics analysis.

Specific Jet Properties

  • CaloJet also contains information about the fraction of energy deposited in a particular calorimeter compartment or group of compartments: ECAL, HCAL, HB(barrel), HO(outer), HE(endcap), HF(forward).

Note that for CMS.CaloJets, the functions p4().eta() and eta() both give you an estimate of the jet rapidity determined with the calorimeters alone. One can get better rapidity resolution (particularly for high energy jets) by instead taking the rapidity using functions physicsEtaQuick(float zPV) or physicsP4(float zPV). These correct the jet direction for the z-offset of the reconstructed primary vertex zPV from zero.

  • GenJet contains information about fraction from different types of generated particles, i.e. from charged hadrons.

  • PFJet conains information about energy contribution and number of contribuing different types of Particle Flow objects.

Run Jet Reconstruction

The jet reconstruction procedure is defined in an example configuration file, reco-jetmet-allinone.cfg. This file essentially includes fragments necessary to make full chain of event processing:
  • Generating single pion events with fixed pT of 50 GeV/c
  • GEANT simulation of detector response
  • Digitization - simulation of detector readout
  • Local calorimetry reconstruction
  • Combining hits into Calorimetry Towers
  • Running CMS.CaloJets reconstruction
  • Running GenJets reconstruction
  • Applying Jet corrections

Details of the configuration file syntax are discussed elsewhere.

To run full chain of Jet reconstruction:

> cmsRun reco-jet-allinone.cfg
Note: you may want to direct output to another file by changing PoolOutputModule filename parameter in the configuration file.

Jet Analysis


Data samples

In following examples we will explore two data samples. One file is reco-jet-allinone.root produced on the previous step and containing 50 single pion events. Another is publically available files containg Z'(700) to dijet events sample with logical name available in CMS DBS catalog (see Locating Data Samples section for more details).


> root.exe reco-jet-allinone.root
root [0] TBrowser b;

Travel to list of objects in the file: "ROOT Files" -> "reco-jet-allinone.root" -> "Events" Now you can browse EDM objects available in the file: Objects list,

particularly CMS.CaloJets: CaloJet, or GenJets: GenJet,

Note: clicking on the leaf is equivalent to executing "Draw" command from the ROOT prompt:

   root [2] Events->Draw("recoCaloJets_iterativeCone5CaloJets__ALL.obj.p4_.fCoordinates.fT");
produces energy distribution for reconstructed jets


The name of the ROOT branch containing jet objects strongly depends from the process name of the job producing jets. To be able to address jets independently from the process name used, a well-defined generic alias is assigned to every Jet collection. The following branch name aliases are produced for the standard jet reconstuction algorithms and inputs

MC5CaloJet = recoCaloJets_midPointCone5CaloJets_X (Midpoint Cone,R=0.5,calorimeter jets)
MC7CaloJet = recoCaloJets_midPointCone7CaloJets_X (Midpoint Cone, R=0.7, calorimeter jets)
IC5CaloJet = recoCaloJets_iterativeCone5CaloJets_X   (Iterative Cone, R=0.5, calorimeter jets)
IC7CaloJet = recoCaloJets_iterativeCone7CaloJets_X   (Iterative Cone, R=0.7, calorimeter jets)
KT6CaloJet = recoCaloJets_fastjet6CaloJets_X              (Kt, D=0.6, calorimeter jets)

MC5GenJet = recoGenJets_midPointCone5CMS.CaloJets_X (Midpoint Cone,R=0.5,stable generator particle jets)
MC7GenJet = recoGenJets_midPointCone7CMS.CaloJets_X (Midpoint Cone, R=0.7, stable generator particle jets)
IC5GenJet = recoGenJets_iterativeCone5GenJets_X     (Iterative Cone, R=0.5, stable generator particle jets)
IC7GenJet = recoGenJets_iterativeCone7GenJets_X     (Iterative Cone, R=0.7, stable generator particle jets)
KT6GenJet = recoGenJets_fastjet6GenJets_X                (Kt, D=0.6, stable generator particle jets)

In general, the alias contains a number which is equal to R times 10 (cone algorithm) or D times 10 (Kt algorithm) rounded to the nearest integer. When making plots interactively the user can simply substitute the short alias name for the long branch name, making things easier to type, and insuring that the user is picking up the last processing of the jets. For, examle, the same energy distribution as in previous section may be plot using alias for the branch:

  root [2] Events->Draw("IC5CaloJet.p4_.fCoordinates.fT");

Users can also employ aliases within root analysis scripts and Framework Lite. To do this they must translate the alias back to the branch name using GetAlias, for example

  TBranch *branch = tree->GetBranch(tree->GetAlias("MC5CaloJet"));
will get the branch corresponding to the alias "MC5CaloJet" for the root tree called "tree".

Using aliases makes data addressing much easier, so we will use aliases whenever possible in following examples.

FWLite Analysis

FWLite mode allows one to address not only members of objects, but also object's methods. See SWGuideEDMWithRoot for details. The precondition for using FWLite is to have regular CMSSW environment established, or at least CMSSW objects libraries available. Fortunatelly this is not a big restriction. The following two commands executed before openning data file enable autoloading of objects libraries:
   > root
   root [0] gSystem->Load("libFWCoreFWLite");
   root [1] AutoLibraryLoader::enable();
   root [2] TFile f ("reco-jet-allinone.root");
   root [3] TBrowser b;

Now Jet objects (like all other CMSSW objects) in the browser are accompanied by available functions, which are clickable and may be used in ROOT scripts.

  root [3] Events->Draw("");
Corresponding methods are indicated by the exclamation leaf in the browser window.

FWLite is both simple to use and easy to maintain: analyzeJets_head.C and analyzeJets.C FWLite allows one to run an event loop with complete sophisticated analysis of objects in the event. The following example demonstrates simple data analisys which runs on dijet sample and makes histograms for properties of two leading jets, and stores histograms in the file:

> root.exe 
root [0] .x analyzeJets_head.C
root [1] .x analyzeJets.C

The reverse side of running FWLite is the lost ability to use logical names as defined in DBS. The example above addresses file in the Fermilab dCache directly, thus this example only works in Fermilab domain.

Access from Framework

The following example demonstrates use of an EDAnalyzer for both CMS.CaloJets and GenJets. It analyzes the simulated Z'->Dijet data file mentioned above. The file is addressed by the logical name.
scramv1 project CMSSW CMSSW_1_6_0
cd CMSSW_1_6_0/src
eval `scramv1 runtime -csh`
cmscvsroot CMSSW 
cvs co -r  WB_1_6_0 RecoJets/JetAnalyzers
 cd RecoJets/JetAnalyzers
scramv1 b
cd test
cmsRun jetPlots.cfg
The analysis is done in the file which loops over the two leading CMS.CaloJets and GenJets in the event, makes some basic histograms, and writes them to a file named histo.root. The algorithm used to make the CMS.CaloJets and GenJets that we read from the event is specified by a label in the configuration file jetPlots.cfg. The labels are specified by the lines
    string CaloJetAlgorithm ="midPointCone5CMS.CaloJets"
    string GenJetAlgorithm = "midPointCone5GenJets"
Here we chose the midpoint algorithm, but other algorithms should work as well, provided jets from those algorithms are in the event. You should browse the input data file in root to see what algorithms are currently available and what their label is (the second field Y in the branch name X_Y_Z). The label will also indicate whether the jet has been corrected (currently this is specified with "cor"). If the label for the algorithm changes in future releases then the user will need to change the label in the config file. As mentioned above, the user will need to change the input file names in the configuration file to point at whatever data file needs to be read.



This tutorial illustrates basics of how to use Jet objects. No special drawing option is used. Tutorials how to produce fancy plots with ROOT may be found elsewhere

Examples with Z'(700) to di-jets data sample

Load dijet data file (in a single line):

  > root.exe dcap://

1. View total and electromagnetic energy in CMS.CaloTowers for single event #5 in di-jet file:

Events->Draw ("", "CaloTowersSorted_towerMaker__Rec.obj.obj.emEnergy() *  (EventAuxiliary.id_.event_==5)","LEGO" );
Events->Draw (""," * (EventAuxiliary.id_.event_==5)", "LEGO");

2. Et distribution for Midpoint Cone 0.5: !GenJets and !CMS.CaloJets:

These distributions show that we have huge contribution of soft jets.

Hint: Use logarithmic scale to see high Et jets

3. Correlation and difference for phi's of high Et GenJets and CMS.CaloJets:

Events->Draw("MC5CaloJet.phiUncached():MC5GenJet.phiUncached()",">100 &&>100");
Events->Draw("MC5CaloJet.phiUncached()-MC5GenJet.phiUncached()",">100 &&>100");

These distributions shows that we have mostly matched or back-to-back generated and reconstructed jets.

Note: we use phiUncached() rather than regular phi(). This is becouse of ROOT habit to bypass regular object constructors, pt(), eta(), phi(), mass(), and some other functions using cached polar coordinates do not update values for every jet. "Uncached" clones of corresponding functions handle this problem.

4. Correlations between eta and energies of matched GenJet and CaloJet:

Events->Draw("MC5CaloJet.etaUncached():MC5GenJet.etaUncached()",">100 &&>100 && abs (MC5CaloJet.phiUncached()-MC5GenJet.phiUncached())<0.5");
Events->Draw("",">100 &&>100 && abs (MC5CaloJet.phiUncached()-MC5GenJet.phiUncached())<0.5");

These distributions confirm that generator-based and CaloTower-based jets are strongly correlated indeed

Advanced Topics

Association of jets to the primary vertex

One of the most experimentally challenging aspects of LHC physics is the issue of in time pile-up, where minimum-bias interactions can introduce additional jets into the event. A technique to efficiently associate jets with the signal vertex is needed to reduce the large luminosity-dependent instrumental background from pile-up jets. The CMS tracker can provide this information by associating reconstructed charged tracks to primary vertices and to jets. To associate a jet with a signal vertex, defined by a lepton or other high-pT tracks of interest, a significant fraction of the tracks in the jet should originate from this primary vertex.

Two approaches have been investigated to test whether jets originate from the signal vertex or not. They differ in the use of the calorimeter jet energy measurement. The detailed description of the method could be found in CMS NOTE-2006/091.

Method A: 1) The variable ALPHA is determined for each jet as the ratio of the sum of transverse momenta of all tracks found inside the jet cone and having the same vertex as the signal (by a Z matching residual) to the transverse momentum of the jet as measured by the calorimeters; 2) If ALPHA > ALPHA_0, this jet is assigned to the signal vertex.

Method B: 1) The variable BETA is determined for each jet as the ratio of the sum of transverse momenta of all tracks found inside the jet cone and having the same vertex as the signal to the transverse momentum of all tracks inside the jet cone; 2) If BETA > BETA_0, this jet is assigned to the signal vertex.

The example configuration files to run Jet-Vertex association is jetVertexRun.cfg and jetVertexAnalysis.cfg

cmsRun jetVertexRun.cfg
cmsRun jetVertexAnalysis.cfg

Jet Corrections


The following jet corrections are available at CMS. The L2 + L3 jet correction is now the standard correction that should be sufficient for the average CMS user. MCJet is an older monlithic jet correction that is now obsolete but available for backwards compatibility. Other specialized corrections are also provided below. Some run in place of L2 + L3, others run on top of L2 + L3 (factorized) or even on top of MCJet. We are still in a transition period in which both standard monolithic MCJet corrections and more advanced factorized corrections are being simultaneously made available to CMS, but the user is cautioned that MCjet will not be available for releases beyond 1_6. R. Harris, May 12, 2008.

Jet Corrections using MCJet

These are now obsolete and the user is recommended to use the L2 + L3 corrections below. This section is unfortunately still first because it describes some of the Jet correction machinery, but we will soon reorganize this workbook.

Corrections to calorimeter reconstructed jets ( CMS.CaloJets) as a function of jet ET and eta
are available in the MCJet package of JetMETCorrections.

Jet corrections are provide in two ways as of 1.6.0:

1. Corrected Collections: take as input a collection of CMS.CaloJets and write as output a collection of corrected CMS.CaloJets.

2. Correction Service: accesses the jet correction itself for a given jet, allowing user to correct CMS.CaloJets "on the fly" without creating a collection of corrected CMS.CaloJets.

The correction was derived from the jet response, CaloJet ET/GenJet ET, from all jets in a QCD MC sample w/o pileup. The correction scales the CaloJet Lorentz vectors so that on average the corrected CaloJet response is equal to 1.

The correction is available in the MCJet package. The most recent .cff file to apply this calibration is

which can correct the algorithms Midpoint Cone R=0.5 and R=0.7, Iterative Cone R=0.5 and R=07, and Fastjet KT D=0.6 for the response measured in the CMSSW_1_5_2 sample (generation and simulation CMSSW_1_4_x, digitization and reconstruction CMSSW_1_5_2).

An example of using the most recent corrections to apply the calibration for Midpoint Cone R=0.5 and access the corrected jet collections, and also to apply jet corrections on the fly, is in

Here are instructions to build and run that example.

    scramv1 project CMSSW CMSSW_1_6_0
    cd CMSSW_1_6_0/src
    cmscvsroot CMSSW
    cvs co -r jet_corrections_16X JetMETCorrections/MCJet/data
    cvs co -r jet_corrections_16X RecoJets/JetAnalyzers
    scramv1 b
    eval `scramv1 runtime -csh`
    cd RecoJets/JetAnalyzers/test
    cmsRun CorJetsExample.cfg 
In CMSSW_1_6_9+ corrections are included into release, so one does not need to checkout stuff except RecoJets/JetAnalyzers itself into working area. The example config file and source code accesses the correction in the following steps:

1. The config file declares the possible kinds of jet correction services and corrected jet collections:

   include "JetMETCorrections/MCJet/data/MCJetCorrections152.cff"
The config file then resolves the ambiguity of which kind of jet correction should set the records IOV:
   es_prefer MCJetCorrectorMcone5 = MCJetCorrectionService {}
Inside MCJetCorrectionsSpring07.cff the corrections are specified as those appropriate for the Spring07 MC sample.

2. The config file picks the algorithm and jet correction service the code will actually use:

  module plots = CorJetsExample {
    string CaloJetAlgorithm ="midPointCone5CMS.CaloJets"
    string CorJetAlgorithm = "MCJetCorJetMcone5"
    string JetCorrectionService = "MCJetCorrectorMcone5"
    string GenJetAlgorithm = "midPointCone5GenJets"
The source code uses the passed corrected jet collection name to get the collection:
  evt.getByLabel( CorJetAlgorithm, corJets );
The source code also uses the correction sevice name to get jet corrections on the fly. This is done by passing a jet to the corrector and getting back the scale which should be used to multiply any of the jet's energy quantities (E, Px, Py, Pz, Pt, Et, m):
  const JetCorrector* corrector = JetCorrector::getJetCorrector (JetCorrectionService, es);
  for( CaloJetCollection::const_iterator cal = caloJets->begin(); 
                          cal != caloJets->end(); ++ cal ) {
    double scale = corrector->correction (*cal);
    double corPt=scale*cal->pt();
Most user's will only need to use one of these two techniques for accesing corrected jets, but this example demonstrates both.

3. The config file includes the producer ( MCJetCorJetMcone5) n the path.

  path p = { MCJetCorJetMcone5, plots }
This is only neded if the user is accessing corrected jet colllections; it is not needed if the user is accessing jet corrections on the fly.

The corrections were made from the CMSSW_1_5_2 MC sample without pileup.

L2 Relative Jet Corrections

Contribution of Konstantinos Kousouris

These, along with the L3 corrections, are now the standard CMS jet corrections. R. Harris, May 12, 2008.

The goal of the L2 Relative Corrections is to make the jet response flat vs eta. In order to achieve this objective, a control region is defined (|eta|<1.3) and all jets are corrected relative to the control region. The L2 Relative Corrections are expressed in terms of CaloJetPt and CaloJet_eta and are smooth in both these variables. Currently, the L2 Relative Corrections are derived using the MC Truth while the ultimate plan is to be derived by the Dijet Balance technique (data driven). They are available for CMSSW_1_5_2 samples and for all jet reconstruction algorithms commonly used. Details on deriving the corrections and their performance can be found in:

Instructions (getting the code and running a simple example):

   scramv1 project CMSSW CMSSW_1_6_7
   cd CMSSW_1_6_7/src
   cmscvsroot CMSSW
   cvs co -r jet_corrections_168 JetMETCorrections/MCJet
   cvs co -r jet_corrections_168 JetMETCorrections/Modules
   cvs co -r jet_corrections_168 CondFormats/JetMETObjects
   cvs co -r jet_corrections_168 RecoJets/JetAnalyzers
   scramv1 b // in case compilation crashes because of the file classes.h just remove it.
   eval `scramv1 runtime -csh`
   cd RecoJets/JetAnalyzers/test
   cmsRun L2L3CorJetsExample.cfg
In CMSSW_1_6_9+ corrections are included into release, so one does not need to checkout stuff except RecoJets/JetAnalyzers itself into working area.

L3 Absolute Jet Corrections

Contribution of Konstantinos Kousouris

These, along with the L2 corrections, are now the standard CMS jet corrections. R. Harris, May 12, 2008.

The goal of the L3 Absolute Corrections is to correct jets in a control region (|eta|<1.3) back to the particle level (GenJets). Currently the L3 Absolute Corrections are derived using MC Truth and the ultimate plan is to be derived by data driven methods (photon+jet balance, MPF, Z+jet balance). Details on deriving the corrections and their performance can be found in: Although it is not technically required, the complete factorized jet corrections can only be achieved by sequential use of L2 Relative Corrections and L3 Absolute Corrections. The example given in the previous section applies the L2 and L3 corrections sequentially. The part of the code that describes the proper use of the combined L2 & L3 factorized correction for the case of the jet algorithm iterative cone R=0.5 is given below:

   es_source L2JetCorrectorIcone5 = L2RelativeCorrectionService { 
        string tagName = 'CMSSW_152_L2Relative_iterativeCone5'   // this is the name of the data file containing the L2 correction constants
        string label = 'L2RelativeJetCorrectorIcone5'                          
   es_source L3JetCorrectorIcone5 = L3AbsoluteCorrectionService { 
   string tagName = 'CMSSW_152_L3Absolute_iterativeCone5'   // this is the name of the data file containing the L3 correction constants
   string label = 'L3AbsoluteJetCorrectorIcone5' 
   es_prefer L2JetCorrectorIcone5 = L2RelativeCorrectionService {}   // Pick JetCorrectionService to set record's IOV
   module L2JetCorJetIcone5 = JetCorrectionProducer { 
        InputTag src   = iterativeCone5CMS.CaloJets   // this is the name of the L2 input jet collection (uncorrected)
        vstring correctors = {"L2RelativeJetCorrectorIcone5"} 
        untracked string alias = "L2JetCorJetIcone5"   // this is the name of the L2 output jet collection (L2 corrected)
   module L3JetCorJetIcone5 = JetCorrectionProducer { 
         InputTag src   = L2JetCorJetIcone5   // this is the name of the L3 input jet collection (L2 corrected)
         vstring correctors = {"L3AbsoluteJetCorrectorIcone5"} 
         untracked string alias = "L3JetCorJetIcone5"   // this is the name of the L3 output jet collection (L3 corrected)
   module plots = JetPlotsExample {   // simple analyzer to produce a few histograms
          string CaloJetAlgorithm ="L3JetCorJetIcone5"   // L3 output jet collection (L2&L3 corrected)
          string GenJetAlgorithm = "iterativeCone5GenJets"   // particle level jet collection
  path p = {L2JetCorJetIcone5,L3JetCorJetIcone5,plots}

L2 + L3 Corrections Updates

These are now the standard CMS jet corrections. R. Harris, May 12, 2008.

CSA07 jet corrections were produced from the following samples

  • 10pb mis-calibration QCD dijets
  • 100pb mis-calibration QCD dijets
  • "perfect detector" CSA07-Njet_#j-ALPGEN samples
The example procedure to apply the CSA07 L2 + L3 corrections in release CMSSW_1_6_x is
     scramv1 project CMSSW CMSSW_1_6_9
     cd CMSSW_1_6_9/src
     cmscvsroot CMSSW
     cvs co -r jet_corrections_CSA07_169_v1 CondFormats/JetMETObjects
     cvs co -r jet_corrections_CSA07_169_v1 JetMETCorrections/Modules
     cvs co -r jet_corrections_CSA07_169_v1 JetMETCorrections/MCJet
     cvs co -r jet_corrections_CSA07_169_v2 JetMETCorrections/MCJet/data
     cvs co -r jet_corrections_CSA07_169_v1 RecoJets/JetAnalyzers
     scramv1 b
     eval `scramv1 runtime -csh`
     cd RecoJets/JetAnalyzers/test
     cmsRun L2L3CorJetsExample.cfg
The above will not work for release CMSSW_1_8_x. The example procedure to apply the CSA07 L2 + L3 corrections in release CMSSW_1_8_x is
    scramv1 project CMSSW CMSSW_1_8_4
    cd CMSSW_1_8_4/src
    cmscvsroot CMSSW
    cvs co -r jet_corrections_184 CondFormats/JetMETObjects/data
    cvs co -r jet_corrections_184 JetMETCorrections/Configuration
    cvs co -r jet_corrections_184 RecoJets/JetAnalyzers
    scramv1 b
    eval `scramv1 runtime -csh`
    cd RecoJets/JetAnalyzers/test
    cmsRun L2L3CorJetsExample.cfg
In addition, when running at Fermilab, the line "unsetenv PYTHONPATH" is needed before "scramv1 b" for the 18x releases. -- RobertMHarris - 29 Apr 2008

L2 + L3 Jet Corrections for CSA08 samples: (Instructions & Examples)

The MC truth L2+L3 jet corrections for the CSA08 samples were derived from the MC data reconstructed with the "S156" conditions in CMSSW_2_0_7. These conditions include an important HCAL inter-calibration which aims at equalizing the HF response and has a large impact on the jet response. Therefore it is NOT recommended to apply these jet corrections to samples reconstructed with different conditions. The corrections are available for the jet algorithms: "iterativeCone5CMS.CaloJets", "sisCone5CMS.CaloJets", "sisCone7CMS.CaloJets", "kt4CMS.CaloJets", "kt6CMS.CaloJets", "iterativeCone5PFJets". The procedure to apply the corrections is the following:

    scramv1 project CMSSW CMSSW_2_0_7
    cd CMSSW_2_0_7/src
    cmscvsroot CMSSW
    cvs co -r jet_corrections_iCSA08_S156 CondFormats/JetMETObjects/data
    cvs co -r jet_corrections_iCSA08_S156 JetMETCorrections/Configuration/data
No compilation is needed. There are also available two examples of the jet corrections application:
    cd CMSSW_2_0_7/src
    cvs co -r jet_corrections_iCSA08_S156 JetMETCorrections/MCJet/plugins
    cvs co -r jet_corrections_iCSA08_S156 JetMETCorrections/MCJet/test/PFJetsCorExample.cfg
    cvs co -r jet_corrections_iCSA08_S156 JetMETCorrections/MCJet/test/CaloJetsCorExample.cfg
    scramv1 b
    eval `scramv1 runtime -csh`
    cd JetMETCorrections/MCJet/test
    cmsRun PFJetsCorExample.cfg
    cmsRun CaloJetsCorExample.cfg
The first example shows how to correct PF jets, "on the fly" (the ability to have corrected PF jets collections is not implemented yet) and the second example shows how to correct standard CaloJets, either "on the fly" or using the corrected jet collections. -- KonstantinosKousouris - 29 Jul 2008

L4 Factorized Jet Corrections using Jet Electromagnetic energy fraction

Contribution of Selda Esen

Here are instructions how to run factorized (Level 4) corrections which take into account electromagnetic fraction of jet energy. The corrections were derived on top of L2 and L3 corrections in the CMSSW_1_5_2 sample, and the example below applies them after the L2 and L3 corrections in the same sample.

scramv1 project CMSSW CMSSW_1_6_9
cd CMSSW_1_6_9/src
cmscvsroot CMSSW
cvs co -r jet_corrections_169_EMF RecoJets/JetAnalyzers
cvs co -r jet_corrections_CSA07_169_v4 JetMETCorrections/MCJet/data
scramv1 b
eval `scramv1 runtime -csh`
cd RecoJets/JetAnalyzers/test
cmsRun L2L3L4CorJetsExample.cfg

Instructions updated by -- RobertMHarris - 31 Jul 2008

L5 Jet Flavor Corrections

Contribution of Jochen Cammin

Updated L5 corrections 21 August 2008

Previous versions of the L5 corrections combined flavor corrections and parton-level corrections. For details of these now obsolete corrections follow this link. The new default L5 corrections are described below and should be used from now on (combined with the L7 corrections if needed). We discourage the use of the old L5 corrections!

New L5 corrections: The updated L5 corrections now follow the philosophy of truely factorized corrections:

  • they have been derived after applying the L2 and L3 corrections
  • they correct differences in the jet flavors at the particle level
  • they can be combined with the L7 corrections to go back to the parton level.

Background information on L5 corrections:

The L2+L3 corrections scale the energy of an "average QCD jet" back to the energy of the corresponding generator level particle jet. However, an analysis of the individual jet flavors (uds, c, b, gluon) shows that different corrections are needed for different jet flavors. This leads to an over- or undercorrection if the L2+L3 corrections are applied to jets with a flavor composition different than that of QCD jets. For example, jets from the hadronic decay of a W boson consist only of uds and c quarks, which have a higher energy response than b and gluon jets. Consequently, applying L2+L3 corrections to these jets will result in an overcorrection. A first pass of flavor-specific corrections is provided as a a tool to minimize the flavor-dependence of the L2+L3 corrections.The L5 corrections act at the particle level. If corrections back to the parton level are required (for example, when reconstructing the Z or W mass in their hadronic decays), the L2+L3+L5 corrections can be combined with the L7 corrections.

Note that the L5 corrections provide corrections only relative to the 'typical' mix of flavors present in the sample that they have been derived from. Currently, L5 corrections derived on QCD dijets events and from top-quark pair events are available.This approach has been chosen in order to reflect the current understanding of the L2+L3 corrections. In practice this means that even after applying the L5 (and L7) corrections to W->jj' or Z->qq the reconstructed W or Z mass will not necessarily peak at the generated W or Z mass, but at a value that is determined by the current level of closure of the L2+L3 corrections.

The following example shows how to use the updated L5 corrections in a CMSSW_1_6_12 release area.

   scramv1 project CMSSW CMSSW_1_6_12
   cd CMSSW_1_6_12/src
   eval `scramv1 runtime -csh`
   cmscvsroot CMSSW
   cvs co -r jet_corrections_16X_L5_v2 JetMETCorrections/MCJet/data
   cvs co -r jet_corrections_CSA07_169_v3 JetMETCorrections/Modules
   cvs co -r jet_corrections_16X_L5_v2 CondFormats/JetMETObjects
   cvs co -r jet_corrections_16X_L5_v2 RecoJets/JetAnalyzers
   cvs co -r jet_corrections_CSA07_169_v3 RecoJets/JetAnalyzers/src/
   cvs co -r jet_corrections_CSA07_169_v3 RecoJets/JetAnalyzers/interface/L2L3CorJetsExample.h
   scramv1 b
   cd RecoJets/JetAnalyzers/test/
   cmsRun runL2L3L5CorrectionsExample.cfg

The example applies L5 corrections derived on TTbar events. To use L5 corrections derived on QCD events, replace the line

include "JetMETCorrections/MCJet/data/JetCorrections_L5Flavor_fromTTbar_iterativeCone5.cfi"
include "JetMETCorrections/MCJet/data/JetCorrections_L5Flavor_fromQCD_iterativeCone5.cfi"
in runL2L3L5CorrectionsExample.cfg.

At this time L5 corrections are available only for iterativeCone5 jets. Other algorithms will be included in future updates.

Instructions updated by -- JochenCammin - 21 Aug 2008

L7 Parton Jet Corrections

Contribution of Attilio Santocchia

The following instructions are tested with CMSSW 200 cycle. The stand alone correction function however can be used indipendently from CMSSW

The L7 correction function has been calculated comparing the GenJet transverse momentum to the matched parton (ΔR<0.15). Physics definition of the GenJet flavour has been used. The stand alone version of the correction function can be found here (theStandAloneL7CorrectionFunction.cpp)

There are 5 jet algorithms: iterative cone ΔR=0.5 (IC5), KT jet D=0.4 and 0.6 (KT4 and KT6) and SisCone ΔR=0.5 and 0.7 (SC5 and SC7). For each algorithm 9 different functions are available:

  1. flavour: 0 gluons from diJet
  2. flavour: 1 light quark from diJet
  3. flavour: 2 charms from diJet
  4. flavour: 3 beauty from diJet
  5. flavour: 4 soup from diJet
  6. flavour: 5 light quark from ttbar
  7. flavour: 6 charms from ttbar
  8. flavour: 7 beauty from ttbar
  9. flavour: 8 soup from ttbar

To apply correctly the correction, the transverse momentum to be considered has to be the jet momentum AFTER the L2-L3 correction.

An example to apply the correction is given in RecoJets/JetAnalyzers. The analyzer is in the src while the file runPartonJetCorrectionExample.cfg in the test directory is a simple config file to run the anlyzer.

Jet Corrections in CMSSW_2_1_X

Contribution of Konstantinos Kousouris

Instructions for applying the factorized jet corrections in CMSSW_2_1_X using PYTHON configuration files (The instructions have been tested successfully in CMSSW_2_1_2 and CMSSW_2_1_4).

Mandatory checkouts from cvs:

cvs co -r jet_corrections_21X CondFormats/JetMETObjects
cvs co -r jet_corrections_21X JetMETCorrections/Configuration
cvs co -r V02-09-00 JetMETCorrections/Modules
scramv1 b
Illustrated examples can be found in the RecoJets/JetAnalyzers package:
cvs co -r V00-04-01 RecoJets/JetAnalyzers
scramv1 b
There are currently available the following examples in RecoJets/JetAnalyzers/test:
  • (default L2+L3 jet corrections by creating corrected jet collections).
  • (default L2+L3 jet corrections applied "on the fly").
  • (optional L4(EMF) correction on top of the default L2+L3).
  • (optional L5(Flavor) correction on top of the default L2+L3).
  • (optional L7(Parton) correction on top of the default L2+L3).
  • (optional L5(Flavor)+L7(Parton) correction on top of the default L2+L3).

The above combinations of jet correction levels do not cover all the possible user cases but they clearly illustrate the methodology. The basic concept is the correction chain where the output of one level of correction is plugged into the next level.

The first step is the definition of the correction services:

#############   Define the L2 correction service #####
process.L2JetCorrector = cms.ESSource("L2RelativeCorrectionService", 
    tagName = cms.string('iCSA08_S156_L2Relative_Icone5'),
    label = cms.string('L2RelativeJetCorrector')
#############   Define the L3 correction service #####
process.L3JetCorrector = cms.ESSource("L3AbsoluteCorrectionService", 
    tagName = cms.string('iCSA08_S156_L3Absolute_Icone5'),
    label = cms.string('L3AbsoluteJetCorrector')
#############   Define the L5 correction service #####
process.L5JetCorrector = cms.ESSource("L5FlavorCorrectionService",
    section = cms.string('uds'),  
    tagName = cms.string('L5Flavor_fromQCD_iterativeCone5'),
    label = cms.string('L5FlavorJetCorrector')
#############   Define the L7 correction service #####
process.L7JetCorrector = cms.ESSource("L7PartonCorrectionService", 
    section = cms.string('qJ'),
    tagName = cms.string('L7parton_IC5_080301'),
    label = cms.string('L7PartonJetCorrector')
The next step is to define the correction chain service (any number of correction services can be chained):
#############   Define the chain corrector service ###
process.L2L3L5L7JetCorrector = cms.ESSource("JetCorrectionServiceChain",  
    correctors = cms.vstring('L2RelativeJetCorrector','L3AbsoluteJetCorrector','L5FlavorJetCorrector','L7PartonJetCorrector'),
    label = cms.string('L2L3L5L7JetCorrector')
IMPORTANT: if multiple correction services are defined, an es_prefer statement that selects one of them to set the record's IOV has to be included. ANY service can be chosen!!!! but the es_prefer statement must only be defined ONCE. This is a dubious feature of the CMSSW framework and is irrelevant to the actual application of the jet corrections.
# set the record's IOV. Must be defined once. Choose ANY correction service. #
The last step is to define the corrector module (this step is not needed if the jet corrections are applied "on the fly"):
#############   Define the chain corrector module ####
process.L2L3L5L7CorJet = cms.EDProducer("CaloJetCorrectionProducer",
    src = cms.InputTag("iterativeCone5CMS.CaloJets"),
    correctors = cms.vstring('L2L3L5L7JetCorrector')
Once the chain corrector module is defined, it must be called in the execution path BEFORE the user analyzer which requires the corrected jet collection.

IMPORTANT: for the default L2+L3 jet correction, the appropriate chains have already been defined and the users only have to include the proper .cff file (according to the set of jet corrections they desire: CSA08, CSA07, CMSSW_1_5_2).

Jet Corrections in FWLite environment

Simple jet corrections, that are corrections which are dependent from jet properties only, may be directly accessed from ROOT scripts running in FWLite environment, like in the following example:

// Extract local release location
  const char* releaseBase = gSystem->Getenv ("CMSSW_RELEASE_BASE");
// Pick required correction data - IC5 corrections for 1.5.2 data in this case 
  std::string correctionData (releaseBase);
  correctionData += "/src/CondFormats/JetMETObjects/data/CMSSW_152_iterativeCone5.txt";
// Make MCJet corrector using selected correction data
  SimpleMCJetCorrector corrector (correctionData); 
// get energy correction for kinematics defined as px/py/pz/e
  cout << "jet energy correction for px=50, pz=50: " << corrector.correctionXYZT (50, 0, 50, 80) << endl;
// get energy correction for kinematics defined as pt/eta/phi/e
  cout << "jet energy correction for eta=1, pt=50: "  << corrector.correctionPtEtaPhiE (50, 1, 0, 200) << endl;
// get energy correction for jet 
  cout << "jet energy correction for given jet: "  << corrector.correctionXYZT (jet.px(),, jet.pz(), << endl;

Jet Corrections using Jet+tracks algorithm

Contribution of Sasha Nikitenko and Olga Kodolova

The Jet+tracks (JPT) corrections in CMSSW_1_6_X and later versions are accompanied by the Zero Supression (ZSP) corrections, thus the complete energy correction chain (ZSP+JPT) includes two steps:

1. The calorimeter jet energy is corrected for the effect of the ZSP on the calorimeter readouts forming ECAL+HCAL tower.

2. The energy after ZSP corrections is corrected again with the JPT algorithm applying in-cone-track and out-of-cone-track corrections

Jet+tracks corrections are provided in two ways as of 1.6.X:

1. Correction Service: accesses the jet correction itself for a given jet, allowing user to correct CMS.CaloJets "on the fly" without creating a collection of corrected CMS.CaloJets. The example is provided below.

2. Corrected Collections: take as input a collection of CMS.CaloJets and write as output a collection of corrected CMS.CaloJets. In order to have this way, in the example below one should use JPTanalyzer1.cfg instead of JPTanalyzer.cfg. Please, in JPTanalyzer1.cfg change path to path p1 = {ZSPJetCorrections,JetPlusTrackZSPCorJetIcone5,myanalysis}. It will run "standard" ctfWithMaterialTracks with pT > 1 GeV.

The example is provided below on how to correct jets "on the fly" with ZSP+JPT corrections. Checkout and compile the code in CMSSW_1_6_12 with:

    scramv1 project CMSSW CMSSW_1_6_12
    cd CMSSW_1_6_12/src

    cvs co -r JPT070808 JetMETCorrections/JetPlusTrack  (the same tag for running with AOD)
    cvs co -r V02-01-00-04 JetMETCorrections/Modules
    cvs co -r CMSSW_1_6_12 JetMETCorrections/MCJet/data

    cp JetMETCorrections/JetPlusTrack/data/ZSPJetCorrections152.cff JetMETCorrections/MCJet/data/ZSPJetCorrections152.cff

    scramv1 b
    eval `scramv1 runtime -csh`

    cd JetMETCorrections/JetPlusTrack/test
    cmsRun JPTanalyzer.cfg  (for AOD:  cmsRun JPTanalyzerAOD.cfg)

In this example the EDM analyser in JetMETCorrections/JetPlusTrack/plugins/ run on 40K QCD di-jet events from Summer07 data, select two highest ET Gen jets, find calirimeter jets matched to Gen jets within DR < 0.3 and correct calo jet energy using ZSP, ZSP+JPT in-cone-track and finally full ZSP+JPT corrections. It creates and save the user root tree
which can be analyzed in an iteractive root session with JetMETCorrections/JetPlusTrack/test/JPTRootAnalysis.C macro:
cd JetMETCorrections/JetPlusTrack/test
correct JPTRootAnalysis.h putting proper name for root file to be analyzed
start root interactive session:
.L JPTRootAnalysis.C
JPTRootAnalysis m;

References to JPT algorithm: CMS Note 2002/036, CMS Note 2004/015, CMS IN 2007/048.


12 Febr 08 Usage of iterative tracking*: Example below uses "standard" ctfWithMaterialTracks with pT > 1 GeV. There is possibility to use tracks from Iterative tracking by M. Pioppi with pT > 0.3 GeV. In order to do it one should use JPTanalyzerIterTrk.cfg instead of JPTanalyzer.cfg in the example below.

18 Febr 08 Access to sum Pt of tracks used for corrections*: on request of SUSY PAG the access to sum pT of tracks was added. It can be used to calulate so called "alpha" parameter, sum pT trk / Et jet, used for fake jet supression in a number of Higgs analyses. The example how to access sum pT of tracks is shown in

4 March 08 Tracker inefficiency is taken into account*

16 May 08 Running on AOD*: on request of SUSY PAG modifications are made to run code on AOD. It provides full JPT corrections with "standard" ctfWithMaterialTracks with pT > 1 GeV and trk. inefficiency taken into account. So called in-cone corrections are presently not activated (return correction factor 1).

16 June 08 Add muons to jet energy, subtract responce of out-of-cone-at-vertex tracks, correct for different response of lost tracks.

30 June 08 updated ZSP corrections, useage of GenJets with no neutrinos; ZSP with 0.8 cone (needed for Z+jet usage); it is commited into JetMETCorrections/JetPlusTrack/data, but once running should be copied into CMSSW_1_6_12 CondFormats/JetMETObjects/data

30 July 08 bug fix for jets which include muon

7 August 08 updated single particle response map with 11x11 crystals and 5x5 HCAL matrix around ip of reco track in ECAL


Jet Energy Scale validation

Contribution of Roger Wolf

A description on how to validate the obtained Jet Energy Scale correction can be found here.

True Jet Flavour Definition

Contribution of Attilio Santocchia

Addendum (How to Run with 16X - 17X - 18X)

The data format used for the true jet flavour has been completely re-designed for CMSSW 180. The CandMatchMap has been discarded and more compact classes (to save space) have been adopted.

A full description of the new implementation and instructions can be found in SWGuideBTagMCTools. The definition of the algorithms ( Algorithmics and Physics) is however unchanged.

End Addendum

GenJet are built from a GenParticleCandidate collection, CaloJet from calorimeters towers. The true Jet flavour depends on the choosen algorithm. In CMS exist 3 different algorithms which have been developed for 2 different purposes: jet bTag and jet calibration. The final outcome of each algorithm is to assign a flavour to thejJet. The assigned flavour can be:

  • light jet (uds jet)
  • b jet
  • c jet
  • gluon jet

Depending on the algorithm light and gluon jets can be considered as one single category (udsg jets). The 3 algorithm are called:

  • Algorithmic definition (bTag purpose)
  • Physics definition (bTag purpose)
  • Energetic definition (Calibration purpose)

More info on the first 2 algorithms can be found in the proper twiki page (SWGuideBTagMCTools). The original definition is located in the RecoBTag/MCTools package and is based on HepMC and not on the Candidate Model. The HepMC event is however dropped in the RECO/AOD data formats and a new implementation of the same functionalities have been implemented to deal with the GenParticleCandidate collection. The new implementation is found in CMS.PhysicsTools/JetMCAlgos; the plugins is called and produces (and eventually saves it in the event) a CandMatchMap where each jet is matched to a GenParticleCandidate (according to the choosen algorithm).

The major difference among the first 2 algorithm and the 3th is the particles used for the flavour definition: the Algorithmic and the Physics definition looks for generator particles in a cone around the jet axis while the Energetic definition looks directly to the particles used to build the jet (the constituents of the jet).

An example to run both the HepMC and GenParticleCandidate implementation is found in CMS.PhysicsTools/JetExamples/test where a simple analyzer ( is available. After the production of the proper CandMatchMap (see printJetFlavour.cfg in the same directory as an example), the flavour of the jet is identified using the following code:

for( CandMatchMap::const_iterator f  = theJetPartonMap->begin();
                                  f != theJetPartonMap->end();
                                  f++) {

    const Candidate *theJet     = &*(f->key);
    const Candidate *theParton  = &*(f->val);

    printf("(pt,eta,phi) jet = %7.3f %6.3f %6.3f | parton = %7.3f %6.3f %6.3f | %2d\n",


the Energetic definition

Each GenJet is formed from a set of GenParticleCandidate (constituents), each GenParticleCandidate can be checked for its decay chain looking at its ancestors using the method:
std::vector<const reco::Candidate *> getAncestors(const reco::Candidate &c);
Most of the time, the decay chain starts from a string (ID=92), a cluster (ID=91) or a lepton (a tau for example). Each ancestors is looked for its flavour using the methods:
bool hasBottom(const reco::Candidate &c);
bool hasCharm(const reco::Candidate &c);
A variable is built for each jet computing the fractio of the energy of the jet which comes from b ( c) hadrons. In other words the sum of energy of the particles decayed from a b ( c) hadrons is computed.

A typical light jet is the following:

[GenJetTest] (pt,eta,phi | bRatio cRatio) =  87.41 -0.59 -0.18 | 0.000 0.000 |
        [Constituents] (pt,eta,phi | isB,isC |) =  78.66 -0.58 -0.21 | 0 0 |
        [Constituents] (pt,eta,phi | isB,isC |) =   2.57 -0.75  0.14 | 0 0 |
        [Constituents] (pt,eta,phi | isB,isC |) =   2.36 -0.51  0.01 | 0 0 |
        [Constituents] (pt,eta,phi | isB,isC |) =   1.06 -0.58  0.06 | 0 0 |
        [Constituents] (pt,eta,phi | isB,isC |) =   0.97 -0.54  0.28 | 0 0 |
        [Constituents] (pt,eta,phi | isB,isC |) =   0.48 -0.39  0.14 | 0 0 |
where the first line is the jet itself and bRatio and cRatio are the quantity computed as the fractio of energy of all the constituents (the following lines) which decay from a b ( c) hadron (zero in this case because none of the constituents decay from an heavy hadron).

An example of a b jet is the following:

[GenJetTest] (pt,eta,phi | bRatio cRatio) =  75.30 -0.25 -1.15 | 0.798 0.375 |
        [Constituents] (pt,eta,phi | isB,isC |) =  23.51 -0.15 -1.10 | 1 0 |
        [Constituents] (pt,eta,phi | isB,isC |) =  11.15 -0.26 -1.20 | 1 1 |
        [Constituents] (pt,eta,phi | isB,isC |) =  10.95 -0.33 -1.17 | 1 1 |
        [Constituents] (pt,eta,phi | isB,isC |) =   7.80 -0.31 -1.16 | 1 0 |
        [Constituents] (pt,eta,phi | isB,isC |) =   5.89 -0.19 -1.21 | 1 1 |
        [Constituents] (pt,eta,phi | isB,isC |) =   4.48 -0.23 -1.18 | 0 0 |
        [Constituents] (pt,eta,phi | isB,isC |) =   2.83 -0.23 -1.01 | 0 0 |
In this case there are 2 particles that decay directly from a b hadron and 3 particles that decay from a b hadron throug a c hadron. Hence the 79.8% of the energy for this jet comes from b particles, while 37.5% comes from c particles.

The typical distribution for the variables bRatio and cRatio are shown in the following plots for the samples tt1j, tt2j, tt3j and tt4j produced with ALPGEN. Immagine1.png Immagine2.png

The sharp peak on the left of the plots are light jets. Choice of the value to cut for flavour definition is a user responsability, typical value are:

bRatio>0.20 for bJets
 cRatio>0.20 and bRatio<0.20 for cJets
 bRatio<0.20 and cRatio<0.20 for light Jets

The implementation for the Energetic definition is in the package CMS.PhysicsTools/JetMCUtils

A simple analyzer ( printGenEvent.h) for accessing the variable bRatio and cRatio for a GenJet is the the following:

  for( CandidateCollection::const_iterator f  = genJets->begin();
                                           f != genJets->end();
                                           f++) {
    double bRatio = EnergyRatioFromBHadrons(*f);
    double cRatio = EnergyRatioFromCHadrons(*f);
    for( Candidate::const_iterator c  = f->begin();
                                   c != f->end();
                                   c ++) {
      const Candidate* theMasterClone;
      bool isB = false;
      bool isC = false;
      if (c->hasMasterClone ()) {
        theMasterClone = c->masterClone().get();
        isB = decayFromBHadron(*theMasterClone);
        isC = decayFromCHadron(*theMasterClone);

This example produce an output similar to the previous jet output with information on one jet and its constituents. The relative configuration file is printEvent.cfg

Jet Matching

There are 2 matching tools implemented:

  • One-To-One matching
  • One-To-Many matching
Each tool works on Candidate: every collection represented as a CandidateCollection can be uses as input to the matching tools. Hence the use of these tools is not limited to RecoJets and GenJets.

A simple analyzer jetTest.h exists in CMS.PhysicsTools/JetMCAlgos/interface showing an example for both the matching tools. The relative jetMatch.cfg file is in CMS.PhysicsTools/JetMCAlgos/test

First 2 JetCollection are cloned to CandidateCollection:

# this is to get a CandidateCollection from a JetCollection
  module caloJetCollectionClone = CaloJetShallowCloneProducer{
    InputTag src = iterativeCone5CMS.CaloJets

  module genJetCollectionClone = GenJetShallowCloneProducer{
    InputTag src = iterativeCone5GenJets

Then a cut on the minimum $E_T$ is applied for reducing the number of objects in the collection (A typical jet collection contains tenths of jets, most of them with very low $E_T$ $\to$ not interesting for analysis):

# Selection of jets
  module caloJetSele = PtMinCandSelector{
    InputTag src = caloJetCollectionClone
    double ptMin        = 20.0

  module genJetSele = PtMinCandSelector{
    InputTag src = genJetCollectionClone
    double ptMin        = 20.0

Finally the 2 matching tools are called to save in the events the 2 MatchingMap:

# The matching routine OneToOne
  module jetMatchOne = CandOneToOneDeltaRMatcher {
    InputTag src      = genJetSele
    InputTag matched  = caloJetSele
    untracked bool printDebug = true

# The matching routine OneToMany
  module jetMatchMany = CandOneToManyDeltaRMatcher {
    InputTag src      = genJetSele
    InputTag matched  = caloJetSele
    untracked bool printDebug = true

One-To-One Matching

The One-To-One Matching is the typical operation for matching a collection of RecoGet to a collection of GenJet. In the One-To-One matching, each component of the first collection (InputTag src) is matched to a unique component of the second collection (InputTag matched) and viceversa. This means that the number of matched object is equal to the smaller collection and the bigger one has un-matched objects.

The metrics used for matching is $min(\Sigma_{ij}\Delta R)$, where $\Delta R = \sqrt{\Delta\eta^2+\Delta\phi^2}$. The sum is computed over all the ij possible combination of pairing an object of the first collection to an object of the second collection.

The number of combinations increase as n! where n is the number of objects in the bigger collection $\to$ the CPU time needed to check for all the combination can become extremely high: a Hard-Coded limit of 9 objects is implemented for performing the matching. To change this limit, the CMS.PhysicsTools/JetMCAlgos should be check-out and the file in the plugins directory has to be edited and recompiled.

  if( matched->size() > 9 || matched->size() <= 0 ) return;
  if( source->size()  > 9 || source->size()  <= 0 ) return;

This is an example of One-To-One matching with 2 collections (the src with 5 jets and the matched with 3 jets)

[CandOneToOneDeltaRMatcher] Et source  90.2919
[CandOneToOneDeltaRMatcher] Et source  55.8628
[CandOneToOneDeltaRMatcher] Et source  50.3346
[CandOneToOneDeltaRMatcher] Et source  41.4992
[CandOneToOneDeltaRMatcher] Et source  36.3017

[CandOneToOneDeltaRMatcher] Et matched 84.928
[CandOneToOneDeltaRMatcher] Et matched 72.3578
[CandOneToOneDeltaRMatcher] Et matched 53.4144

The $\Delta R$ matrix and the best combination is the following:

1.927 2.393 0.264 1.789 0.497
 2.682 0.567 2.188 0.418 1.642
 0.102 2.088 1.792 3.036 2.399
[CandOneToOneDeltaRMatcher] Best DeltaR=0.784598 230
[GenJetTest] (pt,eta,phi) source =  90.29 -2.13  1.31 matched =  53.41 -2.21  1.24 dR=0.102
[GenJetTest] (pt,eta,phi) source =  50.33 -1.87  3.00 matched =  84.93 -1.68 -3.11 dR=0.264
[GenJetTest] (pt,eta,phi) source =  41.50 -0.89 -1.50 matched =  72.36 -1.19 -1.21 dR=0.418

New OneToOne Matching tool

The OneToOne matching tool has been improved in order to have a more flexible routine. The new version includes the following changes:

  • No more limits on the number of elements in the source and matched collection (originally it was set to 9)
  • Three different methods are now available:
    1. Brute Force (BF - algoMethod=0 in the config file): the original method: be careful with it --> a large number of input objects (in the src or matched collection) could produce easily minutes (hours) of CPU time for processing. ( Not Suggested! if you don't know what you are doing)
    2. Switch Method (SM - algoMethod=1 in the config file): originally developed by Daniele Benedetti. There is no guarantee that you get the solution which minimize the sum of $\Delta R$, but is a good approximation and there is no CPU time problem (very quick algorithm).
    3. Mix Method (MM - algoMethod=2 in the config file): If the number of case to be checked by BF is lower than 10000, BF is used otherwise SM.
  • Two maps are now produced and saved: both key( src)->value( matched) map and viceversa... this allows for looking at the matched objects starting both from the src or the matched collection.

To have this new version of the OneToOne matching in CMSSW 16X you have to check-out version B160_V00-04-03 and re-compile (this new version will be present in CMSSW 170):

cvs co -r B160_V00-04-04 PhysicsTools/JetMCAlgos

An example on how to run the new producer ( CMS.PhysicsTools/JetMCAlgos/plugins/ is available in the test directory: is a simple analyzer and matchOneToOne.cfg is the config file to use.

One-To-Many Matching

The One-To-Many is simpler: each object of the second (matched) collection is matched to each object of the first (src) collection. The typical output of the One-To-Many matching using the same input is the following:

[GenJetTest] (pt,eta,phi) source =  90.29 -2.13  1.31
             (pt,eta,phi) matched =  53.41 -2.21  1.24 - dR= 0.10
             (pt,eta,phi) matched =  84.93 -1.68 -3.11 - dR= 1.93
             (pt,eta,phi) matched =  72.36 -1.19 -1.21 - dR= 2.68
[GenJetTest] (pt,eta,phi) source =  55.86 -1.48 -0.72
             (pt,eta,phi) matched =  72.36 -1.19 -1.21 - dR= 0.57
             (pt,eta,phi) matched =  53.41 -2.21  1.24 - dR= 2.09
             (pt,eta,phi) matched =  84.93 -1.68 -3.11 - dR= 2.39
[GenJetTest] (pt,eta,phi) source =  50.33 -1.87  3.00
             (pt,eta,phi) matched =  84.93 -1.68 -3.11 - dR= 0.26
             (pt,eta,phi) matched =  53.41 -2.21  1.24 - dR= 1.79
             (pt,eta,phi) matched =  72.36 -1.19 -1.21 - dR= 2.19
[GenJetTest] (pt,eta,phi) source =  41.50 -0.89 -1.50
             (pt,eta,phi) matched =  72.36 -1.19 -1.21 - dR= 0.42
             (pt,eta,phi) matched =  84.93 -1.68 -3.11 - dR= 1.79
             (pt,eta,phi) matched =  53.41 -2.21  1.24 - dR= 3.04
[GenJetTest] (pt,eta,phi) source =  36.30 -1.25 -2.85
             (pt,eta,phi) matched =  84.93 -1.68 -3.11 - dR= 0.50
             (pt,eta,phi) matched =  72.36 -1.19 -1.21 - dR= 1.64
             (pt,eta,phi) matched =  53.41 -2.21  1.24 - dR= 2.40


Review status

Reviewer/Editor and Date (copy from screen) Comments
-- RobertMHarris - 12 May 2008 Updated recommendation to use L2 + L3 instead of MC Jet
AttilioSantocchia - 30 Oct 2007 Matching Routines and True Jet Flavour updated for 160 (and 170 - 180)
JennyWilliams - 16 Oct 2007 minor tidying of twiki code
RobertMHarris - 15 Oct 2007 Fixed framework example to use JetAnalyzer_16x tag and Jet Corrections Example to work for 1.6.0
FedorRatnikov - 08 Oct 2007 created 160 reco page based on earlier instruction sets

Responsible: FedorRatnikov
Last reviewed by: Main.cgtully - 19 Dec 2006 (release 120 page)

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Immagine1.png r1 manage 17.6 K 2007-10-29 - 23:46 FedorRatnikov  
PNGpng Immagine2.png r1 manage 23.1 K 2007-10-29 - 23:47 FedorRatnikov  
GIFgif etaphi1.gif r1 manage 25.4 K 2007-10-29 - 22:50 FedorRatnikov  
GIFgif etaphi2.gif r1 manage 23.9 K 2007-10-29 - 22:51 FedorRatnikov  
GIFgif etavseta.gif r1 manage 9.7 K 2007-10-29 - 22:52 FedorRatnikov  
GIFgif etgen.gif r1 manage 11.5 K 2007-10-29 - 22:52 FedorRatnikov  
GIFgif etreco.gif r1 manage 12.2 K 2007-10-29 - 22:53 FedorRatnikov  
GIFgif etvset.gif r1 manage 10.5 K 2007-10-29 - 22:55 FedorRatnikov  
GIFgif phiminusphi.gif r1 manage 12.7 K 2007-10-29 - 22:55 FedorRatnikov  
GIFgif phivsphi.gif r1 manage 9.5 K 2007-10-29 - 22:56 FedorRatnikov  
PNGpng pigun_CaloJet.png r1 manage 76.0 K 2007-10-29 - 21:58 FedorRatnikov  
PNGpng pigun_CaloJet_fwlite.png r1 manage 123.0 K 2007-10-29 - 21:59 FedorRatnikov  
PNGpng pigun_GenJet.png r1 manage 69.3 K 2007-10-29 - 21:59 FedorRatnikov  
PNGpng pigun_GenJet_fwlite.png r1 manage 90.3 K 2007-10-29 - 22:00 FedorRatnikov  
PNGpng pigun_objects.png r1 manage 72.1 K 2007-10-29 - 22:00 FedorRatnikov  
Unknown file formatcfg reco-jetmet-allinone.cfg r1 manage 2.4 K 2007-10-19 - 22:12 FedorRatnikov PG configuration
Edit | Attach | Watch | Print version | History: r67 < r66 < r65 < r64 < r63 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r67 - 2008-10-15 - KonstantinosKousouris
    • 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