A description of the demo system » History » Version 9

John Freeman, 07/20/2014 10:39 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 5 John Freeman
artdaq-demo serves as an example of how components of the artdaq package can be pieced together to create a functioning DAQ system; a careful study of the package along with its associated documentation is intended to provide DAQ designers the knowledge base they need to develop their own, experiment-specific daq systems. artdaq-demo provides:
6 5 John Freeman
7 6 John Freeman
** Examples of various types of ART modules useful for DAQ systems (online monitoring, etc.)
8 5 John Freeman
9 6 John Freeman
** an example of an artdaq::Fragment class overlay for a commonly used board (the CAEN digitizer unit V172x), as well as a simple artdaq::Fragment class overlay designed to help users learn about how overlays work in artdaq-demo. An "overlay class" is designed to provide an interface to an experiment's raw data which separates its users from the low-level details of the data layout 
10 5 John Freeman
11 6 John Freeman
** artdaq::CommandableFragmentGenerator -derived classes capable of simulating DAQ input, allowing users to learn about running an artdaq-based system without needing to interface with actual DAQ hardware
12 5 John Freeman
13 6 John Freeman
** A set of scripts, the use of which is described in [[Running a sample artdaq-demo system]], that the user can run to simulate a full DAQ system run, using the artdaq::CommandableFragmentGenerator -derived class demo::ToySimulator to simulate production of data fragments represented by the artdaq::Fragment overlay class demo::ToyFragment, and then processing the data by running ART modules and and writing the result to disk
14 5 John Freeman
15 5 John Freeman
h2. artdaq 
16 5 John Freeman
17 5 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; once this overview is read, go to [[Fragments and FragmentGenerators w/ Toy Fragments as Examples]] for more information.
18 5 John Freeman
19 5 John Freeman
h3. The artdaq::Fragment class
20 5 John Freeman
21 8 John Freeman
The basic unit of data in artdaq-based DAQ systems is a "fragment"; this data is contained within an object of the artdaq::Fragment class. This object 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 describing the physics as well as potential experiment-specific metadata such as the serial number of the upstream DAQ board where the fragment was created, the sample rate frequency, etc. Users should represent their experiment's data via an overlay class which takes a basic artdaq::Fragment object as a constructor argument and provides functions to allow users to access experiment-specific information of interest within the object's payload without having to worry about low-level details of the data layout. artdaq-demo's demo::ToyFragment class is an example of such an overlay class.
22 5 John Freeman
23 5 John Freeman
h3. The artdaq::CommandableFragmentGenerator class
24 5 John Freeman
25 7 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. When implemented by a user, it can either contain the functionality to obtain fragments from an experiment's upstream hardware, or alternatively, serve as a simulation class for the experiment. The demo::ToySimulator class is an example of such a simulation, and is employed in the standard artdaq-demo run scripts.
26 5 John Freeman
27 5 John Freeman
h3. The BoardReaderMain application
28 5 John Freeman
29 7 John Freeman
In a running artdaq-based DAQ system, a BoardReaderMain process 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 (the values of which could conceivably be contained in the raw upstream data itself). BoardReaderMain receives state transition commands (init, start, stop, shutdown), and sends them to the fragment generator class derived from CommandableFragmentGenerator. Each BoardReaderMain process is in charge of some predefined set of fragment IDs.
30 5 John Freeman
31 5 John Freeman
h3. The EventBuilderMain application
32 5 John Freeman
33 8 John Freeman
Each EventBuilderMain application receives fragments from all BoardReaderMains; a given EventBuilderMain 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, EventBuilderMain will receive fragments and whenever it determines it has enough fragments for a complete event will then either send the complete event to a thread it's running which then allows the event to be processed by a series of art modules (if no AggregatorMain processes are running) or will send the complete event to the AggregatorMain processes.
34 5 John Freeman
35 1 John Freeman
h3. The AggregatorMain application
36 1 John Freeman
37 8 John Freeman
EventBuilderMain applications are unaware of each other. The previous edition of artdaq (and by extension, artdaq-demo) did not contain an AggregatorMain application, and as a result each EventBuilderMain in a DAQ system would write to a separate file on disk. AggregatorMain, on the other hand, sees all EventBuilderMains and consequently the full set of events passing through the DAQ system; they can be tailored to different tasks (for example, one can focus on writing processed events to a single file on disk, another can focus on running online monitoring). Note that as of artdaq v1.08.00, no more than two AggregatorMain processes may run, and as they rely on the same shared memory they need to be on the same host. 
38 5 John Freeman
39 5 John Freeman
h2. artdaq-demo
40 5 John Freeman
41 5 John Freeman
artdaq-demo comes with a pair of scripts, and, which can be run in separate terminal windows to execute a sample DAQ system. The "2x2x2" refers to the use of two BoardReaderMains, two EventBuilderMains, and two AggregatorMains. primarily serves as a wrapper around artdaq's pmt.rb script (pmt == "process management tool")  which sets up the MPI environment and checks that it's possible to communicate with the processes used in the system via the XML-RPC protocol, which will be necessary in order to send them transition commands. primarily serves as a wrapper around artdaq-demo's DemoControl.rb script, which itself defines how the demo is to be run in that it's in charge of sending the FHiCL control code used to initialize the various artdaq applications comprising the DAQ system (where FHiCL is the "Fermilab Hierarchical Command Language": ). In order to see what those FHiCL strings are, you can include a "-v" among the options to when initializing, e.g., " -v -m on init", in which case *.fcl files for each process will be written to the directory out of which you're running. For more on this, see [[Running a sample artdaq-demo system]] .
42 6 John Freeman
43 6 John Freeman
Now that you've read up a bit on artdaq and its demo, you can obtain your own copy of it by following the instructions at [[Installing and building the demo]].
44 9 John Freeman
45 9 John Freeman