Tracking in the Inner Detector

Introduction

I am going to summarize the tracking in the Inner detector for my own record. Many of the wording is directly copied from ATL-SOFT-PUB-2007-007.

2. The embedding software framework ATHENA

2.1.1 The Athena component pattern architecture

The Athena framework has a component model, and it provides interfaces at different levels in the program sequence.

  • Service class: provides functionality during the entire program execution, (eg. the central data storage). ATHENA Service instances are handled by a central ExtSvc manager.
  • Algorithm class: executed exactly one time for every processed event. The Algorithm class must be registed to a central ApplicationMgr in the job configuration.
  • AlgTool class: more flexible solution for repeated operations than Algorithm class. It is called by an Algorithm that either owns the associated AlgTool or retrieves it from the central ToolSvc where all public toos are registered. AlgTool can be shared between different applications.
The ApplicationMgr calls various Algorithm instances per event. The Algorithms are independent, and they use ATHENA Service StoreGateSvc to retrieve input data collections and write the output data to the transient event store. Then the StoreGateSvc acts as a blackboard while ApplicationMgr acts as a teacher. Please see the figure below.

Screenshot_from_2015-02-27_154547.png

2.1.2 Data factory pattern and encapsulation of algorithmic code

So the main concept on the ATLAS computing model is simple. Operations are performed on input data classes, and newly created output data is produced. In general, modifications to the input data are now allowed, but rather a new output data will be created. In this way, while different Algorithms run, the input data can stay unchanged. This model will be referred to as "data factory pattern".

3. Concepts and common components of the new tracking

3.1 Reconstruction sequences, modules, tasks and operations

We can classify and name the components of the track reconstruction software as sequence, module, task, and operation

  • Sequence: A complete chain of Algorithms. It specifies a complex reconstruction steps leading to high level output object. e.g. track finding
  • Module: realized as Algorithm classes. A complete chain of retrieving input data from the transient event store, processing the data, and the recording of the output data. e.g. track refitting
  • Task: consists an Algorithm class. It is often performed by AlgTool classes. The AlgTool instances that are directly called by Algorithm class is said to be at "fist level". e.g. refit of a track
  • Operation: usually performed by AlgTool object. Operations are often shared between tasks. The difference between Task and Operation is that Task leads to a direct output data object while Operation doesn't. e.g. extrapolation of a track representation to surface, pattern recognition, vertex fitting, combined reconstruction

3.2 Tracking AlgTool classes: common interface and specific interface

We can classify the AlgTool class into two categories: common interface and specific interface.

  • Common interfaces are performed on base class level of the tracking EDM
  • Specific interfaces describes operations and tasks that are particular to a sub-detector
The following table lists some of the common interface packages.

Interface package Description Example (.h file)
TrkExInterface propagation, extrapolation, material effects IPropagator
TrkDetDescrInterfaces building of the TrackingGeometry IGeometryBuilder
TrkMagFieldInterface magnetic field access, parameterizations IMagneticFieldTool
TrkFitterUtils fitting interfaces and extensions ITrackFitter
TrkToolInterfaces truth processing, updator, ... IUpdator
TrkValInterfaces validation tools IResidualPuulCalculator
TrkVertexFitterInterfaces vertex seed finding, fitting IVertexFitter

3.3 The ATLAS tracking Event Data Model and reconstruction geometry

The full explanation about ATLAS tracking EDM and reconstruction geometry is beyond the scope of this Twiki. The detailed information about the EDM will be summarized here. Here are two man classes.

  • Tracking class: The ATLAS tracking EDM is concentrated around the Track class. The collection of Track objects is capable of holding the entire tracking information of the event.
  • Surface class: relates geometrical information to tracking relevant data such as hits on detecting surfaces.
  • Layer and TrackingVolume class: This is an extension of Surface class. It gives access to the material and magnetic field information.
  • TrackingGeometry class: The full reconstruction geometry.

Main tools and concepts used in the reconstruction are described in the following sections. More references can be found below.

3.1.1 TrkExtrapolation (A collection of AlgTool packages, Tracking/TrkExtrapolation)

Before the reconstruction, the track parameters are given with respect to the specific detector surface, and it needs to be transported for track reconstruction. The ATLAS extrapolation packages provide a set of AlgTool for transporting of track parameters. Further details about the extrapolation package can be found below.

TrkExtrapolation is a collection of packages, including the following tools:

  • Propagators for purely mathematical transport of the track parameters
  • Material effects integration and magnetic field access
3.3.2 Magnetic Field Access (Service)

The magnetic field information is accessible by a dedicated AlgTool, called ATHENA MagFieldSvc. The tool allows simplification, modification or the direct access of the given magnetic field map.

3.3.3 ITrackFitter (AlgTool, Tracking/TrkTools/TrkToolInterfaces package)

In ATLAS, TrkFitterInterfaces package is used for tracking fitting. It offers six different fitting techniques that can be specified at job configuration level. The input data can be one of the followings:

Input data of ITrackFitter (.h file inside TrkFitterInterfaces package):

Here is the list of six different fitting techniques:

3.3.4 IUpdator (AlgTool, Tracking/TrkTools/TrkToolInterfaces package)

The TrkToolInterfaces package contains IUpdator.h file. The IUpdator interface provides four different AlgTool. The updator is responsible for the following process.

  • Update of the predicted track parameters with a measurement
  • A reverse measurement update for a given a full information on the measurement surface. This allows to calculate unbiased hit residuals without performing an additional track fit
3.3.5 Calibration on Track (AlgTool, Tracking/TrkTools/TrkToolInterfaces package)

In the ATLAS New Tracking, the (re-)calibration of the measurement can be performed based on the track direction and sensor interaction point. The calibration model includes the adaption of

  • Cluster errors
  • Integration of chamber
  • module distortions to account for a realistic geometry description

Each sub-detector has different strategies for calibration. So we need a common interfaces to integrate the on track calibration into the general track fit.

  • IRIO_OnTrackCreator (.h): transforms non-calibrated object, PrepRawData, to calibrated object, RIO_OnTrack and finds a common implementation
  • RIO_OnTrackCreator (.h): holds a collection of pointers to IRO_OnTrackCreatorTool object which represents a different sub-detector.
3.3.6 Summary, Scoring and Helper Tools

the ATLAS tracking EDM provides detailed information about the track characteristics.

  • In Track object: ndof, χ2
  • TrackSummary object: Created by TrackSummaryTool package (Tracking/TrkTools/TrkTrackSummaryTool). It contains identification of fake tracks, solving of hit ambiguties, and evaluation of track extension.

Dedicated scoring functions are used to calculate a final track score, which is used for the track classification. The scoring functions give bonus or penalty points for different patterns.

  • ITrackScoringTool (AlgTool, Tracking/TrkTools/TrkToolInterfaces/TrkToolInterfaces) allows different implementation of scoring functions
3.3.7 Truth Association and Validation

The validation is required for the entire track reconstruction chain.

Truth Association

The MC simulated data is used for validation of the reconstruction chain. This can be done by associating the Monte Carlo truth with reconstructed input data. The reconstructed objects and MC truth objects are linked by an associate container. This truth association is mainly done on three different levels:

  • Hit truth association: This PrepRawData is associated with the simulated hits. There is an ambiguity arises from the fact that hits from multiple particles can form a single PrepRawData object during the clusterization process. The PrepRawData truth collection is implemented as an associative container that allows this multiple relationship.
    • In simulation, the simulated hits are available
    • In the clusterization process, the clusters and drift circles are represented by PrepRawData
  • Track truth association: IDetailedTrackTruthBuilder (Tracking/TrkTools/TrkToolInterfaces) is used to associate the reconstructed track objects with the generated particles. The reconstructed track is associated with one more more truth generated particles. Again, this association is available in PrepRawData truth collection.
    • In full detector simulation, the hard interaction process changes the identifier of the particle. Therefore, a track can correspond to one more more generated particles.
    • Tracking reconstruction of the truth particle is still reconstructed as a whole.
  • TrackParticle truth association: TrackParticle object contains a dedicated truth association container to associate truth particle and reconstructed particle object.

The MC truth association is highly detector specific. Therefore, the Algorithm implementations are located in the sub-detector repositories.

Validation

