Difference between revisions of "Mattione Particle Classes"

From GlueXWiki
Jump to: navigation, search
(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>
 
* Problems:
 
** Storing final track information in DVertex subclasses is non-intuitive (especially the 2D track_info_t vector).
 
** DVertex::track_info_t does not inherit from JObject: cannot add associated objects (DTOFPoint, etc.)
 
** Cannot call JEventLoop->Get(DVertex::track_info_t) (No factories for the particles)
 
** All neutral particles are assumed to be photons (could be neutrons, such as from Lambda decay).
 
  
 
== 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

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)