Electron and Photon Isolation

Complete: 3

Introduction

In the following can be found information on how to compute and/or use isolation variables for Electrons and Photons. Since the algorithms and the software are not yet fully stable the text is divided in sections according to software releases. Modules to compute various isolation variables for electrons and photons are available in RecoEgamma/EgammaIsolationAlgos.

Electron and photon isolation in 3_1_X

Methods are provided to calculate isolation variables in tracker, ECAL and HCAL. The isolation variables are ET or PT sums in circles ("cones") in eta,phi space with inner veto areas to remove the electron "footprint". In 3_1 it has been also implemented the complete removal of the SuperCluster hits from the ECAL sum. Two standard sums (radii 0.3 and 0.4) for each isolation variable (tracker, ECAL, HCAL) will be stored with the Photon and the Electron objects. For the tracker isolation the sums are of CMS.GeneralTracks, for the ECAL isolation the sums of RecHits, for the HCAL isolation the sums are of the HCAL compartments of calorimeter towers.

In 3_1 it has been decided to remove the IsoDeposits from the Reco and build the isolation sums directly from tracks, ECAL RecHits, and HCAL sections of CMS.CaloTowers. The RecHits about electrons and photons are stored in an "interesting RecHits" collection which will be kept in AOD and allow isolation sums around electrons and photons to be made in AOD. The tracks and CMS.CaloTowers are already present in AOD.

Isolation in the PAT

PAT Electrons and Photons can store isolation values for tracker, ecal, hcal and "user isolations". In 2_1 and 2_2 intermediate objects known as IsoDeposits can also be used instead of tracks, rechits and towers. These are collections of the ET or PT of the objects to be summed with information about their distance from the object being isolated. A dedicated isolation methods then make the sums using these collections. The isolation methods based on the IsoDeposits have a default cone size (as well as other defaults). IsoDeposits from calorimeter RecHits and tracks are computed in RECO and are stored in AOD; IsoDeposits from CMS.CaloTowers can be made directly from AOD, as the CMS.CaloTowers are available also there.

The default PAT setup in 2.2.X contains:

  • Isolation sums computed from tracks, ECAL RecHits and HCAL deposits from CMS.CaloTowers similar to those that are stored in electrons and photons in 3.1.X
  • IsoDeposits from tracks, ECAL RecHits and HCAL deposits from CMS.CaloTowers (the first two are read from AOD, last one is made on the fly in PAT).

In 3.1.X the situation is as follows:

  • Isolation sums is read directly from the pre-computed values for tracks, ECAL RecHits and HCAL CMS.CaloTowers; separate sums for the two depths of HCAL is saved.
  • If one needs to have IsoDeposits into PAT objects to carry out isolation studies in FWLite, it will still be possible to produce the IsoDeposits from the AOD information (tracks, CMS.CaloTowers and "interesting RecHits") when producing the PAT objects.

How to use the code

The easier way to use egamma isolations in CMSSW (>= 3.1) is to access directly to the pre-computed values in the Electron and Photon objects. The Electron object for example implements the follwoing methods:

const IsolationVariables & dr03IsolationVariables()
const IsolationVariables & dr04IsolationVariables()
to retrieve the default values computed in the cones of 0.3 and 0.4. The IsolationVariables struct is defined as follows:
struct IsolationVariables
     {
      float tkSumPt ;                // track iso deposit with electron footprint removed
      float ecalRecHitSumEt ;        // ecal iso deposit with electron footprint removed
      float hcalDepth1TowerSumEt ;   // hcal depht 1 iso deposit with electron footprint removed
      float hcalDepth2TowerSumEt ;   // hcal depht 2 iso deposit with electron footprint removed
      IsolationVariables()
       : tkSumPt(0.), ecalRecHitSumEt(0.), hcalDepth1TowerSumEt(0.), hcalDepth2TowerSumEt(0.)
       {}
     } ;

Direct access to the deposits is implemented as well:

    float dr03TkSumPt() 
    float dr03EcalRecHitSumEt() const { return dr03_.ecalRecHitSumEt ; }
    float dr03HcalDepth1TowerSumEt() const { return dr03_.hcalDepth1TowerSumEt ; }
....
Analogous methods have been defined also for Photons.

In any case if you need to change the default parameters and compute the sums again there are two complementary ways which give identical results and both produce a edm::ValueMap keyed to the electron containing the appropriate isolation. It can either be made in one step using the EgammaElectronTowerIsolationProducer in RecoEgamma/EgammaIsolationAlgos/plugins straight from the CMS.CaloTowers or the CMS.CaloTowers can be first converted into IsoDeposits and then later made into isolation values by CandIsolatorFromDeposits in CMS.PhysicsTools/IsolationAlgos/plugins/. The following example is for the IsoDeposits way as that is what is used by the PAT. The IsoDeposits used to make the HCAL isolations are produced using the EgammaTowerExtractor module in RecoEgamma/EgammaIsolationAlgos/plugins. There is a configuration parameter known as hcalDepth which controls which effective depth of the hcal is used for the isolation. hcalDepth can have 3 values:

  • -1 : all depths (default)
  • 1 : depth 1
  • 2 : depth 2
The IsoDeposits are then made into isolation values in the normal way using the CandIsolatorFromDeposits. The configuration to make the IsoDeposits for electrons can be found here and the configuration to produce the isolation values from the IsoDeposits can be found here.

