CVS head for this package - Administrative privileges

Description

Classes defining particle candidate. The class reco::Candidate is intended to be a common class for many Physics Analysis tools.

Public interface

reco::Particle: a reconstructed particle with momentum 4-vector, a vertex and an electric charge.
reco::Candidate: a generic reconstructed particle candidates. It adds to reco::Particle interface for navigation among constituents. Utilities to extract components from a reco::Candidate avoiding explicit dynamic_cast are provided. A tag struct can be used as optional second template parameter to disambiguate between more components in a Candidate of the same type. The following example shows how to extract references to a reco::Track or reco::Muon. The following syntaxes are all equivalent:
```
  const Candidate & cand = ...;
  TrackRef track1 = c.get<TrackRef>( c );
  TrackRef track2 = get<TrackRef>( c );
  TrackRef track3 = component<TrackRef>::get( c );
```
It is possible to access different types of components, but you have to get sure to include the header files of the concrete candidate subclass in order to define the proper template specialization.
```
  const Candidate & c = ...;
  TrackRef track = c.get<TrackRef>();
  SuperClusterRef cluster = c.get<SuperClusterRef>();

  const Candidate & g = ...;
  const HepMC::GenParticle * gen = g.get<const HepMC::GenParticle *>();
```
In case of multiple components of the same type, it is possible to specify an extra "tag" to disentangle the ambiguity. For instance:
```
  const Candidate & muon = ...;
  // tracker fit: default
  TrackRef trackerFit = muon.get<TrackRef>();
  // stand alone muon fit
  TrackRef standAloneMuFit = muon.get<TrackRef, StandAloneMuonTag>();
  // combined muon + tracker fit
  TrackRef combinedFit = muon.get<TrackRef, CombinedMuonTag>();
```
reco::LeafCandidate: a reco::Candidate with no component nor daughters. Suitable to store just 4-vector, vertex and electric charge.
reco::CompositeCandidate: a composite reco::Candidate where the daughters are owned by the composite candidate.
reco::CompositeRefCandidate: a composite reco::Candidate where the daughters have persistent references (edm::RefVector <...>) to reco::Candidate stored in a separate collection.
reco::CompositeRefBaseCandidate: a composite reco::Candidate where the daughters have persistent references (edm::RefToBase <...>) to reco::Candidate stored in a separate collection of concrete types.
reco::ShallowCloneCandidate: a candidate with a reference to a "master clone". All methods, except the kinematics, that is copied, are delegated to the master clone.
OverlapChecker: utility to check overlap between two candidates, looking for a common component recursively along daughters.

typedefs

reco::CandidateCollection: collection of reco::Candidate objects
reco::CandidateRef: persistent reference to a reco::Candidate object
reco::CandidateBaseRef: persistent reference to a reco::Candidate object as base class
reco::CandidateRefProd: reference to a reco::Candidate collection
reco::CandidateRefVector: vector of references to reco::Candidate objects in the same collection
reco::candidate_iterator: iterator over a vector of references to reco::Candidate objects in the same collection
reco::CandMatchMap: one-to-one candidate association map by reference

Modules

None.

Unit tests and examples

testParticle: test reco::Particle class
testCompositeCandidate: test reco::CompositeCandidate class
testSetup: test reco::Setup mechanism

Status and planned development

Complete.

Last updated: @ L. Lista