Chapter 7: Data Acquisition 7–334 Chapter 7 1 Data Acquisition 2 Fix SI units throughout, and remove a lot of the dword references (looks distracting). Georgia 3 7.1 Introduction 4 The far detector (FD) data acquisition (DAQ) system is responsible for receiving, processing, and 5 recording data from the DUNE FD. In doing so, it provides timing and synchronization for all 6 detector modules and subdetectors; receives, synchronizes, compresses, and bu ff ers streaming data 7 from the subdetectors; extracts information from the data at a local level to subsequently make 8 local, module, and cross-module data selection decisions; builds event records from selected space- 9 time volumes and relays them to permanent storage; and carries out local data reduction and 10 filtering of the data as needed. 11 This chapter provides a description for the design of the DUNE FD DAQ system developed by the 12 DUNE FD DAQ consortium. This consortium brings together resources and expertise from CERN, 13 Colombia, France, Japan, the Netherlands, the UK, and the USA. Its members bring considerable 14 experience from ICARUS, MicroBooNE, SBND, and DUNE prototype LArTPCs, as well as from 15 ATLAS at the LHC and other major HEP experiments across the world. 16 The system is designed to service all FD detector module designs indistinguishably. However, 17 some aspects of the DAQ design are tailored to meet module-specific requirements, and those are 18 documented in sections of this chapter which are unique to the detector module covered in this 19 TDR volume; these sections are identifiable by their use of module-specific terms. In general, 20 the DAQ services each FD detector module independently, but cross-module communication is 21 facilitated at the trigger level. 22 The chapter begins with an overview of the DAQ design, including requirements that the design 23 must meet, and specification of interfaces between the DAQ and other DUNE FD systems. Sub- 24 Single-Phase Far Detector Module The DUNE Technical Design Report
Chapter 7: Data Acquisition 7–335 sequently, Section 7.4, which comprises the bulk of this chapter, describes the design of the FD 1 DAQ in greater detail. Section 7.5.1 describes design validation e ff orts to date, and future design 2 development and validation plans. At the center of these e ff orts is the ProtoDUNE DAQ system, 3 which has served as a demonstrator of several key aspects of the DUNE DAQ design, and continues 4 to serve as a platform for further design development and validation. Finally, the chapter finishes 5 with two sections providing details on the management of the DAQ project, including schedule to 6 completion of the design, production, and installation of the system, as well as cost, resources, and 7 safety considerations. 8 7.2 Design Overview 9 An overview of the DUNE FD DAQ system servicing a single FD detector module is provided 10 in Fig. 7.1. The system is physically located at the FD site, and it is split between the 4850 ft 11 level and the ground level at SURF. Specifically, it occupies space and power both in the central 12 utility cavern (CUC) and the on-surface DAQ room. The front-end part of the system, which 13 is responsible for raw detector data reception and pre-processing, lives underground in the CUC, 14 while the back-end part of the system, which is responsible for event-building as well as run 15 control and monitoring, lives on the surface. Data flows through the DAQ from the front-end to 16 the back-end of the system and to o ffl ine. The majority of raw data processing and bu ff ering is 17 performed underground, in the front-end part of the system, thus minimizing data bandwidth to 18 the surface. A hierarchical data selection subsystem consumes minimally-processed information 19 from the front-end readout, and constructs module-level trigger decisions. Upon such decision, a 20 data flow orchestrator process is activated as part of the back-end part of the system to retrieve 21 data to be built as part of an event record. At event building stage, optional down-selection of 22 the data is possible via high-level filtering, prior to shipping the data to o ffl ine. The specifics of 23 design implementation and data flow are described in Section 7.4. 24 Figure should perhaps be modified to indicate low level data selection. Some rewording on boxes is also neeeded to match subsystem definitions. Georgia 25 7.2.1 Requirements and Specifications 26 The DUNE FD DAQ system is designed to meet the DUNE top-level as well as DAQ-level re- 27 quirements summarized in Table 7.2. The DAQ-level requirements are imposed to ensure that 28 the system can record all necessary information for o ffl ine analysis of data that is associated with 29 on- and o ff -beam physics events, as directed by the DUNE physics mission, and with minimal 30 compromise to DUNE’s physics sensitivity. The requirements must be met by following the speci- 31 fications provided in the same table. Those specifications are associated with trigger functionality, 32 readout considerations, and operations considerations, and are motivated further in the following 33 subsections. 34 Single-Phase Far Detector Module The DUNE Technical Design Report
Chapter 7: Data Acquisition 7–336 Timing & Sync External time reference Calibration systems One of these One of these in DUNE FD SNEWS, LBNF etc Module External level trigger trigger Detector Module One of these To / from other MLTs Front end Event builder Filter Storage Bu fg er Network Front end Event builder WAN to FNAL Front end Event builder One or more of these One of these O(100) of these A few of these Detector CUC Surface control room cavern Figure 7.1: DAQ design physical layout focusing on a single 10 kt module. Not shown in this figure are the system control paths. 7.2.1.1 How DUNE’s Physics Mission Drives the DAQ Design 1 The DUNE Far Detector has three main physics drivers: neutrino charge-parity symmetry violation 2 (CPV) and related long baseline oscillation studies using the high intensity beam provided by 3 Fermilab, o ff -beam measurements of atmospheric neutrinos and searches for rare processes such 4 baryon-number-violating decays, and detection of supernova neutrino burst (SNB) occurring within 5 our galaxy. The DUNE FD DAQ system must facilitate data readout for delivering on these main 6 physics drivers, while keeping within physical (space, power) and resource constraints for the 7 system. In particular the o ff -beam measurements require the continuous readout of the detector, 8 and the lack of external triggers for such events requires real-time or online data processing, and 9 self-triggering capabilities. Since the continuous data rate of the far detector module reaches 10 multiple terabytes per second, significant data bu ff ering and processing resources are needed as 11 part of the design. 12 The DUNE FD modules employ two active detector components from which the the DAQ system 13 must acquire data: time projection chamber (TPC) and photon detection system (PDS). The 14 two components access the physics by sensing and collecting signals associated with very di ff erent 15 sensing time scales. Ionization charge measurement by the time projection chamber (TPC) for any 16 given localized activity in the detector requires a nominal recording of data over a time window of 17 order 1 ms to 10 ms. This time scale is determined by the ionization electron drift speed in LAr and 18 the detector dimension along the drift direction. On the other hand, the photon detection system 19 (PDS) measures argon scintillation light emission, which occurs and is detected over a timescale 20 of multiple nanoseconds to microseconds for any given event and/or subsequent subevent process. 21 Unlike the TPC, the PDS data is zero-suppressed in the PDS electronics (see Chapter ?? ); therefore 22 the total raw data volume received by the DAQ system is be dominated by the TPC data, which 23 is sent out as a continuous stream. 24 Single-Phase Far Detector Module The DUNE Technical Design Report
Recommend
More recommend
