Mattione Particle Classes
From GlueXWiki
Contents
Introduction
- I think that the current class structure has become a little fragmented at the top level, and I'd like to suggest a few changes to make things simpler and more intuitive.
- Although commonly used, neither DChargedTrack nor DPhoton are actually used in any way in the creation of the DPhysicsEvent class. Instead, the particle information is stored as either DVertex::shower_info_t or DVertex::track_info_t objects. These objects are non-intuitive for final reconstructed objects, and most of their information is merely duplicated in the DChargedTrack and DPhoton classes.
- Also, the reconstruction algorithm assumes that all showers in the calorimeters not matched to charged tracks correspond to photons, instead of allowing for the possibility of neutron detection (such as from Λ decay). This assumption is also implicit in the class structure, as there is no way of storing separate objects for different mass hypotheses.
Current Class Structure
DPhysicsEvent | vector < DParticleSet > / | \ vector < DVertex::shower_info_t > DVertex vector < vector < DVertex::track_info_t > > / | \ / | \ vector < DVertex::shower_info_t > Misc. vector < vector < DVertex::track_info_t > > / \ / | \ DBCALShower DFCALShower tprojected DTrackTimeBased FOM * DVertex::shower_info_t is a class that inherits from DKinematicData * DVertex::track_info_t is a struct * vector < vector < DVertex::track_info_t > > : for each DTrackCandidate there are multiple fit hypotheses (DTrackTimeBased), corresponding to different particle masses * The DParticleSet organizes the particles in DVertex according to particle id (instead of by DTrackCandidate)
Proposed Class Structure
Overview
- Effectively, DVertex::track_info_t would be replaced by DChargedTrackHypothesis, and for each charged track a DChargedTrack object would contain multiple DChargedTrackHypothesis objects.
- This structure is then mimicked by DNeutralTrack, allowing for multiple hypotheses for each neutral track.
- Also, the particle id is stored as a Particle_t enum of the DChargedTrackHypothesis and DNeutralTrackHypothesis classes. This enum is defined in libraries/include/particleType.h, and uses the GEANT particle ID scheme.
- This not only eliminates the DVertex::shower_info_t and DVertex::track_info_t objects, but also avoids using the DPhoton, DBCALPhoton, and DFCALPhoton classes.
DPhysicsEvent | vector < DParticleSet > / | \ vector < DNeutralTrack > DVertex vector < DChargedTrack > / | \ / | \ vector < DNeutralTrack > Misc. vector < DChargedTrack > | | vector < DNeutralTrackHypothesis > vector < DChargedTrackHypothesis > / | \ / | \ FOM, tprojected, DKinematicData, Particle_t FOM, tprojected, DTrackTimeBased, Particle_t * Particle_t is an enum defined in libraries/include/particleType.h that is used to store the particle id (values = Proton, PiPlus, etc.) * It uses the GEANT particle ID scheme. * The DParticleSet organizes the particles in DVertex according to particle id (instead of by DTrackCandidate).
Notes on the particle (DChargedTrack, etc.) classes
- Particle construction (creating the DChargedTrack, etc. objects) is still performed by the DVertex factory.
- The particle objects (DChargedTrack, DChargedTrackHypothesis, DNeutralTrack, and DNeutralTrackHypothesis) will each have a factory so that they can be grabbed via JEventLoop->Get().
- These factories would essentially call JEventLoop->Get(vector<const DVertex*>) to construct the particles, then return only the desired objects.
- The particle objects (DChargedTrack, DChargedTrackHypothesis, DNeutralTrack, and DNeutralTrackHypothesis) will store the objects they are matched with (DBCALShower, DFCALShower, DTOFPoint, and DVertex) as associated objects (not implemented in the current structure).
- One DNeutralTrackHypothesis would be generated for each combination of DVertex and mass hypothesis, each with a FOM.
Other Notes
- Class changes:
- In the proposed scheme DPhoton, DBCALPhoton, and DFCALPhoton would no longer be used, and I am unsure of the benefit of supporting them.
- Also, the definition of DChargedTrack would change.
- Would need to update associated programs (hdview2, danaevio, ...?) and plugins.
- Simulations of the fractional energy deposited by neutrons in the calorimeters are needed to implement neutron energy reconstruction and identification.
- In the meantime, neutron ID would be effectively disabled (FOM forced to zero)