Replace the monitoring aggregator with a dispatcher
With standalone art processes now capable of processing events sent from an artdaq-based DAQ system given the Transfer input source (Redmine Issue #13360), the use of an aggregator to run art modules to perform monitoring is somewhat redundant. Rather than have a monitoring aggregator, we can use a dispatching aggregator (or even a non-aggregator standalone process) whose job it is to receive events from the diskwriting aggregator (data logger) via the shared memory Transfer plugin and then send them out via another Transfer plugin (probably a different variant, e.g., the multicast Transfer plugin). This process can be termed a "dispatcher".
#1 Updated by John Freeman over 3 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
With artdaq commit 4f48cf0be9aad6b24b835d5f279a6be86cd79574 on the feature/dispatcher branch, I've added code whereby an aggregator can not only be a data logger or a monitoring aggregator, it also has the option of being a dispatcher aggregator. If it's a dispatcher aggregator, it receives events via a transfer plugin (for now, a shared memory transfer plugin) from the data logger, and then sends them out via another transfer plugin to standalone art processes for monitoring. I've successfully run using a dispatcher aggregator on mu2edaq01 sending out events via shared memory to a standalone art process, and also successfully run using a dispatcher aggregator on mu2edaq01 sending out events via multicast both to a standalone art process on mu2edaq01 and mu2edaq05. Full results for testing can be found in mu2edaq01:~jcfree/tests/dispatcher/ .
artdaq-demo has a feature/dispatcher branch whose FHiCL code works with this new artdaq code.