Project

General

Profile

The artdaq-demo Examples

In addition to the default configuration (a TOY1 and TOY2, using the WFViewer analysis module), several examples are included with artdaq-demo.
These examples come actually as part of daqInterface which is now checked when the demo is first installed.
See Running_a_sample_artdaq-demo_system.

ASCII Simulator (simple_test_config/ascii_simulator_example)

The ASCII Simulator example demonstrates that artdaq does not alter the input data at any point in the DAQ system. It accomplishes this through the use of the asciiSimulator Fragment Generator, which generates two alternating ASCII strings. These strings may be viewed in the output file through the "asciiDump" art module.

Data Requests (simple_test_config/request_based_dataflow_example)

This example demonstrates the Data Request functionality that is present in all artdaq FragmentGenerators. It consists of a 3 BoardReader (using the ToySimulator FragmentGenerator), 2 EventBuilder, 2 Aggregator system.
The three BoardReaders are configured as follows:
  1. A “DAQ” BoardReader which operates in the “traditional” artdaq manner, sending each event to the EventBuilders as the FragmentGenerator supplies it
  2. A “DCS” BoardReader which has a ToySimulator configured to generate data slowly with respect to the rest of the system, and which sends whatever its latest data point is for each data request
  3. A “CRV” BoardReader which uses a ToySimulator configured to generate data faster than the “DAQ” BoardReader, but not send it until it receives a data request.

The "DAQ" BoardReader is configured to send fragments at approximately 10 Hz, the "DCS" at about 1 Hz, and the "CRV" at about 50 Hz. The "timestamp" is simulated in the "DAQ" and "CRV" BoardReaders using the "timestamp_scale_factor" configuration parameter for the ToySimulator. This parameter is set to 5 for the "DAQ" BR, and 1 for the "CRV", reflecting that the "DAQ" BoardReader generates one fragment for every 5 "CRV" fragments.

The “DAQ” BoardReader corresponds to request_mode: Ignored. It uses a data-collection thread, and another thread sends each data point as a new event as it becomes available.
The “DCS” BoardReader corresponds to request_mode: Single. Its sending thread has a buffer of exactly one event, with which it responds to each request event. Whenever its FragmentGenerator has new data, that buffer is replaced with the new data. If, for example, the FragmentGenerator was generating fragments at a faster rate than the request messages were arriving, then it would silently discard the extra data.

Finally, the “CRV” BoardReader corresponds to request_mode: Window. This request mode uses the “timestamp” field of the artdaq Fragment class to determine which fragments in its buffer it should send in response to a request message. The request contains a sequence id and a timestamp, the BoardReader is configured with offset and length parameters to translate the timestamp in the request to a window of timestamps that it should search for in its buffer. The buffer depth is configurable in number of fragments stored, total buffer size, and timestamp-wise (the difference between buffer entry n and the latest addition is used here). If the buffer is full, then the data-taking thread is paused until it drains via the sending thread. The sending thread will also hold on to requests until the last fragment in the buffer has a timestamp greater than the end of the window.

The "CRV" BoardReader has an offset of 2 and a width of 5. This means that when it receives a request for timestamp 15, it will return fragments with timestamps in the range 13 to 18. By default, when the EventBuilder receives the first fragment for a sequence id it has not yet seen, it will send a request message with that sequence id and the timestamp of the received fragment. Despite it being configured as a TOY2 FragmentGenerator, the CRV BoardReader will reply with "Container" type fragments. These are used to keep consistent fragment counts between events. Each Container fragment can contain a variable number of fragments, and is easily inspected to determine the number of fragments present.

The request message is a simple UDP packet that is defined in artdaq/DAQrate/RequestMessage.hh, and can be sent from anywhere, and, as you saw, the BoardReaders can be configured for where to listen for these requests.

Notes:
  • you must open firewall port 3001/udp for this example to work! On SL7: firewall-cmd --add-port 3001/udp
  • check data file (substituting filename as appropriate) via: art -c wfViewer.fcl daqdata/artdaqdemo_r000101_sr01_20180206T211124_1.root

Larger System (simple_test_config/demo_largesystem)

Run this system for 2 minutes via:

ipcrm -a; . run_demo.sh --basedir=$PWD --config demo_largesystem --comps component{01..19} -- --no_om  --runduration 120