Here's a link to the spec PDF in my issue_854 branch via launchpad:

http://bazaar.launchpad.net/~plane1/maus/issue_854/view/head:/doc/global_track_reconstruction_specification.pdf

The LaTeX source is in doc/doc_src/reconstruction/global_track_reconstruction_specification.tex.

Section 3.4 of the spec now contains a more detailed description of the inputs and outputs. I'll need information back as to what form this input data will be in so I can create the appropriate C++ class instances in the map component.

Plan for data structure for global reconstruction.¶

Based on conversation at MICE software workshop, 15th-16th Oct 2012, between: Chris Rogers, Ian Taylor and Peter Lane.

Goal:¶

A robust data format/framework, which will be filled by the global reconstruction code, and passed to analysts. The framework should be clear and obvious, while providing the flexibility required for the expected (and unexpected?) complexities of the data.

Discussion:¶

We expect the data to be stored in: Spill -> ReconEvent -> Global. The format will be used for all data inside the path, and will provide converters from the necessary inputs (i.e. TOF, SciFi, etc.).

We want to provide for the output of multiple hypotheses from the global reconstruction. This was deemed vital due to the degeneracy in track fits for different particle IDs and momentum estimates. For example, the reconstruction will consider 'decay in flight' and 'multiple primary particle' hypotheses if appropriate, and will provide any hypotheses which are deemed plausible. These hypotheses will be represented by recon::global::PrimaryChain objects.

Proposal:¶

The basic objects would be:

SpacePoint:¶

Analogous to current implementations in TOF and SciFi, they would represent detector measurements, such as the hits in a single station of the tracker.

Data elements:

Location
4-vector (x,y,z,t)

Location errors
4-vector (x,y,z,t)

Detector or Geometry volume
ENum, geometry string, ???

Global would provide functions for copying external SpacePoint objects from TOF or SciFi into Global format.

TrackPoint:¶

A 'state' along the path of a track. This comes from the form of Kalman filters, which will be used to fit global objects.

Data elements:

Mapper Name
Name of reconstruction mapper which produced track

Location
4-vector (x,y,z,t)

Location errors
4-vector (x,y,z,t)

Momentum
4-vector (px,py,pz,E)

Momentum errors
4-vector (px,py,pz,E)

Detector or Geometry volume
ENum, geometry string, ???

SpacePoint
Pointer to associated SpacePoint, NULL if no SP

This will allow us to create one TrackPoint for each SpacePoint included by the reconstruction, but also add TrackPoints at arbitrary locations, potentially very useful for an analysis or MC comparisons.

Track:¶

A track constructed by the global reconstruction, or coming from a previous reconstruction step. The main data element will be a vector of pointers to TrackPoints, which will completely define the reconstructed path of the track. We will provide access methods for the start/end position and momentum, accessing the TrackPoints.

We foresee a possibility where the track reconstructed by global reconstruction will be dependent on an assumption of the particle identity. Therefore, the PID for the assumption will be stored, and parallel versions of the track will be possible, if they are deemed physically plausable.

For bookkeeping purposes, we will store pointers to all constituent tracks, either global or priors.

Data elements:

Mapper Name
Name of reconstruction mapper which produced track

TrackPoints
STL Vector of pointers

PID
ENum, including 'Unset' option

Detectors
bitmask (or STL vector) of detectors contributing to track.

Tracks
STL Vector of pointers

Goodness of Fit / Likelihood
Double

PrimaryChain:¶

A hypothesis for the reconstruction of one or more individual primary particles entering the detector region. Different hypotheses will be stored in parallel, e.g. a '\mu \to e decay in flight' v.s. 'a \mu with a hard scatter' v.s. 'two incoming tracks'.

Where it is impossible to separate individual primaries through pattern recognition (time or space), there will be the potential for a large number of hypotheses. These situations will be fully documented by the code, with an attempt to provide a 'goodness of fit' for each hypothesis and a tree of daughter particles, but the final decision should lie with the analysis group as to how to use the hypotheses.

Data elements:

Tracks
STL Vector of pointers

Parents
STL Vector of signed shorts -1 for primary, index of 'Tracks' vector for secondaries

Goodness of Fit / Likelihood
Double

Open Questions:¶

For errors, do we require a full co-variance matrix, and if so, at
which stages? Internally vs input/output. Tracks, TrackPoints,
SpacePoints? I would assume that SpacePoints will have 4,
independent errors for x,y,z,t. Tracks and TrackPoints probably
need a full covariance matrix.

Comments and suggestions are most welcome. I will be preparing a
first draft over the next week, based on the plan above, but
nothing will be set in stone for a while.

I committed the global recon framework to the trunk. This does not include the proposed analysis data structure or a functioning track fitter. I am still investigating issues with the Minuit fitter, but I wanted to get the framework out so that others can see and play with it.

I just merged the Minuit track fitter and muon-only global recon workflow mappers. I still need investigate reconstruction inaccuracies which are dependent on a fix to issue #1394. If I can resolve the inaccuracy issues then I will write integration tests.