Data Logger Design Document Stu Fuess June 17, 1998 Abstract The Data Logger is the central process in the physics event data flow through the DØ Host system. It receives entire events from the Level 3 Trigger farm and assembles collections of events into files. The Data Logger then interfaces with the RIP system to transfer completed files to offline storage and processing. This is a preliminary release of the rough draft of this document. It is expected that this document will go through several revisions before being officially released. Currently not all sections have been completed, as the package is developed these sections will be filled in. CLIENT/SERVER DESIGN DOCUMENT 1 STU FUESS AND LAURA PATERNO 1 ABSTRACT 1 1 INTRODUCTION 4 1.1 PURPOSE 4 1.2 DEFINITIONS 4 2 OVERVIEW 4 2.1 REQUIREMENTS 4 2.1.1 Client Requirements Error! Bookmark not defined. 2.1.2 Server Requirements Error! Bookmark not defined. 2.1.3 General Requirements Error! Bookmark not defined. 3 DESIGN 4 3.1 COMMUNICATIONS ERROR! BOOKMARK NOT DEFINED. 3.2 THREADS ERROR! BOOKMARK NOT DEFINED. 1 Introduction The Data Logger is a single application (of which there may be more than one instance) with the main function of receiving physics event data on the DAQ Host from the Level 3 Trigger farm, assembling events into files, and interfacing with the RIP processes which transfer these files to offline storage and reconstruction. The Data Logger is directed by COOR, the central DAQ Configuration and Run Control manager. It must additionally communicate with several other Host tasks – database servers, alarm system, luminosity server, and several monitoring applications. Event data is expected to be streamed by the Data Logger on the basis on information derived from the specific trigger conditions; a single event may be directed to one or more files. To meet bandwidth requirements, there may potentially be the need for several instances of the Data Logger to run on separate Host nodes, each receiving some portion of the events from Level 3. 1.1 Purpose The purpose of this document is to describe the Data Logger requirements, design and all of its major components. 1.2 Definitions Level 3 – The final stage of the DØ Trigger system, a farm of software processors each of which assembles and operates on the data of an entire event. Level 3 Collector – An instance (of several possible) of a node within the Level 3 system which is dedicated to collecting events on the output data cable of a section of the Level 3 processor farm and further directing them via a standard network to the Host Data Logger process(es). COOR – The Host process which manages detector and software Configuration and Run Control. COOR gets its primary guidance from a Run Control interface application, and then directs numerous other Host, Trigger, and Front End applications to prepare for and execute the data taking. Database Server – Currently a catch-all definition to indicate the interaction of a Data Logger with a database containing configuration information and acting as a repository for information accumulated during data acquisition activities. Luminosity Server – An application charged with reporting instantaneous and integrated luminosity. Alarm Server – The central application within the Alarm system to which a Data Logger sends significant activity information, error condition (state change or simple notification) information, and 'heartbeat' monitoring information. Data Distributor – A component of the Data Logger, or a process parisitic to the Data Logger, which takes selected events from the data stream and additionally directs them, via the network, to monitoring applications. DAQ Monitor – A system of monitoring tasks which accumulate operating information from various applications and makes the information available for user view or logging. RIP – The collection of tasks which manages the transfer of files from the DAQ Host system to the offline storage repositories and reconstruction facilities. 2 Overview Figure 1. Schematic of communication paths to Data Logger The operation of the Data Logger is best described in the context of Figure 1, which indicates the various applications surrounding and interfacing with it. The principal associated applications (as defined above) are: • Level 3 Collector • COOR • Database Server • Luminosity Server • Alarm Server • Data Distributor • DAQ Monitor The sequence of actions of the Data Logger for normal physics operation is roughly: • COOR informs the Data Logger(s) that a run is about to begin. Included in the transmitted message is information about the run number and streaming schemes. • The Data Logger(s) request information from the Luminosity Server on the current luminosity and beginning integrated luminosity for each trigger bit. The Luminosity Server had been previously informed of the pending beginning of run and had acquired needed information. • The Data Logger(s) record information in the database for each stream. The information is the run number, current luminosity, and initial integrated luminosity for each trigger. This is considered to be the beginning of a partition (file) for each stream. • Similar information may be reported to the DAQ Monitor. • The Data Logger(s) report to the associated Data Distributor(s) which streams they will manage. • The Data Logger(s) report back to COOR that they are ready for data. COOR then requests the Trigger system to begin accepting events. • As each event arrives at the Data Logger from the Level 3 Collector, it is directed to the appropriate file for its stream. The arrival of the first event in a stream causes the initial file to be opened (Should this be done earlier?). Events are also handed to the Data Distributor; this may be achieved by allowing events to remain resident in a global shared common area, and passing only the event location from the Data Logger to the Data Distributor. • If the writing of an event to a stream causes the resultant file to exceed its maximum allowed size, then the file is closed and activity related to the ending of a partition is initiated. The Luminosity Server is queried for the same information as at the beginning of the partition. The complete partition information is logged to the database via the Database Server. The partition ending luminosity information is reused as the beginning information for the next partition. All relevant information is passed to the DAQ Monitor. • If a maximum partition limit is exceeded, then COOR is notified and the run may be terminated. • Any abnormal conditions are reported to the Alarm Server. Additionally the Data Logger(s) sends a periodic heartbeat message to the Alarm Server; if the heartbeat is noted to be missing then an alarm is generated. • The Data Logger(s) may also report back to COOR if any specific run conditions are met, for example a specific number of total events or events per stream or trigger. • Associated with the Data Logger(s), or ancilliary to their activity, the completed partitions are transferred via the RIP system to permanent storage. • This process continues until COOR requests the end of the run. Processing of all active streams proceeds as per the case where a partition is full. 2.1 Requirements To be done. 3 Design To be done.