Trigger and DAQ
Students and staff from RHUL are involved in a wide range of work on the ATLAS Trigger, from developing software to select electrons in a few milliseconds, to day-to day online operation of the trigger.
The ATLAS trigger has to sift through the debris of LHC proton bunch collisions that occur at up to 40 million times per second, and select only a few hundred per second of these 'events' to save for further analysis. The rest are lost for ever. So, no pressure then!
ATLAS has designed a three-level trigger system to perform this challenging task. It was designed, built and commissioning by a community of over 500 people from universities and labs all over the world, including RHUL. The first level is realised in custom-built electronics (FPGA and ASIC in case you're an interested electronics expert). The higher level trigger (HLT) is implemented as software running on a network of around 2300 computers. We've been developing several parts of this software, including the framework and some of the algorithms.
RHUL staff and students regularly play their part in operating the trigger, with expert roles and shifts in the Atlas Control Room. Special training is given so you can sit at the trigger desk all night and know what to do when the trigger rate goes up - or down - unexpectedly.
RHUL staff have a long standing involvement in the management of the Atlas Trigger, with leadership in the areas of software coordination and trigger algorithms. We have also represented the interests of several key physics groups in the trigger menu coordination group, where the high-level strategies for the trigger are decided.
The trigger software project has about a million lines of C++/Python code, ~50 active developers and we build about 20 releases per year. In a typical week we have ~100 open bugs and 50 opened/closed. RHUL staff coordinate this work and develop many of the tools and procedures for managing and validating all this the software.
Trigger algorithms are developed though collaboration between trigger experts, reconstruction software developers and physics analysis groups to give the optimum balance between technical performance (memory, cpu and network usage), the best rejection and least biased selection. This performance has to be validated before use and monitored once it is on-line. Students and staff from RHUL have been involved in all parts of this process, including recent work in electron/photon triggers.
On ATLAS, we had a major involvement in the design, development, prototyping, testing and production of the Read Out Buffer (ROBin) cards, which are a key part of the Read Out Subsystem (ROS). The PCI-based ROBin card, which incorporates the S-LINK on the PCB is shown above. The UK production of 350 ROBin cards for ATLAS was completed in March 2006.
We also developed the buffer manager software for the ROBin card in which the memory management of the buffer is performed in the host PC processor, and software to deal with data requests and data distribution. We have benchmarked the switch-based ROS, to be compared with the bus-based ROS. We developed a Test Suite of programs to configure and test the ROBin cards.
The current Robin design interfaces to the ROS host PC using PCI-X. This technology is fast becoming obsolete as it has been superseeded by PCI Express (PCIe). The ATLAS ROS host PCs (ELONEX) have motherboards with six PCI-X slots; the CPUs are Intel single core Xeons, which are not manufactured any more. Even though ATLAS has 10% spares, it is realistic to assume that in a time scale of, say, 3-5 years ATLAS will need a new PCIe version of the Robin, to cope with irrecoverable Robin/motherboard/CPU failures. Investigation has found that the replacement of only one major component would convert the existing Robin design to PCIe thus allowing ROSs to be implemented using PCIe technology.
The plan is to prototype and test a new Robin compatible with PCIe, by effecting minimal changes to the current, PCI-X-compatible, design. This will allow ATLAS to rely on more modern motherboards, thus ensuring the medium-term life of the ATLAS ROS system. An essential requirement is that the new RobinExpress ROSs must be able to coexist side-by-side with the current PCI-X ROSs.