The high level trigger software for the CMS experiment

Abstract

The observation of new physics will be a challenging task for the CMS experiment at the LHC, in particular for its High Level trigger (HLT). A prototype of the High Level Trigger software to be used in the filter farm of the CMS experiment and for the filtering of Monte Carlo samples will be presented. The implemented prototype heavily uses recursive processing of a HLT tree and allows dynamic trigger definition. The general architecture and design choices as well as the timing performance of the system are reviewed in the light of the DAQ constrains. CMS DAQ AND TRIGGER DESIGN The Compact Muon Solenoid (CMS) [1] is one of the two multi-purposes experiments at the future Large Hadron Collider. The CMS data acquisition system (DAQ) [2] is particular in the sense that it has been designed to minimize the use of custom technologies. The collaboration therefore benefits from the rapid growth of standard network and computing technologies. This choice implies that there is no special resources allocated in the design of a so called Level-2 trigger. The whole event selection is performed in two stages, respectively called Level-1 and High Level Trigger (HLT). The by-product of this decision is that the selection strategies will only be defined in the HLT software. It will certainly give more flexibility for the evolution of the selection strategies that physicist will require when developing new analysis. Another specificity of the CMS DAQ is it’s modularity. It is expected that the LHC instantaneous luminosity will build up with time. Therefore it is not necessary to have the full bandwidth at the first day of beam crossing. The DAQ design allows to add bandwidth by chunks of 12:5kHz as needed as the luminosity build up as well as the storage capacity. This modularity is reflected in the HLT cluster, build with a large amount of commercial computers. The High Level Trigger is involved each 10 s, as soon as a Level-1 trigger accept is issued by the Level-1 Global Trigger Processor. The task of the HLT is to further reduce the data rate by a factor 1000in or order to fulfill the requirement of an output rate below 100Hz. This means that the HLT decision has to be taken within 10 ms while keeping efficiency as high as possible for the known physics channels. In order to achieve this data reduction, a massive computing power will be required. If one assumes Universite Catholique de Louvain, olivier.van.der.aa@cern.ch y Universite Catholique de Louvain, christophe.delaere@cern.ch a mean computing time of O(10 2) s for each Level-1 acceptm with a data input rate of O(105) Hz, it means that the computing cluster that will host the HLT system will be constituted of about 1000CPUs. The role of the CMS DAQ is to provide the events to the computing elements of the HLT system. With an estimated event size of 1MB per event at the Level-1 output rate the DAQ system will require a total bandwidth of 100GB=s. HLT STEERING SOFTWARE The HLT steering software [3] has the role of applying selection criteria on reconstructed quantities. For that purpose, it uses reconstruction software [4] dedicated to each subdetector and has to bring individual responses together to build the global accept/reject . It can be seen as a logical equation involving the evaluation of several quantities that are reconstructed from the detector response. The equation can be translated into a tree where each node or element is either an operand or an logical operator. The tree representation allows to recursively evaluate the trigger. HighLevelTriggerElement RecAlgorithm LazyObserver HighLevelTriggerLevel p2 p1 p1 p2=NULL vector cand bool result bit_vector response Figure 1: UML diagram of the HLT basic building blocks The basic building blocks of the HLT are shown in Fig 1. The HighLevelTriggerElement represents each element (node) of the HLT tree. An element of a binary tree is by definition connected to two other elements that we will call “daughters”. It outputs three objects 1. bool decision , stating the result of the selection performed in the element,