dataesr/scientific-paragraphs-categorization huggingface dataset:
This allows the capabilities of a KDE environment to be defined and restricted based on the credentials of the users. When the user logs into a control room machine, the access control of the CRD retrieves the user role data from the Access Management system (2. 11. 2) and decides which KIOSK profile to load for the user. The GUI environment offered to the user is generated from the KIOSK profile so the user has access only to the functions and applications specific to his current roles. Data taking efficiency tools. The databases with information about LHC beam status, run start and stop times, Ready For Physics and trigger Busy flags are queried by tools that compute statistical information on DAQ efficiency (efficiency per fill, fill duration, Ready For Physics flag delay, inefficiency sources etc.
Updates may be performed every few minutes for high priority histograms to only once per run for histograms with low priority. The HLT publishes histograms in Histmon via a special version of the Athena histogram service THistSvc. This special version makes use of the abstract Athena interface ITHistSvc, which defines the histogram service interface to Athena algorithms, and interfaces also to the Histmon package and its registry. The corresponding offline Athena service, which makes use of the same interface, saves the histograms in regular ROOT  [133]  files. • Event monitoring (emon) for event sampling and distribution of event data. Users may request event fragments with selected properties such as trigger type, from a specific sampling point. Emon does not depend on the event format and can handle events coming from any level of the data flow.
A summary of the results produced by the algorithms is published to IS and is also archived for future offline use. The data quality monitoring display (2. 12. 3) allows the analysis results to be visualized. The framework consists of a core part, which executes the algorithms and communicates via plugins with the configuration database, the conditions database and IS. The framework provides already a number of predefined algorithms for common operations on histograms like comparison or fitting. With custom plugins different input sources and output destinations can be selected and the framework can be extended with new algorithms. • Monitoring data archiving: ATLAS produces up to 10 GB of monitoring data per run. Most of this data need to be available offline so that offline analysis results can be crosschecked with online monitoring results.
Only users with specific roles are allowed to run synchronization jobs on a restricted set of directories by means of the"sudo" command. Both the CFS and LFSs are standard systems, with the operating system installed on local disks, originally maintained via the Quattor configuration management system  [145]. The nodes serving the different control rooms were also standard Quattor-managed systems; as for the file servers, a gradual move towards Puppet  [146]  has been completed  (4. 8). Most of the other ATCN nodes are netbooted clients, i. e. they boot their operating system from the network rather than from a local drive. They are supported by the LFSs, which serve DHCP requests and provide boot images and NFS shares containing the operating system, the TDAQ software, common areas holding log files, different utilities, etc.
The configuration of each netbooted client is done via the Boot-With-Me project  [147] , which allows mounting special areas, running specific scripts at boot time, etc. The rationale behind the choice of the netboot system, and its evolution are described in more detail in 4. 8. Since the winter of 2009, the majority of the nodes connected to the ATCN are running SLC5 (Scientific Linux for CERN [59], a specialized variant of Scientific Linux  [148] ). At that time the DAQ/HLT software had been built for SLC4, so compatibility between the specific built libraries and the system had to be ensured. Nonetheless, the system has been running smoothly under SLC5. Security is of course of great concern, so as soon as security updates are available in the CERN IT repository, they are tested on dedicated machines and, if no problems are found, they are applied to nodes connected to the ATCN.
System administration tools Node management: the ConfDB GUI and tools. A MySQL  [43]  database (ConfDB) contains various hardware and software configuration parameters of the nodes. Part of the information (e. g. OS, MAC addresses, location) is retrieved from the CERN central networking database (LanDB), which ensures consistency and simplifies the management. A dedicated set of tools based on this database has been developed and is available to the system administration experts, also via a web-based Graphical User Interface (see figure  49 ). This GUI allows the handling of a variety tasks; the most notable are the registration of new cluster nodes, the configuration of the Nagios monitoring (2. 14. 2), the choice of the operating system and boot parameters for the netbooted nodes, and their assignment to a specific LFS, and finally the issuing of IPMI17 and system commands to custom sets of nodes, with high parallelism.
Monitoring: Nagios. The system is constantly monitored using the Nagios monitoring software  [128]. For most of the ATCN nodes only high-level monitoring has been implemented: basic OS warnings and errors are reported, network connections are regularly polled and the hardware state is checked. Specific services, like the NTP18 service, NFS19, the DHCP20 service, etc. , are also monitored for the core nodes (LFSs, gateways, CFS, web servers) and an email/SMS alert system has been implemented, so that critical failures are reported to the experts as soon as they occur. The historical performance data collected by the monitoring system are stored on disks: nearly 30,000 RRD (Round Robin Database) files  [112]  with a total size of approximately 5. 5 GB keep track of the whole system history. Status information for all the nodes is published automatically in the monitoring section of the ATLAS Operations web server.
There are two access levels for the information available to operators and experts: a detailed view of specific hosts that helps to debug and understand failures, and a general overview of the system. The latter is accessible via the ATCN and the GPN through the corresponding web servers. It facilitates spotting of failures and taking action accordingly and is provided by a set of custom dynamic web pages, which use information stored in a common MySQL database by the separate Nagios instances running on the LFSs. Role Management: the Access Manager Role GUI. As described earlier (2. 11. 2 and 2. 14) the authentication mechanism is role-based  [149]. Therefore a web-based graphical user interface (see figure  50 ) has been developed to manage the Access Manager roles. The application allows users with specific roles (administrative roles) to manage roles that users need to correctly perform their tasks.
ACR and SCR -generic information The ATLAS data-taking operations are controlled from the main control room, the "ATLAS Control Room" (ACR). The computers in a second control room, the "Satellite Control Room" (SCR), run the same software, usually in monitoring mode, but they can also be used to control the experiment should the main control room become unavailable. The ACR hosts a number of desks from which various operations are performed. The desk relevant to DAQ/HLT is the run control (RC) desk. A second desk, the DAQ/HLT desk was in use until mid 2011. From the RC desk the runs are initiated, the run parameters (such as the data set tags, the set of detectors participating to the current datataking session etc. ) are set, the system configuration database is modified and the messages from the various components are followed with the aim of finding and correcting any issues affecting data taking.
The third step involves the inclusion of the physics algorithms and preloading into ROS memories data coming from Monte Carlo simulations or from earlier data-taking sessions. At the second and third stage, the monitoring applications are also tested for their functionality and performance. Trigger software testing. Changes in trigger configuration or menus are tested in multiple steps. Most testing of algorithm improvements and trigger menu changes is done using the Athena offline analysis software with dedicated signal samples, either simulated or previously recorded, as explained in 2. 9. 3. For large-scale testing, special datasets of minimum bias collision or simulated data have been filtered to select events passing at least low-p T L1 trigger requirements. These samples are used for large-scale tests running the trigger in a normal batch queue system using athenaMT.
py and athenaPT. py (2. 9) to emulate a more online-like environment and check for code stability and rejection power. Typically about one million events are used, corresponding to a few tens of seconds of data taking in the real system. From this processing, changes in L2 data request patterns and trigger processing time can also be found. Final testing is done in a small-cluster partition (2. 1. 2) test using preloaded filtered data as described above to confirm that results are the same as in the offline environment. This also tests that the full set of state transitions is working correctly. Tests of new features in the trigger software infrastructure or of major software updates are done using the same procedure as described above, but in addition tests are done using the full DAQ/HLT system with data samples preloaded in the ROS PCs.
Test platforms Private small test clusters. Several small to medium size clusters of Linux nodes were built to allow early development and testing of the TDAQ software. These range from clusters of about 10 nodes belonging to a single institute to clusters of 50-80 nodes shared by all interested TDAQ users. Some of these clusters contained hardware that early on allowed tests of ROS hardware as well as network switches together with the DAQ/HLT software. Others were geared towards development and test of the infrastructure of DAQ and HLT, in particular also the trigger algorithms for event selection. These are needed to closely follow the ATLAS offline software, e. g. by providing access to the AFS file system widely used in offline. all applications on all hosts in the partition are collected and written to a summary file.
TDAQ software releases New versions of the TDAQ software are regularly released. Each release consists of packages built together for a number of platforms (a platform is characterized by a combination of tags, which define the type of binaries built, e. g. i686-slc5-gcc43-opt for Intel 32-bit architecture, SLC5 Linux, GNU C compiler version 4. 3, optimization enabled). The software is organized in a tree of projects or sub-releases: the tdaq-common, dqm-common and main tdaq releases. This factorization allows the integration of TDAQ software with other ATLAS Offline and Trigger software projects as shown in figure  52. There is also a common layer, called LCG (LHC Computing Grid  [152] ) Applications, which provides a set of third-party packages widely used in ATLAS, like Boost  [153] , ROOT  [133]  and CORAL  [41].
Version tdaq-03-00-01 of the tdaq project, released in November 2010, consisted of 210 packages, which contain about 1. 8 million lines of source code. The release policy should provide a good balance between further development of the software and stability. Therefore there are two types of releases: major releases and minor releases. Major releases may contain important changes in the architecture of the software, new functionality and API changes in packages, database schema changes and other changes, which may require actions -82 -from end users (most probably modification of their code). In contrast, minor releases only contain internal changes, which do not require users to modify code. In addition, a patching scheme allows particular problems to be fixed by a binary patch to a package in the release that is already deployed.
It is estimated that the patching dead time, i. e. the time needed to roll-back a "bad" patch, is about 20 minutes. Given the long lifetime of the production release, the patching procedure is used not only to deploy fixes for urgent issues, but also to introduce some new developments, provided that the public API is not changed and no new behavior is introduced by the patch. A web-based tracking system based on Savannah  [156]  is used to manage patching of the software. For every patch, validation on a special testbed is required prior to deploying the patch in the ATLAS TDAQ system. -83 -   Since October 2009 until the end of Run 1 (February 2013), more then 401 patches were installed in the production system without changing the base TDAQ software release.
Performance of the ROS PC The performance of the ROS PC is determined on the one hand by the ROBINs and on the other by the combination of the hardware of the PC and the software running on it. The performance of the standard ROS PCs, installed in the TDAQ system at the start of Run 1, is mainly determined by the latter as will be obvious from the measurement results to be discussed. The configuration of the hardware and of the operating system affect the performance of the ROS PC, as well as the configuration of the ReadoutApplication. For the first category the version and the type of Linux kernel used (uniprocessor or SMP26), the use of hyper-threading, the use of interrupt coalescence for the Ethernet interfaces, and the use of safety features of Linux (SELinux) are important. It has been found that the best performance for the standard ROS PC, equipped with one single core CPU (Irwindale  [53] ) obtained with a uniprocessor Linux kernel as was available in SLC4 [59]) 26Symmetric MultiProcessor, for use with a CPU or CPUs with multiple cores and /or supporting hyper-threading.
The maximum data rate that the Data Storage farm can handle has been measured for event sizes varying from 50 kB to 1. 5 MB in view of this, with 24 XPU racks configured as Event Filter and 90 emulated SFIs. Information on throughput and event size published in IS were used for producing the plot of figure  70. Approximately full utilization of the available input bandwidth of the storage farm is observed for events with a size of 100 kB or larger. The SFO farm is composed of storage servers with 8 physical cores each. In order to benefit from the multi-core architecture and from hyper-threading, multi-threaded software must be used. The SFO application is multi-threaded, but a single thread, the "main thread", uses 95% of the available CPU power if the SFO application runs with full utilization of the input bandwidth and performs full event stripping, a procedure described in 2.
The simulation program fetches events one-by-one from the front of the queue and processes each event. This could result in the generation of new events that should occur at a later time and that are stored in the queue, where the position in the queue is determined by the time at which the event should occur. In this way a complex system with many parallel processes can be simulated on a sequential computer. The first models were developed with a special simulation language, MODSIM-II  [173] [174] [175] [176]. Later work was done using the Ptolemy environment  [177] [178] [179] , with special attention to models of networking technology. In parallel also C++ with direct implementation of the support required for discrete-event simulation was used  [180] [181] [182]. The computer model implemented in C++ made it possible to tune the discrete-event mechanism to obtain optimum performance of the simulation program and therefore allowing a detailed model of the DAQ and L2 system to be run.
With the progress in network technology and the advance of cheap and increasingly powerful PCs (Moore's Law  [194] ) a radical solution based on more conventional components was proposed. The main ingredients of the L2 Pilot Project  [195]  were: an L2 architecture very similar to the current one, PCs running Linux or Microsoft Windows NT, three networks (Control, L2 data, EB data) and the use of C++ in a common software framework for the data flow (the "Reference Software"). Three different technologies were proposed for the networking: ATM  [193] , SCI  [193, 196]  and Fast Ethernet with custom protocols. The current Message Passing layer is a relic of the software layer introduced to provide an abstract software interface to these technologies. In the longer term, high-end rack mounted PC servers, Linux, (multi)Gigabit Ethernet and TCP/IP have been chosen as suitable technologies.
Convergence After the TP, the TDAQ architecture was to a very large extent already determined. The earlier software was re-engineered for the entire data flow and integrated with the Run Control software using C++ and targeted to PC farms with Linux as operating system. An important decision was to develop and test the trigger software in the offline environment. This had profound consequences for both the online and offline software. Large parts of the offline software, including its infrastructure, now had to run online. Likewise, offline software had to be adapted to allow interfacing to online services such as the event data source (acquired in real-time online and even piecemeal in L2), error reporting, monitoring, histogramming and database accesses. It also had to become aware of the Run Control states.
The L2 processors run an SMP Linux kernel to support multiple CPUs, each implementing multiple cores. Hence, L2 processes were designed to be multi-threaded allowing several events to be processed in separate worker threads. This was not supportable with the offline software. Consequently, in each L2PU application the trigger selection is now performed by a single worker thread. With the integration of the offline selection software it became possible to inject simulated detector data (into ROS PCs and L2SVs) to run the entire selection chain on multi-node TDAQ testbeds. The work culminated in the submission of the ATLAS High-Level Trigger, Data Acquisition and Control Technical Design Report (TDR) in June 2003  [30]. -114 -.
Status and outlook The period after the submission of the TDR was followed by refinements of data flow (e. g. with respect to robustness, fault tolerance, multiple output streams, monitoring, access to databases) and selection software (e. g. with respect to trigger configuration, menus, calibration). The TDAQ hardware was installed and commissioned in test runs initially with Monte Carlo simulated data and eventually cosmic ray data. The use of common selection software in online and offline has many advantages. It shortens the time and effort for testing, brings coherency in the updates, allows for consistent normalisation in the analyses and enlarges the pool of experts. The online and offline software produce identical results. Events that fail the online selection (because of possible glitches in some of the many thousands of processes) are saved in a debug stream and recovered in offline mode.
Multiple constraints make it difficult to balance the processor resources devoted to L2 or EF: the same number of racks has to be assigned to each L2SV, each L2 or EF sub-farm has to have the same processing power and the EF sub-farms should have the same input bandwidth. In general modification of the configuration database is required to modify the working point. Architectural changes implemented during the shutdown of 2013-2014 allow a more gradual transition between the two HLT levels by executing both L2 and EF selection within the same process.
History The roots of the current TDAQ software go back to the mid 1990s. Following the work in various R&D projects  [191]  leading up to the ATLAS Technical Proposal in 1994  [200] , there was a first effort that culminated in the so-called Prototype '-1' software  [201]. This software was focused mainly on issues related to run control and configuration as well as the readout part of the DAQ system (i. e. the interface to the detectors) and the event building. Many of the software components developed at this time are still in use today, often modified or updated. Tests related to the HLT were mostly concerned with the performance of network interconnects. They often used stand-alone code before the so-called Reference Software provided a common framework in 1998 that was subsequently adopted by all the various proposals for the ATLAS networking technology.
Software development process From the beginning the online software was using C and C++ rather than Fortran. There was also an emphasis on using best practices for software design that resulted for a while in the use of commercial design tools. In most cases the use of expensive specialized tools has given way to a much more practical application of the principles behind them. In the following we discuss various aspects of the software development process and how it has changed over the years. CVS  [119]  was used almost exclusively for concurrent software version control from the beginning, as it was the only widely available free tool for this purpose. While there was a surge of new tools in this area in the last ten years, ATLAS stayed with CVS until 2008 and then switched to Apache™ Subversion ® (SVN)  [202] , mainly because of scalability problems of CVS.
SVN was seen as the natural successor and also the least disruptive for users, because of its similarity to CVS. After extensive tests the actual conversion happened for all of ATLAS within the same week, preserving all history in the case of the TDAQ software. Over the lifetime of the TDAQ software two major build systems were used. The first was an ATLAS specific version of the Software Release Tools (SRT) that originated at the BaBar experiment  [203]. This was replaced ATLAS wide in 2001 with a new tool, Configuration Management Tool (CMT  [204] ), which was seen as more user friendly and with support available from within the collaboration. -118 -.
Operating systems and compilers During the prototype phase, a number of hardware and software platforms for TDAQ applications were studied. This started with commercial UNIX implementations like SunOS/Solaris for Sparcpowered workstations  [205]  and real-time LynxOS  [206]  running on PowerPC read-out single-board computers. Later, with the growing popularity of Intel-based PCs (i386 architecture) with Windows or Linux as operating system, the main effort was put into validation of these platforms for both front-end and back-end TDAQ applications. The main platform has become 64-bit Linux SLC5 (a flavor of RedHat Enterprise Linux 5 with Linux kernel 2. 6) [59] running on modern generation PCs with Intel XEON multi-core processors and 32-bit Linux running on the ROS PCs and on Single Board Computers in VME crates (RoI Builder, ROD crates).
Offline software in an online environment The use of offline software in the online environment implies a tight coupling of the two software domains, mainly caused by base libraries, software infrastructure environments and core software packages that are used in both domains. Examples are software components from the LCG releases  [100]  such as ROOT  [133] , the common raw data format library from the online group and the basic Athena core software components from the offline framework (2. 9). A careful synchronization of the versions of common software components is therefore required. The dependencies go even further and imply also the use of the same version of the operating system in the trigger farms and in the farms used for offline event reconstruction. In ATLAS these questions and the global release schedules are regularly discussed in a "Global Release Coordination" forum, with members from the online, offline and detector communities.