Dune cdr the Single-Phase Protodune

Chapter 2: Detector components
2–89
2.9.8
Control, configuration and operational monitoring
The artDAQ software used for all applications dealing with the movement, processing and storage
of data is interfaced with software of the Joint Controls Project (JCOP) for the purpose of control,
configuration and operational monitoring. JCOP provides a toolkit to implement run control
(finite state machine (FSM), distribution of commands, error propagation and handling) as well
as graphics tools that allow for the implementation of user interfaces and monitoring dashboards.
In order to minimize the software development needs, the same FSM as defined by artDAQ is
implemented and commands are sent to the applications using the already supported XML-RPC
protocol. Monitoring data are pushed into the JCOP framework by implementing the appropriate
artDAQ monitoring plugin. Log and error messages will be most probably collected and processed
using an implementation of the ELK (elastic search, logstash, kibana [11]) stack. The internal
configuration of DAQ applications are carried out using the mechanisms provided by artDAQ.
The overall system is modeled and configured using the JCOP paradigm of data-points.
2.9.9
Interface of the DAQ to the online storage
The software framework for interfacing with the electronics, building events, writing data files, and
providing an interface to online monitoring of data as they are acquired is artdaq [12].
Computers running BoardReader processes read out the RCEs and SSPs and transmit data to
a set of computers running EventBuilder processes. These computers and a pair of 10 Gbit/sec
Network Interface Cards (NICs) provide the CPU and networking needed to build events, collect
basic metadata, and send the data to storage and online monitoring. The Event Builders assemble
data fragments into self-consistent events and perform basic data integrity checks before writing
records out.
Table 2.8 indicates a nominal trigger rate of 25 Hz for the mid-range scenario. Data are assumed to
be collected based on prompt trigger signals generated by the beamline instrumentation in order
to purify samples of desired particles.
Current estimates put the PDS data at approximately 10% of the TPC data rate. Beam instru-
mentation data are expected to be lower still. Although adding to the total data rate only slightly,
adequate resources must be provisioned in order to acquire and store the data from these systems.
The network speed of all computers in the DAQ chain is anticipated to be 20 Gbit/sec.
Given that each RCE reads out 256 channels of the TPC, 60 RCEs need to be active. For the PDS,
24 SSPs are used. At least four computers running BoardReader processes are therefore used to
read out the RCEs and transmit the data to the EventBuilder processes.
The online buffer layer consists of ∼300 TB of storage, which is connected directly to the Event
Builders. The baseline storage option consists of two SAS arrays DAS with > 40Gbit/s bandwidth,
redundant paths, controllers, and power supplies. A backup option for storage is an XRootD
ProtoDUNE Single-Phase Technical Design Report

---

Chapter 2: Detector components
2–90
cluster [13] taking data directly from the Event Builders over the network.
After the data are written to disk by artDAQ, the data handling system creates metadata files,
and transfers the data from EHN1 to the CERN Computing Center [14]. The Fermi File Transfer
Service
(F-FTS) software developed and maintained at Fermilab is the central element of the data
flow management at this level.
2.9.10
Online monitoring
In addition to the monitoring of the operations of the DAQ system, the quality of the data taken by
the detectors has to be constantly monitored. This assurance is provided by the online monitoring
system. This subsection describes the baseline monitoring framework for ProtoDUNE-SP. The final
implementation is subject to change, but will likely be similarly linked to artDAQ and LArSoft
(introduced in Section 5.5) as described here.
The online monitoring framework runs as a DAQ process and therefore is able to provide data
quality assurance in real-time. ArtDAQ splits the data into distinct physics and monitoring streams
via its aggregator processes. The data rate to the monitoring is tunable such that the monitoring
can digest the data in a timely fashion. The software framework used for online monitoring consists
of an art::Analyzer module which interfaces with the artDAQ framework and owns instances of
further classes, each designed to handle different aspects of the monitoring.
The DataReformatters restructure the data to allow for efficient subsequent analysis and provide a
standard interface to the methods, which look through the events. These reformatted objects are
passed to MonitoringData, which owns all of the data products (TTrees, TH1s, TGraphs, etc.) and
output from the monitoring software, and provides methods for filling them when required. Finally,
the online event displays are contained within the monitoring framework using the EventDisplay
class.
The output is then saved in a common area for offline access and for syncing with a web server.
This is hosted at CERN and allows for remote monitoring of the experiment.
2.10
Cryostat and feedthroughs
2.10.1
Scope and requirements
The cryostat consists of a steel warm outer structure, layers of insulation and an inner cold mem-
brane. The outer structure (shown in Figure 2.61), which provides the mechanical support for
the membrane and its insulation, consists of vertical beams that alternate with a web of metal
frames. It is constructed to withstand the hydrostatic pressure of the liquid argon and the pressure
of the gas volumes, and to satisfy the external constraints. In particular, this structure is to be
ProtoDUNE Single-Phase Technical Design Report

---