Quantum Diaries

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…

G’day all! Today I will be continuing the Australian theme and discuss panning for gold. Which being completely correct isn’t really Australian, since it was probably practiced in any gold rich area. However in my defense, an integral part of Australian history is the gold rush in the late 19th century and a visit to one of the old gold areas is an excursion most Australian school children take.

For those who are wondering what gold panning is, it’s a method of searching for gold in stream beds using a pan. It doesn’t tend to yield high quantities of the precious metal, but it doesn’t take much equipment and can be used to locate gold rich areas. It requires lots of patience to sit by a stream and slowly separate the dense precious metal from the less dense, less interesting rocks and sand.

What does this have to do with particle physics and LHCb I hear you all ask? Well, gold panning is a fairly good analogy for trying to identify collisions in which B mesons are produced, and from those collisions trying to find the particular B meson decays we are interested in.

To give you some numbers, the rate of collisions at the LHCb interaction point is 40 MHz, of which only about 10 MHz will contain particles which are within the acceptance of the LHCb detector. Events where all the decay products of a B meson can be detected by LHCb have a rate of about 15 kHz, while the rate of specific B meson decays that are interesting for physics analysis is around a few Hz. So we are only interested in approximately one out of ten million collisions that the detector sees per second.

The first level of event selection is performed by an online electronic system, called the trigger, that selects which events will be stored on disk for offline analysis. The trigger is a very important system, since it is not possible to record every event on disk due to limited bandwidth; we must make sure that events containing interesting B meson decays are kept.

Schematically shown above, the LHCb trigger system operates on two levels. The first, called L0, is comprised of custom electronics and uses information from the VELO, the calorimeter, and the muon systems. From the ten million proton collisions that LHCb sees per second, it selects around one million events per second for further processing, while discarding the remaining nine million. The first level trigger works incredibly fast, making its decision in just four millionths of a second.

After filtering by the first level trigger, an overwhelming number of events still remains. These are fed into a farm of over two thousand computers, which make up the HLT, the second level trigger, located deep underground at the LHCb site. These machines select interesting events to save for analysis, further trimming the one million events per second to a more manageable two thousand. This second level trigger uses the full detector information and has more time to make a decision than its first level counterpart.

If you’ve been paying very close attention to all the numbers you might have noticed that we’re writing events to disk at a rate of 2 kHz, while the interesting physics rate is a few Hz. Due to computing resources, it is not possible to analyse the full dataset when the signal to background ratio is so low, so there is second level of event selection, called stripping[*]. The major difference between trigger and stripping is that events which the trigger rejects are lost forever; stripping selections on the other hand, can be rerun if necessary.

Stripping contains a set of preselection algorithms defined by each physics analysis in LHCb, which are run offline after data taking to produce a set of selected events for further individual analysis. The events that pass the defined stripping selection criteria will be fully reconstructed, recreating the full information associated with each event in preparation for detailed analysis.

Returning to the gold panning analogy, we started out with a pan full of generic proton collisions. Triggering removed all the collisions which are obviously not gold, which don’t look like B meson decays at all. Stripping removed what we think isn’t gold, but we put the rejected collisions to the side, just in case they could be gold. With what’s remaining, with a bit more work, hopefully we can find what we are looking for… Gold!

[*] Yes, it is actually called stripping. I’m too new to the experiment to know the history of the term, though I have been privy to enough discussions on the topic that I don’t find it amusing anymore.