CMSPublic Web>SWGuide>WorkBook>WorkBookParticleCandidates (2018-04-19, ThomasStrebler)

EditAttachPDF

4.4 Particle Candidates

Complete:

Detailed Review status

Goals of this page:

To introduce the basic functionalities and describe the different types of particle candidates.

What are Particle Candidates?

Particle Candidates represent reconstructed physics particles. Different types of particle candidates exist. The class reco::Candidate is the common base class for all reconstructed particle types. It provides three basic functionalities:

Access to kinematics information. The current implementation stores momentum Lorentz-vector, vertex, electric charge, PDG id. Examples:

      double pt = cand.pt(), eta = cand.eta(), phi = cand.phi();
      int q = cand.charge(), id = cand.pdgId(), st = cand.status();
      int qx3 = cand.threeCharge();

Access to underlying components, could be of any type. For instance, links to a track, super-cluster, etc. Example:

      TrackRef trk = cand.get<TrackRef>();
      SuperClusterRef cluster = cand.get<SuperClusterRef>();

The specializations of the get<...> template method are in the header file DataFormats/RecoCandidate/interface/RecoCandidate.h that has to be included.

In case an object has multiple components of the same type, like a muon having three different track fits, one can pass an extra tag argument. To access muon track fits one can do the following:

      TrackRef trackerTrack = cand->get<TrackRef>();
      TrackRef stAloneTrack = cand->get<TrackRef,reco::StandAloneMuonTag>();
      TrackRef globalTrack  = cand->get<TrackRef,reco::CombinedMuonTag>();

To get a CaloTowerRef out of a calo-jet constituent, include the header file DataFormats/RecoCandidate/interface/CaloTowerCandidate.h, and use:

      CaloTowerRef ct = jetConstituent.get<CaloTowerRef>();

Navigation among daughter. Daughters are again of type Candidate. Examples:

      for( size_t i = 0; i < cand.numberOfDaughters(); ++ i ) {
        const Candidate * daughter = cand.daughter( i );
      }

      Candidate::const_iterator d, b = cand.begin(), e = cand.end();
      for( d = b; d != e; ++ d ) {
        const Candidate & daughter = * d;
      }

Particle candidate objects are represented in this document by the following icon, sketching a vertex plus a momentum vector:

Where are Particle Candidates Currently Used?

Most of high level physics object are based on particle candidate. In particular:

Electrons, Muons, Photons, Jets, MET, Jet constituents, generator particles in AOD
Particle Flow
PAT
Combinatorial analysis to reconstruct leptonic Z and J/ψ decays;

Particle Candidate types

Particle candidate types belong to two main categories:

Leaf candidate types: candidates reconstructed from the information collected from CMS sub-detectors. Leaf candidates contain no candidate daughters and should inherit from the base class LeafCandidate.
Composite candidate types: candidates reconstructed from the composition of other candidate objects. Those candidate contain internally references to or clones of the daughter candidates used for their reconstruction.

The sections below describe the main particle candidate types used in CMSSW.

LeafCandidate class

All particle candidate types with no daughters should inherit from the class LeafCandidate.

In LeafCandidate, the method numberOfDaughters() always returns zero, the method daughter(i) always returns a null pointer.

LeafCandidate is mainly used as a base class, but it is a concrete class, so it could also be used to create concrete particles with no link to external components.

RECO Candidates

Candidates with no daughter and with components from other RECO/AOD objects should inherit from the class RecoCandidate. This interface provides methods to navigate to a set of standard RECO/AOD components.

For object that inherit from RecoCandidate, "automatic" overlap checking looking for possible common RECO constituent is implemented.

Candidate for High Level Physics Objects

The following High Level Physics Objects inherit from the RecoCandidate:

Electron, Photon
Muon
CaloJet, GenJet, BasicJet and their base class Jet

The High Level Physics Objects treated as candidates are represented with the following icons:

High Level Physics Objects have references to their underlying components stored in the AOD. For instance, an electron has references to its track and super-cluster:

Candidate RECO/AOD Object Adapters

RECO/AOD objects, like track, super-clusters, calo-towers do not inherit from reco::Candidate. Some applications need to create candidates from such objects, for instance to run jet clustering algorithm. This can be done done supplying the missing information to complete the particle candidate kinematics. For instance, adding a mass hypothesis to create a particle from a track, or add vertex information and assume a null mass hypothesis to create a photon candidate from a a super-cluster or calo-tower.

