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.
Contents
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
-
RecoEcalCandidate
, containing a reference to a SuperCluster
-
RecoCaloTowerCandidate
, containing a reference to a CaloTower
Hep MC Candidates
Details about
GenParticle
, the candidate type representing generator particles are described in
the following document:
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:
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
Bs-> 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.
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 (χ
2, number of
degrees of freedom).
Utilities and Framework Modules
See for details:
Review status
Responsible:
LucaLista
Last reviewed by:
PetarMaksimovic - 28 Feb 2008