Werner Wiedenmann

The Configuration System of the ATLAS Trigger

The ATLAS detector at CERNs LHC will be exposed to proton-proton collisions at a rate of 40 MHz. To reduce the data rate, only potentially interesting events are selected by a three-level trigger system. The first level is implemented in custom-made electronics, with an output rate to less than 100 kHz. The second and third level are software triggers with a final output rate of 100 to 200 Hz. A system has been designed and implemented that holds and records the full configuration information of all three trigger levels at a centrally maintained location. This system provides fast access to consistent configuration information of the online trigger system for the purpose of data taking as well as to all parts of the offline trigger simulation. The use of relational database technology provides a means of reliable recording of the trigger configuration history over the lifetime of the experiment. In addition to the online system, tools for flexible browsing and manipulation of trigger configurations, and for their distribution across the ATLAS reconstruction sites have been developed. The usability of this design has been demonstrated in dedicated configuration tests of the ATLAS level-1 Central Trigger and of a 600-node software trigger computing farm. Further tests on a computing cluster which is part of the final high level trigger system were also successful.

Performance of the final Event Builder for the ATLAS Experiment

Event data from proton-proton collisions at the LHC will be selected by the ATLAS experiment in a three level trigger system, which reduces the initial bunch crossing rate of 40 MHz at its first two trigger levels (LVL1+LVL2) to ~3 kHz. At this rate the Event-Builder collects the data from all read-out system PCs (ROSs) and provides fully assembled events to the the event-filter (EF), which is the third level trigger, to achieve a further rate reduction to ~ 200 Hz for permanent storage. The event-builder is based on a farm of O(100) PCs, interconnected via gigabit Ethernet to O(150) ROSs. These PCs run Linux and multi-threaded software applications implemented in C++. All the ROSs and one third of the event-builder PCs are already installed and commissioned. We report on performance tests on this initial system, which show promising results to reach the final data throughput required for the ATLAS experiment.

Overview of the high-level trigger electron and photon selection for the ATLAS experiment at the LHC

The ATLAS experiment is one of two general purpose experiments to start running at the Large Hadron Collider in 2007. The short bunch crossing period of 25 ns and the large background of soft-scattering events overlapped in each bunch crossing pose serious challenges that the ATLAS trigger must overcome in order to efficiently select interesting events. The ATLAS trigger consists of a hardware-based first-level trigger and of a software-based high-level trigger, which can be further divided into the second-level trigger and the event filter. This paper presents the current state of development of methods to be used in the high-level trigger to select events containing electrons or photons with high transverse momentum. The performance of these methods is presented, resulting from both simulation studies, timing measurements, and test beam studies.

The ATLAS Event Builder

Event data from proton-proton collisions at the LHC will be selected by the ATLAS experiment in a three-level trigger system, which, at its first two trigger levels (LVL1+LVL2), reduces the initial bunch crossing rate of 40 MHz to ~3 kHz. At this rate, the Event Builder collects the data from the readout system PCs (ROSs) and provides fully assembled events to the Event Filter (EF). The EF is the third trigger level and its aim is to achieve a further rate reduction to ~200 Hz on the permanent storage. The Event Builder is based on a farm of 0(100) PCs, interconnected via a Gigabit Ethernet to 0(150) ROSs. These PCs run Linux and multi-threaded software applications implemented in C++. All the ROSs, and substantial fractions of the Event Builder and Event Filter PCs have been installed and commissioned. We report on performance tests on this initial system, which is capable of going beyond the required data rates and bandwidths for Event Building for the ATLAS experiment.

The ATLAS online High Level Trigger framework: Experience reusing offline software components in the ATLAS trigger

Event selection in the ATLAS High Level Trigger is accomplished to a large extent by reusing software components and event selection algorithms developed and tested in an offline environment. Many of these offline software modules are not specifically designed to run in a heavily multi-threaded online data flow environment. The ATLAS High Level Trigger (HLT) framework based on the GAUDI and ATLAS ATHENA frameworks, forms the interface layer, which allows the execution of the HLT selection and monitoring code within the online run control and data flow software. While such an approach provides a unified environment for trigger event selection across all of ATLAS, it also poses strict requirements on the reused software components in terms of performance, memory usage and stability. Experience of running the HLT selection software in the different environments and especially on large multi-node trigger farms has been gained in several commissioning periods using preloaded Monte Carlo events, in data taking periods with cosmic events and in a short period with proton beams from LHC. The contribution discusses the architectural aspects of the HLT framework, its performance and its software environment within the ATLAS computing, trigger and data flow projects. Emphasis is also put on the architectural implications for the software by the use of multi-core processors in the computing farms and the experiences gained with multi-threading and multi-process technologies.