The validation concentrates on two different topics: performance and reliability.

Performance:

  • In general, performance validation is done at various stages and is deeply woven into sub-detector concept.
  • It can be performed within the common tracking framework to some extension using TrkValidation (A collection of track validation related packages, Tracking/TrkValidation)
  • Many performance validations rely on MC truth information and thus require the truth association to be done before.

Here are some of the packages used in the performance validation.

Container (Package) Description

TrkValAlgs

(Tracking/TrkValidation/TrkValAlgs)

Steering Algorithm for track based validation, including track parameter residuals and pulls, hit residuals and pulls, an Algorithm for track difference calculation, material validation

TrkValInterfaces

(Tracking/TrkValidation/TrkValInterfaces)

interface definitions for AlgTool classes used within this context

TrkValTools

(Tracking/TrkValidation/TrkValTools)

several AlgTool classes that are maily used by modules from the TrkValAlgs package.
Additional validation and statistics packages can be found in the sub-detector repositories such as
  • InDetRecStatistics package: which focuses on a detailed validation of the pattern recognition efficiency and track reconstruction resolution in comparison with MC truth information from the Inner Detector.

Reliability: ATHENA framework provides automatic test runs to monitor changes on performance, memory consumption, and leaks.

4. The ATLAS New Tracking in the Inner Detector

The ID New tracking consists of two consecutive sequences with and additional trigger stage which is referred to as offline reconstruction. The sequences are listed below.

  1. inside-out and outside-in track reconstruction
  2. Primary vertex finding
  3. ATLAS Event Filter (EF)

4.1 Inside-out Track Reconstruction

The primary ID pattern recognition follows an inside-out strategy for track finding. The inside-out track reconstruction is realized as a sequence of modules, and each module is represented through a dedicated Algorithm. The following UML (Unified Modeling Language) sequence diagram describes inside-out tracking.

Inside-out track reconstruction

4.1.1 SpacePoint Formation (InnerDetector /InDetTrigRecAlgs/SiTrigSpacePointFormation)

The first step of the inside-out track reconstruction is the creation of three-dimensional representation of the silicon detector measurement.

For pixel detector measurement, A two-dimensional local measurement transformed into a SpacePoint by local-to-global transformation. Therefore, each cluster directly leads to a SpacePoint object.

For SCT measurement, a single SCT cluster can not be transformed directly into a 3D representation. However, the sandwich module structure is used together with a beam spot constraint to form a SpacePoint. Therefore, it requires two different modules with separate readout for the creation of one single SpacePoint, and the SCT SpacePoint formation features an instrinsic noise suppression at the very first pattern stage.

4.1.2 SpacePoint seeded Track Finding (InnerDetector /InDetRecAlgs/SiSPSeededTrackFinder)

The SiSPSeededTrackFinder Algorithm uses the SpacePoint collections filled in the previous step as a input for seeding the track candidate search. The SiSPSeededTrackFinder Algorithm is divided into two different tasks, track seed finding and track candidate creation.

Step 1. Track seed finding

Track seed finding can be done using SiSpacePointSeedMaker package (InnerDetector /InDetRecTools/SiSpacePointsSeedTool_xk/SiSpacePointsSeedTool_xk). There are two different methods for seed searches. At this stage, SpacePointSeed objects are created.

  • Seed search with z vertex constraint: SpacePoint pairs from only the pixel detector are used to form z vertices using SiZVertexMaker AlgTool (InnerDetector /InDetRecTools/SiZvertexTool_xk). A fast primary vertex search is performed, and the primary vertex is used to further constrain the seeds with three or more SpacePoint. Here is an example view of the seed search with z vertex constraint.Seed search with z vertex constraint
  • Seed search with no constraint: The seed search can be performed without z vertex constraint. This method is more time consuming although it is more efficient to find tracks. Here is an example view of the seed search with no constraint.
    Seed search with no constraint
The comparison between two methods are shown below.

Screenshot_from_2015-03-03_183241.png

Step 2. Track candidate creation

