A. Bogaerts

Studies for a common selection software environment in ATLAS: from the level-2 trigger to the offline reconstruction

The ATLAS High Level Triggers (HLT) primary function of event selection will be accomplished with a Level-2 trigger farm and an event filter (EF) farm, both running software components developed in the ATLAS offline reconstruction framework. While this approach provides a unified software framework for event selection, it poses strict requirements on offline components critical for the Level-2 trigger. A Level-2 decision in ATLAS must typically be accomplished within 10 ms and with multiple event processing in concurrent threads. To address these constraints, prototypes have been developed that incorporate elements of the ATLAS data flow, high level trigger, and offline framework software. To realize a homogeneous software environment for offline components in the HLT, the Level-2 Steering Controller was developed. With electron/gamma- and muon-selection slices it has been shown that the required performance can be reached, if the offline components used are carefully designed and optimized for the application in the HLT.

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.

Architecture of the ATLAS High Level Trigger Event Selection Software

We present an overview of the strategy for Event Selection at the ATLAS High Level Trigger and describe the architecture and main components of the software developed for this purpose.

Algorithms for the ATLAS high-level trigger

Following rigorous software design and analysis methods, an object-based architecture has been developed to derive the second- and third-level trigger decisions for the future ATLAS detector at the LHC. The functional components within this system responsible for generating elements of the trigger decisions are algorithms running within the software architecture. Relevant aspects of the architecture are reviewed along with concrete examples of specific algorithms and their performance in vertical slices of various physics selection strategies.

ATLAS TDAQ DataCollection software

The DataCollection (DC) is a subsystem of the ATLAS Trigger and DAQ system. It is responsible for the movement of event data from the ReadOut subsystem to the Second Level Trigger and to the Event Filter. This functionality is distributed on several software applications running on Linux PCs interconnected with Gigabit Ethernet. For the design and implementation of these applications a common approach has been adopted. This approach leads to the design and implementation of a common DC software framework providing a suite of common services.

First experience with the scalable coherent interface

The research project RD24 is studying applications of the scalable coherent interface (IEEE-1596) standard for the Large Hadron Collider (LHC). First SCI node chips from Dolphin were used to demonstrate the use and functioning of SCIs packet protocols and to measure data rates. We present results from a first, two-node SCI ringlet at CERN, based on a R3000 RISC processor node and DMA node on a MC68040 processor bus. A diagnostic link analyzer monitors the SCI packet protocols up to full link bandwidth. In its second phase, RD24 will build a first implementation of a multi-ringlet SCI data merger. >

The CHI, a new Fastbus interface and processor

The CERN Host Interface (CHI) is a family of interfaces to interconnect Fastbus, VMEbus, and external host computers. The Fastbus interface consists of a processor board (CHI-P) and host-specific I/O ports allowing connection using fast parallel or serial interfaces. For efficiency in a data acquisition chain, the CHI-P contains a 1-MB triple-port memory which allows concurrent access by Fastbus (as master or slave), the host link, and the 4.5 MIPS onboard processor. The processor, an MC68030 with floating point coprocessor, also has 1 Mb of local memory and 1.25 Mb of EPROM (electrically programmable ROM). The hardware modularity allows the CHI-P to be used as an interface, general-purpose Fastbus test module, or an embedded Fastbus processor. The resident software supports its use in each of these modes. Remote procedure calls, an ISO-style transport service, and the Standard Routines for Fastbus are provided on the host and on the CHI-P, allowing the migration of software between the two. Menu-driven test software and an interactive interpreted/compiled language support its use in a test environment. >

An overview of the ATLAS high-level trigger dataflow and supervision

The ATLAS high-level trigger (HLT) system provides software-based event selection after the initial LVL1 hardware trigger. It is composed of two stages, the LVL2 trigger and the event filter (EF). The LVL2 trigger performs event selection with optimized algorithms using selected data guided by Region of Interest pointers provided by the LVL1 trigger. Those events selected by LVL2 are built into complete events, which are passed to the EF for a further stage of event selection and classification using off-line algorithms. Events surviving the EF selection are passed for off-line storage. The two stages of HLT are implemented on processor farms. The concept of distributing the selection process between LVL2 and EF is a key element in the architecture, which allows it to be flexible to changes (luminosity, detector knowledge, background conditions, etc.) Although there are some differences in the requirements between these subsystems there are many commonalities. An overview of the dataflow (event selection) and supervision (control, configuration, monitoring) activities in the HLT is given, highlighting where commonalities between the two subsystems can be exploited and indicating where requirements dictate that implementations differ. An HLT prototype system has been built at CERN. Functional testing is being carried out in order to validate the HLT architecture.

The ATLAS Level-2 Trigger Pilot Project

The Level-2 Trigger Pilot Project of ATLAS, one of the two general purpose LHC experiments, is part of the on-going programme to develop the ATLAS High Level Triggers (HLT). The Level-2 Trigger will receive events at up to 100 kHz, which has to be reduced to a rate suitable for full event-building of the order of 1 kHz. To reduce the data collection bandwidth and processing power required for the challenging Level-2 task it is planned to use Region of Interest guidance (from Level-1) and sequential processing. The Pilot Project included the construction and use of testbeds of up to 48 processing nodes, development of optimised components and computer simulations of a full system. It has shown how the required performance can be achieved, using largely commodity components and operating systems, and validated an architecture for the Level-2 system. This paper describes the principal achievements and conclusions of this project.

Experience with a Virtual Memory Based Data Acquisition System at CERN

This paper describes a Data Acquisition System which has been specifically designed to take advantage of modern operating systems. It is modular, structured as a set of independent tasks communicating via a shared data area. The design is based on the concept of circular buffers with associated data producer and (parallel) consumer tasks. By using privileged tasks in time critical areas, a fast and efficient system has been obtained: interrupt latency of less than 100 microseconds, and data transfer speeds essentially limited by hardware (CAMAC DMA or magnetic tape recording). The tasks may be distributed over different processors. For example, 16/32 bit multi-processors with a shared multi-port memory are used to implement systems where powerful data reduction and/or monitoring tasks are required. The system is in use at over 25 high energy and nuclear physics experiments at CERN and in other European laboratories.