PaperlayerView exact revision on arXiv

Source-linked AI summary

A Common Tracking Software Project

Xiaocong Ai, Corentin Allaire, Noemi Calace, Angéla Czirkos, Irina Ene, Markus Elsing, Ralf Farkas, Louis-Guillaume Gagnon, Rocky Garg, Paul Gessinger, Hadrien Grasland, Heather M. Gray, Christian Gumpert, Julia Hrdinka, Benjamin Huth, Moritz Kiehn, Fabian Klimpel, Attila Krasznahorkay, Robert Langenberg, Charles Leggett, Joana Niermann, Joseph D. Osborn, Andreas Salzburger, Bastian Schlag, Lauren Tompkins, Tomohiro Yamazaki, Beomki Yeo, Jin Zhang, Georgiana Mania, Bernadette Kolbinger, Edward Moyse, David Rousseau

arXiv:2106.13593v1physics.ins-dethep-ex

TL;DR

Track reconstruction is a growing computational challenge because execution time scales approximately quadratically with charged-particle multiplicity. ACTS packages tracking algorithms in an experiment- and framework-independent toolkit designed for concurrent use; it is maturing and being integrated into experimental frameworks, while detector-specific tuning remains outside this paper’s scope.

  • Problem

    Track reconstruction is computationally demanding because execution time scales approximately quadratically with charged-particle multiplicity, and future computing architectures require increasingly parallelized code.

    Source: §1 · p. 3

  • Method

    ACTS packages ATLAS-derived tracking algorithms in an open-source, experiment- and framework-independent toolkit designed for thread-safe concurrent execution.

    Source: §1 · p. 4, §2.1 · p. 5

  • Results

    ACTS provides a range of track and vertex reconstruction algorithms being integrated into experimental frameworks, with geometries for multiple particle and nuclear physics detectors included.

    Source: §6 · p. 23

  • Takeaways & Limitations

    ACTS has been or is being integrated into a range of experimental frameworks, supporting its use across detector programs.

    Source: §6 · p. 23

    Full performance requires detector-specific algorithm tuning, which is beyond this paper’s scope and expected to be done by experimental collaborations.

    Source: §6 · p. 23

Abstract

from arXiv · show

The reconstruction of the trajectories of charged particles, or track reconstruction, is a key computational challenge for particle and nuclear physics experiments. While the tuning of track reconstruction algorithms can depend strongly on details of the detector geometry, the algorithms currently in use by experiments share many common features. At the same time, the intense environment of the High-Luminosity LHC accelerator and other future experiments is expected to put even greater computational stress on track reconstruction software, motivating the development of more performant algorithms. We present here A Common Tracking Software (ACTS) toolkit, which draws on the experience with track reconstruction algorithms in the ATLAS experiment and presents them in an experiment-independent and framework-independent toolkit. It provides a set of high-level track reconstruction tools which are agnostic to the details of the detection technologies and magnetic field configuration and tested for strict thread-safety to support multi-threaded event processing. We discuss the conceptual design and technical implementation of ACTS, selected applications and performance of ACTS, and the lessons learned.

1 Introduction

Track reconstruction is a growing computational challenge because execution time scales approximately quadratically with charged-particle multiplicity, while future collider environments bring higher occupancy and constrained computing resources. ACTS responds with an experiment- and framework-independent toolkit designed for parallel use, but its algorithms still require detector-specific tuning.

1 Introduction

  • For most tracking algorithms, execution time scales approximately quadratically with charged-particle multiplicity.At pp colliders, multiplicity usually rises with simultaneous interactions per event; for heavy-ion collisions, it primarily depends on event centrality.Source: §1 · p. 3
  • HL-LHC events are expected to contain about 4,000 charged particles and 300,000 detector measurements, while reconstruction CPU needs are projected to exceed available budgets by at least a factor of two.The upgraded ATLAS and CMS detectors are also expected to see pile-up of 140–200.Source: §1 · p. 3, Figure 1 · p. 3
  • Processor speed gains increasingly come from adding cores or using GPUs, FPGAs, and SoCs, which demand more parallelized code and changed programming paradigms.Machine-learning research has also produced new tracking algorithm ideas, though none had displaced existing methods at the time described.Source: §1 · pp. 3–4
  • ACTS provides open-source tracking algorithms and fast simulation in a framework- and experiment-independent toolkit designed for thread safety and vectorized linear algebra.Detector-specific tuning remains necessary; compile-time specializations support experiment-specific adaptations, while customizability makes ACTS an R&D platform.Source: §1 · p. 4
  • TrackML data are used to demonstrate current ACTS algorithm performance, but the paper does not quantify ultimate performance for a specific detector setup.The studies were not rigorously tuned; the toolkit has also been explored for several detector programs.Source: §1 · p. 4

