Running a sample artdaq demo system
{{toc}}
See
https://github.com/art-daq/artdaq-utilities/repository/daqinterface/revisions/develop/show/simple_test_config
Some of these configurations are used in artdaq
[[artdaq:Artdaq_Release_testing_documentation_and_results#DAQInterface
Example Configurations|release testing]]
At the top of this
artdaq:Artdaq_Release_testing_documentation_and_results#DAQInterface-Example-Configurations
section are example run_demo.sh command lines.
These steps assume that you have already installed and built the necessary packages using the steps listed on the [[Installing and building the demo]] page.
The standard method of running an artdaq-based system for experiments is to use a program called DAQInterface; for actual experiments using an artdaq-based system specific to their hardware and analysis needs rather than artdaq-demo, a bit of configuration is needed, as described on the DAQInterface wiki. However, the good news is that when you installed artdaq-demo, not only was DAQInterface installed as well, but it was configured automatically to work with artdaq-demo. In other words, the instructions given in the “Getting Started” section of the DAQInterface wiki were executed within the artdaq-demo installation scripts. Therefore, to begin running immediately, first do the following:
cd <base directory where you installed artdaq-demo>/DAQInterface
…and then take up the instructions on the DAQInterface wiki from the section “A First Walkthrough”, https://github.com/art-daq/artdaq_utilities/wiki/Artdaq-daqinterface#A-first-walkthrough.
Or, you can use run_demo.sh as described next.
cd <base directory where you installed artdaq-demo>/DAQInterface
ipcrm -a;./run_demo.sh --config <configuration> --comps "<components>" --no_om --runduration 20
is one of the sub-directories in the
daqinterface/simple_test_config
directory.
is one of the “components” in the first column of
docs/known_boardreaders_list_example files.
For example:
ipcrm -a;./run_demo.sh --config demo --comps component{01..02} --no_om --runduration 20
OR
ipcrm -a;./run_demo.sh --config request_based_dataflow_example --comps component{01..03} --no_om --runduration 20
If, following the instructions on the DAQInterface wiki, you get the DAQ into a running state, it’s possible to launch an art process designed for online monitoring purposes. To accomplish this, open a new terminal, and do the following:
cd <base directory where you installed artdaq-demo>
source setupARTDAQDEMO
art -c ${MRB_TOP}/srcs/artdaq_demo/tools/fcl/TransferInputShmem.fcl
and what you’ll see, twice a second, are messages like the following:
######################################################################
Run 5, subrun 1, event 135 has 2 fragment(s) of type TOY1 or TOY2
TOY1 fragment 0 w/ seqID 135 has total ADC counts = 40
Fragment metadata:
Board serial number = 618, sample bits = 12 -> max ADC value = 4095
First 10 ADC values in the fragment:
...0: 2552 1218 2957 2154 1547 1510 1834 2028 2072 2186
TOY2 fragment 1 w/ seqID 135 has total ADC counts = 40
Fragment metadata:
Board serial number = 7848, sample bits = 14 -> max ADC value = 16383
First 10 ADC values in the fragment:
...0: 6682 8936 10249 5296 10108 6224 9552 8805 8923 9715
######################################################################
Basically, each of the two BoardReaders contains a fragment generator called “ToySimulator” which is creating fragments with a payload of 40 ADC counts apiece. However, the two fragment generators are configured differently - in one, the ADC values are 12-bit and can therefore assume a maximum value of 4095, in the other, the ADC values are 14-bit and can assume a maximum value of 16383. The values are randomly distributed according to a gaussian centered half-max with a sigma of 1/10th of the max. This monitoring you’re running prints out the first 10 ADC values of this fragment from every 5th event passing through the system.
Let’s play with this a little. First, hit “Ctrl-c”; you should see something like the following:
%MSG-i TransferWrapper: ToyDump:toyDump@EndJob 19-Sep-2016 13:50:49 CDT PostEndRun
Requesting that this monitor (shmem1) be unregistered from the dispatcher aggregator
%MSG
%MSG-i TransferWrapper: ToyDump:toyDump@EndJob 19-Sep-2016 13:50:49 CDT PostEndRun
Response from dispatcher is "Success"
When you started art, a message was sent via XML-RPC to Dispatcher indicating that you wanted it to send you events. The details (that every 5th event should be sent, and that it should be done via shared memory as opposed to, say, over a network via multicast) were provided in the FHiCL, along with a unique label for your process, “shmem1”. The aggregator will refuse to accept your request for events if you don’t provide it with a unique label - so if, e.g., you set up another artdaq-demo environment and tried to run the same script without having terminated the first instance, you’d get something like the following:
%MSG-i TransferWrapper: art 19-Sep-2016 14:14:56 CDT JobSetup
Attempting to register this monitor ("shmem1") with the dispatcher aggregator
%MSG
%MSG-i TransferWrapper: art 19-Sep-2016 14:14:56 CDT JobSetup
Response from dispatcher is "Attempt to register newly-created monitor with label "shmem1" failed; a monitor with that label already exists"
However, since we just hit “Ctrl-c” on the first monitoring process, if the Dispatcher successfully unregistered it, we can fire it up again with the same FHiCL document (and hence the same unique label). However, before we fire it up again, let’s change both the fraction of events we receive as well as the way we monitor them. Edit the TransferInputShmem.fcl file you provided the art process by changing its “modulus” variable from 5 to 100, and then change the following line:
end_paths: [ a3 ]
to
end_paths: [ a1 ]
Now run
art -c srcs/artdaq_demo/tools/fcl/TransferInputShmem.fcl
once again.
What you’ll see is two plots, which update about once every ten seconds,
and which are filled with data from every 100th event. One shows all the
ADC values for both fragments within a single event; notice that while
the TOY1 fragment has 12-bit ADCs and hence a max ADC value of 4096,
TOY2 has 14-bit ADCs and hence a max ADC value four times greater:
The other plot is two histograms, each showing the cumulative ADC values
from all fragments of a given type for every 100th event. If you let it
run for a while, you’ll slowly see a gaussian forming.
While the demo described above is designed to give a feel for what a full artdaq-based DAQ system looks like, frequently it’s desirable to test fragment generators (discussed in-depth later in this wiki) and art modules in a more lightweight environment. Along with the standard BoardReaderMain, EventBuilderMain and AggregatorMain processes out of which one can create a DAQ, artdaq also supplies the artdaqDriver executable. Running artdaqDriver at the command line itself is very simple as all one needs to do is provide it with a FHiCL document; the complexity is in the FHiCL document itself. An example of this can be seen by the following steps:
## log into the test system where you installed the artdaq-demo
## switch to the bash shell, if needed
## cd <BASE_DIR>
## source setupARTDAQDEMO
## artdaqDriver -c
srcs/artdaq_demo/tools/fcl/driver_test3.fcl
And you’ll see output like the following:
######################################################################
Run 101, subrun 0, event 1 has 1 fragment(s) of type TOY2
Toy fragment 0 has total ADC counts = 100
Fragment metadata:
Board serial number = 999, sample bits = 14 -> max ADC value = 16384
First 10 ADC values in the fragment:
PRINCIPAL TYPE: Event
PROCESS NAME | MODULE LABEL.. | PRODUCT INSTANCE NAME | PRODUCT FRIENDLY TYPE | SIZE
Driver...... | TriggerResults | ..................... | art::TriggerResults.. | ...-
Driver...... | daq........... | TOY2................. | artdaq::Fragments.... | ...1
Total products (present, not present): 2 (2, 0).
######################################################################
Basically, in the driver.fcl document, it’s specified that an instance of the ToySimulator fragment generator (the same type used in the 2x2x2 demo) generate and send a set of events, which are then processed by the ToyDump art module, found in artdaq-demo/ArtModules. You can open up driver.fcl and play around with things like the parameter settings for ToySimulator, the art modules used to process the events, or even the fragment generator used - on this final point, artdaqDriver is very useful for testing purposes when you’re developing your own fragment generator.
By now you should have a taste of what artdaq and artdaq-demo are capable of. To learn how to run a DAQ system with different numbers of artdaq processes running on different hosts, potentially using artdaq-based systems different than artdaq-demo, take a look at the DAQInterface documentation, https://github.com/art-daq/artdaq_utilities/wiki/Artdaq-daqinterface .