At this stage, the SpacePoint ojects are converted into a new cluster objects with a base type RIO_OnTrack (Reconstruction input object). The extension of RIO_OnTrack in the inner detector are PixelClusterOnTrack, SCTClusterOnTrack, or TRTDriftCircleOnTrack. InDetRIO _OnTrack pacakge (InnerDetector /InDetRecEvent/InDetRIO_OnTrack) holds these classes. Here is the chain of measurement data process.

  1. PrepRawData (PixelCluster, SCT_Cluster) ->
  2. SpacePoint (PixelSpacePoints, SCT_SpacePoints, OverlapSpacePoints) ->
  3. RIO_OnTrack (PixelClusterOnTrack, SCTClusterOnTrack, TRTDriftCircleOnTrack)

Recall that the output of track seed finding process are SpacePointSeed objects. Once the SpacePointSeed objects are found, the track candidate creation is performed (road building process) within the pixel detector framework. The cluster collection that are not used to create SpacePoint objects are retrieved from the transient event store and used for track candidate. Therefore, the track candidate creation is in general performed on either PrepRawData (un-used clusters) or RIO_OnTrack objects. This process is done by SiSPSeededTrackMaker AlgTool (

For about 10 percent of the SpacePointSeed objects are successfully extended to a track candidate and stored in the common TrackCollection object.

4.1.3 Ambiguity Solving (InnerDetector /InDetRecTools/InDetAmbiTrackSelectionTool)

The seeded track finding results in a very high umber of track candidates. These track candidates needs to be resolved before extended into the outer TRT region. The track candidates can share hits, are incomplete or describe fake tracks. Here is the link to the detailed explanation about ambiguity solving.

The first step is to refit the track candidates, resulting a global parameter, χ2/ndof. This global parameter is not a good measure to distinguish between a good track and a fake track. Therefore, track scoring strategy has been developed. Here are some general features of the scoring system.

  • Each hit associated with a track leads to a better score value
  • Favors fully reconstructed track rather than a small track segment.
  • The measurements of different sub-detectors are weighted with different scores, preferring the precision measurement (pixel clusters)
  • If there is a shared hit between the tracks after the track scoring, the shared hit is assigned to the track with higher score. The remaining track is refitted without the formerly shared hit.
The table below gives an overview of the different benefit and penalties of tracks found in the SpacePoint seeded track search.
Track characteristics Detector Effect on the track score
B layer hole pixel strong panalty
Layer hole pixel penalty
Overlap hit pixel, SCT strong benefit
Sensor hole SCT weak penalty
Layer hole (module) SCT strong penalty
PRD_AssociationTool

In the inner detector, PRD_AssociationTool (PrepRawData Association) is used for the ambiguity solving process. First, registerPRDs(const Trk::Track*), reset(), getPrdsOnTrack() methods are used to register real hits to a track.

Then getCleanedOutTrack() is used to evaluate the remaining real hits. TrackStateOnSurfaces, TSOS (which do not related to a measurement), all non-InDet Measurements, all Outliers, and all pseudo-measurements are buffered to be kept on the track. Then the actual analysis is performed on the remaining 'real' hits.

  • For "real" hit, PRD_AssociationTool asks if the track is already used by a previously accepted track.
    • If not, it is added to a buffer of the kept hits
    • If it is already used by a previously accepted track and is not TRT hit, it is added to a buffer for potentially shared hits
  • Hits are only allowed to be shared if
    • the track in question has a minimum score AND
    • the PRD is question is not used already by more than a pre-defined number of tracks.
  • Shared TRT hits are not supported
4.1.4 TRT Track Extension

So far, the tracks and track segments are created at the silicon detector (Pixel, SCT) level thus it is called SiSPSeededTrackFinder. Now, it is time to extend the tracks and track segments from the silicon detector into the TRT. The TRT track extension consists of two modules (Algorithm).

TRT_TrackExtensionAlg (InnerDetector /InDetRecAlgs/TRT_TrackExtensionAlg)

The tracks found in the silicon detectors through the silicon seeds and ambiguity solving are used as an input to find compatible sets of TRT measurement. TRT_TrackExtensionAlg simply delegates this task to a dedicated AlgTool, ITRT_TrackExtensionTool.

  • The silicon-only track must not be modified
  • The association of the TRT hits are purely extension and is not done by a combination
There are two concrete implementations of the track extension tools:

  • TRT_TrackExtensionTool_xk (InnerDetector /InDetRecTools/TRT_TrackExtensionTool_xk): follows a classical approach starting with road finding through track extrapolation.
  • TRT_TrackExtensionTool_DAF (InnerDetector /InDetRecTools/TRT_TrackExtensionTool_DAF): uses deterministic annealing filter (DAF) which is optimized for very high hit densities.

The map of the seeded silicon tracks and its extensions are stored in the transient event store to be picked up by the next Algorithm, InDetExtensionProcessor.

InDetExtensionProcessor (InnerDetector /InDetRecAlgs/InDetExtensionProcessor)

This Algorithm evaluates the extended tracks with respect to the pure silicon track.

  • Combined track refit is performed on two tracks, the silicon track and the extension track
  • Track scoring is performed on two tracks again
  • Unlike TRT_TrackExtensionAlg, the refit in this Algorithm can modify the silicon hits by flagging them as outlier measurements
  • If the track score of the silicon track is higher than the combined track, the silicon track is kept, and the TRT hits are put as outlier measurements onto this track.
  • InDetExtensionProcessor can be configured to work optimally with the DAF specific extension Algorithm.
The figure below shows the extensions of the silicon seeded tracks into the TRT detector for a sample ttbar event.

Extension of silicon seeded tracks into TRT

4.2 Outside-in Track Reconstruction

The inside-out sequence of the ID New Tracking relies on a tack seed found in the silicon detector. There are many possibilities that the inside-out approach cannot reconstruct tracks correctly.

  • Initial track seeds may not be found or do even not exist
  • Ambiguous hits can shadow the track seed in the silicon and prevent the score of the silicon seeded track to survive the ambiguity processor
  • Tracks coming from secondary decay vertices may not have any or only insufficient silicon hits to comply with the inside-out sequence.
  • If a particle loses substantial energy (mostly of electrons), TRT_TrackExtensionAlg may build the track into a wrong direction in which there are no corresponding TRT hits found
For the reasons listed above, we need another sequence to reconstruct tracks in the ID, starting from the outside. The outside-in track reconstruction is realized as two different modules (Algorithm)
  1. A dedicated segment finding Algorithm
  2. Back tracking of the segment into the silicon detector
4.2.1 TRT Segment Finding

The TRT segment finding follows two step precedure.

  1. A global pattern search: Because the TRT drift tube measurements do not provide any information about the coordinate along the straw direction, SpacePoint object cannot be built, and the global pattern recognition has to be done in projection plane. The Hough transform is used to find the global track segment.
  2. A subsequent local pattern recognition: The drift time information is not only used in the global pattern search but also used in the local pattern recognition process. Using a Kalman filter-smooting formalism, the track segments are build, and the final collection of TrackSegment objects are written to the transient event storage.
If the track segment is already associated to tracks found in the silicon detector, event cleaning is performed by the PRD_AssociationTool to save CPU time.

4.3 The Event Filter Realization

Skipped

4.4 NEWT in the Combined Test Beam (CTB) and commissioning setup

The CTBTracking is a complete independent New Tracking sequence developed and used for the track reconstruction and alignment studies. The CTBTracking has been also adopted to serve the needs for reconstructing cosmic ray tracks.

5. NEWT for Combined Reconstruction

5.1 Calorimeter impact and vertex expression

The main tool used in the track extrapolation to the calorimeter is TrackToCalo AlgTool (Reconstruction/RecoTools/TrackToCalo). The TrackToCalo Algorithm compares tracks with clusters, and the extrapolation is performed to the different sampling layers of the calorimeter. The cells with energy deposit are collected in a given isolation cone. Some of the main AlgTool used in this step are:

5.2 Combined muon refitting

Skipped

SiinnChe - 2015-03-04

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng Screenshot_from_2015-03-03_183147.png r1 manage 242.1 K 2015-03-03 - 18:47 SiinnChe Seed search with z vertex constraint
PNGpng Screenshot_from_2015-03-03_183241.png r1 manage 97.7 K 2015-03-03 - 18:58 SiinnChe  
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r14 - 2015-03-20 - SiinnChe
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Sandbox All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback