Difference between revisions of "Mattione Particle Classes"

From GlueXWiki
Jump to: navigation, search
(Proposed Class Structure)
(Overview)
Line 29: Line 29:
 
* Effectively, DVertex::track_info_t would be replaced by DChargedTrackHypothesis, and for each charged track a DChargedTrack object would contain multiple DChargedTrackHypothesis objects.   
 
* 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.   
 
* 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.   
+
* 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.  The particle id would be performed by calling a new function, DParticleID::IDTrack, which would implement the algorithm currently executed in DParticleSet_factory::evnt().
 
* 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.   
 
* 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.   
  

Revision as of 15:12, 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 to create 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 of the 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 neutral track 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. The particle id would be performed by calling a new function, DParticleID::IDTrack, which would implement the algorithm currently executed in DParticleSet_factory::evnt().
  • 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.
      • To access the DTrackTimeBased data, you would call: DChargedTrack.hypotheses[0]->track->mass() instead of DChargedTrack.hypotheses[0]->mass()
    • 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)