Difference between revisions of "Mattione Particle Classes"
From GlueXWiki
(→Other Notes) |
|||
Line 1: | Line 1: | ||
+ | == 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 == | == Current Class Structure == | ||
<pre> | <pre> | ||
Line 15: | Line 20: | ||
* DVertex::shower_info_t is a class that inherits from DKinematicData | * DVertex::shower_info_t is a class that inherits from DKinematicData | ||
* DVertex::track_info_t is a struct | * DVertex::track_info_t is a struct | ||
− | * vector < vector < DVertex::track_info_t > > : for each DTrackCandidate there are multiple fit hypotheses, corresponding to different particle masses | + | * 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) | ||
</pre> | </pre> | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Proposed Class Structure == | == 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. | ||
<pre> | <pre> | ||
Line 43: | Line 49: | ||
* Particle_t is an enum defined in libraries/include/particleType.h that is used to store the particle id (values = Proton, PiPlus, etc.) | * 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. | * It uses the GEANT particle ID scheme. | ||
+ | * The DParticleSet organizes the particles in DVertex according to particle id (instead of by DTrackCandidate). | ||
</pre> | </pre> | ||
Line 49: | Line 56: | ||
* The particle objects (DChargedTrack, DChargedTrackHypothesis, DNeutralTrack, and DNeutralTrackHypothesis) will each have a factory so that they can be grabbed via JEventLoop->Get(). | * 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. | ** 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. | + | * 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. | * One DNeutralTrackHypothesis would be generated for each combination of DVertex and mass hypothesis, each with a FOM. | ||
Revision as of 15:03, 20 June 2011
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 > > (one for each charged particle id) / | \ / | \ 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)