The sequence to run the egamma isolation values using the IsoDeposit intermediary step is found in RecoEgamma.EgammaIsolationAlgos.egammaIsolationSequencePAT_cff. This will define a sequence egammaIsolationSequencePAT which should be added to your path.

Older Releases

Isolation Algorithms by Subdetector

Track isolation

Description

The sum of PT of tracks is made centered on the electron track at vertex. The code is set up to allow cuts on track PT, Δz and Δr with respect to the Electron vertex, χ2 and number of hits of the track when the IsoDeposits are filled. Only the PT cut is currently used. Once the IsoDeposits are filled, it is possible to further cut on the PT of the track when making the isolation sum. Footprint removal for electrons uses an inner veto cone of 0.015 (see page 10 of this talk).

Defaults (methods for electrons running on IsoDeposits in Reco)

  • Inner veto cone radius: 0.015
  • PT threshold cut on tracks: 1.0
  • Cone radius: 0.3
Defaults for running on IsoDeposits in PAT for electrons are the same. Some recent studies and results suggest that:
  • The inner veto cone for electrons may be too small, particularly for |eta|>2 (see also description of defaults for photon isolation below)

For photons the cones are centered on the line from the vertex pointing to the photon supercluster. The inner veto cone size is set to 0.04, optimized to exclude reconstructed tracks in Z->ee events so that this quantity may be verified in early data (note that for electrons, the track isolation cone is centered on the associated track). In 2_2 the default outer cone size is 0.4, in 3_0 isolation sums for both 0.3 and 0.4 are stored. No threshold is applied to the PT of the tracks used in this isolation.

ECAL isolation

Description

RecHits are summed in a cone centered on the the electron or photon ECAL supercluster, with a footprint removal region consisting of a strip of specified eta width and an additional circular region (i.e. inner veto cone). This footprint removal region is called "Jurassic" - see: slides. (Note that the inner veto cone is centered on the ECAL supercluster position, as is the overall isolation cone, although the pictures in these slides sometimes seem to imply otherwise).

The most recent results on the choice of threshold on RecHits can be found here.

Defaults

  • Jurassic strip half width, barrel: 0.02; endcap: 0.02
  • Jurassic veto cone radius, barrel: 0.045; endcap: 0.070
  • RecHit noise cut, barrel: 0.08 GeV; endcap: 0.30 GeV
  • Cone radius: 0.4

Photons in 2_1 and 2_2 currently only save the full sum of ECAL RecHits within a 0.4 cone, which includes the energy of the supercluster. This needs to be subtracted by the user, before the quantity is useful for analysis. For 3_0, the Jurassic isolation is calculated with an eta width of 0.04, an inner cone width of 0.06, and is provided by default for both 0.3 and 0.4 cones.

HCAL isolation

Description

CaloTower HCAL sections are summed in a cone centered on the electron or photon ECAL supercluster position. Currently no inner veto cone is applied and this means that the HCAL isolation includes an implicit H/E cut. It is intended to cleanly separate the H/E cut from HCAL isolation in CMSSW 3_0. The best current suggestion is to use an inner footprint removal region of radius 0.15, and redefine the H/E cut to use this veto region for H. It is also intended to use both depths of the HCAL (where they are available).

The Hcal Isolation is now computed using CMS.CaloTowers. The HCAL component of CMS.CaloTowers differ from HCAL RecHits in that a noise cut is applied and that they are the sum of all depths. Therefore a CaloTower will contain a number of RecHits equal to its depth assuming each passes the noise cut. The noise cut is 0.9 GeV (HB) or 1.4 GeV (HE) and each rec-hit must pass this cut before it is added to the CaloTower. Preliminary studies indicate that the noise cuts both improve the overall rejection and stabilize it better vs eta. The HCAL is separated into multiple depths depending on the region and this is useful for high energy electrons. The number of depths range from a single depth in the barrel to up to 3 depths in the endcap. The depths are not uniform in interaction lengths, for example Tower 16 has a very small short depth 1. As such the HCAL isolation sums use a quantity known as effective HCAL depth which aims to keep depth 1 and 2 as uniform as possible in interaction lengths in the endcap. The effective depths are defined below, if the definitions look odd, looking at the HCAL diagram in the PTDR will help show the rational behind them:

Effective Depth 1: All depths Towers 1-17, depth 1 Towers 18-29, depth 2 Towers 27-29
Effective Depth 2: Depth 2 Towers 18-26, depth 3 Towers 27-29.

From 21X, the depth information is available in the CMS.CaloTowers. To save space, it uses the HO energy field to store the energy of the second depth which was unused for the endcap. A minor issue of this is that while Tower 16 could be split into two depths in theory, as it also has an HO component, we are limited to storing just a single depth. The functions CaloTower::hadEnergyHeInnerLayer and CaloTower::hadEnergyHeOuterLayer can be used to access depth 1 and depth 2 respectively for towers number 18+.

Defaults

Parameter 22X 3XX
Cone radius: 0.4 0.4
Veto: none 0.15
Depth: all all

Note that an outer cone size of 0.3 is also supported and that depth separation is also supported although the sequence to separate the depths is not run by default but it can be run from AOD and Pat ntuples.

Review Status

MatteoSani - 06 Apr 2009
MatthiasMozer - 24 Sep 2007 Page Author

Responsible: MatteLeBourgeois

Edit | Attach | Watch | Print version | History: r24 < r23 < r22 < r21 < r20 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r24 - 2009-09-08 - PedroParracho



 
    • 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