Eur. Phys. J. C (2019) 79 :683 Page 3 of 11 683
Fig. 1 Schematic diagram of the data selection workflow. The Couch-
DB database is checked for information on the runs. Certain runs are
discarded for example because they are not a physics run type (they
may be a calibration run) or because they were flagged as problem runs
(for example because a DAQ subsystem crashed). The thermodynamic
conditions of the detector are then checked and events during upset
conditions are discarded. Finally, possible dark matter signal events are
identified out of all remaining recorded events
analysis of scintillation signals, called RAT [13]. The RAT
architecture is used by several collaborations, such as Mini-
CLEAN [14] and SNO+ [15]. The RAT-DEAP branch of the
codebase was specifically developed and extended for the
DEAP experiment.
The default RAT architecture contains functionality to
read local JSON-like documents at run-time, and defines a
structure for these JSON documents so that they can be used
for database-like lookups. The JSON format is an unordered
collection of key/value pairs, stored as human-readable text.
Local JSON files are used to define material properties and
detector geometry for simulation purposes, and store settings
that determine how the code behaves.
In RAT-DEAP we have kept the conceptual database (DB)
architecture envisioned in the original RAT codebase. We
describe here an implementation of the CouchDB and Post-
greSQL backends as well as a number of extensions to RAT
which enable revision control and the storing of information
by RunID.
3 Database infrastructure
Figure 2 is a schematic representation of the detector hard-
ware and computing systems. The detector is located at SNO-
LAB, in a mine 2 km underground. The DAQ and slow control
systems are physically next to the detector.
Three servers run an instance of the DEAP CouchDB.
Server 1 is dedicated to DAQ operation and is near the DAQ
racks. This allows the DAQ system to take data and write
metadata even when the network connection is interrupted.
Server 2, located on surface, is used for development of
new interfaces or data structures and for resource-intensive
queries. Server 3 is used for regular user queries. It is located
off-site to protect against site-specific downtime.
Fig. 2 The flow of event and non-event data between the DEAP-3600
detector and different computing systems
Within CouchDB, information is stored in three separate
databases. The objects tracked in each database are listed in
Table 2. The main physics-analysis database is deapdb.The
RAT-DEAP analysis framework relies on this database for
detector status and calibration information. The other two
databases support operational tasks. daqdb is solely used
by the DAQ system to manage the DAQ settings. The DAQ
accesses this database by direct HTTP requests. scheduledb
serves as the database backend to a webpage through which
DAQ shift sign-up and scheduling are managed. It is usu-
ally accessed from this webpage. Separating information into
different databases within the CouchDB system simplifies
access control and database management tasks. For example,
maintenance or improvements can be done on scheduledb
without impacting access to information stored in deapdb.
Each server runs standard CouchDB continuous pull repli-
cations to synchronise its databases.
All user queries by default go to the production server. If
server 3 is unavailable, queries go to server 2 instead. Load-
balancing or additional servers are not necessary at this point;
however, this could be trivially implemented if and when it
becomes necessary. Server 1 does not accept regular user
queries but could be opened in case the two other servers
become unavailable.
Server 3 also runs the PostgreSQL database. The majority
of analysis tasks do not require access to the slow control
data so that temporary loss of access has minor impact on
the project and it has not been necessary to provide a fall-
back server. Since the DeltaV system itself acts as a backup
to the slow control data, mirroring the data on another server
as backup is not necessary.
123