← Back to branch summary

~chris-rogers/maus/emr_mc_digitization

« back to all changes in this revision

Viewing changes to doc/doc_src/reconstruction/global_track_reconstruction_specification.tex

  • Committer: Chris Rogers
  • Date: 2014-04-16 11:48:45 UTC
  • mfrom: (707 merge)
  • mto: This revision was merged to the branch mainline in revision 711.
  • Revision ID: chris.rogers@stfc.ac.uk-20140416114845-h3u3q7pdcxkxvovs
Update to trunk

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/doc_src/reconstruction/global_track_reconstruction_specification.tex
524
524
An instance of the reconstruction input data structure requires three pieces of
525
525
information:
526
526
\begin{enumerate}
527
 
  \item a flag indicating the polarity of the particle beam,
528
527
  \item a list of detector information data structures, and
529
 
  \item a list of track point data structures.
 
528
  \item a global event data structure.
530
529
\end{enumerate}
531
530
 
532
531
Each instance of the detector information data structure is comprised of
536
535
  \item a matrix of covariances indicating the uncertainties of the detector.
537
536
\end{enumerate}
538
537
 
539
 
The items of the track point data structure that are used for inputs into
 
538
The items of the global event data structure that are used for inputs into
540
539
reconstruction are
541
540
\begin{enumerate}
542
 
  \item the 6D phase space coordinates of the track point $(t, E, x, Px, y, Py)$, and
543
 
  \item the ID of the detector which produced the track point.
 
541
  \item space points generated by the detectors $(x, y, z)$,
 
542
  \item the timestamp of each space point,
 
543
  \item the component momentum $(px, py, pz)$, if available, and
 
544
  \item the ID of the detector which produced each space point.
544
545
\end{enumerate}
545
 
This data structure also contains the z and Pz coordinates as well an
546
 
uncertainty matrix. The z and Pz coordinates are filled in automatically and are
547
 
provided as an output of reconstruction. For measured track points the
548
 
uncertainty matrix is filled in using the one given for the detector where
549
 
the track point was produced.
550
546
 
551
547
\subsection{Output Data Structure}
552
548
 
554
550
Each track contains
555
551
\begin{enumerate}
556
552
  \item the PDG particle ID for the type of particle associated with the track, and
557
 
  \item a list of track pont data structures that comprise the discrete track.
 
553
  \item a list of track point data structures that comprise the discrete track.
558
554
\end{enumerate}
559
555
 
560
556
Each track point data structure contains the following items:
563
559
  \item the calculated z and Pz coordinates,
564
560
  \item the uncertainties on the phase space coordinates in the form of a
565
561
        covariance matrix.
566
 
  \item the ID of the detector which produced the track point, or zero if this track point was 
567
 
        calculated during reconstruction.
 
562
  \item the ID of the detector which produced the track point, or zero if this
 
563
        track point was generated by interpolation between the detectors.
568
564
\end{enumerate}
569
565
 
570
566
\section{Task Breakdown}
571
567
 
572
568
\subsection{Data Structures}
573
569
 
574
 
Define input and output data structures. It is crucial to get this flushed out early on so that the detector groups know what is needed. Referring to the class diagram, this would involve implementing PhaseSpaceVector (exists already), TrackPoint, Detector,
575
 
and ReconstructionInput for the inputs. Track must be implemented
576
 
for the outputs.
 
570
Define input and output data structures. It is crucial to get this flushed out early on so that the detector groups know what is needed. Referring to the class diagram, this would involve implementing PhaseSpaceVector (exists already), TrackPoint, Detector, and ReconstructionInput for the inputs. Track must be implemented for the outputs.
577
571
 
578
572
\subsection{Interfaces}
579
573
 
580
574
Defining the OpticsModel and TransferMap interfaces.
581
575
 
582
 
\subsection{Polynomial Transfer Map}
 
576
\subsection{Polynomial Optics Model}
583
577
 
584
 
Convert existing PolynomialVector into three separate classes: PolynomialMap, PolynomialVector, and LeastSquaresOpticsModel. LeastSquaresOpticsModel would become an implementation of the OpticsModel interface. The PolynomialTransferMap class will be the first TransferMap  implementation, and will also be a subclass of PolynomialMap.
 
578
A first implementation of OpticsModel will be created that builds a model based on the creation of PolynomialMaps between the start plane and desired planes along the beam axis.
585
579
 
586
580
\subsection{Basic Minuit Track Fitter}
587
581
 
588
 
The TrackFitter implementation MinuitTrackFitter will be created and tested with just fields (no materials).
 
582
The first TrackFitter implementation will be MinuitTrackFitter that will assume only fields (no materials).
589
583
 
590
584
\subsection{Basic Track Reconstructor}
591
585
 
592
 
This will likely be created in tandem with the Minuit Track Fitter to serve as an interface for testing the reconstruction. This task is to create a "map" in the Python Map/Reduce flow structure that can be inserted into the chain of execution of a MAUS simulation or live run.
 
586
This will likely be created in tandem with the Polynomial Optics Model and Minuit Track Fitter to serve as an interface for testing the reconstruction. This task is to create a "map" in the Python Map/Reduce flow structure that can be inserted into the chain of execution of a MAUS simulation or live run.
593
587
 
594
588
\subsection{Minuit Material Effects}
595
589