2 Conceptual Design

ACTS is designed as an experiment- and framework-independent toolkit and a platform for developing tracking applications. Its design addresses concurrent execution, experiment-specific conditions, and research into newer algorithms and computing approaches.

2 Conceptual Design

  • ACTS targets preservation and advancement of established tracking code, an R&D test bed, and a mature toolkit for rapid development of future tracking applications.The toolkit is intended to accommodate experiment-specific adaptations while keeping its core broadly reusable.Source: §2 · pp. 4–5

2.1 Concurrent code execution

  • ACTS modules are designed for concurrent calls controlled by input and output data, while callers choose the execution pattern and parallelization technology.Tests check reproducibility across single- and multi-threaded execution; accelerator wrappers are possible, but efficient operation across hardware types still needs development.Source: §2.1 · pp. 5–6, Figure 2 · p. 6

2.2 Contextual data handling

  • Experiment-defined context objects travel through ACTS calls so detector geometry, alignment, magnetic field, and calibration data can reflect the current call context.The experiment implementation determines whether a context object carries an identifier or the full contextual data.Source: §2.2 · p. 6, Figure 3 · p. 7

2.3 Research and Development projects

  • ACTS provides a playground for prototyping and testing machine-learning and accelerator approaches, including demonstrated ONNX, autodiff, CUDA, and SYCL integrations.Smaller machine-learning components are described as needing tests in realistic data flow.Source: §2.3 · pp. 6–7

3 Technical Implementation

ACTS uses implementation choices intended to support performance, flexibility, and integration with existing experiment software. Its components are organized in a single repository with core functionality, plugins, simulation, and validation code.

3.1 Basic Technology Choices

  • The core library keeps external dependencies minimal, while plugins provide core-like functionality requiring additional packages, including geometry tools and GPU support.Eigen and Boost are the two required third-party libraries; CMake handles dependency management and builds.Source: §3.1 · pp. 7–8, §3.2 · p. 8
  • ACTS favors small compile-time interfaces and templates over virtual interfaces, and data-oriented programming over object-oriented programming.It is implemented in C++17, with movable types and value-like semantics among the stated ownership and quality practices.Source: §3.1 · pp. 7–8

3.2 Code Organization

  • ACTS is maintained in a single open-source repository containing the core, plugins, Fatras simulation, and test and validation code.The repository supports end-to-end tests with realistic reconstruction chains; Fatras can be built on demand and is not required for reconstruction.Source: §3.2 · p. 8

3.3 Core Components

ACTS organizes reconstruction tools into modules connected through common event data structures, with geometry and propagation supporting track finding and fitting. Configurations are explicit, while potentially mutable algorithm state and event-varying context are passed separately.

3.3 Core Components

  • Geometry, surfaces, material, propagation, track finding, track fitting, vertexing, and seeding are organized as modules with defined dependencies.EventData structures communicate between algorithms; track finding and fitting use geometry and propagation, while seeding uses global 3D points.Source: §3.3 · p. 8

3.4 Configuration, State, and Context

  • ACTS uses nested configuration types to keep algorithm settings explicit and support configuration and construction.The configuration object is passed to the algorithm constructor, which performs setup accordingly.Source: §3.4 · p. 9
  • Mutable cached or intermediate values reside in explicit state objects, leaving the algorithm itself stateless and const-correct.The framework or caller creates these states and decides where parallel execution and synchronization occur.Source: §3.4 · pp. 9–10
  • Algorithms that need event-varying detector data receive an explicit context object passed through the execution chain.Experiment-specific code handles the context where needed.Source: §3.4 · p. 10

3.5 Event Data Model

