• John
  • Felde
  • University of Maryland
  • USA

Latest Posts

  • USLHC
  • USLHC
  • USA

  • James
  • Doherty
  • Open University
  • United Kingdom

Latest Posts

  • Andrea
  • Signori
  • Nikhef
  • Netherlands

Latest Posts

  • CERN
  • Geneva
  • Switzerland

Latest Posts

  • Aidan
  • Randle-Conde
  • Université Libre de Bruxelles
  • Belgium

Latest Posts

  • TRIUMF
  • Vancouver, BC
  • Canada

Latest Posts

  • Laura
  • Gladstone
  • MIT
  • USA

Latest Posts

  • Steven
  • Goldfarb
  • University of Michigan

Latest Posts

  • Fermilab
  • Batavia, IL
  • USA

Latest Posts

  • Seth
  • Zenz
  • Imperial College London
  • UK

Latest Posts

  • Nhan
  • Tran
  • Fermilab
  • USA

Latest Posts

  • Alex
  • Millar
  • University of Melbourne
  • Australia

Latest Posts

  • Ken
  • Bloom
  • USLHC
  • USA

Latest Posts

Anna Phan | USLHC | USA

View Blog | Read Bio

We’ll deal with that later…

In my last post, I described the different LHC collision setup at LHCb this year. Today, I thought I would describe the different LHCb trigger setup.

Now what is the LHCb trigger, I hear you all ask? I actually wrote a post on the topic last year, which I invite you all to read for details, here I’m just going to explain the details I need to describe the changes.

The LHCb trigger is an online electronic system that selects which collision events will be written to disk for offline analysis. On the right here, I have a schematic of the system. It consists of two levels; the first is made up of custom electronics, called L0, while the second is a computer farm, called HLT.

We call it an online system, as it runs in real time. As fast as collision events are coming in, the L0 electronics decides whether to reject an event or send it to the HLT. The HLT gets a little more time to make a decision, but it still needs to be pretty fast. However, sometimes it can’t handle all the events that the L0 is feeding it, and we lose events as the buffers fill up.

 

This situation is what our new trigger setup is designed to avoid. How are we going to do this? It was noticed that the HLT computing farm sits idle when there aren’t any collisions. So somebody came up with the clever idea to buffer events locally on the farm nodes and defer processing them until after the current collision period[*]. Thus the trigger now looks something like the schematic on the left[**].

This means we can record even more data!

——————————————————————————–

[*] The LHC doesn’t collide protons continuously, there’s a cycle in which protons are injected, accelerated, collided, ejected and the machine prepared for the next injection. Ideally, most of the time would be spent in collisions (in LHC speak: stable beams), but this isn’t always possible or viable.

[**] I have obviously simplified how the deferred HLT works. Like most simple ideas, it was quite complicated in practice. There were a lot of technicalities to consider, like how many events to store in the overflow, or what to do if the overflow became full, or how to avoid the scenario where we’re still processing deferred events when the next collision period starts…

Share

Tags: ,