Implementation and performance of the seeded reconstruction for the ATLAS event filter

ATLAS is one of the four major Large Hadron Collider (LHC) experiments that will start data taking in 2007. It is designed to cover a wide range of physics topics. The ATLAS trigger system has to be able to reduce an initial 40 MHz event rate, corresponding to an average of 23 proton-proton inelastic interactions per every 25 ns bunch crossing, to 200 Hz admissible by the Data Acquisition System. The ATLAS trigger is divided in three different levels. The first one provides a signal describing an event signature using dedicated custom hardware. This signature must be confirmed by the High Level Trigger (HLT) which using commercial computing farms performs an event reconstruction by running a sequence of algorithms. The validity of a signature is checked after every algorithm execution. A main characteristic of the ATLAS HLT is that only the data in a certain window around the position flagged by the first level trigger are analyzed. In this work, the performance of one sequence that runs at the Event Filter level (third level) is demonstrated. The goal of this sequence is to reconstruct and identify high transverse momentum electrons by performing cluster reconstruction at the electromagnetic calorimeter, track reconstruction at the Inner Detector, and cluster track matching.


Implementation and Performance of the Seeded I. INTRODUCTION
A TLAS is one of the two multi-purpose experiments of the LHC. This accelerator will provide, at its design luminosity of cm s , an average of 23 inelastic proton-proton collisions per bunch crossing at a center of mass energy of 14 TeV. This means a rate of interactions per second. The ATLAS Trigger must reduce this to a rate of the order of 200 Hz, which is the maximum storage capacity of the Data Acquisition System, with the highest possible efficiency for selecting interesting events.
The ATLAS trigger is subdivided in three levels. The first one (LVL1) is fully accomplished by electronic modules that detect electron, photon, jet, tau, missing and muon candidates. This Manuscript received June 16, 2005;revised April 8, 2006. Please see the Acknowledgment section of this paper for the author affiliations.
Digital Object Identifier 10.1109/TNS. 2006.875440 system also provides the timing information for the subdetectors readout. LVL1 must, in a latency of 2 s, reduce the event rate to 75 kHz, upgradeable to 100 kHz. The second and third levels of the ATLAS trigger constitute the so-called High Level Trigger (HLT). Both levels analyze the events accepted by LVL1 in commercial computer farms. The third trigger level, called Event Filter (EF) has a target execution time of 1 second. Both the second level and the Event Filter are seeded 1 , this means reconstruction is guided by the previous trigger level to access data only in a "Region of Interest" (RoI) where the detector signal shows the signature of a particle candidate. The average number of RoIs per event is expected to be around 1.4 but this depends on the luminosity and LVL1 trigger configuration. Typically an HLT algorithm is run once per RoI. This means that in general HLT algorithms can be executed more than once per event. Differently, and by software design, the offline reconstruction algorithms can be only executed once per event. Despite the these differences between trigger and offline algorithms, the programming environment is common for both. In fact the aim is that EF algorithms are adaptations of the offline ones.
While the LVL2 and EF infrastructure significantly differs [4] the HLT algorithms could be, in principle, ported from LVL2 to EF and vice versa. In practice the latter is unlikely since LVL2 algorithms must run in less than 10 ms, whereas a single EF algorithm, using offline software, can take of the order of 50 ms or more. In general LVL2 algorithms are characterized by a fast data access, using in some cases their own data converters, and coarse reconstruction. EF algorithms are more precise and use most of offline services. The advantage of using offline code in the EF is to significantly reduce the amount of reconstruction code to be written and maintained specially for the trigger.
Performing the reconstruction only in small neighborhoods of hot regions has the advantage of minimizing the time for data unpacking and preparation. Furthermore, many of the interesting physics events correspond to topologies where a large number of RoIs are active. The HLT software can be configured to request n different simultaneous physics signatures. For that  TABLE I  PHYSICS GOALS OF THE ELECTRONS DETECTION LVL1 will need to provide at least n active RoIs. The reconstruction is made stepwise and in parallel per RoI while selection requirements are applied after every step. The event is rejected if at any point the number of simultaneous reconstrucion chains falls below n. This feature facilitates an early rejection of the event.
In this paper we analyze the design and implementation of a fully seeded Event Filter trigger menu for the selection of high transverse momentum isolated electrons. We will also discuss the different algorithms, their physics goals as well as their time performance.

