Source-linked AI summary
Tesla : an application for real-time data analysis in High Energy Physics
R. Aaij, S. Amato, L. Anderlini, S. Benson, M. Cattaneo, M. Clemencic, B. Couturier, M. Frank, V. V. Gligorov, T. Head, C. Jones, I. Komarov, O. Lupton, R. Matev, G. Raven, B. Sciascia, T. Skwarnicki, P. Spradlin, S. Stahl, B. Storaci, M. Vesterinen
TL;DR
LHCb faces the challenge of selecting rare beauty decays from high-rate collisions. Tesla processes compact trigger-calculated records for direct physics analysis, and its 2015 commissioning supported multiple analyses using this model.
Problem
Selecting beauty and charm decays from roughly 30 million proton-proton collisions per second is a significant Big Data challenge.
Source: §1 · p. 3Method
Results
Successful commissioning in 2015 allowed multiple analyses to use this model, and higher LHCb upgrade output rates will make it increasingly necessary.
Source: §6 · p. 16Takeaways & Limitations
Tesla output files are compatible with existing analysis-framework software with minimal changes required from analysts.
Source: §6 · p. 16Analysis-quality HLT reconstruction depends on real-time detector alignment and calibration enabled by upgraded computing infrastructure and buffering after the first software trigger level.
Source: §6 · p. 16
Abstract
from arXiv · showhide
Upgrades to the LHCb computing infrastructure in the first long shutdown of the LHC have allowed for high quality decay information to be calculated by the software trigger making a separate offline event reconstruction unnecessary. Furthermore, the storage space of the triggered candidate is an order of magnitude smaller than the entire raw event that would otherwise need to be persisted. Tesla, following the LHCb renowned physicist naming convention, is an application designed to process the information calculated by the trigger, with the resulting output used to directly perform physics measurements.
1 Introduction
LHCb must select rare beauty decays amid roughly 30 million proton-proton collisions per second. Run-II computing upgrades enabled online reconstruction with offline-like quality, allowing Tesla to prepare trigger information for direct physics analysis without a separate offline reconstruction.
1 Introduction
- Selecting beauty and charm decays from approximately 30 million proton-proton collisions per second is a major Big Data challenge.At the 2012 nominal luminosity, about 30,000 beauty and 600,000 charm hadron pairs passed through the detector each second; typical interesting beauty decays have probabilities below 10^-5.Source: §1 · p. 3
- The High Level Trigger reduces the event rate from 1 million to about 10,000 events per second [1].The HLT runs on the Event Filter Farm, whose storage can accommodate up to two weeks of nominal LHCb data taking.Source: §1 · p. 3
- In Run-I, HLT-accepted events were stored with raw detector information and reconstructed again offline using improved calibration.The Run-II upgrade made online reconstruction of similar quality possible.Source: §1 · p. 3
- Run-II infrastructure and storage improvements enabled online reconstruction with quality similar to offline reconstruction through real-time automated sub-detector calibration.This removes the need for further reprocessing.Source: §1 · p. 3
- Tesla prepares a compact event record from trigger-calculated information for physics analysis, bypassing offline reconstruction.The paper presents real-time analysis as a way to reach the experiment’s ultimate precision as data arrive.Source: §1 · p. 3
2 The LHCb detector, data acquisition, and trigger strategy
LHCb combines a forward spectrometer and a multi-level trigger to select interesting beauty-hadron decays from high-rate collisions. Its hardware and software stages progressively reduce event rates and reconstruct selected events for analysis and storage.
2 The LHCb detector, data acquisition, and trigger strategy
- The LHCb forward spectrometer measures beauty-hadron decays using tracking, calorimetry, and particle-identification systems.The tracking system includes the VELO, TT, and IT/OT stations; RICH detectors, muon chambers, and calorimeters contribute to particle identification.Source: §2 · p. 4
2.1 Data readout and hardware trigger
- The hardware L0 trigger reduces the roughly 30 MHz collision rate within a fixed 4 µs latency, while readout boards and the supervisor route events to available farm resources.L0 uses FPGA algorithms drawing on ECAL, HCAL, and muon information; the readout boards limit output to 1.1 MHz.Source: §2.1 · p. 4
2.2 High Level Trigger
- HLT1 selects events using charged-track reconstruction, and HLT2 uses all sub-detectors for full reconstruction and final selection.HLT1 outputs about 150 kHz; HLT2 reduces this to about 10 kHz for analysis and permanent storage.Source: §2.2 · p. 5
3 Run-II data taking
Run-II separated the software trigger into independently operating stages, with an intervening buffer supporting alignment and calibration before HLT2. Calibrated trigger reconstructions feed distinct output streams, including Turbo events that need no further event reconstruction.
3 Run-II data taking
- From 2015, HLT1 and HLT2 ran independently with a buffer between them, allowing high-quality alignment and calibration between trigger stages.The new split replaced the Run-I buffer between the hardware trigger and HLT1 and separated direct event processing from asynchronous HLT2 processing.Source: §3 · p. 5
3.1 Real-time alignment and calibration
- Automated alignment and calibration use dedicated HLT1 samples and run before HLT2, with updated parameters stored by time when they differ significantly.Tasks run on Event Filter Farm nodes in a few minutes and at regular intervals that can be as frequent as each new proton beam.Source: §3.1 · pp. 5–6
- Real-time calibration covers tracking alignment, RICH mirror alignment, outer-tracker time offsets, and RICH radiator refractive indices.Tracking alignment minimizes Kalman-fit residuals; the RICH refractive-index calibration compares expected and measured Cherenkov angles.Source: §3.1 · pp. 6–7
3.2 Streaming and data flow
- Trigger routing bits assign events to Full, Turbo, or Calibration streams, and an event may appear in more than one stream.Full-stream events undergo offline reconstruction from raw banks, while Turbo datasets are ready for analysis after luminosity records and trigger-object restoration, without further event reconstruction.Source: §3.2 · pp. 7–8
- The Calibration stream stores selected candidates together with raw sub-detector data, enabling both offline reconstruction and Turbo trigger restoration on the same events.These candidates can provide data-driven corrections for online and offline reconstructions.Source: Calibration · p. 8
4 Implementation of the Turbo stream
The Turbo stream replaces conventional raw-event processing with compact trigger candidates prepared for analysis, while persistence mechanisms retain decay topology and analysis-specific information. Tesla formats the output for existing tools, and example distributions show signals reconstructed online.
4 Implementation of the Turbo stream
- Turbo events are an order of magnitude smaller than Full-stream events; under standard Run-II conditions, about 20% of HLT2-selected events use less than 2% of output bandwidth.The size reduction allows sub-detector information to be discarded.Source: §4 · p. 8
- For 3 GB of input, traditional processing takes 24 hours for reconstruction plus 6 hours for selection, while Tesla formats Turbo data in approximately 1 hour.Figure 2 compares the processing steps and their times for a 3 GB raw data file.Source: §4 · p. 8, Figure 2 · p. 9
4.1 The Tesla application
- Tesla prepares trigger candidates for existing analysis tools, records luminosity information, exposes online quantities, and retains requested candidates, trigger decisions, and headers.It also supports simulated datasets and can protect raw detector data for offline reconstruction.Source: §4 · p. 9, §4.1 · pp. 9–10
4.2 Persistence of trigger objects
- Decay-topology links extend object summaries to save complete decay chains; versioned converters and per-class static maps restore selected class information across bank versions.The version is recorded event by event, allowing multiple versions to be processed simultaneously.Source: §4.2 · pp. 12–13
4.3 Additional analysis requirements
- Analysis-dependent isolation maps use generated utility keys to persist each map key/value pair, while static analysis objects such as primary vertices fitted without signal tracks use ordinary persistence.The dynamic-map approach preserves the map's key and corresponding value in the raw data stream.Source: §4.3 · p. 13
4.4 Analysis using the online reconstruction
- Example distributions of online-reconstructed candidates show clear D+, Ds+, and D*+ peaks; Full-stream output limits would otherwise exclude some high-rate decays.The stated purpose of the infrastructure is to collect more decays and enable more precise measurements than the Run-I computing model allowed.Source: §4.4 · pp. 13–14, Figure 7 · p. 14
5 Outlook and future prospects
Turbo stream use succeeded in 2015, and higher output rates expected in the upgraded LHCb experiment increase the need for it. The paper also outlines extending trigger reconstruction to save complete reconstructed events and avoid another reconstruction.
5 Outlook and future prospects
- The first two LHCb physics measurements based on 2015 data used Turbo, and around half of current HLT2 trigger lines persist trigger reconstruction through it.The successful 2015 use supports multiple analyses based on the model.Source: §5 · p. 14
5.1 Use in the upgraded LHCb experiment
- The upgraded experiment raises luminosity from 4 × 10^32cm−2s−1 to 2 × 10^33cm−2s−1, while removing L0 means the software trigger must handle input rates around 30 times larger.A mixture of Turbo and traditional approaches is expected because many analyses require full event information; using Turbo for all events is projected to require 100 MB/s and provide 20× the traditional approach's output event rate with the same resources.Source: §5.1 · p. 15
5.2 Extended use of the trigger reconstruction
- Saving trigger-reconstructed physics objects in raw data banks could avoid an additional reconstruction, reduce computing time, and allow event-by-event decisions to retain raw data.The proposal extends the Turbo model by formatting online-reconstructed objects for user-level analysis tools.Source: §5.2 · pp. 15–16, Figure 8 · p. 16
6 Summary
Tesla enables physics analyses using event reconstruction performed by the LHCb HLT, whose quality for analysis depends on real-time detector alignment and calibration. Its successful 2015 commissioning supported multiple analyses, and higher upgrade output rates will make the approach increasingly necessary.
6 Summary
- Tesla allows analyses to use LHCb HLT event reconstruction, with output files compatible with existing analysis software and requiring minimal analyst changes.The HLT reconstruction is considered sufficient for physics analyses because detector alignment and calibration occur in real time.Source: §6 · p. 16
- Successful commissioning in 2015 allowed multiple analyses to use the model, and higher output rates in the LHCb upgrade will make it increasingly necessary.Source: §6 · p. 16