The Event Data Model (EDM) provides shared structures for communication across reconstruction steps while aiming to remain generic and low-overhead. ACTS represents tracks with surface-bound or surface-independent parameters, and treats measurements as projections into bound parameter space, including time in the fit.

3.5 Event Data Model

  • The EDM connects reconstruction steps through shared structures for measurements, track parameters, and vertex parameters, represented as vectors.It is designed to accommodate possible event-data types while remaining minimal to avoid overhead from extensive use.Source: §3.5 · p. 10
  • Bound track parameters describe a track relative to a surface, whereas free parameters use a surface-independent 3D position and direction, time, and curvature.The free parameter representation is eight-dimensional and used throughout track propagation.Source: §3.5 · p. 10
  • Measurements are vectors in a subspace of bound track parameter space, and ACTS includes time directly in the track fit as another parameter.A projection matrix maps the estimated bound parameters to the measurement space to form a residual vector.Source: §3.5 · p. 10
  • Compile-time dispatch selects optimized code paths for measurement dimensions, and a dedicated data structure can store measurements and track-state trees.Track states may contain a measurement, estimated track parameters, or both.Source: §3.5 · p. 10

3.6 Geometry

ACTS builds reconstruction geometry from surfaces grouped into layers and volumes, enabling navigation and propagation through detector structures. It simplifies material descriptions for reconstruction by mapping detailed material onto configurable surfaces or volumes.

3.6 Geometry

  • ACTS builds geometry from surfaces, with layers defined by bounding and contained surfaces and volumes formed from boundary surfaces.Contained surfaces may represent sensitive detector elements or passive material.Source: §3.6 · p. 11
  • Navigation uses portal surfaces between volumes or searches layer surfaces locally, and surfaces can support propagation, material, or sensitive elements.This makes the geometry suitable for both reconstruction and fast simulation.Source: §3.6 · p. 11

3.6.1 Layer geometry and plugin mechanism for detector elements

  • Approach surfaces bound a layer and initiate local navigation, while a representative surface provides a single surface for fast navigation search.After intersecting an approach surface, propagation tests candidate surfaces in the layer against the trajectory.Source: §3.6.1 · p. 11, Figure 6 · p. 12
  • ACTS can attach experiment-specific information to sensitive surfaces and provides plugins to translate existing geometry representations.Examples include DD4Hep, TGeo, and GeoModel.Source: §3.6.1 · p. 11

3.6.2 Surface and Volume-based Material

  • Detector material is a major source of uncertainty in track reconstruction, so its amount, type, and location require precise description.Passive material can be modeled as deterministic trajectory changes or stochastic additions to the covariance matrix.Source: §3.6.2 · p. 11
  • For reconstruction, material may be approximated by average mixtures and merged slabs; fewer surface intersections and material calculations can reduce CPU cycles.ACTS maps detailed material onto selected surfaces or volumes, with accuracy and speed balanced for each experiment.Source: §3.6.2 · p. 11

3.7 Propagator

The ACTS propagator combines a stepper for mathematical transport with a navigator for geometry-aware surface prediction and step control. Its magnetic-field interpolation uses a thread-local field-cell cache whose performance depends on the access pattern.

3.7 Propagator

  • The propagation engine transports track parameters and covariance matrices through the detector while supporting additional actions along trajectories.Its stepper performs mathematical transport through the magnetic field, and its navigator predicts candidate surfaces and regulates step size.Source: §3.7 · p. 12
  • Propagation calls receive options containing extensible actor and aborter lists, invoked after each step to perform actions or enforce stopping conditions.Actors can include surface-material interaction logic, while aborters can enforce target conditions or path-length restrictions.Source: §3.7 · p. 12
  • The provided steppers include Runge-Kutta-Nyström implementations, an optional material-propagation extension, and a straight-line option for zero magnetic field.The Runge-Kutta-Nyström steppers can provide helical behavior in a constant field.Source: §3.7 · p. 12

3.7.1 Magnetic Field Access

  • A thread-local cache lets successive field lookups reuse the current interpolation cell or retrieve a neighboring cell when propagation crosses its boundary.The interpolated field map can approximate an inhomogeneous field when supplied suitable input.Source: §3.7.1 · p. 13, Figure 7 · p. 13
  • All interpolated field-query strategies are approximately three orders of magnitude faster than the dynamically calculated solenoidal field.Caching improves fixed-point and straight-line access, but degrades fully random access; straight-line access emulates particle propagation.Source: §3.7.1 · p. 13, Figure 8 · p. 13