Specialized candidate types are provided to work as RECO/AOD adapters. They contain a reference to a single component belonging to the RECO/AOD data tier. Specific framework modules are provided to fill the kinematic information from the RECO/AOD objects. Those modules are described in another documentation page.

The following adapters for RECO/AOD objects inherit from the RecoCandidate base class:

RecoChargedCandidate, containing a reference to a Track

RecoChargedCandidate

RecoEcalCandidate, containing a reference to a SuperCluster

RecoEcalCandidate

RecoCaloTowerCandidate, containing a reference to a CaloTower

RecoCaloTowerCandidate

Hep MC Candidates

Details about GenParticle, the candidate type representing generator particles are described in the following document:

HepMC format using GenParticleCandidate

Candidate Collections

Candidate can be stored in different collection types. The recommended approach is to stored them as collections of concrete objects, wherever it is possible. For instance as:

std::vector<reco::Electron> or reco::ElectronCollection

or:

std::vector<reco::Muon> or reco::MuonCollection

or:

std::vector<reco::CaloJet> or reco::CaloJetCollection

Collections of concrete objects are represented above <as sets of object icons all of the same type enclosed between brackets.

It is also possible to store candidate objects in a collection that may contain candidate objects of heterogeneous types. Such collection is defined as the type:

edm::OwnVector<reco::Candidate> or reco::CandidateCollection

reco::CandidateCollection is a polymorphic container, i.e.: candidate objects are only know through their base class Candidate. This polymorphic collection is represented above with curly brackets, and can contain object icons representing heterogeneous types.

For more details about OwnVector containers, please have a look at the:

OwnVector Workbook documentation page

Shallow Clone Candidates

A shallow clone of a Candidate ( ShallowCloneCandidate) is a Candidate with a reference ( edm::RefToBase<Candidate>, i.e.: reco::CandidateBaseRef) to a master clone Candidate. This type of reference can refer to a master clone stored in any candidate collection type.

All the relevant information of a shallow clone are taken from its master clone, with the exception of kinematic information that can be changed in the shallow clone to take into account possible corrections or constrained fits.

The base class Candidate provides methods to navigate to the master clone, if existent:

   if ( cand.hasMasterClone() ) {   
     CandidateBaseRef master = cand.masterClone();
   }

In some application, you may need to transform the reference to the base type CandidateBaseRef to a concrete reference, say CandidateRef. This can be done with a cast:

   if ( cand.hasMasterClone() ) {   
     MuonRef master = cand.masterClone().castTo<MuonRef>();
   }

Composite Candidate Types

Particle Candidates reconstructed from a decay chain, like Z->µµ or B_s-> J/ψψ can be defined as one of the possible Candidate subtype defining a composite particle candidate. Composite Candidates can containing any number of (clones or references to) daughters.

A few types of composite candidates are provided. Most of the applications should just use CompositeCandidate and VertexCompositeCandidate, which adds vertex fit information.

CompositeCandidate

CompositeCandidate is a composite particle Candidate whose daughters are stored internally to and owned by the mother Candidate.

Example of how to create a CompositeCandidate is below:

      const Candidate & dau1 = ..., & dau2 = ...;
      CompositeCandidate comp;
      comp.addDaughter( dau1 );
      comp.addDaughter( dau2 );

Note that the above code does not set up the kinematics of the mother candidate that has to be explicitly set either adding the daughters four momenta (as in the linked example), or applying a constrained fit (this possibility is under development and not documented yet), or any other desired method.

CompositeCandidate can contain ShallowCloneCandidate as daughters in order to have both a clone of the daughter kinematics in the composite candidate and references to the master daughters particles. This is suitable to perform constrained fits that modify the daughter's kinematics, but still preserve original daughters kinematics that can be retrieved following the references to master clones.

Names of CompositeCandidates

CompositeCandidate also contains an option to specify the name for the candidate, and "roles" for the daughters. The syntax for this is

      const Candidate & dau1 = ..., & dau2 = ...;
      CompositeCandidate comp("myCompositeCandidate");
      comp.addDaughter( dau1, "daughter1" );
      comp.addDaughter( dau2, "daughter2" );

One can access the daughters via their roles as follows:

     const Candidate * dau1 = comp.daughter("daughter1");

VertexCompositeCandidate

VertexCompositeCandidate is a subclass of CompositeCandidate specialized for constrained fits. It contains a covariance matrix of the vertex and information on the fit (χ², number of degrees of freedom).