Jet Reconstruction in CMSSW 2_1_0

Complete: 2
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.

Jet Algorithms

Run Jet Reconstruction

The jet reconstruction procedure is run as part of the default reconstruction. In order to see final jets, one can simply run a full simulation and reconstruction step in order to see how CMSSW works. We simply use cmsDriver in order to:
  • Generating single pion events with fixed pT of about 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

In order to obtain such a python config file we run: SinglePiE50HCAL_cfi -s GEN,SIM,DIGI,L1,DIGI2RAW,RAW2DIGI,RECO -n 50 --no_exec
This should produce a config file called:
To run the full chain we simply run
> cmsRun
Note: you may want change settings like, the number of events, output filename, content, etc. in the config file. In order to learn about this, refer to the documentation of the python configs.

Jet Analysis


Data samples

In following examples we will explore two data samples. One file is SinglePiE50HCAL_cfi_GEN_SIM_DIGI_L1_DIGI2RAW_RAW2DIGI_RECO.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 SinglePiE50HCAL_cfi_GEN_SIM_DIGI_L1_DIGI2RAW_RAW2DIGI_RECO.root
root [0] TBrowser b;

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

for example CMS.CaloJets:

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

   root [2] Events->Draw("recoCaloJets_kt6CaloJets__RECO.obj.pt_");
produces transverse momentum 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

SISC5CaloJet = recoCaloJets_sis5ConeCaloJets_X (Seedless Cone,R=0.5,calorimeter jets)
SISC7CaloJet = recoCaloJets_sisCone7CaloJets_X (Seedless Cone, R=0.7, calorimeter jets)
IC5CaloJet = recoCaloJets_iterativeCone5CaloJets_X (Iterative Cone, R=0.5, calorimeter jets)
KT4CaloJet = recoCaloJets_kt4CaloJets_X (Kt, D=0.4, calorimeter jets)
KT6CaloJet = recoCaloJets_kt6CaloJets_X (Kt, D=0.6, calorimeter jets)

SISC5GenJet = recoGenJets_sisCone5CMS.CaloJets_X (Midpoint Cone,R=0.5,stable generator particle jets)
SISC7GenJet = recoGenJets_sisCone7CMS.CaloJets_X (Midpoint Cone, R=0.7, stable generator particle jets)
IC5GenJet = recoGenJets_iterativeCone5GenJets_X (Iterative Cone, R=0.5, stable generator particle jets)
KT4GenJet = recoGenJets_4GenJets_X (Kt, D=0.4, stable generator particle jets)
KT6GenJet = recoGenJets_6GenJets_X (Kt, D=0.6, stable generator particle jets)

'Calorimeter jets' means jets from so called CaloTowers, produced from Hcal and Ecal cells. 'Stable generator particles' means particles marked as stable by the generator, excluding prompt muons and neutrinos from resonances (W,Z,etc.), as they won't give you a jet. 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 transverse momentum distribution as in previous section may be plot using alias for the branch:

  root [2] Events->Draw("KT6CaloJet.pt_");
