framework for track reconstruction and it’s implementation for the cms tracker...

Framework for track Framework for track reconstructionreconstruction

and it’s implementation for the CMS and it’s implementation for the CMS trackertracker

A.Khanov,T.Todorov,P.Vanlaer

8 Feb 2000 CHEP 2000. CMS/Track Reconstruction. Abstract A295 . T.Todorov 2

Problem ComplexityProblem Complexity

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


MotivationMotivation We cannot implement the optimal track reconstruction

algorithm right away

There’s 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


Trajectory StateTrajectory 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


TSoS (cont’d)TSoS (cont’d) 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


PropagatorPropagator 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


Abstract detectorAbstract 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

Detmeasurements( TSoS,MeasurementEstimator)

DetLayernextLayers(TSoS)


More componentsMore 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


Trajectory BuilderTrajectory BuilderNow 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)

measurement

Updated state

Predicted State


Track ReconstructorTrack ReconstructorPutting 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)


Present statusPresent 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


Conclusions and OutlookConclusions 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.

framework for track reconstruction and it’s implementation for the cms tracker...

Documents