Improvements of the ALICE GPU TPC tracking and GPU framework for online and offline processing of Run 3 Pb-Pb data

TL;DR

The paper documents improvements to ALICE's GPU-based TPC tracking and GPU framework designed to handle Run 3 Pb--Pb data with continuous readout and large space-charge distortions. It outlines a three-phase progression of tracking enhancements (Phase I–III) to improve cluster attachment, efficiency, and resilience to high occupancy, along with a cluster-reduction strategy for online data compression. It also details GPU framework advances, notably Run Time Compilation (RTC), a deterministic processing mode, and Optuna-based auto-tuning, which collectively yield significant online and offline speedups and enable greater GPU participation in both online and offline reconstruction. The results show strong progress toward higher physics efficiency with manageable fake rates, substantial online/offline speedups, and a clear path to broader GPU use and full-barrel offline offloading in future runs.

Abstract

ALICE is the dedicated heavy ion experiment at the LHC at CERN and records lead-lead collisions at a rate of up to 50 kHz in LHC Run 3. To cope with such collision and data rates, ALICE uses a new GEM TPC with continuous readout and a GPU-based online computing farm for data compression. Operating the first GEM TPC of this size with large space charge distortions due to the high collision rate has many implications for the track reconstruction algorithm, both anticipated and unanticipated. With real Pb-Pb data available, the TPC tracking algorithm needed to be refined, particularly with respect to improved cluster attachment at the inner TPC region. In order to use the online computing farm efficiently for offline processing when there is no beam in the LHC, ALICE is currently running TPC tracking on GPUs also in offline processing. For the future, ALICE aims to run more computing steps on the GPU, and to use other GPU-enabled resources besides its online computing farm. These aspects, along with better possibilities for performance optimizations led to several improvements of the GPU framework and GPU tracking code, particularly using Run Time Compilation (RTC). The talk will give an overview of the improvements for the ALICE tracking code, mostly based on experience from reconstructing real Pb-Pb data with high TPC occupancy. In addition, an overview of the online and offline processing status on GPUs will be given, and an overview of how RTC improves the ALICE tracking code and GPU support.

Figures (4)

• Figure 1: Matching Efficiency for ITS and TPC tracks versus local TPC occupancy. (a) shows two curves for processing of raw data and for MC data. Solid markers indicate the probability to find a TPC track for a given ITS track. Hollow markers indicate in the other way around the probability to find an ITS track for a given TPC track. Local TPC occupancy is the number of clusters in the TPC time bins close to the track. A cut of $\lvert \eta \rvert < 0.2$ is applied to show only tracks where all clusters of the track see more or less the same local occupancy. (b) shows the probability to find a TPC track for a given ITS track versus the lowest TPC pad row, which has a cluster assigned to the TPC track. Two curves are shown for collisions in the highest 30% and in the lowest 40% of TPC occupancy.
• Figure 2: Track finding efficiency, clone rate and fake rate comparison of the original ALICE TPC tracking algorithm in operation until August 2025, the new version including the phase I improvements deployed in September 2025, and the development version containing the phase II improvements. Findable tracks are required to have at least 70 hits in the TPC, while the efficiency for general tracks is computed for tracks that have at least as many hits in the TPC as the $p_{\text{T}}$-dependent $n_{\text{Cl}}$ cut during the tracking requires.
• Figure 3: Track $p_{\text{T}}$ spectrum comparison of direct reconstruction from raw data to first compression to a CTF and then reconstruction from CTF. The tracking algorithm including the phase I improvements is used. (a) applies strict cuts during both the online and offline phases, and compares the reconstruction via CTF in the original form and with the fix to protect the history of the tracks. (b) applies loose cuts during the reconstruction, and compares the usage of strict cuts versus loose cuts during the compression to CTF.
• Figure 4: Fraction of TPC tracks found given an ITS track in reconstruction from CTF relative to direct reconstruction from the raw data. Square brackets in the legend indicate whether the original reconstruction or phase I improvements were used, in any case with loose cuts. Brackets indicate which cuts and which reconstruction version was used for the online phase to produce the CTF.