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

PAT - Layer 0: cleaning and association

Complete:

Overview

Edited by: FredericRonga

The Layer 0 of the Physics Analysis Toolkit performs all the "cleaning" tasks: selection, isolation, duplicate removal, and Monte Carlo and trigger matching of the various AOD collections. A number of other tasks are also performed at this level to complete the information needed for selection (e.g., jet and MET corrections, b-tagging, etc.). The output of layer 0 is a consistent set of AOD objects and associated information.

See also the documentation about PAT Layer 1, which collapses all this information into compact objects.

The layer 0 sequence consists of the following steps (with possible variations in each step):

• extraction of AOD information (generator, tau tagging and isolation information, JetMET corrections): sequence patBeforeLevel0Reco
• cleaning (muons, electrons, photons, taus, jets, MET): sequence patLayer0Cleaners
• computing of additional information (electron ID, jet information) and re-keying of associations: sequence patHighLevelReco
• Monte Carlo matching: sequence patMCTruth
• Trigger matching: sequences patL1 and patHLT

The various levels are explained in the sections below.

Note: an object that does not match one of the isolation, selection or duplication criteria is first marked. The user can choose what to do with such objects, as explained in the first section below.

Configuration: patLayer0.cff, patLayer0_EventContent.cff

Marking and flagging objects

Edited by: GiovanniPetrucciani

The PAT Layer 0 selection is conceptually done in two steps:

• Set some veto flags on the objects, specifying if fails some selection criteria (e.g. identification, isolation, overlap removal, ...)
  • The output flags are also saved in the object itself, and can be recovered from the status word (C++ method status()) to be reused in later steps of the analysis
