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

• CMS.JetMET,
• Egamma,
• Muon,
• Tau,
• BJet,
• cross channel and
• special.

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