3.8 Track Seed Finder

ACTS seed finding forms measurement triplets and prioritizes those likely to belong to one particle, providing initial candidates for track following. Its performance depends on detector-specific selection criteria and the occupancy trade-off between efficiency and computational cost.

3.8 Track Seed Finder

  • ACTS seed finding forms triplets of measurements to estimate track candidates for subsequent track following.Its aim is to identify triplets corresponding to a single particle.Source: §3.8 · p. 13
  • Seed finding prioritizes efficiency because particles without seeds cannot be reconstructed, while later steps can remove fakes and duplicates at extra execution cost.Source: §3.8 · p. 14
  • Three-dimensional measurements from specified detector components are filtered using selection criteria optimized for the detector geometry; track parameters from triplets use approximations including a homogeneous magnetic field.The finder relies on global measurements, so detector geometry is not needed during execution.Source: §3.8 · p. 14
  • Higher measurement occupancy increases combinatorial cost and fakes; tighter cuts mitigate both at the cost of lower efficiency, while more layers raise requirements and duplicate rates but can improve efficiency.Detector alignment accuracy also affects efficiency.Source: §3.8 · p. 14

3.9 Kalman Filter

ACTS uses Kalman filtering and smoothing to fit tracks, with a combinatorial extension that searches measurement alternatives during fitting. Its vertexing suite combines configurable finders, fitters, and auxiliary tools, including simultaneous multi-vertex fitting with dynamic track assignment.

3.9 Kalman Filter

  • The Kalman filter estimates a track state by iteratively incorporating measurements assigned by track-finding algorithms, and it can model magnetic-field motion and material effects such as scattering and energy loss.Source: §3.9 · p. 14
  • ACTS makes filtering and smoothing replaceable at compile time and configures the propagator, track and measurement representations, outlier identification, and measurement calibration.Source: §3.9 · p. 14
  • At each surface, accepted measurements update track parameters, missing measurements on sensitive surfaces create hole states, and smoothing begins after measurements are processed or geometry navigation ends.Material effects can be included before or after filtering; smoothing uses Rauch-Tung-Striebel formalism or reverse propagation.Source: §3.9 · p. 14
  • The CKF searches compatible measurements during fitting and branches propagation when multiple measurements match, producing multiple fitted track-state sets rather than the KF’s single set per seed.A measurement selector handles the search criteria.Source: §3.9 · p. 14

3.10 Vertexing

  • ACTS vertexing includes an iterative finder and an adaptive multi-vertex finder that fits vertices simultaneously while dynamically assigning tracks; AMVF is intended for high vertex density and is the ATLAS Run-3 default.Its toolkit also includes four seed-finding approaches, dedicated fitters, impact-point estimators, and track linearizers; interfaces accept ACTS or user-defined track types.Source: §3.10 · p. 15

4 Applications and Performance

ACTS is used or explored across several experiments, and its TrackML studies report track, vertex, and CPU performance under specified simulation conditions. Results include strong multi-thread utilization, while reconstructed-seed performance and timing remain affected by untuned criteria and duplicate seeds.

4.1 Selected Applications

  • ACTS vertexing is integrated into ATLAS, its seeding, fitting, and vertexing components are deployed in sPHENIX, FASER will rely on ACTS for tracking and fitting, and Belle II is exploring its use.The toolkit is also being explored for Belle II’s low-momentum tracking requirements.Source: §4.1 · p. 16

4.3 Track and Vertex Reconstruction Performance

  • TrackML studies use a 2 T solenoidal field and simulated single-particle and t¯t samples, with truth and reconstructed seeds used to distinguish pattern-recognition effects in CKF performance.The reconstructed tracks require at least six measurements; the studies also evaluate vertexing with truth tracks.Source: §4.3 · p. 18

