LHCb Refines Legacy Collision Data Processing to Sustain High-Energy Physics Analyses

The LHCb collaboration has systematically optimized its centralized offline data processing architecture through the ongoing LHCb Stripping project, establishing a sustainable framework to preserve, refine, and reprocess petabyte-scale legacy collision data from the Large Hadron Collider. Serving as the vital final stage of centralized offline production before distributed physics analyses take place, the Stripping framework extracts clean, manageable subsets of particle collision events from billions of recorded interactions. Integrated since 2020 as a core pillar of Work Package 5 within the experiment’s Data Processing and Analysis framework, the project manages the preservation of software and legacy data collected during Run 1 between 2010 and 2012 as well as Run 2 between 2015 and 2018. By combining modular Python-configurable selection algorithms with modernized continuous integration systems, automated campaign tracking, and robust distributed computing workflows, the framework guarantees that older experimental datasets remain fully accessible and computationally viable for ongoing and future precision physics measurements.

The operational necessity of the Stripping framework arises directly from the extreme data production rates generated by CERN’s Large Hadron Collider. During proton-proton collision operations, the collider delivers particle interactions to the LHCb detector at a continuous frequency of 40 megahertz, producing an overwhelming influx of raw data that reached approximately one terabyte per second during Run 2. Because permanent storage of such massive volumes exceeds practical budgetary and infrastructure limits, the experiment relies on a multi-stage filtering hierarchy. Initial event selection begins with hardware-based Level-0 triggers and software-driven High Level Triggers that identify kinematic characteristics and decay candidate signatures in real time. Events satisfying these initial criteria are reconstructed by the Brunel application, which transforms raw detector signals and sensor hits into physical tracks and particle identification hypotheses stored in optimized Data Summary Tape files. The DaVinci application then executes the Stripping process, performing specialized selection algorithms to filter and persist events in standard or micro formats.

The Stripping package itself operates directly on top of the DaVinci offline analysis framework, which coordinates event-by-event data processing, produces end-user nTuples, and harmonizes selection utilities across central and individual analysis tiers. DaVinci is built upon the Gaudi framework and LHCb core software, drawing critical operational dependencies from specialized packages including Phys, Rec, and LbCom. To handle underlying algorithmic execution and mathematical modeling, this architecture relies upon external software distributions supplied by the Worldwide LHC Computing Grid, with specific versions of the ROOT scientific software framework bound to designated computing grid releases. In parallel, DaVinci incorporates an Analysis sub-project that supplies advanced analytical utilities specifically intended for downstream physics investigations without burdening the upstream event-filtering routines executed during centralized Stripping passes.

The data processing architecture applies equivalent filtering rigor to simulated datasets, ensuring that detector effects, background processes, and systematic uncertainties are treated symmetrically between synthetic models and real experimental runs. Synthetic data generation begins with the Gauss application, which models primary proton-proton collisions and particle decay chains through specialized event generators such as Pythia and EvtGen, followed by detailed Geant4 simulations that track particle trajectories through detector geometry and material media. The Boole application then digitizes these simulated interactions, transforming simulated energy deposits into synthetic electronic signals that closely mimic actual detector readouts. Once digitized, these simulated events are routed through the identical Brunel reconstruction software and DaVinci Stripping selections applied to real collision data.

Execution of the Stripping framework is organized through structured campaigns that define the physics scope and available event selections across distinct data-taking periods. Historically classified into prompt campaigns executed during active data collection, full campaigns, and incremental campaigns, these efforts are cataloged using a standardized versioning nomenclature denoted as SXrYpZ. Within this naming scheme, the major index designates a full campaign corresponding to an entire data year, the minor index reflects a superseding full reprocessing pass, and the patch index marks an incremental update containing newly implemented or modified selection algorithms. While prompt campaigns have become obsolete, the collaboration relies on full campaigns to reprocess all active selection lines and incremental campaigns to execute newly approved lines over targeted legacy data. Each campaign requires coordinated preparation spanning several months, engaging central coordinators, physics working group liaisons, and distributed computing teams to consolidate legacy production Git branches, validate algorithm performance, and schedule execution on distributed grid nodes.

