A description of the demo system » History » Version 30

Version 29 (John Freeman, 01/05/2017 12:45 PM) → Version 30/31 (John Freeman, 01/08/2017 05:42 PM)

h1. A description of the demo system

h2. Intro

artdaq-demo and artdaq-core-demo serve as an example of how parts components of the artdaq and artdaq-core packages, described below, can be pieced together to create a functioning DAQ system; a careful study of the packages along with their associated 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:

** Examples of various types of art modules useful for DAQ systems (online monitoring, etc.)

** 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 its users 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.

** 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

** 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 ToySimulator to simulate production of data fragments which are represented by the toy overlay class, and then processed in real-time processing the data by running art analyzer modules which use and and writing the ToyFragment overlay class result to work with the fragments. Additionally, by default the data produced is written to disk


_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._


h2. artdaq-core-demo and artdaq-core

h3. artdaq-core-demo: overlays

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.

h3. artdaq-core: the underlying data representation and the artdaq::Fragment class

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 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 describing the upstream hardware physics as well as potential experiment-specific metadata such as the serial number of the upstream DAQ board where the fragment's data fragment was created, the sample rate frequency, etc.

h2. artdaq-demo and artdaq

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.

h3. The artdaq::CommandableFragmentGenerator class

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 demo::ToySimulator class found in artdaq-demo/artdaq-demo/Generators/ is an example of such a simulator, simulation, 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.

For more information on the artdaq state machine, see the diagrams "here":

h3. The BoardReaderMain application

In a running artdaq-based DAQ system, a BoardReaderMain 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. BoardReaderMain receives state transition commands (the main ones being init, start, stop, shutdown), and sends them to the fragment generator. generator class derived from CommandableFragmentGenerator. Each BoardReaderMain process is in charge of some predefined set of fragment IDs- usually just a single one.

h3. The EventBuilderMain application

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 the correct number of enough fragments to constitute for a complete event it will then send the complete 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 AggregatorMain processes for further art processing.

h3. The AggregatorMain application

Unlike an EventBuilderMain process, both AggregatorMain processes see the full set of events passing through the DAQ system. Typically, they're tailored to different tasks. One, referred to as the "data logger", receives the tasks - one is focused on writing processed events from the upstream EventBuilderMains and writes them to a file on disk using art's the RootOutput module. The other, called module provided by art, and the "dispatcher", receives events in a non-blocking manner from the data logger and receives event requests from other runs experiment-specific analyzer art processes running art modules designed which allow for an experiment's monitoring, sending (dispatching) events when it receives requests. online monitoring. As the dispatcher online monitoring AggregatorMain receives sees the art events provided by the data logger diskwriting AggregatorMain in shared memory, memory (ensuring online monitoring modules can't exert backpressure on the system), both AggregatorMains need to be on the same host - as can be seen in the deployment diagram below. diagram.

h3. Sample artdaq deployment diagram

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 BoardReaderMain application, both running on the same host; additionally, there are two EventBuilderMains running on two desktops and the two AggregatorMains running on a single desktop.


h2. artdaq-demo

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 XML-RPC transition commands sent demo is to be run in that it's in charge of sending the processes, as well as FHiCL control code which generates used to initialize the FHiCL documents expected by the various artdaq processes during applications comprising the initialize transition. DAQ system (where FHiCL is the "Fermilab Hierarchical Command Language": . ). In order to see what those FHiCL documents strings are, after the first time you initialize the system, *.fcl files for each process will be written to the directory out of which you're running. running containing the strings. For more on this, see [[Running a sample artdaq-demo system]] .

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]].