• Write a list of "good" items to the event: an item is normally considered "good" if it does not have veto flags turned on, but in the configuration one can specify that some veto flags should be ignored (e.g. one can decide that electrons failing the isolation cut should anyway be saved in the collection of "good" electrons
  • The choice of which flags to ignore is controlled by the bitsToIgnore parameter of the cleaner modules, which accepts a list of flag names.
  • It's possible to write also two additional lists of objects: the ones which are not "good", and the full list of objects; as the objects in these lists have the flags written inside them, this can be useful to investigate what's the efficiency of each selection criteria. This feature can be turned on by setting to a non empty label the parameters saveRejected, saveAll of the cleaner modules

For a more in depth explanation of flags, see SWGuidePatFlagDefinitions and CMS.PatToolsHelpers#CleanerHelper

Cleaners can produce a summary table of the efficiency of each selection flag at the end of the job; this feature can be turned on by configuring the message logger to print out PAT Layer 0 summary information

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

By default all cleaner modules print out summary information, but this can be controlled at per-cleaner level by setting the wantSummary parameter of each cleaner ( default is true )

Configuration: see for example cleaningLayer0/electronCleaner.cfi In this case, some isolation criteria is applied ( PSet isolation = { ... } ), but isolation flags are not required when deciding if an electron is good ( bitsToIgnore = { "Isolation/All" } ).

Selection

The selection performed on AOD objects at the layer 0 cleaning stage is described below. Again: objects are flagged and will only be actually discarded if the user chooses to do so.

Primary vertex selection

Edited by: nnn, mmm

Configuration:

Muon selection

Edited by: ClemensZeidler

An approach similar to Tracker Muons is followed to define the RPC Muons: in this case a match is sought between the extrapolated inner track and hits on the RPC muon detectors. A description of the algorithm and the performance measurements is contained in the CMS AN-2012/482 . The effects of including the RPC hits in the global muon reconstruction have also been studied and are described in M.S.Kim, JINST 8 (2013) T03001 . The main twiki page documenting the RPC Muon algorithm is linked HERE .

isGood(SelectionType type) function can be directly used with PAT muons. For more details on muon identification in the muon POG, see muon WorkBook.

At the moment the selection is also wrapped in a MuonSelector (similar to the electron selection below). (It is recommended to use the isGood function if available.)

This selection configured in the PATMuonCleaner module, in the selection parameter set:

PSet selection = {
   string type = "..."
   [...]
 }

where selection types are one of the following strings:

• globalMuons for global muons selection (default, and recommended);
• none for no selection at all, except from reconstruction (same as globalMuons in releases < 1_7);
• muonPOG for selection based on a Muon POG algorithm; in that case the additional parameter flag will specify the algorithm to use (see the MuonIdentification pages for details); This selection works only for tracker muons.
• custom for cut-based selection (ported from TQAF and SusyAnalyzer); in that case, the cut values have to be provided in the selection parameter set.

Configuration: see the selection parameter in cleaningLayer0/muonCleaner.cfi

Electron selection

Edited by: FredericRonga

The electron selection is primarily based on the electron ID, as provided by the E/gamma POG, but user-defined cuts are also provided (from SusyAnalyzer). This is configured in the PATElectronCleaner module, in the selection parameter set:

PSet selection = {
   string type = "..."
   [...]
 }

where selection types are one of the following strings:

• none for no selection at all.
• cut for cut-based electron ID. In this case, an InputTag eIdSource containing the relevant electron ID information has to be provided (see example below). This electron ID already contains the decision (see SWGuideElectronID for details).
• likelihood or neuralnet for more advanced POG electron ID. This is still under development.
• custom for fully customised selection. In that case, all the cuts have to be specified in the selection parameter set, together with the cluster shape input sources.

Here is how to add the electron ID producer to the path and select only those electrons that have been identified (to be added in the main cfg file):
This will not work out-of-the-box in 2_0.

# Copy the electron ID producer
module myElectronId = electronId from "EgammaAnalysis/ElectronIDProducers/data/electronId.cfi"
replace myElectronId.doPtdrId   = false  # Do not use PTDR cuts...
replace myElectronId.doCutBased = true   #  ... but the new cuts
replace allLayer0Electrons.selection =  { # Our new selection for Layer 0 electrons
    string type = "cut"    
    InputTag eIdSource = myElectronId # Produced by our new producer
}
path p = {
  myElectronId,
  [...]   # Whatever comes afterwards
}

This will apply the default electron ID: "robust". Using one of the two other electron ID cuts (tight or loose) is a bit hazardous in 1_6 and 2_0, because all cuts will be changed (i.e., also the electron ID that is stored in the object at Layer 1). This, however, can be achieved by adding the following to the above list of replaces:

replace CutBased_ID.electronQuality = "tight"  # WARNING: this replaces all electron ID cuts! 

Configuration: see the selection parameter in cleaningLayer0/electronCleaner.cfi. It is also documented in the cleaner module's code: CMS.PhysicsTools/PatAlgos/plugins/PATElectronCleaner.h.

Photon selection

Edited by: FredericRonga

There is no selection applied on the photons at the moment. Only duplicate removal and isolation computation are performed in the cleaner.

Configuration: see cleaningLayer0/photonCleaner.cfi

Tau selection

Edited by: GiovanniPetrucciani

The cleaner for Taus performs only a few basic tasks:

• Read a reco::CaloTauDiscriminatorByIsolation or reco::PFTauDiscriminatorByIsolation and consider "good" only the items that pass it (this discriminator is just a boolean true/false provided by Tau POG). This cut is associated with the "Core/Preselection" flag, because the selection bits will be used by a more complex selector soon.
• Allow for a simple overlap checking by deltaR, which can be used to remove electrons and muons faking taus. It is not on by default.

In the future a more advanced tau cleaning will be added, with help from the Tau POG.

Configuration: The only relevant parameter specific of the tau cleaner is tauDiscriminatorSource , which should be an InputTag to a TauDiscriminatorByIsolation produced by the tau tagging modules.

Jet selection

Edited by: GiovanniPetrucciani

There are two possible selections for jets in PAT, plus the option of performing no selection at all.

This is configured in the PATXXXJetCleaner modules ( XXX is any one of Calo , PF , Basic ), in the selection parameter set:

PSet selection = {
   string type = "..."
   [...]
 }

where selection types are one of the following strings:

• none for no selection at all.
• IDmap to select applying a cut on a pre-computed likelyhood or discriminator. The additional parameters are IDmap (InputTag of the map) and value (jets are accepted if the discriminator is strictly greater than this value)
• custom for fully customised selection. In that case, all the cuts have to be specified in the selection parameter set. At the moment, this is works only for CaloJets, and the available cuts are:
  • Etamax (on abs eta)
  • Ptmin
  • EMFmin, EMFmax
  • EMvsHadFmin, EMvsHadFmax
  • HadFmin, HadFmax
  • HighestTowerOverJetmin, HighestTowerOverJetmax
  • N90min, N90max
  • NCaloTowersmin, NCaloTowersmax
  • PtJetOverAreamin, PtJetOverAreamax
  • PtTowerOverAreamin, PtTowerOverAreamax
  • RWidthmin, RWidthmax

Configuration: see the selection parameter in cleaningLayer0/caloJetCleaner.cfi

MET selection

Edited by: FredericRonga

There is no selection cut on the caloMET.

Configuration: see cleaningLayer0/caloMetCleaner.cfi

Isolation

Edited by: GiovanniPetrucciani

Inside PAT, the isolation workflow is:

• Isolation information is read from the AOD, or computed from AOD objects using tools from POGs or common modules from PhysicsTools
• All the isolation collections are gathered and converted to a uniform format so that they can be easily used by PAT modules, and easily managed in PoolOutputModule configuration.
• Within layer 0 cleaners, isolation cuts can be applied to the items, and this information can be used to select items (e.g. pick only isolated photons) or to resolve ambiguities (find jets which overlap with isolated electrons).
• This isolation information is then copied and saved associated to the pat layer 0 objects, so that one no longer needs access to the AOD object (this is just a technical step to overcome some limitations of the framework)
• When producing layer 1 objects, the information from layer 0 isolation collections is embedded in the PAT objects, so that they can work standalone.

Isolation in the cleaners

Isolation in layer 0 cleaners has two purposes:

• completely discard non isolated objects, if they're not relevant to its physics analysis
• mark non isolated objects persistently, so that at any further step in the analysis chain this information is kept coherent (e.g. to avoid easy mistakes such as removing jets that overlap with "isolated" electrons, with a cut at 3GeV, and then looking at "isolated" with a cut at 2GeV or 5GeV)

Isolation in layer 0 is implemented for muons, electrons, photons and taus (but the default configuration for the tau is empty, as isolation is already implemented natively in the Tau object). It will also be implemented in the new "isolated object", soon to be added in PAT, which will allow users to work also with candidates created from raw tracks or calorimeter towers.

The configuration of the isolation is performed using the parameter isolation in the cleaners, and possibly also setting the bitsToIgnore to specify that objects can be "good" even if they're not isolated.

There are three pre-defined isolation types (tracker, ecal, hcal), but there is also room up to 5 additional "user defined" isolation cuts. An example configuration fragment is

    PSet isolation = {
           PSet tracker = { 
                 InputTag src = ...
                 double    cut = ...
                 ...
           }
           ...
           VPSet user = {  
                 { InputTag src = ... 
                   double cut =  }
           }
    }

Each isolation PSet , tracker, ecal, hcal or any item in the user list, has at least two parameters:

• InputTag src = ... the name of the input collection to read isolation information from
• double cut = ... an item will be considered isolated if the value is strictly below this cut

Isolation parameter sets are optional: if no PSet tracker is specified, tracker isolation will not be computed and no items will have the veto flag associated to tracker isolation.

The most basic input that can be given for the isolation is a set of computed isolation values, produced by some other CMSSW module. Cleaners will read collections of type ValueMap but there is a PAT module to convert almost any type of isolation collection into this format.

Another option is to specify that the isolation should be computed on the fly from an IsoDeposit, a compact data structure used to store isolation information. In order to use IsoDeposit, you must specify at least one additional parameter double deltaR = ... , the size of the cone used to compute isolation (it is enough to you specify this parameter and the cleaner will assume you're using IsoDeposits instead of simple isolation values). Additional parameters can be used to further tune the IsoDeposit based isolation:

• veto : the radius of a veto cone to exclude from isolation totals, in the delta R metric; this is in addition to any veto already written in the IsoDeposit. (you can set the additional parameter skipDefaultVeto to true to ignore the predefined veto)
• threshold : deposits below the threshold are not used when computing the isolation total; if not specified, all deposits are used.
• mode : by default the isolation total is computed as the sum of deposits, but it's possible also to change the algorithm:
  • by setting this string parameter to "sumRelative" the value is computed relative to some "energy" specified when creating the deposit (this "energy" is the track pt for track based isolations, the Et for most calorimetric ones, the raw energy of the supercluster for egamma calorimetric isolations)
  • by setting it to "count" the isolation is computed as the number of the individual deposits (tracks, rechits, ...) instead of the sum of the values.
  • if requested, other algorithms can be implemented easily (e.g. the energy of the hardest deposit)

Warning : for egamma isolation based on ecal rechits the raw energy of the egamma object is subtracted from the total if and only if you don't specify any threshold nor veto. There is also the option of a more advanced configuration of this isolation, which allows also for 3D-angle cones and vetos, which is not yet documented

Adding other isolations

The defaut configuration in layer 0 already contains some isolation, but you might want to run some additional isolation module yourself, and use its results from PAT.

Specific instructions for this task will be added to the documentation soon.

Configuration: recoLayer0/*Isolation.cff

Overlap removal

Edited by: nnn, mmm

How overlaps are checked within collections, and with jets. How to configure.

Configuration: see relevant cfi files in cleaningLayer0

Monte Carlo matching

Edited by: WolfgangAdam - 08 Oct 2008

The PAT MC matching associates generator level objects to reconstructed objects. The default PATLayer0 sequence matches GenParticles to reconstructed electrons, muons, taus and jets. In the case of jets also an association to GenJets is built.

The matching proceeds in 4 steps:

1. A preselection of the generator level objects. Possible criteria are the PdgId, the generator status code and a charge consistent with the reconstructed object.
2. The selection of matched objects. Possible criteria are either purely deltaR or deltaR and relative deltaPt.
3. The ranking in case of multiple matched objects.
4. An optional resolution of ambiguities, i.e., generator objects matched to more than one reconstructed object.

The algorithms used for the first three points are specific to the EDProducer modules used for the matching and can be changed via templates (for details see CMS.PatModules). Currently two modules are used:

• The PATMCMatcher matches by deltaR and relative deltaPt and ranks by deltaR (used for all parton-level matches);
• the PATGenJetMatcher matches and ranks by deltaR only.

A third module PATMCMatcherByPt is predefined and can be used by a simple configuration change. It matches by deltaR and relative deltaPt and ranks by relative deltaPt. All three modules are defined in PATMCMatcher.cc .

Currently only one match is stored: either the best match for each reconstructed object according to (3) in the list above or - if ambiguity resolution is enabled - the best match out of those generator objects which haven't yet been assigned. The ambiguity resolution confirms assignments either in the order of the best global match (if resolveByMatchQuality is chosen) or in the order of the reconstructed objects. The ambiguity resolution mechanism is limited by the fact that MC matching works independently for each collection of reconstructed objects; there is no global resolution of ambiguities other than the fact that the GenParticles to be matched can be preselected by PdgId.

Default settings are summarized in SWGuidePAT#PAT_configuration_defaults .

Configuration: all cfi files are in mcMatchLayer0

Trigger matching

Edited by: VolkerAdler - 22 June 2008

The PAT trigger matching offers the opportunity to compare and associate PAT objects with trigger primitives. It helps to identify objects which actually fired a given trigger, e.g. those trigger(s) a particular analysis is based on. Therefor the same technique and matching algorithm are used as for the MC matching, splitted in two steps:

1. Match trigger primitives to AOD objects and build an edm::Association to hold the link of the AOD objects to matching trigger primitives (layer 0).
2. Store the matching trigger primitives as additional information in the PAT objects built from the AOD objects (layer 1).

Due to the wide spread of possible trigger configurations used in a CMS analysis, this tool cannot serve all possibly needed configurations. It rather offers some example prototypes of growing number and complexity, which should make it easy for the user to implement a match to the particular trigger(s) (s)he is interested in. 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). In the following, the implementation and the configurable parameters are described. Particular muon triggers are used as examples. A recipe how to create a certain trigger match for your own use case is given here.

PAT branch B1_6_X (for CMSSW_1_6_X)

Configuration: see files in triggerLayer0

In CMSSW_1_X AOD, trigger primitives are not accessable directly, so that additional producer modules are needed before the 1. step to extract them from the available trigger information. In addition to the steps listed above, this can be seen as 0. step. In order to hold the necessary information, a dedicated class pat::TriggerPrimitive has been implemented which inherits from reco::LeafCandidate and additionally consists of the names of the trigger path and filter module (for HLT) resp. the trigger and object type (for L1). Since reco::LeafCandidate again inherits from reco::Candidate, pat::TriggerPrimitive is sufficient to use the PATCandMatcher module for the matching. A std::vector is the data member of the pat::PATObject class, the base class of all PAT objects, which finally stores the matched trigger primitives.

Producing the trigger primitives

Since L1 and HLT information is stored differently, two different producers are needed to fill the trigger primitives. After this step, both triggers can be treated equally due to the uniform pat::TriggerPrimitive format.

L1 trigger primitives

The L1 trigger primitives are produced with the module PATL1Producer as a pat::TriggerPrimitiveCollection.

The L1 information is found in AOD in an l1extra::L1ParticleMap with the InputTag l1extraParticleMap::Raw. Nevertheless, this InputTag has been made configurable with the name particleMaps for flexibility. A wrong entry here will lead to an edm::Exception.

The available L1 triggers are listed here or in L1ParticleMap.cc (std::string array L1ParticleMap::triggerNames_) of that release the data was produced with. The trigger of interest is taken from this list and given as configurable triggerName. A wrong trigger name entered here will lead to a LogDebug message and an empty collection.

The L1 particle map stores the trigger primitives typified either as electro-magnetic (electron or photon), muon, jet ("real" jet or tau) or missing transverse energy. This is of particular importance for triggers combining different types. The name of the configurable string is objectType and accepts the values "em", "muon", "jet" and "etmiss". A wrong entry here will lead to a LogDebug message and an empty collection.

With these ingredients, an example producer configuration for a particular muon trigger looks like this:

module L1SingleMu3 = PATL1Producer {
    InputTag particleMaps  = l1extraParticleMap::Raw // default for CSA07 data
    string   triggerName   = "L1_SingleMu3"          // found hard-coded in L1ParticleMap::triggerNames_
    string   objectType    = "muon"                  // "em", "muon", "jet" or "etmiss"
}

In case the trigger of interest did not accept a particular event, a LogDebug message is launched.

HLT trigger primitives

The HLT trigger primitives are produced with the module PATHLTProducer as a pat::TriggerPrimitiveCollection.

The HLT information is found in AOD for the run modules only in a reco::HLTFilterObjectWithRefs for each module. The explicit information on the HLT paths is not stored in AOD and has to be extracted from the edm::TriggerResults table of the HLT process. Since there exists no unique assignment of trigger (filter) modules to the HLT paths, three configurables have to be given:

• the InputTag triggerResults to specify the edm::TriggerResults table of the HLT process,
• the string triggerName to specify the name of the HLT path and
• the InputTag filterName to specify the trigger module within the HLT path.

Usually, the user aims for a certain HLT path. (Lists of HLT paths are found here.) Then the given module should be the last filter module run in that particular path, which filters the objects of interest (especially important for cross channel triggers). HLT paths also consist of other kinds of modules like e.g. pre-scalers, but of course they do not produce 4-vectors of trigger objects to match. However, for "special checks" it is also possible to look for any other filter module within a given HLT path.

With these ingredients, an example producer configuration for a particular muon trigger looks like this:

module HLT1MuonNonIso = PATHLTProducer {
    InputTag triggerResults  = TriggerResults::HLT             // default for CSA07 data
    string   triggerName     = "HLT1MuonNonIso"                // found in "List of HLT paths in CMSSW_1_6_X"
    InputTag filterName      = SingleMuNoIsoL3PreFiltered::HLT // last filter module in path "HLT1MuonNonIso"
}

LogDebug messages are launched in case:

• the HLT path is not identified from the edm::TriggerResults table,
• the specified HLT path
  • was not run,
  • did not accept the event,
  • had an error,
• the specified trigger module does not belong to the specified HLT path.

A LogWarning message is launched in case the specified trigger module is not stored in the event, what usually would lead to an edm::Exception.

Matching AOD objects and trigger primitives

With the TriggerPrimitiveCollection produced in the 0. step above, one continues exactly as for the MC matching, using the PATTrigMatcher module (or the PATTrigMatcherByPt module) in this case.

Here is an example matching configuration, based on the muon trigger primitives from the HLT example above:

module muonTrigMatchHLT1MuonNonIso = PATTrigMatcher {
   InputTag src               = allLayer0Muons // the reconstructed muons
   InputTag matched           = HLT1MuonNonIso // the trigger primitives (name of the used PATHLTProducer as above)
   double maxDeltaR           = 0.5
   double maxDPtRel           = 0.5
   bool resolveAmbiguities    = true
   bool resolveByMatchQuality = false
}

The cuts on the maximum distance between reconstructed object and trigger primitive (maxDeltaR and maxDPtRel) are not tuned.

Store the trigger primitives

This 2. step is already part of the of the PAT object production in layer 1 and integrated into the object producers' code. Hence the configurables are also found in the producers' configurations in producersLayer1/*Producer.cfi.

There is a bool swich addTrigMatch to turn on/off the addition of the trigger matching information to the PAT object and a VInputTag trigPrimMatch specifying the match(es) to add. The information is stored in a data member of the PATObject data format of the type std::vector<pat::TriggerPrimitive> which holds all trigger primitives matched to the particular PAT object.

Following the examples above, one can find these lines in the muonProducer.cfi:

  bool      addTrigMatch  = true
  VInputTag trigPrimMatch = { muonTrigMatchL1SingleMu3,
                              muonTrigMatchHLT1MuonNonIso }

where each particular InputTag in trigPrimMatch corresponds to the name of a PATTrigMatcher modules in the 1. step.

In any case, one has to take care, that the requested information is available. Especially when running layer 1 from a layer 0 input file, the trigger primitives and the matching associations from the 0. and 1. step had to be stored there. By default, this is served in patLayer0_EventContent.cff by the lines

    "keep patTriggerPrimitivesOwned_*_*_*",    
    "keep patTriggerPrimitivesOwnededmAssociation_*_*_*",

And -- of course -- the trigger matching had to be run at all in layer 0 by including the corresponding modules in the path!

PAT branch B2_0_X (for CMSSW_2_0_X)

Configuration: see files in triggerLayer0

This description is not yet complete.

Some basic principles of the trigger matching are already explained in PAT branch B1_6_X (general for everything) and not repeated here.

The trigger matching is not compatible between the different PAT branches.

With CMSSW_2_X, trigger information is provided by the new class trigger::TriggerEvent in AOD. This has the advantage, that the einformation is available centrally, and so the event-by-event availablity does not depend on the particular trigger decisions. To save disk space, only L3 HLT information is available. In CMSSW_2_0_X, this class contains the collections TriggerObjectCollection and std::vector to hold information on both, the trigger primitives and the run filter modules. Nevertheless, the principle of producing PAT-specific trigger primitives in a data format inheriting from reco::Candidate is still needed.

With CMSSW_2_X, the trigger matching configuration files in triggerLayer0 have been restructured.

Producing the trigger primitives

Due to the new structure of the trigger information, the former separation of L1 and HLT trigger primitive producers was dropped in CMSSW_2_X. Also the dependence on certain trigger paths was dropped, since this information is technically irrelevant for the trigger matching. The filter modules used in the trigger matching could be paraphrased as "representatives" for the trigger paths. To reflect the sustained importance of the trigger paths, the naming conventions of the example modules and sequences in CVS still use the path names.

The trigger primitives are produced with the module PATTrigProducer as a pat::TriggerPrimitiveCollection.

Two configurables have to be given:

• the InputTag triggerEvent to specify the edm::TriggerEvent container and
• the InputTag filterName to specify the trigger module.

An example producer configuration for a particular muon trigger looks like this:

module patHLT1MuonNonIso = PATTrigProducer {
    InputTag triggerEvent = hltTriggerSummaryAOD::HLT       // default
    InputTag filterName   = hltSingleMuNoIsoL3PreFiltered
}

In CMSSW_2_X, all producer modules have been combined in patTrigProducer.cfi.

LogDebug messages are launched in case:

• no filter information is available
  • at all,
  • on the given filter.

A LogWarning message is launched in case the specified trigger event is not in the event, what usually would lead to an edm::Exception.

Matching AOD objects and trigger primitives

The modules did not change compared to B1_6_X. In CMSSW_2_X, all matcher modules have been combined in patTrigMatcher.cfi.

Store the trigger primitives

Nothing changed compared to B1_6_X.

PAT branch MAIN (for CMSSW_2_1_X)

Configuration: see files in triggerLayer0

The trigger matching is not compatible between the different PAT branches.

This description is not yet complete.

Some basic principles of the trigger matching are already explained in PAT branch B1_6_X (general for everything) resp. in PAT branch B2_0_X (general for CMSSW_2_X) and not repeated here.

There is only one small, but important difference here compared to CMSSW_2_0_X concerning the trigger primitive producer configuration:

module patHLT1MuonNonIso = PATTrigProducer {
    InputTag triggerEvent = hltTriggerSummaryAOD::HLT
    InputTag filterName   = hltSingleMuNoIsoL3PreFiltered::HLT   // <-- PROCESS NAME !!!
}

The InputTag filterName must be given. This became necessary due to changes in the trigger::TriggerEvent.

Additional information on jets and MET

Other information retrieved or re-calculated from the AOD and attached to the cleaned collections.

Jet and MET corrections

Edited by: VyacheslavKrutelyov - 26 Jun 2008

Configuration: recoLayer0/jetMETCorrections.cff

MET is corrected for jet energy scale and for muons using "Type1" methods:

• Jet energy scale type-1 correction is applied using iterative-cone jets R=0.5. Only contributions from jets with (uncorrected) pt>20 GeV and em-fraction < 0.9 are considered. The corrected jet scale is defined by MC corrections
• MET is corrected for muons using selected muons in the event and taking out the energy found in the tower crossed by the muon. For selections check the corresponding version of JetMETCorrections/Type1MET configuration. The selections used in versions 16X, 20X, 21X are
  • muon pt > 10 GeV
  • number of hits on the track > 5. unfortunately this is applied to the global track and the number of hits here is pretty large on any track
  • The track (global fit) should have a resolution of better than 50%.

Jet Flavour identification

Edited by: nnn, mmm

Configuration: recoLayer0/jetFlavourId.cff

Jet track association and jet charge

Edited by: nnn, mmm

Configuration: recoLayer0/jetTracksCharge.cff

Tau tagging

Edited by: nnn, mmm

Configuration: recoLayer0/tauTagging.cff

b-tagging

Edited by: nnn, mmm

Configuration: ???

Code and packages

The Layer 0 code is released in the following package:

• CMS.PhysicsTools/PatAlgos (producers)
• CMS.PhysicsTools/PatUtils (algorithms)
• CMS.PhysicsTools/PatAlgos/data/*Layer0 (configuration)

Reviewer/Editor and Date	Comments
FredericRonga - 21 Apr 2008	Added subsections and some text
FredericRonga - 13 May 2008	Added muon selection