Table d'hôte or à la carte?

4 October 2010

Today’s trigger menu chefs coordinated by Olya: (standing) Emanuel Strauss, Iwona Grabowska-Bold, Paul Bell, Anna Sfyrla and (in front) Takanori Kono, Rasmus Mackeprang ,Silke Nelson and Olya Igonkina.

We provide an amazing choice of features, and you can even create your own item choosing your favorites from our signature ingredients! Our chefs will do the magic and fire up your creation.

This could be an advertisement for the menu of a new restaurant, or just a spicy description of the ATLAS trigger menu.

For ATLAS, as for any other high energy and luminosity collider experiment, triggering is essential. At a bunch spacing of 25 ns, the LHC has 3564 possible bunch positions, but not all of these are populated. Even if only 1% of the bunches were filled and colliding, the resulting collision rate would be far too large to save to disk even if our readout systems could handle it. Most events are uninteresting to study anyway. Defining the readout timing and only recording interesting bunch crossings at a given rate based on what the detector observed are two functions that the trigger controls.

The ATLAS trigger is a three-tiered system consisting of a hardware-based component, the Level-1 (L1), and two farms of computers running software algorithms, the Level-2 (L2) and the Event Filter (EF). The L2 and the EF are referred to as High Level Trigger (HLT). Available resources define the limitation in the output bandwidth of both the L1 and the HLT. Balancing the interplay between the detector readout bandwidth and the processing power in the HLT limit the L1 output rate to 75 kHz. The offline computing capacity for storing and processing data limits the annual average HLT output rate to O(200Hz). These limiting factors crucially affect the data that we, ATLAS collaboration, retain and analyze. Collision events that are not triggered on are lost forever. This is the point where the trigger menu comes into play.

The trigger menu is a list of trigger selection criteria, each of which refers to requirements at all three trigger levels. The trigger accepts an event only if one or more selection criteria are satisfied. The various selections contained in a menu have to primarily collect as many interesting events as possible for our diverse physics programs, including standard model precision measurements, searches for Higgs, SUSY and other exotic models in a large range of decaying channels, as well as any unpredicted new physics. They also have to provide enough data for calibrations, efficiency measurements and background estimations, together with data without any HLT selection (pass-through triggers) for studying the performance of the trigger itself. The trigger "chefs" (the trigger signature and menu groups) have to continuously deploy all their skill and imagination to create a rich menu that satisfies all tastes.

The menu that we have been collecting data with since last August contains a very broad list of triggers: about 230 L1 items and 440 HLT chains (L2 and EF criteria) are currently defined, covering a wide spectrum of selection aspects. No more than roughly 10 consecutive days could we keep the menu stable since we first deployed it. The continuously increasing luminosities together with optimizations on algorithms and selection definitions, as we gain experience, often result in significant changes.

But how are such changes implemented in our menu? The first step for a trigger selection to be modified or added is a feature request registered in the ATLAS 'Savannah' portal. The proposed changes have to be explained and justified by the physics groups, and it is up to the menu coordination group, run by Olya Igonkina, to approve or reject them. If approved, the trigger menu experts take over: they make the appropriate configuration changes and validate them in a series of tests (nightly built releases and offline trigger reprocessing being the main ones). At this point, the trigger-online and trigger-menu-experts on-call make sure the changes are properly propagated for data taking. This whole procedure takes as little as two days, depending on the urgency of the requested changes. In such cases, the intensive workload for the menu and online trigger experts is taken for granted. In fact, the trigger-menu-experts on-call are by now used to working hard to ensure ATLAS acquires as good and as much data as possible.

At this point, you may ask yourself, but if ATLAS has such a large and broad menu, what is the role of the trigger-menus-expert on-call? The answer is to make sure your favorite trigger is not prescaled out! The prescale is a factor associated with a trigger at each level that indicates what fraction of events that could pass this trigger selection is actually accepted. In an ideal world of unlimited data storage, networking capacity and CPU needed to analyze the acquired data, we would run all triggers 'un-prescaled'. However, prescaling triggers is unfortunately unavoidable. We collect data ensuring that the 'primary' triggers that apply tight selections and are used for physics measurements and searches run un-prescaled. We also collect additional low rate data for commissioning, monitoring and calibration. In this LHC era of continuously increasing instantaneous luminosities, the list of primary triggers evolves rapidly and the task of adjusting prescales becomes quite a challenge. Take as an example "e10_loose", a trigger designed to retain electrons with at least 10 GeV in transverse momentum and selected with loose electron identification criteria. This trigger may run un-prescaled at low luminosity (∼10 30 cm-2 s-1), but its rate becomes too large at higher luminosities and would flood the system. This forces us to prescale it and use as primary un-prescaled trigger a higher momentum threshold and/or tighter selection instead, such as "e15_medium".

The trigger menu experts find the best combination of prescales using the rate predictions provided by the trigger rates group, and taking into account not only the bandwidth limitations per trigger level, but also the bandwidth allocation per trigger signature group. The prescales that the trigger menu experts have developed and that have been approved by the trigger and performance/physics groups are applied online. The trigger-menu-expert on-call is the one of the menu experts that makes sure that prescales are applied properly (e.g. no physics trigger is prescaled) when adjustments are required during data taking.

Trigger prescaling is the main reason why you may have had to change the trigger selection in your analysis more than once already since data taking started. If you are still not sure whether you are using the loosest un-prescaled trigger for each data-taking period, you can consult the ATLAS run query or the trigger signature groups, which will provide you with detailed recommendations. And if you don't see your favorite trigger in the menu, now you know how to order it! Remember, events that are not triggered are lost, and you are the best physicist to know what type of events you need for your analysis. The trigger is served à la carte, and the trigger menu chefs are here to make sure you'll get the most you can from the ATLAS data.


Anna Sfyrla