Which currently only seems to work using FWLite, described below.

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("KT6CaloJet"));
will get the branch corresponding to the alias "KT6CaloJet" for the root tree called "tree", which does not exist in the current example.

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 ("SinglePiE50HCAL_cfi_GEN_SIM_DIGI_L1_DIGI2RAW_RAW2DIGI_RECO.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 the file produced in the previous steps, if you like to use anther file, change analyzeJets_head.C accordingly. This example is currently broken, due to broken FWLite in CMSSW_2_1_6.

Access from Framework

The following example demonstrates use of an EDAnalyzer for CMS.CaloJets, GenJets and PFJets. It analyzes the simulated QCD data file: _'/store/relval/CMSSW_2_1_2/RelValQCD_Pt_80_120/GEN-SIM-DIGI-RAW-HLTDEBUG-RECO/ IDEAL_V6_10TeV_v7/0000/044A7A03-BE6E-DD11-B3C0-000423D98B08.root'_

Instructions to get and compile the code:

scramv1 project CMSSW CMSSW_2_1_9
cd CMSSW_2_1_9/src
eval `scramv1 runtime -csh`
cmscvsroot CMSSW 
cvs co -r  V00-04-04 RecoJets/JetAnalyzers
cd RecoJets/JetAnalyzers
scramv1 b
Then run the example:
cd test
The analysis is done by the template class which can handle CMS.CaloJets, GenJets or PFJets. It loops over a configurable number of leading jets in the event, makes some basic histograms, and writes them to a file. The jet reconstruction algorithm read from the event is specified by the label JetAlgorithm in the configuration file

In this example, the iterativeCone5 algorithm is chosen, but other algorithms should work as well, provided jets from those algorithms are reconstructed in the event. Browsing the input data file in ROOT is a straightforward way to see what jet algorithms are currently available and what their label is (the second field Y in the branch name X_Y_Z). 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.

The particular example consists of three identical modules, each one of which is a specific instance of the template class, in order to handle CMS.CaloJets, GenJets and PFJets. Each module requires some configurable parameters: the jet algorithm (JetAlgorithm), the name of the output ROOT file (HistoFileName) and the number of leading jets in the event that will be analyzed (NJets). Apparently, the user can modify the path to ask for only one or two modules (e.g. if the user wants to analyze a real data file only CMS.CaloJets and PFJets will be available).


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 Energy Corrections

Contribution of Konstantinos Kousouris


The calorimeter response to particles is not linear and therefore it is not straightforward to translate the measured jet energy to the true particle or parton energy. The jet corrections are a set of tools that allows the proper mapping of the measured jet energy deposition to the analysis desired level (particle or parton). In the following sections we describe the CMS strategy for jet energy corrections, present their technical implementation in CMSSW and provide specific examples that cover the majority of the reasonable user cases.

Factorized Approach

CMS has adopted a factorized solution to the problem of jet energy corrections, where each level of correction takes care of a different effect. The motivation behind this approach and the details of the jet corrections' derivation, both from MC truth and data driven methods, can be found in the references here: JEC subgroup TWiki of which CMS-AN-2007/055 is the principal one. At this point, two important points must be emphasized:

  • each level of correction is essentially a scaling of the jet four momentum with a scale factor (correction) which depends on various jet related quantities (pt, eta, flavor, etc.).
  • the levels of correction are applied sequentially (the output of each step is the input to the next) and with fixed order.

L2 Relative Jet Correction

The goal of the L2 Relative correction is to make the jet response flat vs eta. Essentially, the uniformity in pseudorapidity is achieved by correcting a jet in arbitrary eta relative to a jet in the central region (|eta|<1.3). The derivation of the Relative correction is done either by using MC truth or by employing a data driven method (dijet balance).

L3 Absolute Jet Correction

The goal of the L3 Absolute correction is to make the jet response flat vs pt. Once a jet has been corrected for eta dependence (L2 relative correction), it is corrected back to particle level (this means that the corrected CaloJet pt is equal on average to the GenJet pt). The derivation of the Absolute correction is done either by using MC truth information or by employing data driven techniques (Z/gamma+jet balance).

The combination of L2(Relative)+L3(Absolute) jet corrections is required and is currently the default correction in CMS.

L4 EMF (electromagnetic energy fraction) Jet Correction

Contribution of Selda Esen

The goal of the optional L4 EMF jet correction is to make the jet response uniform vs the electromagnetic energy fraction (EMF). It is a residual correction on top of the default L2+L3 and it has been shown to improve the jet resolution.

L5 Jet Flavor Correction

Contribution of Jochen Cammin

The goal of the optional L5 Flavor jet correction is to correct for the jet flavor dependence. It is applied on top of the default L2+L3 jet correction and corrects back to the particle level

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 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.

L7 Parton Jet Correction

Contribution of Attilio Santocchia

The optional L7 parton correction is applied on top of the default L2+L3 correction and corrects back to the parton level, which means that the corrected CaloJet pt is equal to the originating parton pt on average.

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 (theResponseFunction.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

Applying the Jet Energy Corrections

Jet Correction Service

The foundamental unit for the application of jet corrections is the Jet Correction Service. There is one service per level of correction plus a chain service that allows to apply several corrections sequentially. The typical structure of a service is the following (example with L2 Relative correction):
L2JetCorrectorIC5Calo = cms.ESSource("L2RelativeCorrectionService", 
      tagName = cms.string(Summer08Redigi_L2Relative_IC5Calo'),
      label = cms.string('L2RelativeJetCorrectorIC5Calo')
In the above definition, the tagName is the actual filename that contains the correction parametrization and by default it lies in CondFormats/JetMETObjects/data. The parameters' filename typically specifies the set used for the derivation of the correction (Summer08Redigi), the level of correction (L2Relative), the jet algorithm (IC5) and the jet type (Calo).

Modular application: corrected jet collection

Once a jet correction service has been defined, as described above, the correction can be applied to create a corrected jet collection. More specifically, in every event all the jets are corrected and put into the event as a new collection. The corrected jet collection is sorted in decreasing pt. With this method, analysis must be done using the corrected jet collection. A typical module that produces the correction is the following:
process.L2CorJetIC5Calo = cms.EDProducer("CaloJetCorrectionProducer",
    src = cms.InputTag("iterativeCone5CMS.CaloJets"),
    correctors = cms.vstring('L2JetCorrectorIC5Calo')
The corrected collection producer is templated to account for both CMS.CaloJets and PFJets. The two instances are named CaloJetCorrectionProducer and PFJetCorrectionProducer. In the above definition, the src is the name of the jet collection where the correction will be applied and the correctors is the name of the predefined correction service. Apparently, this module must be called in the execution path before the user analyzer.

Correcting jets "on the fly"

By the term "on the fly" we mean that the jet correction is applied jet by jet in the user analysis code. It is essential that the name of the predefined jet correction service is passed as a parameter to the user analyzer. Below is the part of a user analyzer that applies the correction "on the fly":
edm::Handle<CaloJetCollection> jets;                       //define input jet collection
Event.getByLabel (jetCollectionName, jets);              //get input jet collection
const JetCorrector* corrector = JetCorrector::getJetCorrector (JetCorrectionService,EvtSetup);   //Define the jet corrector
for (CaloJetCollection::const_iterator jet = jets->begin(); jet != jets->end(); jet++) 
      CaloJet  correctedJet = *jet;                                 //copy original jet
      double scale = corrector->correction(jet->p4());  //calculate the correction
      correctedJet.scaleEnergy(scale);                        // apply correction
IMPORTANT: after applying corrections "on the fly", the resulting jets are NOT sorted by pt.


Contribution of Konstantinos Kousouris

  • Instructions for CMSSW_2_1_X
    • Tags:
            V01-06-05 CondFormats/JetMETObjects
            V01-08-10 JetMETCorrections/Configuration
            V02-09-00 JetMETCorrections/Modules
    • Configuration File:

  • Instructions for CMSSW_2_2_X ( X < 7)
    • Tags:
            V01-07-02 CondFormats/JetMETObjects
            V01-08-13 JetMETCorrections/Configuration
            V02-09-02 JetMETCorrections/Modules
            V01-08-00 JetMETCorrections/Algorithms
    • Configuration File:
      IMPORTANT: users that are interested in applying the JetPlusTrack correction (and its residual L2+L3) on the Winter09 samples should also checkout the following package
            V01-04-03 RecoJets/JetAssociationAlgorithms
      in addition to those described above.

  • Instructions for CMSSW_2_2_7 (and higher)
    • Tags: All the tags described above are part of the CMSSW_2_2_7 release and NO ADDITIONAL tag is needed.
    • Configuration File: The recommended sets of corrections are:
      • Summer08Redigi for Summer08, Fall08 and Summer08Redigi samples (FULL simulation).
      • Winter09 for Winter09 samples (FAST simulation).

  • Instructions for CMSSW_3_1_2
    • Tags:
            V01-08-08 CondFormats/JetMETObjects
            V01-08-21 JetMETCorrections/Configuration
            V02-09-05 JetMETCorrections/Modules
            V01-08-04-01 JetMETCorrections/Algorithms
    • Configuration File:

  • Instructions for CMSSW_3_1_4
    • Tags:
            V01-08-08-02 CondFormats/JetMETObjects
            V01-08-21-01 JetMETCorrections/Configuration
    • Configuration File:

  • Instructions for Summer09,Summer09@7TeV samples with CMSSW_3_3_4
    • Tags:
            No tags needed. Everything is in the release.
    • Configuration File:

  • Instructions for samples reconstructed with CMSSW_3_3_2 and higher (new jet reco thresholds)
    • Release: CMSSW_3_3_4
    • Tags:
            V01-08-08-06 CondFormats/JetMETObjects
            V01-08-23-04 JetMETCorrections/Configuration
    • Configuration File:

  • Instructions for 900 GeV samples AND data !!!
    • Release: CMSSW_3_3_5
    • Tags:
            V01-08-08-09 CondFormats/JetMETObjects
            V01-08-23-05 JetMETCorrections/Configuration
    • Configuration File:

  • Instructions for 2360 GeV samples AND data !!!
    • Release: CMSSW_3_3_5
    • Tags:
            V01-08-08-09 CondFormats/JetMETObjects
            V01-08-23-05 JetMETCorrections/Configuration
    • Configuration File:

Naming Scheme

Both calorimeter jets (Calo) and particle flow jets (PF) are supported, for all the default reconstructed jet algorithms in the official samples (IC5,SC5,SC7,KT4,KT6,AK5,AK7). In addition there are also available corrections on top of the JetPlusTrack algorithm. The names of the corrected jet collections (identical naming scheme in Summer08, Summer08Redigi, Winter09, Summer09, Summer09_7TeV, Summer09_7TeV_ReReco332, 900GeV, 2360GeV set of corrections) are listed below:

  • L2L3CorJetIC5Calo (iterative cone R=0.5 CMS.CaloJets corrected with L2+L3)
  • L2L3CorJetIC5PF (iterative cone R=0.5 PFlow Jets corrected with L2+L3)
  • L2L3CorJetIC5JPT (iterative cone R=0.5 CMS.CaloJets corrected with JetPusTrack and a residual L2+L3) Only in Summer08Redigi and Winter09!!!
  • L2L3CorJetSC5Calo (SISCone R=0.5 CMS.CaloJets corrected with L2+L3)
  • L2L3CorJetSC5PF (SISCone R=0.5 PFlow Jets corrected with L2+L3)
  • L2L3CorJetSC7Calo (SISCone R=0.7 CMS.CaloJets corrected with L2+L3)
  • L2L3CorJetSC7PF (SISCone R=0.7 PFlow Jets corrected with L2+L3)
  • L2L3CorJetKT4Calo (KT D=0.4 CMS.CaloJets corrected with L2+L3)
  • L2L3CorJetKT4PF (KT D=0.4 PFlow Jets corrected with L2+L3)
  • L2L3CorJetKT6Calo (KT D=0.6 CMS.CaloJets corrected with L2+L3)
  • L2L3CorJetKT6PF (KT D=0.6 PFlow Jets corrected with L2+L3)
  • L2L3CorJetAK5Calo (anti-KT D=0.5 Calo Jets corrected with L2+L3)
  • L2L3CorJetAK5PF (anti-KT D=0.5 Calo Jets corrected with L2+L3)
  • L2L3CorJetAK7Calo (anti-KT D=0.7 Calo Jets corrected with L2+L3) *Only after L2L3Corrections_Summer09_7TeV_cff *
  • L2L3CorJetAK7PF (anti-KT D=0.7 Calo Jets corrected with L2+L3) *Only after L2L3Corrections_Summer09_7TeV_cff *


Illustrated examples can be found in the RecoJets/JetAnalyzers package:

V00-04-08 RecoJets/JetAnalyzers

The default correction example which should be used by most users is in RecoJets/JetAnalyzers/test . (Further examples showing the use of L4, L5, L7 are given later in this section). Putting together all the above instructions, the full prescription for running this example is:

  • CMSSW_2_1_9 (Summer08-FullSim)
       cmsrel CMSSW_2_1_9 
       cd CMSSW_2_1_9/src
       cvs co -r V01-06-05 CondFormats/JetMETObjects
       cvs co -r V01-08-10 JetMETCorrections/Configuration
       cvs co -r V02-09-00 JetMETCorrections/Modules
       cvs co -r V00-04-06 RecoJets/JetAnalyzers
       scram b
       cd RecoJets/JetAnalyzers/test
  • CMSSW_2_2_3 (Summer08-redigi-FullSim)
       cmsrel CMSSW_2_2_3 
       cd CMSSW_2_2_3/src
       cvs co -r V01-07-02 CondFormats/JetMETObjects
       cvs co -r V01-08-13 JetMETCorrections/Configuration
       cvs co -r V02-09-02 JetMETCorrections/Modules
       cvs co -r V01-08-00 JetMETCorrections/Algorithms
       cvs co -r V00-04-06-01 RecoJets/JetAnalyzers
       scram b
       cd RecoJets/JetAnalyzers/test
  • CMSSW_2_2_3 (Winter09-FastSim)
       cmsrel CMSSW_2_2_3 
       cd CMSSW_2_2_3/src
       cvs co -r V01-07-02 CondFormats/JetMETObjects
       cvs co -r V01-08-13 JetMETCorrections/Configuration
       cvs co -r V02-09-02 JetMETCorrections/Modules
       cvs co -r V01-08-00 JetMETCorrections/Algorithms
       cvs co -r V00-04-06-01 RecoJets/JetAnalyzers
       scram b
       cd RecoJets/JetAnalyzers/test
  • CMSSW_2_2_7 (Summer08Redigi & Winter09)
       cmsrel CMSSW_2_2_7 
       cd CMSSW_2_2_7/src
       cvs co -r V00-04-06-01 RecoJets/JetAnalyzers
       scram b
       cd RecoJets/JetAnalyzers/test
    how to run the L2+L3 correction on top of the JetPlusTrack correction
       cmsrel CMSSW_2_2_7 
       cd CMSSW_2_2_7/src
       cvs co -r V00-04-06-01 RecoJets/JetAnalyzers
       cvs co -r V01-04-03 RecoJets/JetAssociationAlgorithms
       scram b
       cd RecoJets/JetAnalyzers/test
  • CMSSW_3_1_2 (Summer09)
       cmsrel CMSSW_3_1_2 
       cd CMSSW_3_1_2/src
       cvs co -r V01-08-08 CondFormats/JetMETObjects
       cvs co -r V01-08-21 JetMETCorrections/Configuration
       cvs co -r V02-09-05 JetMETCorrections/Modules
       cvs co -r V01-08-04-01 JetMETCorrections/Algorithms
       cvs co -r V00-04-08 RecoJets/JetAnalyzers
       scram b
       cd RecoJets/JetAnalyzers/test
  • CMSSW_3_1_4 (Summer09)
       cmsrel CMSSW_3_1_4 
       cd CMSSW_3_1_4/src
       cvs co -r V01-08-08-02 CondFormats/JetMETObjects
       cvs co -r V01-08-21-01 JetMETCorrections/Configuration
       cvs co -r V00-04-08 RecoJets/JetAnalyzers
       scram b
       cd RecoJets/JetAnalyzers/test

The above example runs on 100 events, corrects all the CMS.CaloJets in the events, histograms the two leading CMS.CaloJets, and writes out these histograms files:

  • CaloJetHisto.root contains histograms of the two leading CMS.CaloJets before L2+L3 corrrections.
  • CorJetHisto.root contains histograms of the two leading CMS.CaloJets after L2+L3 corrections.

The full list of examples currently available in RecoJets/JetAnalyzers/test are:

  • (default L2+L3 jet corrections by creating corrected jet collections).
  • (default L2+L3 jet corrections applied "on the fly").
  • (default L2+L3 jet corrections applied on top of the JetPlusTrack correction).
  • (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 listed 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('Summer08Redigi_L2Relative_IC5Calo'),
label = cms.string('L2RelativeJetCorrector')
############# Define the L3 correction service #####
process.L3JetCorrector = cms.ESSource("L3AbsoluteCorrectionService",
tagName = cms.string('Summer08Redigi_L3Absolute_IC5calo'),
label = cms.string('L3AbsoluteJetCorrector')
############# Define the L5 correction service #####
process.L5JetCorrector = cms.ESSource("L5FlavorCorrectionService",
section = cms.string('qJ'), // The available options are: "qJ","gJ","cJ","bJ","gT","qT","cT","bT"
tagName = cms.string('L5Flavor_IC5'),
label = cms.string('L5FlavorJetCorrector')
############# Define the L7 correction service #####
process.L7JetCorrector = cms.ESSource("L7PartonCorrectionService",
section = cms.string('qJ'), // The available options are: "qJ","gJ","cJ","bJ","jJ","qT","cT","bT","tT"
tagName = cms.string('L7Parton_IC5'),
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: 900GeV, 2360GeV, Summer09_7TeV_ReReco332, Summer09_7TeV, Summer09, Winter09, Summer08Redigi, Summer08).

Jet Energy Corrections in FWLite

Simple jet corrections, that are corrections which are dependent from jet properties only, may be directly accessed from ROOT scripts running in FWLite environment. The class that delivers the jet correction is called CombinedJetCorrector and is located in the CondFormats/JetMETObjects package. In order to get the class, the following cvs checkout is necessary (works in the CMSSW_2_2_X releases and above):

cvs co -r V01-08-03 CondFormats/JetMETObjects

Once the package is checked out and compiled, the CombinedJetCorrector class will be loaded in a ROOT macro with the rest of the FWLite libraries.

  • Step by step instructions for use in a ROOT macro.
    • Step1: load the FWLite libraries:
    • Step2: define an object of the class CombinedJetCorrector . There are 2 constructors:
   string Levels = "L2:L3";
   string Tags = "Summer08Redigi_L2Relative_IC5Calo:Summer08Redigi_L3Absolute_IC5Calo";
   CombinedJetCorrector *L2L3JetCorrector = new CombinedJetCorrector(Levels,Tags);
or string Levels = "L2:L3:L7";
string Tags = "Summer08Redigi_L2Relative_IC5Calo:Summer08Redigi_L3Absolute_IC5Calo:L7Parton_IC5";
string Options = "Parton:gJ";
CombinedJetCorrector *L2L3L7JetCorrector = new CombinedJetCorrector(Levels,Tags,Options);
  • The string Levels defines which corrections will be applied. IMPORTANT: the order maters !!!!.
  • The string Tags defines the specific tags for each level of correction. The available tags can be found in CondFormats/JetMETObjects/data
  • The string Options defines the L5 Flavor option ("qJ","gJ","cJ","bJ","gT","qT","cT","bT") and/or the L7 Parton Option ("qJ","gJ","cJ","bJ","jJ","qT","cT","bT","tT"). If both L5 and L7 are requested:
   string Options = "Parton:gJ & Flavor:gJ"
    • Step3: get the correction factor or the vector with the individual corrections:
   double correction = L2L3JetCorrector->getCorrection(pt,eta,energy);
   vector<double> factors = L2L3JetCorrector->getSubCorrections(pt,eta,energy);
If the L4 EMF correction is requested, the above commands become:
   double correction = L2L3JetCorrector->getCorrection(pt,eta,energy,emf);
   vector<double> factors = L2L3JetCorrector->getSubCorrections(pt,eta,energy,emf);
IMPORTANT: the getSubCorrections member function returns the vector of the subcorrections UP to the given level. For example in the second constructor above (with L2, L3 & L7), factors[0] is the L2 correction, factors[1] is the L2+L3 correction and factors[2] is the L2+L3+L7 correction.

A full example ROOT macro is: CondFormats/JetMETObjects/test/TestCorrections.C

Jet Energy Corrections in PAT

Visit the PAT link:

Contribution of Sasha Nikitenko and Olga Kodolova No permission to view CMS.JetPlusTracksCorrections

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 Aug 2009 Added link to jet algorithms page
RobertMHarris - 10 Mar 2009 Updated Jet Plots Example instructino to use 2_1_9
RobertMHarris - 09 Sep 2008 Minor additions to instructions for jet corrections in CMSSW_2_1_X
KonstantinosKousouris - 09 Sep 2008 Updated instructions for jet corrections in CMSSW_2_1_X
KonstantinosKousouris - 04 Sep 2008 Updated example of simple jet analysis in CMSSW_2_1_X
KonstantinosKousouris - 01 Sep 2008 Updated instructions for jet corrections in CMSSW_2_1_X
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: SalvatoreRoccoRappoccio
Last reviewed by: Main.cgtully - 19 Dec 2006 (release 120 page)

-- AndreasOehler - 02 Sep 2008

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng piGun_CaloJet_fwlite.png r1 manage 42.6 K 2008-09-04 - 11:50 AndreasOehler  
PNGpng piGun_CaloJets.png r1 manage 59.6 K 2008-09-04 - 11:28 AndreasOehler  
PNGpng piGun_ptDist.png r1 manage 25.1 K 2008-09-04 - 11:29 AndreasOehler  
PNGpng pigunObjects.png r1 manage 58.2 K 2008-09-04 - 11:28 AndreasOehler  
Edit | Attach | Watch | Print version | History: r41 < r40 < r39 < r38 < r37 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r41 - 2010-11-01 - NasufSonmez
    • 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