Warning, /acts/docs/core/reconstruction/pattern_recognition/track_finding.md is written in an unsupported language. File is not indexed.
0001 (track_finding)=
0002 # Track Finding
0003
0004 :::{todo}
0005 Write CKF documentation
0006 :::
0007
0008 (ckf_core)=
0009 ## Combinatorial Kalman Filter
0010
0011 ACTS provides a Combinatorial Kalman Filter (CKF) implementation for track finding
0012 ({class}`Acts::CombinatorialKalmanFilter`). Its usage is demonstrated in the
0013 example algorithm `ActsExamples::TrackFindingAlgorithm`.
0014
0015 The CKF requires as input a track seed i.e. an estimation of the track parameters,
0016 and a list of measurements with an association to the (sensitive) surfaces of the
0017 tracking geometry. The CKF propagates track states initialised by the track
0018 parameter estimates in direction of the momentum (forward propagation). Whenever
0019 a surface is reached, the CKF searches for compatible measurements. In case of multiple
0020 compatible measurements the trajectory is branched. The track states of all
0021 branches are updated and smoothed following the Kalman filter prescription. The
0022 propagation is aborted if either the maximum path length is exceeded or if user
0023 customizable abort conditions are reached.
0024
0025 The CKF is customizable via template parameters, and options. The template parameters
0026 allow
0027
0028 1. to steer the propagation of the track states e.g. {class}`Acts::Propagator`, and
0029 2. to define the storage container for the trajectories and its track states
0030 e.g. {class}`Acts::VectorMultiTrajectory`
0031
0032 The options {struct}`Acts::CombinatorialKalmanFilterOptions` are also customizable via
0033 template parameters:
0034
0035 1. an iterator to iterate over links to (selected) measurements per tracking
0036 surface and which returns an {class}`Acts::SourceLink` when dereferenced.
0037
0038 2. the storage container for the trajectories and states which must be the same as
0039 for the CKF.
0040
0041 and provide:
0042
0043 1. user defined geometry (e.g. alignment), magnetic field and measurement
0044 calibration context which are unused by ACTS but passed to the possibly
0045 user defined delegates.
0046
0047 2. the reference surface with respect to which the track defining parameters are
0048 expressed (perigee)
0049
0050 3. delegates {class}`Acts::Delegate` mostly via the
0051 {struct}`Acts::CombinatorialKalmanFilterExtensions` to define
0052 - updater e.g. {class}`Acts::GainMatrixUpdater`
0053 - smoother e.g. {class}`Acts::GainMatrixSmoother`
0054 - measurement selector e.g. {class}`Acts::MeasurementSelector`
0055 - SourceLinkAccessor
0056 - measurement calibrator
0057 - branch stopper (optional)
0058
0059 Typically, users have to provide the tracking geometry, an implementation of a
0060 {class}`Acts::MagneticFieldProvider`, which is needed by the stepper
0061 e.g. {class}`Acts::EigenStepper` which is needed by the propagator, a
0062 source link accessor and a measurement calibrator. An implementation of a source link
0063 accessor and the measurement calibrator can be found among the examples
0064 `ActsExamples::IndexSourceLinkAccessor`, and `ActsExamples::MeasurementCalibratorAdapter`
0065
0066
0067 % Functional approach
0068 % Implementation as an actor
0069 % Limitations (no inward filtering)
0070 % Requirement to copy out after smoothing if smoothed track states are desired
0071
0072 ## Machine-Learning based Track Finding
0073
0074 There is a lot of research ongoing about machine-learning based approaches to Track Finding. Because these are not yet stable and bullet-prove, there are no such algorithms distributed with the core library. However, there exists a [plugin](exatrkxplugin), that implements the *Exa.TrkX* algorithm in ACTS.
