PAT Howtos
Collects the frequently asked questions and turns them into "How to...?".
General
How can I turn on the cleaner summary?
Date: 22/05/2008 ---
CMSSW version: any version before CMSSW_2_1_6 (
i.e., using the old configuration language)
This is "just" a matter of
configuring the MessageLogger
(an art in itself). By default, the MessageLogger will suppress INFO messages (but it kindly tells you in its summary).
In the previous PAT configuration files, there was some inconsistency in the MessageLogger configuration. This can be fixed by adding the following lines to the configuration file:
# initialize MessageLogger
include "FWCore/MessageLogger/data/MessageLogger.cfi"
replace MessageLogger.cerr.threshold = "INFO"
replace MessageLogger.categories += "PATLayer0Summary"
replace MessageLogger.cerr.INFO = {
untracked PSet default = { untracked int32 limit = 0 }
untracked PSet PATLayer0Summary = { untracked int32 limit = -1 }
}
This will just turn on the summary. If one wants
all INFO messages to be printed out, one can do instead:
# initialize MessageLogger
include "FWCore/MessageLogger/data/MessageLogger.cfi"
replace MessageLogger.cerr.threshold = "INFO"
replace MessageLogger.cerr.INFO.limit = -1
(but this could be very noisy...).
Edited by: FredericRonga
How can I run the PAT on RECO? Do I need to produce AODs first?
Date: 08/05/2008 ---
CMSSW version: any
AOD is a subset of RECO: if the PAT runs on AOD, it will also run on RECO. No need to convert from one to the other.
Edited by: FredericRonga
How can I get the Particle Flow candidates in PAT?
Date: 16/02/2009 ---
CMSSW version: > 2_2_3
The Particle Flow interface to PAT is called PF2PAT, and all relevant information can be found under
SWGuidePF2PAT.
How can I run PF2PAT and Standard PAT in one config?
See here for instructions:
https://twiki.cern.ch/twiki/bin/view/CMS/SWGuidePF2PAT#Particle_flow_in_the_PAT_PF2PAT
Edited by: FredericRonga
How can I run PAT on "real" data and switch off Monte Carlo matching?
CMSSW version: from 2_X
Add the following to your configuration file:
process.patHighLevelReco_withoutPFTau.remove( process.patJetFlavourId )
process.patLayer0_withoutTrigMatch.remove( process.patMCTruth )
process.allLayer1Muons.addGenMatch = False
process.allLayer1Photons.addGenMatch = False
process.allLayer1Electrons.addGenMatch = False
process.allLayer1Jets.addGenPartonMatch = False
process.allLayer1Jets.addGenJetMatch = False
process.allLayer1Jets.getJetMCFlavour = False
process.allLayer1METs.addGenMET = False
Note: this assumes the data was reconstructed with the standard sequence (not the cosmic muon reconstruction).
CMSSW version: from 3_X
The configuration tool has preset python functions to do this.
from CMS.PhysicsTools.PatAlgos.tools.coreTools import *
removeMCMatching(process, 'All')
Issues related to CMSSW Version
CMSSW_2_2_X
CMSSW_3_1_X
It is currently recommended to switch from CMSSW_3_1_X to CMSSW_3_3_X. The CMSSW_3_3_X releases have significant improvements from the framework in terms of processing speed and our most thoroughly tested configurations and examples are done with CMSSW_3_3_X.
CMSSW_3_3_X
Running PAT in 3.3.X on a sample produced with 3.1.x
An example of how to do this is
here
.
The critical piece is to add this to your config file:
from CMS.PhysicsTools.PatAlgos.tools.cmsswVersionTools import *
# run the 3.3.x software on Summer 09 MC from 3.1.x:
# - change the name from "ak" (3.3.x) to "antikt) (3.1.x)
# - run jet ID (not run in 3.1.x)
run33xOn31xMC( process,
jetSrc = cms.InputTag("antikt5CMS.CaloJets"),
jetIdTag = "antikt5"
)
This will switch the default PAT sequence JEC from "ak5" to "antikt5" (this is due to an incorrect assignment of the name in 3.1.x).
Running PAT in 3.3.X on a sample re-recoed from 3.1.x samples, in 3.3.x
To run the PAT on MC samples from 3.1.x that have been re-recoed with 3.3.x, it is necessary to run the
GenJet sequence for anti-kt jets (again because the name was incorrectly assigned in 3.1.x).
An example is shown
here
.
The critical piece is to add this to your config file:
from CMS.PhysicsTools.PatAlgos.tools.cmsswVersionTools import *
# run the 3.3.x software on Summer 09 MC from 3.1.x,
# re-recoed with 3.3.2:
# - Run GenJets for process in question
run33xOnReRecoMC( process, "ak5GenJets" )
Switching JEC to the 900 or 2360 GeV corrections
The jet corrections from 7
TeV MC are inadequate for 900 and 2360
GeV data and MC due to different particle contents. To run the latest JEC on the latest data, use release CMSSW_3_3_4 or higher, with the following tags:
addpkg CondFormats/JetMETObjects V01-08-08-09
addpkg JetMETCorrections/Configuration V01-08-23-05
The JEC are then switched in the configuration by:
from CMS.PhysicsTools.PatAlgos.tools.jetTools import *
switchJECSet( process, "2360GeV")
or
from CMS.PhysicsTools.PatAlgos.tools.jetTools import *
switchJECSet( process, "900GeV")
CMSSW_3_6_X
Running PAT in 3.5.X sample
To run the PAT on MC samples from 3.1.x that have been re-digied and/or re-recoed with 3.5.x,
it is necessary to run the
GenJet sequence for anti-kt jets (again because the name was incorrectly assigned in 3.1.x).
Furthermore, the b-tagging sequences have changed in 36x so this module will run them also.
The critical piece is to add this to your config file for MC is:
from CMS.PhysicsTools.PatAlgos.tools.cmsswVersionTools import *
run36xOn35xInput(process,
genJets = "ak5GenJets")
If you are running
PF2PAT on an MC sample, add the postfix that you've chosen (for instance, "PF2PAT"):
run36xOn35xInput(process,
genJets = "ak5GenJets",
postfix = "PF2PAT")
If you are running data, omit the genJets:
run36xOn35xInput(process)
Flagging and keeping "bad objets" separately
How can I retrieve the flag of an object?
Date: 06 Jun 2008 ---
CMSSW version: any
The flag (bit mask) is stored in the
status()
method of the PAT objects. You can use the
pat::Flag
interface to decode them:
#include "DataFormats/PatCandidates/interface/Flags.h"
[...]
const reco::Jet & jet = jets[i];
if (pat::Flags::test(jet, pat::Flags::Overlap::Electrons)) {
// the jet does not overlap with electrons
} else {
// the jet is overlapping with electrons
}
More information about the flags under
SWGuidePatFlagDefinitions.
Edited by: FredericRonga
PAT objects
How can I retrieve the reference to the original object from my pat::Object
?
99% of the times you don't need the original object, because its full contents will have been copied within the pat::Object.
Note also that:
- The original object might not be of the type you expect (e.g.
pat::Muon
produced from reco::PFCandidate
instead of reco::Muon
)
- You can get the original object only if it's still in the root file you're working with
- The "original object" is the PAT Layer 0 object, not the AOD one
The recipe to extract the original object depends on the CMSSW release.
For CMSSW 2_0_X and beyond
PAT Objects hold a generic reference to a Candidate
const pat::Muon &mu = .....
edm::Ptr<reco::Candidate> originalRef = mu.originalObjectRef();
You can then check if the original object is still in the root file with
originalRef.isAvailable()
and if you need you can try to convert it to some more specific object type with
dynamic_cast
const reco::Muon *originalMu = dynamic_cast<const reco::Muon *>(originalRef.get())
if (originalMu == 0) { ... sorry, this was not a reco::Muon object ... }
For CMSSW 1_6_X
const pat::Muon &mu = .....
edm::RefToBase<reco::Muon> originalRef = mu.originalObjectRef();
If you need you can try to convert it to some more specific object type with
dynamic_cast
edm::RefToBase<reco::Jet> originalRef = jet.originalObjectRef();
const reco::CaloJet *originalCaloJet = dynamic_cast<const reco::CaloJet *>(originalRef.get())
if (originalCaloJet == 0) { ... sorry, this was not a reco::CaloJet object ... }
Edited by: Clemens Zeidler,
GiovanniPetrucciani
How can I find the generator particle matched to the reconstructed particle?
Date: 23/04/2008 ---
CMSSW version: 1_6_X,
2_X
The PAT particle store a copy of the matched gen particle. Use the
genLepton()
for
pat::Lepton
const reco::Particle * genLepton() const;
and
genJet()
function for
pat::Jet
const reco::GenJet * genJet() const;
to get a pointer to the gen particle.
Sometimes you like to get a Ref of the gen particle in the
GenParticleCollection
and not just a copy. Here is a muon example:
edm::Handle<edm::View<pat::Muon> > recMuons;
iEvent.getByLabel("muons", recMuons);
edm::Handle<edm::Association<reco::GenParticleCollection> > genMatch;
iEvent.getByLabel("muonMatch", genMatch);
edm::RefToBase<pat::MuonType> muonRef = recMuons->refAt(id)->originalObjectRef();
reco::GenParticleRef genMuon = (*genMatch)[muonRef];
Important is here to use the
originalObjectRef()
function to get a
pat::MuonType
(is reco::Muon) Ref as a key for the edm::Association.
The match lable for electrons is "electronMatch" and "jetGenJetMatch" for jets.
Edited by: Clemens Zeidler
Particle identification
How can I select the "tight" cut-based electron ID?
Date: 16/06/2008 ---
CMSSW version: 1_6_X
Note: this is not applicable to 2_1 and greater, where the electron identification interface significantly was improved.
How electron ID is computed
The electron ID is stored as a map in the Event: for each electron, you get the result of the set of cuts (true or false). This is configured by:
EgammaAnalysis/ElectronIDProducers/data/electronId.cfi
which in turn includes:
EgammaAnalysis/ElectronIDProducers/data/cutBasedElectronId.cfi
EgammaAnalysis/ElectronIDProducers/data/ptdrElectronId.cfi
In the former, you will see that the default is PTDR cuts, and in the latter, that the default is "loose".
In the PAT, this is included with:
CMS.PhysicsTools/PatAlgos/data/recoLayer0/electronId.cff
where you can see that we actually also calculate electronIDRobust.
So the default electron ID (you get from
pat::Electron::leptonID()
)
is the PTDR, loose ID. (And you can also get the cut-based (non-PTDR)
robust ID with
pat::Electron::electronIDRobust().
)
How to change?
In order to have tight electron ID (from the new cut-based selection) accessible from
pat::Electron::leptonID()
, you need to add the following in your cfg file:
replace electronId.doPtdrId = false
replace electronId.doCutBased = true
replace CutBased_ID.electronQuality = "tight"
Edited by: FredericRonga
How can I access the electron ID likelihood from the PAT electron?
Date: 26/02/2009 ---
CMSSW version: 2_2_X (for PATv1)
The electron ID likelihood is not in the
pat::Electron
by default, but you can add it:
- run the module that produces that electron ID
process.load('RecoEgamma.ElectronIdentification.electronIdLikelihoodExt_cfi')
- add it in your path before
patLayer0
with
process.eidLikelihoodExt
- add it to the associations to re-key
process.patElectronIds.associations += [cms.InputTag("eidLikelihoodExt") ]
- add it into the PAT Electron
process.allLayer1Electrons.electronIDSources.eidLikelihood = cms.InputTag("patElectronIds","eidLikelihoodExt")
The likelihood will then be accessible with:
pat::Electron::electronID("eidLikelihoodExt")
.
Edited by: see
CMS.HyperNews thread
Date: 18/05/2009 ---
CMSSW version: 2_2_10+ (for PATv2)
- Use same configuration of PATv1 to produce electronLikelihood / add it to path.
- Do not need to re-key.
- add it into the PAT Electron:
process.allLayer1Electrons.electronIDSources.eidLikelihood = cms.InputTag("eidLikelihoodExt")
Jets
Changing Jet Energy correction set
CMSSW version: CMSSW_3_3_X
The
JetMET group provides different sets of jet energy corrections for samples produced under different conditions or with different software. You can change from the default set to another one using a python function
switchJETCSet
.
For example, to move from the default 7
TeV JEC to the 900
GeV JEC:
from CMS.PhysicsTools.PatAlgos.tools.jetTools import *
switchJECSet(process, "900GeV")
Edited by: SalvatoreRoccoRappoccio
In case of multiple sets jet energy corrections, this will change only the first one; this will be fixed as soon as possible.
Turning off Jet Corrections
CMSSW version: CMSSW_3_3_X
You can easily switch off the JEC by:
process.allLayer1Jets.addJetCorrFactors = False
You can also access the uncorrected jets in situ with:
double pt_raw = patJet->correctedJet("raw").pt();
Edited by: SalvatoreRoccoRappoccio
How can I change the jet collection (including PFJets, BasicJets)?
CMSSW version: CMSSW_2_1_X and newer
In 2.1.X the new python configuration makes it much easier to change the jet collections in PAT.
There is a simple function that can be called within the config file to switch the jet collection. This can be done by inserting just two lines after having loaded the PAT config files
from CMS.PhysicsTools.PatAlgos.tools.jetTools import *
switchJetCollection(process, "inputCollectionLabel" [, options])
The
inputCollectionLabel collection of jets should be already in the event before the PAT sequences are run, so unless it's in the AOD you should put the module to produce it before the PAT sequences in your path.

In PAT version 2 instead of specifying a string label you have to specify a
cms.InputTag
.
Examples: See
patLayer1_fromAOD_PFJets_full.cfg.py
and
patLayer1_fromAOD_sisCone_full.cfg.py
for switching to PFJets and to SISCone jets.
The options that you can specify (as
name = value) are
-
doBTagging
: run the BTagging on this jet collection (default is True
)
-
doJTA
: run jet-tracks association and jet charge; the default is True, and it is always True if you're running b-tagging.
-
jetCorrLabel
: choose the jet energy corrections appropriate for this jet. The format is a pair ('algo', 'type')
, where algo is something like IC5
, SC5
, KT4
, and type is Calo
or PF
.
You can set it to None
if you don't want any JEC for the jets.
-
doType1MET
: if you're applying JEC, and this option is True (the default), the jet energy scale corrections to PAT MET will be made from this new collection of jets.
If set to False, the MET will be still computed from IC5 CMS.CaloJets with the Icone5 jet corrector.
Due to limitations in POG software, this works only for CMS.CaloJets.
-
genJetCollection
: InputTag to a collections of GenJets to match against
-
layers
: by default this procedure is applied both to PAT Layer 0 and PAT Layer 1; if you're running only PAT Layer 0, you should set layers = [0]
.
For obvious reasons, this parameter no longer exists in PAT version 2
-
runCleaner
: choose which type of jet cleaner you want to run; the default value is "CaloJet"
, the other available options are "PFJet"
, "BasicJet"
. You can also specify None
(without quotes) for no cleaning at all.
The cleaner module will always be called allLayer0Jets
, even for PFJets or BasicJets.
For obvious reasons, also this parameter no longer exists in PAT version 2

If you want both to change jet energy correction set (e.g. from Summer08 to Winter09) and change the jet collection, you can perform the two operations in any order.
Edited by: GiovanniPetrucciani
How can I add a new jet collection (including PFJets, BasicJets)?
CMSSW version: CMSSW_2_1_X and newer
In 2.1.X the new python configuration makes it much easier to change the jet collections in PAT.
There is a simple function that can be called within the config file to add a jet collection.
You will have to specify a short label for it (e.g. 'Kt4'), which will be appended to the name of all collections referring to those jets (e.g. you will have
allLayer0JetsKt4
,
allLayer1JetsKt4
,
selectedLayer1JetsKt4
,
jetMatchKt4
...)
from CMS.PhysicsTools.PatAlgos.tools.jetTools import *
addJetCollection(process, "inputCollectionLabel", "yourLabel", [, options])

In PAT version 2 instead of specifying a string label you have to specify a
cms.InputTag
.
ORDER OF THE TASKS
- First call
switchJECSet
if you want to change jet energy correction set, as you will want to do this on all jets
- Then call
addJetCollection
to add the extra jets
- Finally if want to switch the default then you can call
switchJetCollection
DO NOT do things in a different order unless you
really know what you're doing, and in any case if you do it make sure to triple check your output config file.
Example : See
patLayer1_fromAOD_jetSuite_full.cfg.py
for an example with all possible options of jet collections at the same time: Calo, PF and Basic jets, with and without cleaning, both fully featured (with btagging & jet energy corrections) and bare (just the jets, MC and trigger matching)
The options are similar to the ones for
switchJetCollection
-
runCleaner
, doBTagging
, doJTA
, jetCorrLabel
, layers
, genJetCollection
: as described above for switchJetCollection
-
doL1Counters
: if set to True, this will also create two filter modules minLayer1JetsXyz
, maxLayer1JetsXyz
to accept/reject events using the number of jets of this collection (Xyz is your label). The default is False
-
doType1MET
: if you're applying JEC, and this option is True (the default), a new PAT MET will be produced in addition to the jet collection.
This feature runs but it has not yet been validated
Edited by: GiovanniPetrucciani
How do I access the value of the jet correction?
The
pat::Jets
are corrected by default. To see the correction, you can use this method:
float jecFactor(const unsigned int& level, const JetCorrFactors::Flavor& flavor=JetCorrFactors::NONE, const unsigned int& set=0) const;
or
float jecFactor(const unsigned int& level, const JetCorrFactors::Flavor& flavor=JetCorrFactors::NONE, const unsigned int& set=0) const;
The string and index correspond, in order, to what is in
jetCorrFactors_cfi.py
. So for instance, in 4.1.4:
'L1Offset', 'L2Relative', 'L3Absolute', 'L5Flavor', 'L7Parton'
To access the value of the current jet correction, do, for instance:
float corr = jet.jecFactor(1);
or
float corr = jet.jecFactor("L2Relative");
Old 2.0.X and 1.6.X recipes
How can I use another CaloJet collection instead of iterativeCone5CMS.CaloJets
In order to run PAT with another collection of CMS.CaloJets you need to replace some parameters in the configuration file and to re-run b-tagging on the new jets.
A working example config file is included in the PAT tests
patLayer1_fromAOD_sisCone_full.cfg
Here we will explain each step, taking as example the
sisCone5CMS.CaloJets
jets.
- Re-run b-tagging: the easiest way is to re-run the b-tagging sequence after replacing the InputTags to select your other jet collection. The only non trivial change is that you need to take away the
btagSoftElectrons
module from the sequence, as you can use the values already stored in AOD because they're independent from the jet collection (and it does not run on AOD, requires RECO)
// standard includes
include "RecoJets/JetAssociationProducers/data/ic5JetTracksAssociatorAtVertex.cfi"
include "RecoBTag/Configuration/data/RecoBTag.cff"
include "Configuration/StandardSequences/data/FrontierConditions_CMS.GlobalTag.cff" // check if this is correct for you
include "Configuration/StandardSequences/data/CMS.MagneticField.cff"
// replaces
replace ic5JetTracksAssociatorAtVertex.jets = sisCone5CMS.CaloJets
replace softElectronTagInfos.jets = sisCone5CMS.CaloJets
replace softMuonTagInfos.jets = sisCone5CMS.CaloJets
// b-tag sequence for AOD (same as standard btagging except no module btagSoftElectrons)
sequence btaggingAOD = { ( impactParameterTagInfos, ( jetBProbabilityBJetTags & jetProbabilityBJetTags & trackCountingHighPurBJetTags & trackCountingHighEffBJetTags & impactParameterMVABJetTags ) , secondaryVertexTagInfos, ( simpleSecondaryVertexBJetTags & combinedSecondaryVertexBJetTags & combinedSecondaryVertexMVABJetTags ) ) & ( softElectronTagInfos, softElectronBJetTags ) & ( softMuonTagInfos, ( softMuonBJetTags & softMuonNoIPBJetTags ) ) }
// sequence to run before patLayer0
sequence prePATreco = { ic5JetTracksAssociatorAtVertex, btaggingAOD }
- Re-configure PAT b-tagging and jet-tracks association. Even if the labels of the b-tagging discriminators are the usual ones, you need to specify which is the source jet collection, and to remove the tau-tagging discriminators from the list because you did not recompute them (and you can't recompute them on AOD)
replace patAODJetTracksAssociator.src = sisCone5CMS.CaloJets
replace patAODTagInfos.collection = sisCone5CMS.CaloJets
replace patAODBTags.collection = sisCone5CMS.CaloJets
replace patAODBTags.associations = {
trackCountingHighEffBJetTags, trackCountingHighPurBJetTags,
impactParameterMVABJetTags, jetBProbabilityBJetTags, jetProbabilityBJetTags,
simpleSecondaryVertexBJetTags,
combinedSecondaryVertexBJetTags, combinedSecondaryVertexMVABJetTags,
softElectronBJetTags, softMuonBJetTags, softMuonNoIPBJetTags
}
replace layer0BTags.associations = {
trackCountingHighEffBJetTags, trackCountingHighPurBJetTags,
impactParameterMVABJetTags, jetBProbabilityBJetTags, jetProbabilityBJetTags,
simpleSecondaryVertexBJetTags, combinedSecondaryVertexBJetTags,
combinedSecondaryVertexMVABJetTags,
softElectronBJetTags, softMuonBJetTags, softMuonNoIPBJetTags
}
- Re-configure JES corrections
replace jetCorrFactors.jetSource = sisCone5CMS.CaloJets
replace jetCorrFactors.defaultJetCorrector = "MCJetCorrectorScone5"
// there is no Type1 MET for sisCone, so you have to re-use the Icone one and replace the parameters
replace corMetType1Icone5.inputUncorJetsLabel = sisCone5CMS.CaloJets
replace corMetType1Icone5.corrector = "MCJetCorrectorScone5"
- Re-configure the PAT jet cleaner
replace allLayer0Jets.jetSource = sisCone5CMS.CaloJets
Edited by: GiovanniPetrucciani - 23 June 2008
How can I use CMS.ParticleFlow jets, or jets from tracks
Date: 28/04/2008 ---
CMSSW version: any version older than CMSSW_2_1_6 (
i.e., using the old configuration language)
At layer 0 there is one different Cleaner module for each specific jet type (CaloJet, PFJet, BasicJet) which can be configured exactly in the same way as the CaloJet cleaner; the PATJetProducer, instead, is an unique module that can read any
reco::Jet
list. As the PFJet case is probably the most popular one, a cleaner for those jets is already defined and configured in
cleaningLayer0/pfJetCleaner.cfi
even if it's not in the main sequence.
In order to run an additional cleaner in Layer 0 one has to manually break up the
patLayer0
or
patLayer0_TriggerMatch
sequence, and replace it with
patBeforeLevel0Reco,
patLayer0Cleaners,
allLayer0PFJets, # <<< your new jet cleaner
patHighLevelReco,
patMCTruth,
patL1, patHLT, # <<< this if you're using "TriggerMatch" layer 0
In addition to this you have, of course, to define your module except if you're using the pre-configured
allLayer0PFJets
module for cleaner.
Depending on whether you're using only the non-CMS.CaloJets or using both the CMS.CaloJets and the others then you might want to reconfigure or to clone some other layer 0 modules and the PATJetProducer. The recipe to switch from CMS.CaloJets to PFJets is
## MC Matching
replace jetPartonMatch.src = allLayer0PFJets
replace jetGenJetMatch.src = allLayer0PFJets
## Trigger Matching (1.6.X only, at the moment)
replace jetTrigMatchHLT1Jet.src = allLayer0PFJets
replace jetTrigMatchHLT2Jet.src = allLayer0PFJets
replace jetTrigMatchHLT3Jet.src = allLayer0PFJets
replace jetTrigMatchHLT4Jet.src = allLayer0PFJets
## Flavour Matching (2.0.X only, in 1.6.X it can't be done)
replace jetPartonAssociation.jets = allLayer0PFJets
## Track matching & jet charge
replace layer0JetTracksAssociator.src = allLayer0PFJets
replace layer0CMS.JetCharge.src = allLayer0PFJets
## Layer 1
replace allLayer1Jets.jetSource = allLayer0PFJets
replace allLayer1Jets.embedCaloTowers = false // meaningless for non-Calo jets
//replace allLayer1Jets.getJetMCFlavour = false // (uncomment in 1.6.X)
replace allLayer1Jets.addBTagInfo = false // you can set it to true only if you run your own b-tag on these jets
replace allLayer1Jets.addResolutions = false // data not available
replace allLayer1Jets.addJetCorrFactors = false // data not available
You can get a full example of PAT with PFJets in the test file
patLayer1_fromAOD_PFJets_full.cfg
Edited by: GiovanniPetrucciani
Missing Transverse Energy
How can I use the just PF MET without running the full PF2PAT
While there might be disagreements on whether this is correct from the physics point of view or not, it is possible to make a pat::MET from the PF MET without running the full
PF2PAT.
There is an example config file
patLayer1_fromAOD_PFMET_full.cfg.py
which allows you to produce an additional collection of pat::MET starting from pfMET (it will be called 'selectedLayer1PFMETs').
The config file is included in PAT from the tag
CMS.PhysicsTools/PatAlgos V04-14-16
An alternative is to totally replace the standard PAT MET ("selectedLayer1METs") with the one from pfMET; you can read how to do from the comments in the above cfg file - but at that point using full
PF2PAT is more consistent.
Edited by: GiovanniPetrucciani
Taus
How can I use the CaloTaus instead of PFTaus
There is an example config file
patLayer1_fromAOD_CaloTau_full.cfg.py
which allows you to produce a collection of pat::Tau starting from CaloTaus (it is called 'allLayer0CaloTaus' which is an input for 'allLayer1Taus' and subsequently to 'selectedLayer1Taus').
The config file is included in PAT from the tag
CMS.PhysicsTools/PatAlgos V04-00-00
Note that if you are using 2.2.X on top of the 2.1.X Summer08 samples, PAT
is already using CaloTau (and it prints it out at the beginning of that job) because the PFTau is not supported (you need the samples with re-digi 2.2.X)
Edited by: MichalBluj
Trigger matching
This documentation refers to PAT v1 (depricated) only.
For documentation on trigger information in PAT v2, look here.
How can I implement a match to trigger objects beside the examples coming with the PAT?
Edited by: VolkerAdler - 22 June 2008
CMSSW version: CMSSW_1_6_X
(For
CMSSW_2_X, this more simplified procedure is explained directly in the configuration file
patTrigProducer.cfi
)
Due to the wide spread of possible trigger configurations used in a CMS analysis, the
PAT trigger matching cannot serve all possibly needed configurations.
It rather offers some example prototypes of growing number and complexity
and this guideline, which should make it easy for the user to implement a match to the particular trigger(s) (s)he is interested in.
The
general description of the PAT trigger matching describes roughly the necessary modules and their configuration, but to create your own trigger match you need also some information on the trigger itself -- so, from the
outside.
In particular, it is said that "in principle, all what is needed are the names of the trigger path and filter module (for HLT) resp. the trigger name and the object type (for L1)".
But unfortunately the access to this information is not straight forward -- especially in case of the
HLT, for which it is descibed here first.
The given examples are the same as given in the general description: muons in
L1_SingleMu3
resp.
HLT1MuonNonIso
.
HLT
At first you have to specify the HLT path you want to explore.
A complete list of available paths is found
here, where you also can find links to more detailed trigger definitions for all
trigger groups
E.g., if looking for non-isolated muons (following the mentioned examples), you choose the
Muon trigger group and will find the HLT path
HLT1MuonNonIso
with a pT-threshold of 16
GeV and without isolation requirement.
After you have selected the HLT paths, you need to find the filter module you are interested in.
For this you have to browse the configuration files in the HLT code
.
In
HLTrigger/Configuration/data/main/
you can find several configuration files corresponding to the trigger groups.
In our example,
Muon.cff
is the starting point.
There you can find the path definition
include "HLTrigger/Muon/data/PathSingleMu_1032_NoIso.cff"
path HLT1MuonNonIso = { singleMuNoIso }
where you are pointed to the definition of the used sequence
singleMuNoIso
in
HLTrigger/Muon/data/PathSingleMu_1032_NoIso.cff
.
In that file, the sequence is defined by
sequence singleMuNoIso = {
#L1 muon
prescaleSingleMuNoIso &
l1muonreco & SingleMuNoIsoLevel1Seed & SingleMuNoIsoL1Filtered
#L2 muon
& l2muonreco & SingleMuNoIsoL2PreFiltered
#L3 muon
& l3muonreco & SingleMuNoIsoL3PreFiltered
}
and also the filter module definitions and configurations are found.
Here the module
SingleMuNoIsoL3PreFiltered
can be identified as the last run filter module in the chosen HLT path.
Now you have all necessary information to configure your
PATHLTProducer
, e.g. as:
module HLT1MuonNonIso = PATHLTProducer {
InputTag triggerResults = TriggerResults::HLT
string triggerName = "HLT1MuonNonIso" // the name of the chosen HLT path
InputTag filterName = SingleMuNoIsoL3PreFiltered::HLT // the InputTag corresponding to the filter module
}
Include this module in your PAT
layer0 path, and it will produce the required trigger primitives!
L1
Fortunately, the informations needed to build the
PATL1Producer
configuration is not as complicated as for HLT and the description given
here should be sufficient.
How can I switch off the default trigger matching in case I have no trigger information in my input file(s)?
Edited by: VolkerAdler - 18 December 2008
Missing trigger information in the input file(s) leads to a
cms::Exception
with the trigger matching switched on.
And the latter is the case for some example trigger matches by default.
In order to switch the trigger matching off, the
!PAT configuration file has to be changed from e.g.
process.load("CMS.PhysicsTools.PatAlgos.patLayer0_cff")
process.load("CMS.PhysicsTools.PatAlgos.patLayer1_cff")
process.p = cms.Path(
process.patLayer0*
process.patLayer1)
to
process.load("CMS.PhysicsTools.PatAlgos.patLayer0_cff")
process.load("CMS.PhysicsTools.PatAlgos.patLayer1_cff")
process.allLayer1Electrons.addTrigMatch = False
process.allLayer1Muons.addTrigMatch = False
process.allLayer1Jets.addTrigMatch = False
process.allLayer1METs.addTrigMatch = False
process.allLayer1Photons.addTrigMatch = False
process.allLayer1Taus.addTrigMatch = False
process.p = cms.Path(
process.patLayer0_withoutTrigMatch*
process.patLayer1)
Troubleshooting
I have a problem running on a sample produced with CMSSW_N using CMSSW_M (with M<N): can you help?
CMSSW version: Any
No. To quote an
authoritative answer
:
You should never expect an old release to be able to read newer data. THIS IS NOT SUPPORTED AT ALL,
you are just lucky if it works at all... within a release series there is no legitimate reason for not moving forward.
Edited by: FredericRonga - 24 Sep 2008
I would appreciate a reference to PAT cofiguration template to run over 354 data/MC
The template to run on CMSSW_3_5_X MC is
here
. It is included as a default in all the examples in
PhysicsTools/PatExamples
and
PhysicsTools/PatAlgos
packages. An example config file using this template is
patTuple_inputs_cfg.py
The latest
PAT tutorial in CMSSW_3_5_X
covers very nice examples
in all aspects of PAT usage - basic, MC matching, Cleaning, Trigger usage etc.
Edited by: SudhirMalik - 22 March 2010
How can I run on fast simulation samples produced with 1_6_X? (X≥8)
CMSSW version: CMSSW_1_6_12
patLayer1_fromAOD_fast.cfg
might fail when running on Fast Simulation samples produced with 1_6_8 or more recent:
RefCore: A request to resolve a reference to a product of type:
St6vectorIN4reco7PFBlockESaIS1_EE
can not be satisfied because the product cannot be found.
Probably the branch containing the product is not stored in the input file.
In short, this is due to a change in the default pfTau reconstruction sequence. Unfortunately there is no easy way of getting this working with a replace, because sequences can't be replaced. The shortest and cleanest thing you can do is to define:
sequence patLayer0_withoutTrigMatch_Famos1612 = {
patBeforeLevel0Reco_withoutPFTau,
pfRecoTauDiscriminationByIsolation,
patLayer0Cleaners,
patHighLevelReco,
patMCTruth
}
and use it in your CFG file instead of
patLayer0_withoutTrigMatch
.
Edited by: FredericRonga - 07 Jul 2008 (see
CMS.HyperNews thread
).
How can I run on early CSA07 samples?
CMSSW version: CMSSW_1_6_12
The following error can be encountered when running on some CSA07 samples:
---- ManyThingsToValueMaps BEGIN
Error in adapter muGlobalIsoDepositCalByAssociatorTowersecal
cms::Exception going through module MultipleIsoDepositsToValueMaps/patAODMuonIsolations run: 30012250 event: 6944
---- ManyThingsToValueMaps END
This most probably indicates that this sample was produced early in Summer 2007, and it does not contain all the necessary information. It is still possible to work around most of the problems with the following modification in the main
.cfg
file:
- modify the main sequence to add muon isolation and turn off trigger matching:
path p = {
patMuonIsolation,
patLayer0_withoutTrigMatch,
patLayer1
}
- turn off b-tagging information:
replace allLayer1Jets.addBTagInfo = false
- turn off trigger matching in the pat object producers:
replace allLayer1Electrons.addTrigMatch = false
replace allLayer1Muons.addTrigMatch = false
replace allLayer1Jets.addTrigMatch = false
replace allLayer1METs.addTrigMatch = false
replace allLayer1Photons.addTrigMatch = false
replace allLayer1Taus.addTrigMatch = false
Obviously, trigger matching and b-tagging will not be available.
Edited by: FredericRonga - 30 Jul 2008