Abstract
Upon its restart in 2022, the LHCb experiment at the LHC will run at higher instantaneous luminosity and utilize an unprecedented full-software trigger, promising greater physics reach and efficiency. On the flip side, conforming to offline data storage constraints becomes far more challenging. Both of these considerations necessitate a set of highly optimised trigger selections. We therefore present HltEfficiencyChecker: an automated extension to the LHCb trigger application, facilitating trigger development before data-taking driven by trigger rates and efficiencies. Since the default in 2022 will be to persist only the event’s signal candidate to disk, discarding the rest of the event, we also compute efficiencies where the decision was due to the true MC signal, evaluated by matching it to the trigger candidate hit-by-hit. This matching procedure – which we validate here – demonstrates that the distinction between a “trigger” and a “trigger-on-signal” is crucial in characterising the performance of a trigger selection.
Highlights
The upgraded LHCb detector in Run 3 (2022-2025) [1] will take data at five times the previous instantaneous luminosity, yielding on average five to six pp interactions per bunch crossing [2]
HLT1 and HLT2, the High Level Trigger (HLT) performs a complete reconstruction of each collision, and persists only those events we consider to be interesting, thereby reducing the amount of data we store by three orders of magnitude
Each of these selections is known as a trigger line, which typically defines how a trigger candidate is reconstructed from tracks up to a software object that represents either a full or partial signal decay, and a variety of complex thresholds that the candidate must satisfy
Summary
The upgraded LHCb detector in Run 3 (2022-2025) [1] will take data at five times the previous instantaneous luminosity, yielding on average five to six pp interactions per bunch crossing [2]. The majority of trigger lines will persist to the Turbo stream, which discards the raw event and saves only the reconstructed signal candidate in the event, in a format ready for physics analysis [2, 6] This drastically reduces the size of each saved event, but makes an offline reconstruction and selection from the raw event impossible. For lines that will persist part/all of the raw event, the only candidates which have a trigger efficiency that can be well understood, in a typical physics analysis, are those that can be matched to the signal.
Sign-in/Register to view highlights & summary Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a callDisclaimer: All third-party content on this website/platform is and will remain the property of their respective owners and is provided on "as is" basis without any warranties, express or implied. Use of third-party content does not indicate any affiliation, sponsorship with or endorsement by them. Any references to third-party content is to identify the corresponding services and shall be considered fair use under The CopyrightLaw.
