|
Imperial Analysis
|
|
|
Imperial Analysis
|
|
This page documents:
Use the contents panel on the right to navigate between objects. Each section provides links to the documentation for the object class in question as well as the producer module. To check the list of properties an object class provides, follow the link to the object page. From this page the documentation for each set_[property] method will contain a link to the source code of the producer module where this method is called.
An example python configuration for each producer module is also given below. All these snippets are extracted from the file: python/default_producers_cfi.py.
The basic configuration for each module is usually the same: the input option takes an edm::InputTag to the input object collection, and the branch option takes a string that will label the branch in the output TTree. Other options typically control the addition of extra object properties that are not filled by default in the module. Reasons for this can vary, but are typically due to one of the following:
edm::ValueMap<T> to the event, where T is the type of the property in question. An option is then provided in the producer to read load this ValueMap and extract the values. There are several examples of this workaround below. These separate producers follow a module naming convention of IC[Object][Property]Calcuator, a CMSSW package convention of ICAnalysis/[Property]Calculator and git repository convention of ICAnalysis-[Property]Calculator.edm::View objects to access the input collection. This provides a certain amount of flexibility in the actual type of the input collection. An edm::View<T>, where T is some object class, can access an std::vector<T>, an edm::RefVector<T>, or the corresponding collections for some other type U which derives from the type T.edm::ValueMap objects these should not be produced using and edm::RefVector<T> collection as input, but rather the original std::vector<T> collection of concrete objects. For example, even if you intend to ntuple-ise a filtered edm::RefVector<GsfElectron> collection, you should still produce the ID and isolation ValueMap objects using the original std::vector<GsfElectron> collection.edm::View<reco::Candidate>std::vector<ic::Candidate>Example usage
edm::View<reco::PFCandidate> or an edm::View<pat::PackedCandidate> (the latter only available in CMSSW_7_X_Y series releases)std::vector<ic::PFCandidate>Example usage
An ic::CompositeCandidate aggregates multiple ic::Candidate (or derived) objects, summing the charge and four-momenta, while maintaining pointers to the original input objects. Due to its transient nature a CMSSW producer is not provided.
edm::View<reco::GsfElectron>std::vector<ic::Electron>The producer takes as input any collection where the objects are, or derive from, reco::GsfElectron objects. This includes pat::Electron collections. There are several ic::Electron properties which are not calculated by default in the producer:
| Properties | Notes |
|---|---|
| ic::Electron::r9 | A ValueMap for this variable can be calculated by the external producer ICAnalysis-ElectronR9Calculator. The option inputR9 should be set to this ValueMap and the includeR9 option should be set to True. |
| ic::Electron::hcal_sum | The extra inputs required to calculate this variable are not available in the AOD for all CMSSW release series. The method by which the variable is calculated is also expected to change in the CMSSW_7_X_Y series. A ValueMap for this variable can be produced by the ICElectronHcalDepthCalculator module within this package. The option inputHcalSum should be set to this ValueMap and the option includeHcalSum option set to true. |
| ic::Electron::has_matched_conversion | In anticipation of the method to calculate this flag changing in future releases the calculation has moved to a separate producer, ICElectronConversionCalculator, within this package. This calculates a ValueMap which should be specified by the option inputConversionMatches when the includeConversionMatches option is set to True. |
| ic::Electron::dxy_vertex ic::Electron::dz_vertex | These must be calculated with respect to a user-specified reco::Vertex. The first vertex in the collection specified by the inputVertices option will be used when includeVertexIP is set to True. |
| ic::Electron::dxy_beamspot | This must be calculated with respect to a user-specified reco::BeamSpot. The beamspot set by the inputBeamspot option will be used when the option includeBeamspotIP is set to True. |
| ic::Electron::dr03_pfiso_charged_all ic::Electron::dr03_pfiso_charged ic::Electron::dr03_pfiso_neutral ic::Electron::dr03_pfiso_gamma ic::Electron::dr03_pfiso_pu ic::Electron::dr04_pfiso_charged_all ic::Electron::dr04_pfiso_charged ic::Electron::dr04_pfiso_neutral ic::Electron::dr04_pfiso_gamma ic::Electron::dr04_pfiso_pu | These should be calculated on-the-fly in a CMSSW job. Individual analyses may modify the isolation definition, for example changing veto cones. See the section PF Isolation below for software recipes. Two sets of isolation values may be stored, nominally for isolation cones of sizes \(\Delta R = 0.3\) and \(\Delta R = 0.4\). These are enabled via the options includePFIso03 and includePFIso04 respectively. The InputTag for each isolation sum ValueMap must be specified in the pfIso03 and/or pfIso04 PSets as relevant. |
Example usage
edm::View<reco::Muon> or an edm::View<reco::PFCandidate>, but see below for detailsstd::vector<ic::Muon>The producer operates in one of two modes, controlled by the option isPF. When set to False, the input collection should contain reco::Muon (or derived) objects. This includes pat::Muon collections. When set to True, the input should be a collection of reco::PFCandidate objects that are identified as PF muons. There are several ic::Muon properties which are not calculated by default in the producer:
| Properties | Notes |
|---|---|
| ic::Muon::dxy_vertex ic::Muon::dz_vertex | These must be calculated with respect to a user-specified reco::Vertex. The first vertex in the collection specified by the inputVertices option will be used when includeVertexIP is set to True. |
| ic::Muon::dxy_beamspot | This must be calculated with respect to a user-specified reco::BeamSpot. The beamspot set by the inputBeamspot option will be used when the option includeBeamspotIP is set to True. |
| ic::Muon::dr03_pfiso_charged_all ic::Muon::dr03_pfiso_charged ic::Muon::dr03_pfiso_neutral ic::Muon::dr03_pfiso_gamma ic::Muon::dr03_pfiso_pu ic::Muon::dr04_pfiso_charged_all ic::Muon::dr04_pfiso_charged ic::Muon::dr04_pfiso_neutral ic::Muon::dr04_pfiso_gamma ic::Muon::dr04_pfiso_pu | These should be calculated on-the-fly in a CMSSW job. Individual analyses may modify the isolation definition, for example changing veto cones. See the section PF Isolation below for software recipes. Two sets of isolation values may be stored, nominally for isolation cones of sizes \(\Delta R = 0.3\) and \(\Delta R = 0.4\). These are enabled via the options includePFIso03 and includePFIso04 respectively. The InputTag for each isolation sum ValueMap must be specified in the pfIso03 and/or pfIso04 PSets as relevant. |
Example usage
edm::View<reco::Photon>std::vector<ic::Photon>The producer takes as input a collection of reco::Photon objects. The following ic::Photon properties are not calculated by default:
| Properties | Notes |
|---|---|
| ic::Photon::pass_electron_veto | This flag is calculated by a separate producer in this package: ICPhotonElectronVetoCalculator |
| ic::Photon::had_tower_over_em | This is calculated by an external producer available in the ICAnalysis-PhotonHadTowerOverEmCalculator repository. |
| ic::Photon::dr03_pfiso_charged ic::Photon::dr03_pfiso_neutral ic::Photon::dr03_pfiso_gamma | As for Electron and Muon production the isolation values will be extracted from the specified ValueMap inputs. |
Example usage
edm::View<reco::PFTau> or an edm::View<pat::Tau>, but see belowstd::vector<ic::Tau>reco::Track objects from the charged PF constituents. The request will be produced with the label requestedTracks.The producer is a template class on the type of the input objects. Two specific template instances are defined as CMSSW modules: one for reco::PFTau input (ICPFTauProducer) and the other for pat::Tau input (ICPFTauFromPatProducer). The main difference between the two is that the user must specify the list of discriminators to extract from the edm::Event in the reco::PFTau case, whereas in the pat::Tau case these are extracted directly from the input object.
The following ic::Tau properties are not calculated by default:
| Properties | Notes |
|---|---|
| ic::Tau::lead_dxy_vertex ic::Tau::lead_dz_vertex | These must be calculated with respect to a user-specified reco::Vertex. The first vertex in the collection specified by the inputVertices option will be used when includeVertexIP is set to True. |
Example usage
edm::View<reco::MET>std::vector<ic::Met> in the ICMetProducer, and ic::Met in the ICSingleMetProducerTwo producers are provided, both of which take a vector of reco::MET (or derived) objects as input. The ICMetProducer will produce a vector of ic::Met objects, whereas the ICSingleMetProducer will produce a single ic::Met object. The ICMetProducer can optionally read a vector<std::size_t> from the edm::Event that should be aligned with the input vector<reco::MET> and will be used to set the ic::Met::id values in the output collection. The main use for this feature is in conjunction with the MVA MET producer where MET objects must be identified by combined hashes of the lepton inputs.
Example usage
edm::View<reco::Jet> or edm::View<pat::Jet> (see below for details)std::vector<ic::Jet>, std::vector<ic::CaloJet>, std::vector<ic::JPTJet>, std::vector<ic::PFJet>reco::Track objects for the charged constituents of PFJet or JPTJet inputs. The request will be produced with the label requestedTracks.reco::SecondaryVertexTagInfo objects associated to the jets, which will be produced with the label requestedSVInfo.The ic::JetProducer is a template class that is specialised for both the input and output jet types. While making the code more complex, this avoids a large amount of duplication that would result for have a normal producer for each possible input-output pairing. The possible CMSSW producers are defined here.
Each choice of input and output type brings with it the need for a specific set of options. This is addressed through two helper structs, the JetSrcHelper which is templated only on the input type, and the JetDestHelper which is templated only on the output type. Please see the documentation pages of these structs for further details.
An important distinction to make between using a reco::Jet and a pat::Jet as input is the treatment of the jet energy corrections. This module assumes a reco::Jet collection as input is uncorrected. The JetSrcHelper in this case provides extra options to specify the list of corrections to apply and an optional cut string that may be applied after the input jet is corrected and before a corresponding ic::Jet is produced.
The following properties are not calculated by default:
| Properties | Notes |
|---|---|
| ic::Jet::parton_flavour | For reco::Jet input producers only: The MC truth jet flavour (as a PDG ID). The method by which this is calculated is expected to change for 2015 data analyses. In anticipation, the calculation has moved to a separate producer: ICJetFlavourCalculator, within this package. This calculates a ValueMap which should be specified by the option inputJetFlavour when the includeJetFlavour option is set to True. |
| ic::PFJet::pu_id_mva_value | For ic::PFJet output producers only: See the section below for details on producing a pileup jet MVA ValueMap. This should be specified by the option inputPileupID when the icludePileupID option is set to True. |
| ic::PFJet::beta ic::PFJet::beta_max ic::PFJet::linear_radial_moment ic::PFJet::charged_multiplicity_nopu | For ic::PFJet output producers only: These variables are only calculated when includeTrackBasedVars is set to True and both the inputTracks and inputVertices collections are defined. |
| ic::JPTJet::beta ic::JPTJet::beta_max ic::JPTJet::track_pt_total | For ic::JPTJet output producers only: These variables are only calculated when includeTrackBasedVars is set to True and both the inputTracks and inputVertices collections are defined. |
| ic::CaloJet::fHPD ic::CaloJet::fRBX ic::CaloJet::id_loose ic::CaloJet::id_tight | For ic::CaloJet and ic::JPTJet output producers only: Requires an external reco::JetID map. Set inputJetID to the label of this map and set includeJetID to True. |
Example usage
edm::View<reco::Vertex>std::vector<ic::Vertex>reco::Track objects used in the vertex fit. The request will be produced with the label requestedTracks.The producer can be configured to store only the first vertex in the input collection by setting the value of the firstVertexOnly option to True. The ic::Track::id values of the tracks used in each vertex fit can also be stored (along with the fit weighting), subject to a minimum threshold set by the option trackPtThreshold.
Example usage
edm::View<reco::SecondaryVertexTagInfo>std::vector<ic::SecondaryVertex>reco::Track objects used in the vertex fit. The request will be produced with the label requestedTracks.Note that each reco::SecondaryVertexTagInfo input (one per jet) can contain multiple secondary vertices, each of which will be added to the output collection. The ic::Track::id values of the tracks used in each vertex fit can also be stored (along with the fit weighting), subject to a minimum threshold set by the option trackPtThreshold.
Example usage
edm::View<reco::Track>std::vector<ic::Track> or std::vector<ic::LightTrack>Two track classes are provided. The ic::Track is the standard class and the ic::LightTrack provides a limited subset of the ic::Track variables for situations where these are sufficient for analysis and ntuple space is at a premium.
Example usage
edm::View<reco::GenParticle>std::vector<ic::GenParticle>The producer can optionally store the relations between particles in decay chains using the includeMothers and includeDaughters flags. When enabled, these options tell the producer to save the corresponding vectors of ic::GenParticle::index values. Note that this index is different from the ic::GenParticle::id value, and is equal to the vector index position of the reco::GenParticle in the input collection.
Example usage
edm::View<reco::GenJet>std::vector<ic::GenJet>reco::GenParticle objects clustered into each jet. The request will be produced with the label requestedGenParticles.Note that due to technical limitations, if the requestGenParticles option is set to True, the original reco::GenParticle collection from which the jets were clustered must also be specified in the option inputGenParticles.
Example usage
edm::View<PileupSummaryInfo>std::vector<ic::PileupInfo>Each object PileupSummaryInfo object in the input collection provides the pileup information for a single bunch crossing. The bunch crossing number, ic::PileupInfo::bunch_crossing can be used to identify the bunch crossing relative to the hard scatter interaction (which has a bunch crossing of zero).
Example usage
edm::View<reco::SuperCluster>std::vector<ic::SuperCluster>The ic::SuperCluster class does not inherit from ic::Candidate but is instead specified by the supercluster position and direction with respect to the detector origin. The producer requires two collections as input as these are stored separately for barrel and endcap superclusters in the edm::Event.
Example usage
pat::TriggerEvent objectstd::vector<ic::TriggerPath>The file test/validation_cfg.py contains examples for creating the pat::TriggerEvent in various CMSSW releases. The producer can be configured to only store the paths that fired in each event via the option includeAcceptedOnly. There is also an option splitVersion (off by default) to strip the integer version number from each trigger path name, and store this is a separate variable: ic::TriggerPath::version. If this is enabled it may also be useful to set saveStrings to False. The ic::TriggerPath::name will not be written, the version-less name will still be hashed and stored in the ic::TriggerPath::id variables, saving space overall.
Example usage
pat::TriggerEvent objectstd::vector<ic::TriggerObject>The producer will store a collection of trigger objects used in the specified hltPath. Each object stores a vector of the (hashed) labels of the filter modules that accepted the object in the path.
Example usage
ic::EventInfoThe core event variables, such as event, lumi and run, are stored automatically. Other variables of interest may be added via the producer options. The options includeJetRho and includeLeptonRho can be used to store the values of the median energy densities used for the pileup jet energy correction and the lepton pileup isolation respectively. The appropriate inputs should be specified by the options inputJetRho and inputLeptonRho. The number of vertices in a particular collection (inputVertices) can also be stored (includeVertexCount), which is a space-saving alternative to storing an entire ic::Vertex collection. The options filters, weights and genFilterWeights are used to specify corresponding lists of input bool, double and GenFilterInfo values that should be added to the ic::EventInfo using the labels provided in the PSet.
Example usage
Supported releases:
CMSSW_4_2_8_patch7CMSSW_5_3_XCMSSW_7_0_X pileup jet ID onlyLinks:
The MVA MET is not available by default in any CMSSW release, and pileup jet ID is only included in the CMSSW_7_0_X series. A recipe is given below for obtaining the versions that were used in the legacy HiggsTauTau analysis, which was based on CMSSW_5_3_7. Newer recipes for the MVA MET have also been provided and are currently in use by some groups. See the twiki page above for details. Notably, newer MVA trainings have been provided that do not require the addition of recoil corrections, but these have not yet been tested in this framework.
The following recipe can be used to set-up the MVA MET and pileup ID in a different CMSSW_5_3_X release. It works by extracting the relevant git commits from a prepared branch based on the CMSSSW_5_3_7 release, and applying these commits to a branch created from a different release.
Supported releases:
CMSSW_4_2_8_patch7CMSSW_5_3_XCMSSW_7_0_XLinks:
Over time many improvements to the tau reconstruction and identification have been developed by the tau POG. The twiki link above is a good reference to the different versions of the tau ID and how to add these to a release using git. The reconstruction and ID used in the legacy HiggsTauTau analysis corresponds to the section Legacy Tau ID (Run I). This is now available by default in releases starting from CMSSW_5_3_12. For older releases the recipe provided on the twiki might cause issues with the merging. It may be safer to identify just the commits that change the RecoTauTag package and git cherry-pick them one-by-one, e.g.
CMSSW_4_2_8_patch7CMSSW_5_3_XCMSSW_7_0_XThe calculation of PF iso-deposits for electrons changed during the CMSSW_5_3_X series. In the legacy HiggsTauTau analysis this was updated using a CVS tag on top of the CMSSW_5_3_7 release. See this git commit for details of the changes:
This updated version was included after some later CMSSW_5_3_X release, so check first if you need to apply it. The change from CandIsolatorFromDeposits to PFCandIsolatorFromDeposits modules for the iso-deposit calculation should be a good indicator.
Supported releases:
CMSSW_4_2_8_patch7CMSSW_5_3_XCMSSW_7_0_XThe code for the electron ID MVA is contained in the EgammaAnalysis/ElectronTools package. In older CMSSW_5_3_X series releases this package was not included. For the legacy HiggsTauTau analysis this code was added to the CMSSW_5_3_7 release using a CVS recipe, but is now most easily obtained by a git cherry-pick of this commit: