Building the Trigger Partition Testbed

Transcription

1 Building the Trigger Partition Testbed David Venhoek August 21, Introduction This document is an introductary description of my Summer Student Project. It explains the general outline of the project, where it fits in with existing software efforts at Atlas and gives an overview of what was implemented and why. A more detailed documentation on how to use and modify the software is available with the software package and on the Atlas TWiki. I would like to use this opertunity to thank Micheal Rammensee, Anna Sfyrla, Haimo Zobernig, Ricardo Abreu, and Werner Wiedenmann for their great guidance and help in building this software. Furthermore I d like to thank Reiner Hauser and Sami Kama for their help with using the TDAQ software. 2 Background and goals This section will give an overview of the relevant context for the trigger partition testbed project. A short introduction will be given on the atlas trigger and data acquisition system, it s existing testing program, and the how the testbed will fit into this. 2.1 Architecture of the Atlas Trigger Detailed information on the design and implementation of the atlas detector and surrounding support infrastructure can be found in [1]. Below is a short overview of the material most relevant to the trigger partition testbed project. At the atlas collision points, interactions will be happening with a peak rate of 40 MHz. Since it is unfeasible to write all of these events to long term storage, some on-line selection has to be made as to which of these events to actually store. The process of reading out the detector and selecting which events to keep is the responsibility of the trigger and data acquisition system (also called TDAQ). The focus here will be on the general architecture of the trigger system, since this is the part most relevant to the trigger partition testbed. The atlas trigger currently is a two level system. The first level, the L1 trigger, is responsible for the initial selection of events as they happen. It uses dedicated trigger hardware operating on lower-resolution data from a subset 1

2 Figure 1: Schematic of the Atlas Trigger of the detectors to provide an initial keep or discard decision in the first 2.5 microseconds after the collision. In the event of a positive decision, it provides the regions of the detector that contained signals of interest as regions of interest (ROIs) to the next level trigger. The High Level Trigger (HLT) is responsible for the final decision to keep an event. Using the ROI data it requests more and more of the full resolution atlas data from the readout systems, continuing until either making the decision to keep the event, or discard it. The High Level Trigger has significantly more time available for it s decision (O(1) minute), and is implemented completely in software. The HLT is built up out of trigger chains. These are sequences of processing steps that check for features in the event data and based upon that either accept or reject the event. The trigger chains can assign an event to one or more output streams, that partition the output into several sets each used for a different purpose. 2.2 Pre-existing testing of the Atlas High Level Trigger Currently the only automated tests for the Atlas HLT are run in the offline environment. The tests in these configure the trigger using a python file as input, which is then used to process a file with one or more events. This produces 2

3 a new event file with the output generated by the trigger, and algorithms and other parts of the trigger can print the results of self-testing procedures to standard output, which can subsequently be examined to ensure the results are as expected. The advantages of this kind of setup is that it is very easy to test various parts, and the entire HLT, in an isolated environment. This allows for testing of the trigger with reduced interference from the environment, making it easier to find any potential issues. However, these kind of tests also have multiple disadvantages. The processing in these tests is not parallel, and hence doesn t really exercise the ability of the trigger to deal with running in multiple processes at the same time. Furthermore, these tests will never be able to validate the integration between the trigger and the rest of the TDAQ software suite. 2.3 Goals for the trigger partition testbed The goal for the trigger partition nightly testbed would is to test the behaviour of the HLT trigger in an environment closer to that actually present in P1. It should enable testing of the interaction of the trigger with the rest of the data acquisition platform, it s behaviour when run in a multiprocess environment and check the consistency of trigger behaviour when compared to the offline environment. 3 Existing software The atlas project already has a number of software tools for creating, manipulating and running partitions. Using these tools provides the assurance that relevant parts of the testing infrastructure will remain compatible with the latest versions of the partition and HLT software. It also makes it easier to rerun a testcase locally, which is important when debugging problems. Below short descriptions will be given of the tools used by the testbed. 3.1 Partition Maker The partition maker is a tool for creating partition configuration files. It takes a relatively small python configuration file, which is used to build a partition database. It also allows the user to install post processing hooks which take this initial database and then modify settings not accessible through the initial configuration steps. 3.2 runner The runner is a tool for running and programmatically controlling a TDAQ partition. It is used by this tester to run the partitions, and for doing test data collection during the running of partitions in those cases where that is necessary. 3

4 The runner provides a framework simplifying a lot of the typical operations done on a partition, such as state transitions. It also manages the initial setup and cleanup of the partition. Within this framework, a test script is then run which tests the actual functioning of the partition. It calls on the framework to control the state of the partition and to query it s information systems. 4 Design and implementation of the testbed The guiding principles in the design of the testbed, and in particular it s interface towards tests, were twofold. One, to provide a small, succinct and easy to use interface for controlling what exactly is done by each testcase. And two, to provide testing procedure that is feasible to recreate manually. 4.1 Implementation of testcases To make the debugging and reproducing of testcases and failures in them easier, all the major steps in running a testcase are done through shell commands. These are logged in a special logfile for the testcase, and can be directly used on a commandline to redo the steps for a specific testcase. Furthermore, the directory structure for the test is stored along the testcase, removing some potential issues in recreating the execution environment The isolation of testcases from the testing software is done by having one special python file per testcase, that creates a testcase descriptor. This descriptor contains all the configurable options for a testcase and is used in the rest of the tester to execute that testcase. This allows the general partition generation and running mechanisms to remain agnostic of the specific needs of a testcase. 4.2 Web interface The main goal of the web interface to the tester is to provide quick insights in the result when looked at at a glance, while also providing access to the more detailed results when needed. Quick, clear communication of the results is achieved through the use of coloured backgrounds in the cells corresponding to various partition services, which indicate the presence of errors and warnings in log files. The same cells also contain links to the log files in question, allowing the user to view the messages produced by the service. 5 Implemented testcases As part of the project, a number of testcases was also implemented. Below an overview of these is given, together with the rationale for their inclusion in the testsuite. 4

5 5.1 Dummy testcases The testcases PuDummy, HelloWorld, RobRequest and RobRequestDataScouting are testcases that don t actually run a complete trigger setup. These testcases are included primarily to test the sanity of the test setup. PuDummy does not include any part of the HLT at all. It provides a check that the installation of the TDAQ software is sane and that it runs without significant issues. HelloWorld builds upon this, and tests the inclusion of the HLT environment in the partition, and the basic capability of running events through a trigger algorithm. RobRequest then tests the capability of HLT trigger algorithms to request information from the actual detector and, together with RobRequestDataScouting, the capability of assigning events to various data streams. 5.2 Output tests The HLTCheckOutput and HLTDBCheckOutput tests do sanity checks over the output files produced by the trigger partition. A reference file is generated using an offline run of the trigger, and this is used to check the stream tags assigned by the partition to an event, as well as the decisions from the various trigger chains for the events. 5.3 Memory tests The testcases HLTMemoryNChild and HLTMemoryTime measure the memory usage of the trigger processes during the running of the trigger. The purpose of these testcases is to assess the memory scaling behaviour of the trigger as it uses more and more processor cores, and to provide insight in how trigger memory usage varies over time. 5.4 Miscellaneous tests The HLTStartStopStart testcase tests the behaviour of the trigger when stopped and then restarted, without reinitializing from scratch in between. HLTJobOptionsP1Menu tests the loading and running with the standard menu using the joboptions configuration method. References [1] ATLAS Collaboration, 2008 JINST 3 S