arXiv subjects

C. Gaspar

Publications and source records attributed to C. Gaspar.

4 recordsLinked to original sources

arXiv2026

Operation and performance of the Probe for Luminosity Measurement at LHCb

The Probe for LUminosity MEasurement (PLUME) detector is a dedicated luminosity monitor at the LHCb interaction point. It is a hodoscope comprising 48 Hamamatsu R760 photomultiplier tubes that detect Cherenkov light produced by particles travelling in the direction opposite to the LHCb spectrometer acceptance. PLUME provides real-time, bunch-by-bunch luminosity measurements during LHCb data taking and serves as the primary detector for controlling the luminosity levelling process at LHCb. In addition, its data are used offline, together with other dedicated counters from LHCb sub-systems, to determine the integrated luminosity delivered to the experiment. This paper reports on the detector's operational performance during the 2024-2026 data-taking period of Run 3. The integrated luminosity recorded by the LHCb experiment in $pp$ collisions at $\sqrt{s} = 13.6$ TeV during this period, as measured by the PLUME online luminosity counters for detector performance monitoring, amounts to $\mathcal{L} = (26.71 \pm 1.07)$ fb$^{-1}$. The luminosity values used in physics analyses are determined separately through dedicated offline calibrations based on van der Meer scans and Beam Gas Imaging techniques, and will be reported in a dedicated publication, as they are beyond the scope of this paper.

hep-ex↗

arXiv2018

Design and performance of the LHCb trigger and full real-time reconstruction in Run 2 of the LHC

The LHCb collaboration has redesigned its trigger to enable the full offline detector reconstruction to be performed in real time. Together with the real-time alignment and calibration of the detector, and a software infrastructure to make persistent the high-level physics objects produced during real-time processing, this redesign enabled the widespread deployment of real-time analysis during Run 2. We describe the design of the Run 2 trigger and real-time reconstruction, and present data-driven performance measurements for a representative sample of LHCb's physics programme.

hep-ex↗

arXiv2013

The LHCb Trigger and its Performance in 2011

This paper presents the design of the LHCb trigger and its performance on data taken at the LHC in 2011. A principal goal of LHCb is to perform flavour physics measurements, and the trigger is designed to distinguish charm and beauty decays from the light quark background. Using a combination of lepton identification and measurements of the particles' transverse momenta the trigger selects particles originating from charm and beauty hadrons, which typically fly a finite distance before decaying. The trigger reduces the roughly 11\,MHz of bunch-bunch crossings that contain at least one inelastic $pp$ interaction to 3\,kHz. This reduction takes place in two stages; the first stage is implemented in hardware and the second stage is a software application that runs on a large computer farm. A data-driven method is used to evaluate the performance of the trigger on several charm and beauty decay modes.

hep-ex↗

arXiv2003

DIRAC - Distributed Infrastructure with Remote Agent Control

This paper describes DIRAC, the LHCb Monte Carlo production system. DIRAC has a client/server architecture based on: Compute elements distributed among the collaborating institutes; Databases for production management, bookkeeping (the metadata catalogue) and software configuration; Monitoring and cataloguing services for updating and accessing the databases. Locally installed software agents implemented in Python monitor the local batch queue, interrogate the production database for any outstanding production requests using the XML-RPC protocol and initiate the job submission. The agent checks and, if necessary, installs any required software automatically. After the job has processed the events, the agent transfers the output data and updates the metadata catalogue. DIRAC has been successfully installed at 18 collaborating institutes, including the DataGRID, and has been used in recent Physics Data Challenges. In the near to medium term future we must use a mixed environment with different types of grid middleware or no middleware. We describe how this flexibility has been achieved and how ubiquitously available grid middleware would improve DIRAC.

cs.DC↗