Package DataFormats/Candidate

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