A configuration system for the ATLAS trigger

The ATLAS detector at CERN’s LHC will be exposed to proton-proton collisions at a rate of 40 MHz. To reduce the data rate, only potentially interesting events are selected by a three-level trigger system. The first level is implemented in firmware, reducing the data output rate to about 100 kHz. The second and third levels are software triggers with an output rate of about 200 Hz. A system has been designed and implemented that hosts and records the configuration of all three trigger levels at a centrally maintained location. This system consistently provides configuration information to the online trigger for the purpose of data taking as well as to the offline trigger simulation. The use of relational database technology provides means of flexible information browsing, easy information distribution across the ATLAS reconstruction sites and reliable recording of the trigger configuration history over the lifetime of the experiment. The functionality of this design has been demonstrated in dedicated configuration tests of the ATLAS level-1 Central Trigger and of a 600-node software trigger computing farm. We present the current status of the system and its readiness for data taking. We put emphasis on the multiple use of the trigger configuration for data-taking, Monte-Carlo simulation and trigger validation.

The ATLAS Trigger Simulation with Legacy Software

Physics analyses at the LHC require accurate simulations of the detector response and the event selection processes, generally done with the most recent software releases. The trigger response simulation is crucial for determination of overall selection efficiencies and signal sensitivities and should be done with the same software release with which data were recorded. This requires potentially running with software dating many years back, the so-called legacy software, in which algorithms and configuration may differ from their current implementation. Therefore having a strategy for running legacy software in a modern environment becomes essential when data simulated for past years start to present a sizeable fraction of the total. The requirements and possibilities for such a simulation scheme within the ATLAS software framework were examined and a proof-of-concept simulation chain has been successfully implemented. One of the greatest challenges was the choice of a data format which promises long term compatibility with old and new software releases. Over the time periods envisaged, data format incompatibilities are also likely to emerge in databases and other external support services. Software availability may become an issue, when e.g. the support for the underlying operating system might stop. The encountered problems and developed solutions will be presented, and proposals for future development will be discussed. Some ideas reach beyond the retrospective trigger simulation scheme in ATLAS as they also touch more generally aspects of data preservation.

ATLAS trigger simulation with legacy code using virtualization techniques

Several scenarios, both present and future, require re-simulation of the trigger response in the ATLAS experiment at the LHC. While software for the detector response simulation and event reconstruction is allowed to change and improve, the trigger response simulation has to reflect the conditions at which data was taken. This poses a maintenance and data preservation problem. Several strategies have been considered and a proof-of-concept model using virtualization has been developed. While the virtualization with CernVM elegantly solves several aspects of the data preservation problem, the limitations of current methods for contextualization of the virtual machine as well as incompatibilities in the currently used data format introduces new challenges. In this proceeding these challenges, their current solutions and the proof of concept model for precise trigger simulation are discussed.

A new Scheme for ATLAS Trigger Simulation using Legacy Code

Analyses at the LHC which search for rare physics processes or determine with high precision Standard Model parameters require accurate simulations of the detector response and the event selection processes. The accurate determination of the trigger response is crucial for the determination of overall selection efficiencies and signal sensitivities. For the generation and the reconstruction of simulated event data, the most recent software releases are usually used to ensure the best agreement between simulated data and real data. For the simulation of the trigger selection process, however, ideally the same software release that was deployed when the real data were taken should be used. This potentially requires running software dating many years back. Having a strategy for running old software in a modern environment thus becomes essential when data simulated for past years start to present a sizable fraction of the total. We examined the requirements and possibilities for such a simulation scheme within the ATLAS software framework and successfully implemented a proof-of-concept simulation chain. One of the greatest challenges was the choice of a data format which promises long term compatibility with old and new software releases. Over the time periods envisaged, data format incompatibilities are also likely to emerge in databases and other external support services. Software availability may become an issue, when e.g. the support for the underlying operating system might stop. In this paper we present the encountered problems and developed solutions, and discuss proposals for future development. Some ideas reach beyond the retrospective trigger simulation scheme in ATLAS as they also touch more generally aspects of data preservation.

The TriggerTool graphical user interface to the ATLAS trigger configuration database

The ATLAS detector at the LHC uses a three-level trigger system to select events of potential interest from the 40 MHz proton-proton collisions, thereby reducing the data rate to a manageable level. A system has been designed and implemented to configure all three trigger levels from a centrally provided relational database, in which an archive of all trigger configurations used in data taking is also maintained. The user interaction with this database is via a Java-based graphical user interface known as the TriggerTool. We describe here how the TriggerTool has been designed to fulfill several different roles for users of varying expertise, from being a browser of the database to a tool for creating and modifying configurations.