II. RELEVANCE OF SELECTION OF ELECTRONS
Isolated electrons provide a clean signature and can be efficiently selected by the trigger. Many important physics channels at the LHC are characterized by one or more hightransverse-momentum electrons in the final state. This includes Standard Model physics (top, QCD, precise measurement of W and Z properties), the discovery of new particles, such as the Higgs boson or the search for SuperSymmetry. In Table I a summary of some relevant channels with at least one electron in its final state is shown together with their corresponding trigger signature. A trigger signature describes a set of criteria for event acceptance. For example, labels an event where the data corresponding to two different RoI's fulfills an electron hypothesis after the HLT algorithms reconstruction, as will be described in Section IV. This event has high probability of having two isolated electrons/positrons with transverse energy above 15 GeV.

III. THE HIGH LEVEL TRIGGER STEERING
The ATLAS High Level Trigger (HLT) is guided by the first level (LVL1) hardware based trigger. The HLT usually accesses only data in an RoI whose position is initially provided by LVL1 and refined by the successive HLT algorithms. The HLT algorithms are driven by the High Level Trigger Steering [5] (the Steering from now on). The Steering is an algorithm of the ATLAS software framework (Athena). The Steering configuration is done with trigger menus. A trigger menu is a table of signatures. An event is accepted if it fulfills at least one signature. A signature is a set of one or several active Trigger Elements where a Trigger Element is an object that symbolises the level to which reconstruction in the RoI has progress and holds a flag to indicate whether or not this succeeded. The execution of algorithms is organized by sequences. A sequence can be represented by a three column list where every row contains one or several algorithms, output Trigger Element(s), and input Trigger Elements. Algorithms can set an "active" flag in the output trigger ele-ment to indicate whether they succeeded or failed to find the desired pattern in the RoI data. The Steering only executes an algorithm if the input Trigger Element(s), the output of a previous sequence, exist(s) and is (are) active. In general a signature requires one or more active Trigger Elements from the last sequence. For example is a signature requiring two simultaneous active trigger elements from the sequence that reconstructs and selects a single electron of more than 15 GeV transverse energy.
The High Level Trigger Steering accepts or rejects an event at every step based on the information from the required signatures of a trigger menu. This means that if a Trigger Element is included in a signature the Steering records all its dependencies in previous Trigger Elements of a sequence. In that way if the Steering sees an inactive Trigger Element at an early stage of a sequence execution it knows that the Trigger Element in the signature will never be active and can stop the sequence execution and in some cases reject the event. For example, if a required signature of an event is (two isolated electrons with transverse energy higher than 15 GeV) then the Steering requests that the event contains at least two LVL1 electromagnetic RoIs. Afterward it will start the execution of an algorithm sequence for each RoI and require after every sequence algorithm execution that there are at least two active output Trigger Elements. If at some point there is only one, the steering will immediately reject the event. This implementation optimizes time consumption of the High Level Trigger avoiding execution of unnecessary algorithms. An example will be discussed in the next two sections.
An algorithm can link an object of any type to its output Trigger Element and the subsequent algorithms will be able to retrieve this object navigating through the chain of Trigger Elements produced by the preceding algorithms and up to the LVL1 RoI descriptor (an object that summarizes the relevant information from LVL1, in particular the position of the RoI).
The High Level Trigger Algorithms are classified in two types: • The Feature Extraction Algorithms that in general retrieve and unpack detector data and perform reconstruction creating simple classes composed of meaningful physics variables. They consume most of the available time and should be run as seldom as possible. For example, the algorithm called TrigCaloRec retrieves the cells within an RoI from the ATLAS calorimeters and constructs Calorimeter Electromagnetic Clusters. The Calorimeter Cluster class contains, among others, the position of the cluster and its energy.
In some cases a Feature Extraction algorithm only merges information already retrieved by a previous algorithm.
Consider as an example TrigegammaRec. This algorithm retrieves, via the Trigger Elements chain, the clusters created by TrigCaloRec and the tracks created by the corresponding Inner Detector algorithm and finds the best track-cluster match by considering several variables such as , the ratio between the cluster energy and the track momentum. The Feature Extraction algorithms normally activate the output Trigger Element.
• The second type of High Level Trigger Algorithms are the Hypothesis algorithms. These are extremely fast execution algorithms ( s) who retrieve the physics information from the Trigger Element chain and validate a given hypothesis. They set the output Trigger element active if the hypothesis conditions are fulfilled. This separation between Feature Extraction and Hypothesis algorithms optimizes time consumption since the data retrieved by a single Feature Extraction algorithm execution can be used to provide several fast Hypothesis algorithms which validate different physics signatures, hence avoiding multiple data access and unpacking. Let us consider the Event Filter sequence to validate the signatures and , isolated single electrons of 25 and 15 GeV . Both will need, for example, the same information from the calorimeter. Then, TrigCaloRec, the above mentioned calorimeter Feature Extraction Algorithm, will be executed once in the RoI. Two different hypothesis algorithms will access the same electromagnetic cluster through the Trigger Element applying their different cuts.

