Framework for track reconstruction and it

1
Framework for track reconstructionand its
implementation for the CMS tracker

• A.Khanov,T.Todorov,P.Vanlaer

2
Problem Complexity

• CMS Tracker
• About 30000 detector units
• About 20M channels
• About 50K hits per event (at nominal luminosity)
• Homogeneous structure

3
Motivation

• We cannot implement the optimal track
  reconstruction algorithm right away
• Theres probably no one optimal algorithm but
  several,each optimized for a specific task
• We need a flexible framework for developing and
  evaluating algorithms
• The mathematical complexity of track
  finding/fitting often limits the number of
  developers
• The involved algebra is often localized in a few
  places
• If we could encapsulate the involved algebra in a
  few classes and separate it from the logic of the
  algorithm it would make track finding easier for
  developers

4
Trajectory State

• A basic object in tracking is the
  TrajectoryStateOnSurface (TSoS in short)
• It fully describes a trajectory locally, i.e. it
  has
• position
• direction
• curvature
• error matrix

surface
5
TSoS (contd)

• Usual problems with defining such a class
• Choice of parameterization(s)
• Who is responsible for conversion from one
  parameterization to another, and from local
  (surface) to global reference frame?
• Who is responsible for propagation
  (extrapolation) to other surfaces?
• Our choice
• The TSoS is providing all useful
  parameterizations, and it is constructable with
  any of them, so it performs all conversions
  internally, and on demand.
• Transformation Jacobians are not accessible
• Propagation is done by a separate object, a
  Propagator

6
Propagator

• Transforms any trajectory state to any surface,
  returning a new TSoS
• Includes material effects
• Is an interface for several concrete propagators,
  useable interchangeably
• a fast propagator using surface geometry
• an interface to GEANE for detailed propagation in
  GEANT3 geometries
• a tool with functionality equivalent to GEANE
  will be needed for GEANT4
• Completely encapsulates the algebra, Jacobians
  are not accessible to clients

7
Abstract detector

• Now that we have defined the basic vocabulary
  (TSoS), we can move to the main building blocks
  of a track reconstructor
• An abstract detector ( Det interface)
• provides measurements compatible with a TSoS on
  demand and in an optimal way
• A DetLayer that adds navigation capability
• navigation connections between DetLayers are
  establiched by algorithm-specific
  NavigationSchool objects

Det measurements( TSoS,MeasurementEstimator)
DetLayer nextLayers(TSoS)
8
More components

• Abstract measurement
• allows combining measurements of different
  dimensionality
• Updator
• updates a TSoS with a measurement from the same
  surface
• operates in the local frame of the Det surface
• Seed Generator
• Crates initial trajectory candidates (seeds)
• seeds are just TSoS with a DetLayer for
  navigation

9
Trajectory Builder

• Now we have all components for a Trajectory
  Builder
• Layer navigation provides next DetLayers to query
• DetLayers provide compatible measurements
• Updator, well, updates the trajectory parameters
  using the measurements
• Do it again
• All we have to specify is the logic
• How many candidates to consider on each layer?
• When to drop a trajectory candidate?
• How to handle ambiguities

• Starting seed (can be external)

Updated state
Predicted State
measurement
10
Track Reconstructor

• Putting together a
• SeedGenerator and a
• TrajectoryBuilder
• and adding a
• TrajectoryCleaner
• to resolve ambiguous cases
• we get a TrackReconstructor!
• Which we can combine with another
  TrackReconstructor and use again a
  TrajectoryCleaner to eliminate duplicate tracks
  and we get a
• more efficient TrackReconstructor!
• Seeded, regional etc. reconstruction is simply a
  matter of using an appropriate SeedGenerator
  (e.g. from a Calorimeter cluster)

11
Present status

• We have successfully implemented a classic Kalman
  filter track finder, fitter and smoother. This
  means we have at least one implementation for all
  the components described.
• It us undergoing full validation for the Tracker
• The reconstruction is extended to include the
  Muon system. This implies
• implementation of Muon DetLayer
• extension of the NavigationSchool to the Muon
  layers
• use of appropriate propagators when crossing
  absorbers
• optimized combinatorial logic
• A Deterministic Annealing track fitting method is
  implemented and is being evaluated
• An advanced Connection Machine - like Seed
  Generator is being implemented

12
Conclusions and Outlook

• We have developed a friendly environment for the
  implementation and evaluation of track
  reconstruction algorithms
• We have successfully implemented a classic Kalman
  filter algorithm in this environment.
• We are implementing and evaluating other
  promising algorithms.
• We will implement versions of some components
  specialized for electron reconstruction, trigger
  and test beam applications, etc.