To ensure high software quality and prevent processing bottlenecks, the Stripping campaign methodology enforces rigorous development and code review protocols managed through GitLab merge requests. Physicists develop selection lines within their designated Physics Working Group packages, submitting merge requests to group-specific development branches rather than directly into production channels. Working group liaisons evaluate these submissions against strict performance baselines, ensuring algorithms consume no more than one millisecond of execution time per event while restricting line retention rates to equal to or less than 0.05 percent for standard Data Summary Tape streams and equal to or less than 0.5 percent for micro Data Summary Tape streams. GitLab continuous integration pipelines automatically execute linting and dataset-specific functional tests on each pushed branch, verifying syntax integrity and timing performance across individual campaign years. Isolating continuous integration runs to specific working group branches minimizes computational overhead, enabling liaisons to validate selection dictionaries and merge approved code into centralized production branches on predictable schedules.

The production management architecture has similarly transitioned from legacy ticketing systems to modern declarative configuration standards that enhance operational consistency. The collaboration phased out its former reliance on JIRA for coordinator-production communications, establishing an integrated GitLab-centric workflow aligned with Run 3 offline production standards. Under this modernized framework, campaign processing directives for the Dirac distributed computing workload system are declared using structured YAML configuration files. These declarative YAML specifications detail complete operational parameters, specifying targeted data years, detector conditions, software versions, and necessary application packages in a unified, machine-readable format. This transition simplifies campaign scheduling and provides operational flexibility when validation stages conclude ahead of planned production timetables.

Quantitative performance evaluations from recent reprocessing campaigns illustrate substantial reductions in data volume achieved by combining event skimming with targeted event slimming. In the latest incremental reprocessing of Run 1 data comprising 2.5 petabytes of input, the Stripping pipeline reduced output storage to 350 terabytes, achieving an overall size reduction factor of seven. Similarly, a 2023–2024 incremental campaign operating across 6.17 petabytes of Run 2 data collected between 2016 and 2018 yielded 1.48 petabytes, delivering a reduction factor of 4.2. In full reprocessing campaigns, where the fraction of selected events across all streams can reach 70 percent, significant volume reductions of two to three are achieved primarily through event slimming—the deliberate stripping away of unneeded detector hits and intermediate reconstruction objects—rather than event skimming, which discards unselected events entirely. Incremental campaigns yield typical volume reduction factors between four and five, maintaining average Run 2 output event sizes between 25 and 35 kilobytes.

Filtered events are categorized and stored across specialized output streams tailored to the analytical requirements of individual physics working groups and detector subsystems. Most campaigns implement seven to nine distinct streams, including the dimuon, electroweak, charm, and heavy b-hadron streams, alongside dedicated channels such as calibration streams for detector alignment and flavor-tagging streams. Event sizes vary widely across stream formats: standard Data Summary Tape streams that persist complete reconstructed events range from 80 to 100 kilobytes per event, semileptonic streams requiring partially reconstructed objects average 70 to 80 kilobytes, and micro Data Summary Tape streams like the basic b-hadron stream require only 10 to 15 kilobytes. Three streams—the complete b-hadron, leptonic micro, and semileptonic streams—collectively account for approximately two-thirds of total output volume. Special fixed-target heavy-ion runs conducted using the System for Measuring Overlap with Gas demonstrated unique behavior, generating 35 kilobytes per event in final ion and fixed-target streams while compressing 110 to 130 terabytes through a threefold volume reduction.

Operational efficiency has advanced markedly alongside technical upgrades, as demonstrated by execution metrics recorded during sequential reprocessing campaigns of 2018 collision data. Processing intervals for 2018 incremental campaigns fell from an initial baseline of two weeks down to a single week for the latest iteration, once planned distributed computing resource pauses were accounted for. To sustain this momentum across multi-year intervals characterized by personnel turnover, targeted training initiatives and developer surveys were integrated into the campaign cycle, substantially increasing analyst confidence and technical proficiency. Building upon these operational insights and the successful Sprucing framework developed for Run 3, the legacy computing team proposed an iterative five-step roadmap featuring early selection line development, branch-based continuous integration validation, regular working group integration, milestone tracking, and buffered operational deadlines.

Subject of Research: Sustainable legacy data processing and campaign workflows in the LHCb experiment

Article Title: The LHCb Stripping Project: Sustainable Legacy Data Processing for High-Energy Physics

Article References: Grieser, N. A., Rodrigues, E., Sahoo, N., Sheng, S., Skidmore, N., & Smith, M. (2025). The LHCb Stripping Project: Sustainable Legacy Data Processing for High-Energy Physics. Computing and Software for Big Science, 9(1), Article 21. https://doi.org/10.1007/s41781-025-00151-6

Image Credits: AI Generated

DOI: 10.1007/s41781-025-00151-6

Keywords: LHCb, CERN, High-Energy Physics, Data Processing, Stripping Project, Particle Physics, Legacy Software, Large Hadron Collider, Stripping, Project, Sustainable, Legacy