IV. THE SEEDED EVENT FILTER MENU FOR HIGH TRANSVERSE MOMENTUM ELECTRONS DETECTION
As mentioned earlier, the aim for the Event Filter was to re-use, as far as possible, the offline code for the event reconstruction. This is why in the past, the studies of the Event Filter performance were made based on pure offline reconstruction. The approach is quite different to that of LVL2 where specific trigger algorithms have been developed for which time performance was the priority. The Event Filter has now been adapted to work with the Steering and access data in RoIs only.
Among others the electron trigger menu that consists of two signatures and two sequences has been implemented. However the two sequences coincide in the algorithms and differ only in the selection cuts implemented in the hypothesis algorithms. The Feature Extraction algorithms sequence is then: • TrigCaloRec: this is, as already mentioned, an algorithm for reconstructing clusters in the electromagnetic calorimeter. It also accesses data in the hadronic calorimeter to compute energy leakage of electromagnetic showers or identify and veto hadrons. • EFID (Event Filter Inner Detector) is composed of: -Pixel clustering: retrieves data from the Pixel silicon detector and forms clusters in the RoI. -SCT clustering: retrieves data from the Silicon Tracker detector and forms clusters in the RoI. -TRT drift circles: retrieves data from the Transition Radiation Tracker and forms drift circles in the RoI. -Space Point formation: uses the clusters and drift circles from the previous algorithms and forms space points (hit positions). -iPatRec: a tracking algorithm that forms track-candidates using space-point combinatorial subject to criteria on maximum curvature and crude vertex region projectivity [3]. • TrigegammaRec: is an algorithm that reconstructs the so called egamma objects in the RoI. An egamma object is composed of four types of variables: -Electromagnetic Cluster shape info. -Electromagnetic Shower variables.
-The pointer to the best matching track with the shower (if it exists). -Combined Shower and Track variables. The sequence is completed with the corresponding hypothesis algorithms where selection cuts are applied. Below the applied selection requirements are described, where the word in italics stands for the numerical value of the corresponding selection cut in every case.
• EFCaloHypo: is the Event Filter Calorimeter hypothesis algorithm. It performs a geometrical cut on and , where the subscript LVL2 indicates the RoI position received from LVL2, and a cut on the cluster . • EFIDHypo: performs the cuts on the inner detector variables. The number of space points in the different detectors must fulfill Hits Hits and Hits . Finally the Track-impact parameter rejects events not produced near enough to the interaction point. 2 • EFIDCaloHypo: performs a cut on the Cluster-Track residual and and on the ratio between the cluster energy and the track reconstructed momentum --. In this case two different regions are defined where two different lower and upper cuts are applied. Fig. 1 gives a schematic view of the structure of the Event Filter sequence for the electron selection. The output objects, linked to the corresponding output Trigger Elements of the Feature Extraction Algorithms are explicitly shown. The different selection cuts are also illustrated linked to the hypothesis algorithm where they are applied.
Two different sets of selection cuts have been applied to identify isolated electrons with transverse energy higher than 15 GeV and higher than 25 GeV, respectively, producing and active Trigger Elements at the end of the sequence in the Event Filter Inner detector are N Hits that is the total number of hits in the Pixel detector, N Hits the total number of hits in the SCT detector and N Hits the number of hits in the innermost layer of the Pixel detector.

