Feature #13360

Create an art source capable of receiving events sent via a Transfer plugin from an artdaq aggregator

Added by John Freeman over 4 years ago. Updated over 4 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
50.00 h
Duration: 75


Traditionally, monitoring has been performed in artdaq by a dedicated monitoring aggregator receiving events from the diskwriting aggregator and sending those events through an art workflow imbedded in artdaq code. However, monitoring artdaq-based DAQ systems could be more flexible if users could launch standalone art processes capable of reading in events sent out by an aggregator, which could then run user-specific art modules that artdaq need not be directly aware of. For this purpose, the TransferInput source has been created. To see it in action, if you've used quick-start to install and build artdaq-demo off its a02e7be28d561197c5971d9891f962922f438795 commit on mu2edaq01 , you can do the following:

-Switch the Transfer plugin from shmem (shared memory) to multicast; to do this, in artdaq-demo/tools/generateAggregator.rb just change transferPluginType: shmem to transferPluginType: multicast and recompile
-Create two terminals on mu2edaq01 in which artdaq-demo is set up, as you would if you ran the standard 2x2x2 simulation
-Take the 2x2x2 simulation up through the init phase. Don't start it.
-Create one terminal on mu2edaq05 in which artdaq-demo is set up
-If you're in build_artdaq-demo, run art -c fcl/TransferInput.fcl
-Now start the system

What you'll see is that there are now TWO sets of WFViewer plots created - one from the monitoring aggregator on mu2edaq01, and one from the standalone art process on mu2edaq05. Note that in the fcl/TransferInput.fcl art workflow running on mu2edaq05 there's a module called "CheckIntegrity" which is running; it's making sure that the distribution in the (TOY1) fragment payloads is monotonically increasing. You shouldn't see any error messages. On the other hand, if you edit artdaq-demo/tools/fcl/ToySimulator.fcl so that the distribution_type is no longer 2 (the monotonic distribution) you'll get an error message for every event.

A note for artdaq developers: the implementation of the TransferInput source can be found in artdaq/TransferPlugins/ . From an implementation perspective, observe that TransferInput is actually the ArtdaqInput class templatized with the TransferWrapper class. By point of comparison, the NetMonInput source is simply the ArtdaqInput class templatized by the NetMonWrapper class. The reason for the creation of ArtdaqInput is that a great deal of the code dealing with art principals, etc. need not be different between the two sources.

The following commits involved the development of the TransferInput source:

5/20 72893777532e32969cc4e66819d47ea9911ed63e
5/20 963eeef2792b5e6eb0417e3c13ce3582a75725de
5/24 104220c1b4b5735c6eaf3d8a99526d85abf9decc
5/25 368058722f246d178da916278327adb896053621
5/26 e90d1194471801b49ed1a63ecb9c3a92ca2425d0
5/27 45e90a420a2e57babe823ba66eca8f1d1c5bc976
5/27 864d104d42b8435876a4964b147158a5feecf106
5/27 1bff7911f2b95a3ef49c82834112a418105e6efe
5/27 20ddb7bafb48a2217fd924f3f918df1d4c23d6ed
5/31 8139e219b2c799c1c2ebba8c99dccf8ec79a7d07
7/11 b2996172118fd70e995b9b38fe185577c57f182c
7/25 7163b11047d62c701629b8bbd8d4e6313a08f00d


#1 Updated by Eric Flumerfelt over 4 years ago

  • Status changed from Resolved to Closed
  • Target version set to v1_13_01

Also available in: Atom PDF