4.3.1 Track Reconstruction Efficiency and Fake and Duplicate Rates

  • For 1,000 t¯t events at ⟨µ⟩=200, truth-propagated-seeded tracks show excellent results, while reconstructed-seeded tracks have inefficiencies and high duplicate rates without detector-specific tuning.The study notes η-dependent seed-criteria tuning as a way to improve performance; such tuning is beyond its scope.Source: Figure 14 · p. 19, §4.3.1 · p. 19

4.3.2 Track Parameter Resolution

  • Pull distributions from the KF are approximately standard normal, supporting proper parameter and uncertainty estimates, with slight standard-deviation deviations for impact parameters and φ due to measurement-model nonlinearity.The study uses truth tracks and single muons to reduce fake-track and material effects.Source: §4.3.2 · pp. 19–20, Figure 15 · p. 20

4.3.3 Primary Vertex Reconstruction Efficiency

  • AMVF performance optimized for a Run-3 mid-range working point at µ≈60 extrapolates well to higher simultaneous-collision counts, using truth tracks in the reported evaluation.Experiments would optimize the configuration for their pile-up range and accelerator conditions.Source: Figure 16 · p. 20, §4.3.3 · p. 20

4.4.1 CPU Utilization

  • All 64 threads were utilized for 91% of execution time for both static and contextual geometry during propagation over 100,000 events with 1,000 pions each.Source: Figure 17 · p. 21, §4.4.1 · p. 21

4.4 CPU Performance

  • On a 32-core, 64-thread Haswell node, the Eigen-based and array-like steppers have very similar propagation performance and approach the straight-line stepper’s best-case timing at higher pion pT.The straight-line baseline takes minimal integration steps but is geometrically incorrect in the 2 T field.Source: §4.4 · p. 20, Figure 18 · p. 21, §4.4.2 · p. 21

4.4.2 Timing Performance

  • At ⟨µ⟩=200, truth-generated-seed KF and CKF take 0.74 and 2.25 seconds per event, while reconstructed-seed finding and CKF take 0.11 and 3.97 seconds; duplicate seeds increase the latter CKF time.The additional CKF time includes compatible-measurement searching and branching when multiple measurements match.Source: §4.4.2 · pp. 21–22, Figure 19 · p. 22, Figure 20 · p. 22

5 Experience

ACTS experience highlights the balance between flexible integration and performance, with contextual data handling separating experiment-specific conditions objects from software data flow. The project also identifies geometry diversity as an ongoing development challenge.

5 Experience

  • Less restrictive software design can ease integration into experiment stacks, but that flexibility must be balanced against track-reconstruction performance.Source: §5 · p. 22
  • ACTS lets experiments supply their own contextual condition objects while carrying them through the call chain, enabling experiment-specific unpacking and minimum conversion overhead.This approach was demonstrated in examples and during Athena integration; logging can likewise be replaced with an experiment-specific logger.Source: §5 · pp. 22–23
  • ACTS’s ATLAS-oriented initial design exposed geometry weaknesses for forward detectors, time projection chambers, drift tubes, and telescopes; some have been resolved, but these remain active development areas.Source: §5 · p. 23

6 Conclusion

ACTS provides open-source, experiment- and framework-independent track reconstruction tools that avoid dependence on detector technology and magnetic-field details and are tested for thread-safety. The toolkit includes track and vertex algorithms, detector geometries, and initial TrackML performance studies, while detector-specific tuning remains outside this paper's scope.

6 Conclusion

  • ACTS provides open-source, experiment-independent and framework-independent track reconstruction algorithms that do not depend on detector technology or magnetic-field details and are tested for thread-safety.The tools are intended to support concurrent event processing.Source: §6 · p. 23
  • The maturing toolkit provides track and vertex algorithms being integrated into experimental frameworks, with geometries for several particle and nuclear physics detectors included.The authors expect further framework deployment and increased investment in R&D lines.Source: §6 · p. 23
  • Initial studies examined the physics and computational performance of ACTS track and vertex reconstruction algorithms using the TrackML detector.Source: §6 · p. 23
  • Full performance for any specific detector requires detailed algorithm tuning, which is beyond this paper's scope and is expected to be done by individual experimental collaborations.Source: §6 · p. 23

Declarations

The paper reports its funding sources, declares no conflict of interest, and states that no associated data are available apart from code. The research code is available open source.

Declarations

Loading 2106.13593v1…