V. PERFORMANCE OF THE EVENT FILTER ELECTRON SELECTION
The performance of the high transverse momentum electron selection of the ATLAS Event Filter can be expressed by three parameters. One is the efficiency for a given sample of data, the second is the output rate of data, strongly dominated by the amount of background events, and the third the average processing time. The efficiency of two different signal samples has been computed. The first one consists of single electron events with monochromatic transverse energy of 25 . This sample is an artificial construction to optimize the selection of the signature, useful for some of the physics goals listed in Table I. The second sample considered is the decay. For this channel the High Level Trigger Steering with two simultaneous signatures, and , was tested. As mentioned above, the signature requires at least two active Trigger Elements while the signature requires a single active Trigger Element. It was also required for this signal sample that from LVL2 there were at least two active Trigger Elements in order to have the same amount of events for both signatures. As a background, a sample composed of jet-jet events was used, where one or both jets could be misidentified as electrons [2].
The event sample was generated with the Pythia Monte Carlo [6] requiring a large transverse jet momentum ( GeV/c).The resulting rates can be seen in Table III. It should be noted that the QCD di-jet cross section for this region is poorly known and hence the trigger rates can change by a factor of two or three when using real data. Table IV shows the execution time per algorithm. Fig. 2 shows the integrated total time distribution. The data unpacking contribution is explicitly shown. For this purpose the hypothesis algorithms were ommited from the sequence and hence all events were processed through the full Feature Extraction algorithm sequence. This overestimates the time consumption because many of the events should be rejected in the early steps of the sequence. Nevertheless it can be seen that the reconstruction at the Event Filter takes much less than the total average allowed time of 1 second (electron and photon selection only has 200 ms allocated). The times are per RoI   while around 1.4 RoI are expected in average per event in ATLAS running conditions [1]. The times were measured with a 2.8 GHz processor and linearly extrapolated to the expected processor specification of the final EF farm: 8 GHz or equivalent lower-speed multicore processors. The data used for this time estimation is a QCD jet-jet sample in the nominal design luminosity of cm s where simulated electronic noise was accounted and pile-up effects simulated by superposing several inelastic proton-proton events.
Finally a comparison of the reconstruction quality of the seeded algorithms has been made with the offline results. The energy resolution in the calorimeter, the momentum resolution in the Inner detector, the position resolution in both systems and the matching residual have shown to be comparable to the results obtained by the standard offline electron reconstruction. As an example, Fig. 3(a) and (b) shows the comparison between the and residuals of the calorimeter cluster and inner detector track match at the electromagnetic calorimeter level. The distribution shows an asymmetry due to the effect of the solenoidal magnetic field of the ATLAS spectrometer. This field bends the electron trajectories in the direction and if the electron looses momentum by bremsstrahlung the bending angle predicted by extrapolating the inner detector track will always be smaller than the one where the particle hits the calorimeter.

VI. CONCLUSION
A menu with more than one signature and containing real Event Filter trigger algorithms has been implemented. The performance of this menu, devoted to high electrons selection, has been tested on ATLAS simulated data. The tests include the execution of two simultaneous signatures per event which has been made for the first time in ATLAS. This analysis shows that the ATLAS Event Filter can be run successfully on physics event samples. In future studies the effect of rate reduction due to rejection by previous algorithms should be considered. S. J. Wheeler is with University of Alberta, Edmonton, Canada, and University of California at Irvine, Irvine, California, USA.