G. Galster

Equilibrium strategy and population-size effects in lowest unique bid auctions.

In lowest unique bid auctions, N players bid for an item. The winner is whoever places the lowest bid, provided that it is also unique. We use a grand canonical approach to derive an analytical expression for the equilibrium distribution of strategies. We then study the properties of the solution as a function of the mean number of players, and compare them with a large data set of internet auctions. The theory agrees with the data with striking accuracy for small population-size N, while for larger N a qualitatively different distribution is observed. We interpret this result as the emergence of two different regimes, one in which adaptation is feasible and one in which it is not. Our results question the actual possibility of a large population to adapt and find the optimal strategy when participating in a collective game.

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.

Run Control Communication for the Upgrade of the ATLAS Muon-to-Central-Trigger-Processor Interface (MUCTPI)

The Muon-to-Central-Trigger-Processor Interface (MUCTPI) of the ATLAS experiment at the Large Hadron Collider (LHC) at CERN will be upgraded to an ATCA blade system for Run 3, starting in 2021. The new design requires development of new communication models for control, configuration and monitoring. A System-on-Chip (SoC) with a programmable logic part and a processor part will be used for communication to the run control system and to the MUCTPI processing FPGAs. Different approaches have been compared. First, we tried an available UDP-based implementation in firmware for the programmable logic. Although this approach works as expected, it does not provide any flexibility to extend the functionality to more complex operations, e.g. for serial protocols. Second, we used a SoC processor with an embedded Linux operating system and an application-specific software written in C++ using a TCP remote-procedure-call approach. The software is built and maintained using the framework of the Yocto Project. This approach was successfully used to test and validate the MUCTPI prototype. A third approach investigated is the option of porting the ATLAS run control software directly to an embedded Linux instance. THE ATLAS EXPERIMENT AT THE LHC Figure 1: The Trigger and Data Acquisition System of ATLAS. The ATLAS experiment [1] is a general-purpose experiment at the Large Hadron Collider (LHC) at CERN. It observes proton-proton collisions at a centre-of-mass energy of 13 TeV. With about 25 interactions in every bunch crossing (BC) every 25 ns, there are 10 interactions per second potentially producing interesting physics. The trigger system selects those events which are interesting to physics and which can be recorded to permanent storage at a reasonable rate. The ATLAS trigger system (see Figure 1) consists of a Level-1 trigger, based on custom electronics and firmware, which reduces the event rate to a maximum of 100 kHz, and a high-level trigger system based on commercial-off-the-shelf computers, network components, and software which reduces the event rate to around 1 kHz. THE LEVEL-1 TRIGGER SYSTEM The Level-1 trigger system (see Figure 2) uses reducedgranularity information from the calorimeters and dedicated muon trigger detectors. The trigger information is based on multiplicities and topologies of trigger candidate objects. The muon trigger is based on Resistive Plate Chambers (RPC) in the barrel region and Thin-Gap Chambers (TGC) in the end-cap region. The Muon-to-CentralTrigger-Processor Interface (MUCTPI) [2] combines the muon candidate counts from the RPC and TGC taking into account double counting of single muons that are detected by more than one chamber due to geometrical overlap of the chambers and the trajectory of the muon in the magnetic field. It sends the results to the Central Trigger Processor (CTP) which combines all trigger object multiplicities from the calorimeter trigger and from the MUCTPI, as well as the topology flags from the Topological Processor to make the final Level-1 decision based on rules described in a trigger menu. The CTP then sends the Level-1 decision back to the detector front-end electronics. Figure 2: The Level-1 Trigger System of ATLAS. ___________________________________________ † Ralf.Spiwoks@cern.ch THE UPGRADE OF THE MUCTPI The MUCTPI upgrade is part of the overall upgrade of ATLAS on the road to High-Luminosity LHC and is in line with the development of the New Small Wheel [3] of the muon trigger system to be installed during the shutdown of 2019 and 2020. The new MUCTPI will use optical links replacing bulky electrical cables. Those links will allow the muon trigger detectors to send more muon candidates with more precise information. The MUCTPI will provide improved overlap handling and full-precision information of the muon candidates to the Topological Processor. The new MUCTPI (see Figure 3) will be built as a single ATCA blade, compared to 18 VME modules in the current system. It will receive 208 optical links and will use two state-of-the-art FPGAs (Xilinx Virtex Ultrascale+) for the overlap handling, counting of muon candidates, and sending candidates to the Topological Processor. A third FPGA (Xilinx Kintex Ultrascale) will provide the total count of muon candidates to the CTP and readout data to the data acquisition system. A System-on-Chip (SoC, Xilinx Zynq 7000) [4] will act as a control processor and integrate the MUCTPI into the ATLAS run control (RC) system. THE RUN CONTROL OF THE MUCTPI The RC system of the ATLAS experiment provides control of the MUCTPI, e.g. start and stop commands; loading of configuration data, e.g. overlap lookup table (LUT) data and collection of monitoring data, e.g. counter values. Due to the new technology (ATCA), new forms of communication between the MUCTPI and the RC system had to be investigated. A SoC with a processor part and a programmable logic part will be used for the communication with the RC system and the processing FPGAs of the MUCTPI (see Figure 4). The processor system runs embedded Linux and the programmable logic provides the communication with the processing FPGAs using Xilinx chip-2-chip links, the configuration of the FPGAs using the Xilinx slave serial protocol, and the configuration and monitoring of the MUCTPI hardware with its power, clock and optical modules using serial buses like I2C and SPI. Three models of communication with the RC system have been investigated and will be discussed below. The software for the operating system, a kernel module for accessing memory, including the use of DMA (for Model #2 and #3), the port of the RC software (for Model #3), and all the applications are built and maintained using the framework of the Yocto Project [5] from the Linux Foundation. Recipes for all packages have been developed, in order to fetch, configure, and compile the software, and create all images necessary to boot the processor system.

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.