A description of the demo system » History » Version 31

John Freeman, 06/03/2017 11:52 AM

1 1 John Freeman
h1. A description of the demo system
2 1 John Freeman
3 5 John Freeman
h2. Intro
4 5 John Freeman
5 31 John Freeman
artdaq-demo and artdaq-core-demo serve as an example of how parts of the artdaq and artdaq-core packages, described below, can be pieced together to create a functioning DAQ system; a careful study of the documentation in this wiki is intended to provide DAQ designers the knowledge base they need to develop their own, experiment-specific daq systems. artdaq-demo and artdaq-core-demo provide:
6 5 John Freeman
7 17 John Freeman
** Examples of various types of art modules useful for DAQ systems (online monitoring, etc.)
8 5 John Freeman
9 30 John Freeman
** An example of an overlay class- a type of class designed to provide an interface to an experiment's raw data which separates an experiment's art module developers from the low-level details of the data layout. artdaq-core-demo's ToyFragment class is an overlay designed to help users learn about how to design their own. 
10 5 John Freeman
11 28 John Freeman
** An artdaq::CommandableFragmentGenerator -derived class called ToySimulator in artdaq-demo, capable of simulating DAQ input and thereby allowing users to learn about running an artdaq-based system without needing to interface with actual DAQ hardware
12 5 John Freeman
13 31 John Freeman
Additionally, during installation of artdaq-demo, along with the packages artdaq-demo depends on a package called artdaq-utilities-daqinterface is downloaded, which contains an application called "DAQInterface". DAQInterface is designed to make it simple to configure and run artdaq-based DAQ systems. As described on its "wiki": it can be used to run any type of artdaq-based DAQ system. However, the one installed alongside artdaq-demo is configured to work with artdaq-demo. DAQInterface will allow us to experience a full DAQ system run, using artdaq-demo's ToySimulator to simulate production of data fragments which are then processed in real-time by running art analyzer modules which use the ToyFragment overlay class to work with the fragments. Additionally, by default the data produced is written to disk.
14 30 John Freeman
15 31 John Freeman
16 23 John Freeman
17 23 John Freeman
18 31 John Freeman
_The following diagram shows the process types and some of the DAQ functions that are provided in artdaq. The boxes that are shown in green are part of what is provided by artdaq. The boxes shown in orange correspond to plugins that each experiment develops for their particular needs. Details are given throughout this wiki page. Please observe that since this plot was made, the task of the Aggregator process shown below has been divided up between the DataLogger and the Dispatcher process types_
19 25 John Freeman
20 27 John Freeman
21 25 John Freeman
22 17 John Freeman
h2. artdaq-core-demo and artdaq-core
23 1 John Freeman
24 17 John Freeman
h3. artdaq-core-demo: overlays
25 1 John Freeman
26 28 John Freeman
The toy overlay is in artdaq-core-demo/artdaq-core-demo/Overlays/ToyFragment.hh. The reason overlays are meant to be in their own package is that the interface to the raw data which they provide is something that can be used in offline as well as online analysis; online-specific code related to the movement of data is located in artdaq and artdaq-demo. artdaq-core-demo depends on artdaq-core; typically an experiment's overlays are defined in a package usable by both offline and online, which depends on artdaq-core. 
27 5 John Freeman
28 18 John Freeman
h3. artdaq-core: the underlying data representation and the artdaq::Fragment class
29 17 John Freeman
30 30 John Freeman
The raw data from an experiment which uses an artdaq-based DAQ system is wrapped in an class called artdaq::Fragment. This class is defined in artdaq-core and overlay classes should have a constructor which takes a const reference to an artdaq::Fragment object. An artdaq::Fragment object is the basic unit of data in artdaq-based DAQ systems; it contains some elementary information about itself, the most important of which are the "fragment ID", corresponding to a section of an experiment's detector, and the "sequence ID", used to uniquely label an event in the experiment. An "event" in an experiment using an artdaq-based DAQ system consists of fragments with a predefined set of fragment IDs all sharing the same sequence ID. Along with this basic info which all artdaq::Fragment objects contain (known as an artdaq::Fragment "header"), an artdaq::Fragment object can also contain a "payload", the raw data produced by the upstream hardware as well as potential experiment-specific metadata such as the serial number of the upstream DAQ board where the fragment's data was created, the sample rate frequency, etc.
31 17 John Freeman
32 21 John Freeman
h2. artdaq-demo and artdaq 
33 1 John Freeman
34 25 John Freeman
The artdaq package provides users the tools (scripts, base classes, and applications) with which to create a DAQ system but does not itself provide a full workable DAQ. artdaq-demo is an example of how a user could create a DAQ system off of artdaq. In order to understand how artdaq-demo works, some components of artdaq first need to be understood; descriptions are provided below. Before reading the descriptions, the more visually inclined readers may want to scroll down to look at the UML deployment diagram showing how an artdaq-based DAQ can be distributed on an experiment's hardware, and the conceptual diagram showing how the various components relate to one another. Once this overview is read, developers and/or the curious can go to [[How to write a fragment generator]] for details on how to develop their own, experiment-specific DAQ software components. 
35 24 John Freeman
36 5 John Freeman
h3. The artdaq::CommandableFragmentGenerator class
37 5 John Freeman
38 1 John Freeman
The artdaq::CommandableFragmentGenerator class interface describes the basic state transition model of artdaq, including initialization, starting, stopping, and shutting down of the DAQ system. A user can override its virtual functions in a derived class to obtain fragments from an experiment's upstream hardware- or alternatively, write a simulation class for the experiment. The ToySimulator class found in artdaq-demo/artdaq-demo/Generators/ is an example of such a simulator, and is employed in the standard artdaq-demo run scripts. Instances of a class such as ToySimulator (i.e., one which derives from CommandableFragmentGenerator) are referred to as "fragment generators". A typical experiment will usually contain at least a few fragment generators. 
39 1 John Freeman
40 1 John Freeman
For more information on the artdaq state machine, see the diagrams "here":
41 1 John Freeman
42 31 John Freeman
h3. The BoardReader application
43 1 John Freeman
44 31 John Freeman
In a running artdaq-based DAQ system, a BoardReader process contains a fragment generator. It is typically in charge of receiving data from a predefined subset of an experiment's DAQ hardware, storing it in an artdaq::Fragment object's payload, and adding a fragment ID and sequence ID. A BoardReader receives state transition commands (the main ones being init, start, stop, shutdown), and sends them to the fragment generator. Each BoardReader process is in charge of some predefined set of fragment IDs- usually just a single one. 
45 1 John Freeman
46 31 John Freeman
h3. The EventBuilder application
47 1 John Freeman
48 31 John Freeman
Each EventBuilder application receives fragments from all BoardReaders; a given EventBuilder application will be in charge of a subset of the total number of events passing through the DAQ system, if there's more than one such process in use. Containing knowledge of what set of fragment IDs constitutes a complete event, EventBuilder will receive fragments and whenever it determines it has the correct number of fragments to constitute a complete event it will then send the event to an art thread it's running which then allows the event to be processed by an optional series of art modules, and will send the complete art event to the DataLogger process(es) for further processing.
49 5 John Freeman
50 31 John Freeman
h3. The DataLogger application
51 1 John Freeman
52 31 John Freeman
A DataLogger receives events from upstream EventBuilders and writes them to a file on disk using art's RootOutput module. If there are N DataLoggers in a running system, then N files will be written to at any point. The DataLogger also sends events in a non-blocking manner to one or more Dispatcher processes. If there are N Dispatcher processes, N > 1, it's possible to configure DataLoggers so that they either send all their events to all Dispatchers, or divide up their events among the Dispatchers. 
53 5 John Freeman
54 31 John Freeman
h3. The Dispatcher application
55 13 John Freeman
56 31 John Freeman
As its name suggests, a Dispatcher is in charge of routing events to art processes which request them for online monitoring purposes. The TransferInput art source found in artdaq allows for this functionality; it makes it possible to register an art process with a dispatcher at any point during running.
57 15 John Freeman
58 31 John Freeman
h3. Sample artdaq deployment diagram
59 10 John Freeman
60 31 John Freeman
The following is a UML (Universal Modeling Language) diagram of a sample deployment of an artdaq-based DAQ system running on a detector consisting of two components, each of which is interfaced with a BoardReader application, both running on the same host; additionally, there are two EventBuilders running on two desktops and a DataLogger and Dispatcher running on the same desktop. For historical reasons, both the DataLogger and Dispatcher are referred to as "AggregatorMain" below. 
61 6 John Freeman
62 31 John Freeman
63 9 John Freeman
64 9 John Freeman
Now that you've read up a bit on artdaq-demo and the packages it depends on, you can obtain your own copy of it by following the instructions at [[Installing and building the demo]].