WARNING: This twiki is outdated , please refer to the main PAT twiki SWGuidePAT

PAT - Layer 1

Complete: 2

Purpose

The Layer 1 transforms the output of Layer 0 in a set of compact objects which are described here. An ordering of the various output collections is also performed, as described below for each object.

TIP More information on these objects and their producers can be found in the Reference Manual (pull down your release, go to Namespaces and choose the pat namespace).

Overview

Layer 1 PAT objects inherit from AOD high level physics objects (except those which only exists in the PAT) and extend their definition with embedded information. The hierarchy of PAT objects is illustrated on the Figure below.

The hierarchy of PAT objects and their relation to the original reco::Candidate objects.
PAT-objects.jpg

PAT Objects inheriting from reco::Candidate

Common interfaces

The pat::Object interface

The commmon layer 1 interface of all PAT objects adds the following:

  • Matching with trigger primitives (both for L1 and HLT)
  • Kinematic resolutions (still work in progress, the current version is an outdated port from TQAF)
  • A reference to the layer 0 object from which the layer 1 object was made (this)

Isolation in Layer 1

For leptons and photons layer 1 objects can have embedded isolation information, both in the form of precomputed values and of IsoDeposit, which allow on-the-fly computation of isolation with different parameters (note: in 16X they're actually called MuIsoDeposit). Many different isolations can be embedded in the same object, using different keys. The three predefined keys are tracker, ecal and hcal, but any number of additional "user" isolation information is allowed in order to maximize the flexibility without having to introduce a large number of predefined keys.

Accessing isolation
Isolation values can be accessed directly through the methods
  • trackIso() , ecalIso() , hcalIso() : return the isolation value for tracker, ecal and hcal; -1.0 is returned if there is no isolation for this key.
  • caloIso() : returns the sum of ecal + hcal isolation, or -1.0 if at least one of the two is missing
  • userIso(index) : returns the user specified isolation with a given index (counting from zero upwards), or -1.0 if missing.
there is also a generic method which could be useful in some generic algorithms
  • isolation(IsolationKey) : retrieves the isolation given a key from enum defined in DataFormats/PatCandidates/interface/Isolation.h

IsoDeposits can be accessed in a very similar way, except that there is no "caloDeposit()" because IsoDeposits can't be added easily. The relevant methods are trackerIsoDeposit() , ecalIsoDeposit() , hcalIsoDeposit() , userIsoDeposit(index) and they all return a pointer to an IsoDeposit. If there is no associated IsoDeposit, the method returns a null pointer, so unless you're sure that the IsoDeposit information was saved you should check the return value

   if (patPhoton.hcalIsoDeposit() == 0) { ... complain and say that it will be considered isolated ... }
   float myIsolation03 = patPhoton.hcalIsoDeposit() ? patPhoton.hcalIsoDeposit()->depositWithin(0.3) : 0.0

Read more pat::Object

Configuring isolation in the PAT Layer1 producers
All the PAT Layer1 object producers which allow for isolation can be configured in the same way.

For what matters isolation values, the configuration is the same as for the PAT Layer 0 cleaners, except that there is no cut on the isolation value, it is only read (or computed) and stored in the object, and so the cut parameter is not needed.

For the IsoDeposits, the configuration is even simpler because one only needs to specify which isodeposits to read (they're never built on the fly)

   PSet isoDeposits = {
        InputTag  tracker = ...
       InputTag  ecal    = ...
       InputTag  hcal    = ...
       VInputTag user    = { ... }
   }
If a parameter is not specified, the corresponding IsoDeposit will not be saved

The pat::Lepton interface

In addition to the features inherited from the pat::Object interface, all leptons have:

  • a pointer to the matching Generator lepton (ALERT! if no matching is found, a particle of charge 0 and momentum 0 is set)
  • methods to retrieve the isolation information (see above for details)

Read more pat::Lepton

Muons

Muons are ordered by decreasing pt in the output collection.

In addition to the tracks available from the plain reco::Muon, the global, tracker-only, and stand-alone muon tracks, there are methods for accessing and embedding the TeV-refit tracks made by the TevMuonProducer. They are available as pat::Muon::pickyMuon(), for the "picky" refit track, and pat::Muon::tpfmsMuon(), for the tracker-plus-first-muon-station track. By default they are loaded into the pat::Muon by the PATMuonProducer from the tevMuons:picky and tevMuons:firstHit reco::TrackCollection branches.

Read more pat::Muon, PATMuonProducer

Electrons

Electrons are ordered by decreasing pt in the output collection.

Read more pat::Electron, PATElectronProducer

Taus

Taus are ordered by decreasing pt in the output collection.

Read more pat::Tau, PATTauProducer

Photons

Photons are ordered by decreasing Et in the output collection.

Read more pat::Photon, PATPhotonProducer

Jets

In addition to the base PAT Object, the pat::Jet has the following additional features:

  • Jet energy corrections: the Layer 1 jet stores internally the jet correction factors, which can be retrieved by value ( jetCorrFactor(std::string &step, const std::string &flavour="")), or used to produce a clone of the jet after applying the specified correction factor (e.g. correctedJet(const std::string &step, const std::string &flavour="")). In either case the jet correction factor or the corrected jet may be retrieved using the arguments for step and flavour as given below, where the arguments may be passed as upper or lower case strings. Note that in 22X a minor feature is that you may retrieve negative correction factors. You can ignore this and take the absolute value for the correction factor or the corrected jet.

step flavour comment
RAW - no correction at all
OFF - offset corrected
REL - relative inter eta calibration
ABS - absolute pt calibration
EMF - calibration as a function of the jet emf
HAD GLU hadron level correction for gluons
HAD UDS hadron level correction for uds
HAD C hadron level correction for charm
HAD B hadron level correction for beauty
UE GLU underlying event correction for gluons
UE UDS underlying event correction for uds
UE C underlying event correction for charm
UE B underlying event correction for beauty
PART GLU parton level correction for gluons
PART UDS parton level correction for uds
PART C parton level correction for charm
PART B parton level correction for beauty
IDEA!Note: the step and flavour strings are case insensitive (so one can write, e.g., "RAW" or "raw").

  • Montecarlo matching both with GenJets ( genJet() ) and with partons ( genParton() ), and jet flavour from Monte Carlo ( partonFlavour() ). Note that the jet flavour can be different from the PDG ID of the parton because the two come from different algorithms.
  • Associated tracks and jet charge as computed in Layer 0. Tracks are not copied inside of the pat::Jet, so the associated tracks are accessible only if the original track collection is still available.
  • b-tagging information, both in the form of computed discriminators and as references to the extended jet tagging information (BaseTagInfos in 2.0.X, JetTagRef in 1.6.X). Results from multiple algorithms can be stored, and retrieved by name.

Different jet types
In the first releases of the PAT the pat::Jet was superclass of reco::CaloJet, but in new ones (DataFormats/PatCandidates at least V01-03-00 in 1.6.X, V02-03-00 in 2.0.X) any reco::Jet can be used to create a pat::Jet. Because of this, the interface of the pat::Jet adds on top of the reco::Jet:

  • Methods isCaloJet() , isPFJet() , isBasicJet() to determine the type of the original jet
  • All the specific methods of reco::CaloJet and reco::PFJet ; the methods will throw an exception if used on a pat::Jet not made from the correct jet type. To avoid conflicts in the names, the methods related to constituents have an extra Calo or PF in the name.

In the default PAT configuration, jet energies have L2 and L3 energy scale corrections applied (based on MC).

Jets are ordered by decreasing PT in the output collection (but note that in 1.6.X and 2.0.X releases they were ordered by ET) - sorting is applied on the already JES-corrected jets.

Read more pat::Jet, PATJetProducer

MET

The pat::MET object is really just a wrapper on the reco::CaloMET object. More information on the MET object can be found on the MET POG's reco::MET page. The object provides the missing energy corrected for jets (corMetType1Icone5) first and then for muons. Access to all corrections is provided through the reco::MET interface, thus giving access to the uncorrected MET (see POG documentation for details).

The pat::MET also provides (in 1.6.X, need to make it work in 2.X) a simplified access to the uncorrected MET using methods with arguments UncorrectionType uncorType. All available UncorectionType values are:

  1. uncorrALL = 0 is used to get a bare MET
  2. uncorrJES = 1 is used to uncorrect the first correction, which happens to be the jet energy scale type-1 correction in PAT.
  3. uncorrMUON = 2 is used to uncorrect the second correction, which happens to be the correction for muons in the PAT met correction sequence.
  4. uncorrMAXN = 3 is the total number of uncorrections defined. Currently (as listed above) these are uncorrALL, uncorrJES, and uncorrMUON.
The most useful uncorrection methods are expected to be pat::MET::uncorrectedPt(uncorType) and pat::MET::uncorrectedPhi(uncorType), where uncorType if not set defaults to "all corrections removed" uncorrAll and the methods return a bare MET. Other options include uncorrJES and uncorrMUON to obtain MET pt and phi before jet correction and muon correction respectively. These two un-corrections are applied assuming the order of correction was "jet corr" was done first and "muon corr" was applied second (current default in PAT).

Read more pat::MET, PATMETProducer

Other PAT objects

Particle

A generic type wrapping a pat::Object around a reco::Particle.

Read more pat::Particle

Hemisphere

Subdivides the event in to hemispheres, each corresponding to the decay of the primary particles. It stems from the development done in SusyAnalyzer (L. Pape, F. Moortgat).

Read more pat::Hemisphere, PATHemisphereProducer

Code and packages

The Layer 1 code is released in the following package:

Reviewer/Editor and Date Comments
FredericRonga - 23 Apr 2008 First layout
GiovanniPetrucciani - 24 Apr 2008 Filled the common interface doc
FredericRonga - 13 May 2008 Added ordering of output collections
FredericRonga - 21 May 2008 Document the MET
Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng PAT-objects-s.png r2 r1 manage 153.9 K 2008-04-24 - 18:12 FredericRonga Illustration of the PAT objects' hierarchy
JPEGjpg PAT-objects.jpg r1 manage 38.4 K 2008-10-07 - 10:06 FredericRonga Illustration of the PAT objects' hierarchy (JPEG file for MAP)
PDFpdf PAT-objects.pdf r2 r1 manage 25.2 K 2008-04-24 - 18:12 FredericRonga Illustration of the PAT objects' hierarchy (PDF file)
Edit | Attach | Watch | Print version | History: r29 < r28 < r27 < r26 < r25 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r29 - 2009-09-19 - SudhirMalik
 
    • 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