Subsystems are a feature of artdaq which allows different parts of detector data to be incorporated into the data stream at different times. An implementation is included in artdaq starting with version 3_06_00. The Mu2e experiment has expressed interest in subsystem-based configurations as a method of adding CRV data to triggered Tracker and Calorimeter events. A fully-realized subsystem implementation will allow experiments to break down their readouts into manageable chunks which can operate almost completely independently of one another.
The Partition_notes_1 wiki pages mentions subsystems.

The simple_subsystems simple_test_config showcases the minimal desired functionality for multi-layer artdaq systems. Two components send data to a farm of two EventBuilders, which send to a DataLogger but also to another layer of EventBuilders. A third component sends data upon request directly to the second layer of EventBuilders. The second layer sends to a second DataLogger, which has a Dispatcher attached to it.

This is a basic example of Mu2e’s desired functionality for the CRV. component01 and component02 represent the Tracker and Calorimeter, while component03 represents the CRV. Event filtering is performed in the first layer of EventBuilders, then triggered events are sent on to the second layer, where CRV data is requested. DataLogger1 is optional, and will take some code changes to integrate into the example.

DAQInterface must be made “subsystem aware” to perform bookkeeping and create the sources and destinations blocks for a subsystem-enabled configuration. The basic changes include adding optional subsystem declarations to the EventBuilder, DataLogger, and Dispatcher application in boot.txt, optional subsystem column in known_boardreaders_list, and subsystem declarations and destination configuration in boot.txt.

With the assumption that subsystems are always implemented between EventBuilders, the only information needed to construct the bookkeeping for a subsystem-based configuration is the destination subsystem for each subsystem, if any. In the simple_subsystems example, Subsystem 1 has a destination of Subsystem 2, and Subsystem 2 has no destination. It may be necessary for DAQInterface to construct entire OutputModule configurations for subsystems, if there are multiple destinations allowed (i.e. multiple output paths with trigger selection).

Currently, the RootNetOutput and BinaryNetOutput modules use NetMonTransportService to configure DataSenderManager. The issue is that as a service, only one instance of NetMonTransport (and therefore DataSenderManager) may exist in an art process. To enable sending to multiple destination subsystems, or to a destination subsystem and one or more DataLoggers, the configuration and construction of DataSenderManager must be moved into the OutputModules themselves, so an arbitrary number of destinations may be defined. Alternatively, NetMonTransportService could be extended to have multiple-destination-set functionality, using some sort of key-based indexing, which would help restrict the senders from sending one event to the same destination through multiple paths.

• {color:purple} [KAB, 14-Nov] I think that it would be useful to talk through the options here. It seems like moving DataSenderManager makes sense, but I don’t remember what value NetmonTransportService provides.
• {color:green} [ELF, 21-Nov] In testing, I have discovered that BinaryNetOutput already instantiates its own copy of DataSenderManager. However, it may still make sense to replace NetMonTransportService, but it is not necessary for this task

Given a system such as the following:

1. Is there any potential use case for such a system?
   • [KAB, 14-Nov] I don’t know of a need for such a system, and based on the comments below, it seems like we would agree that we don’t need to consider this use case at the moment. A more useful use case to consider would be the SBND/MicroBooNE one, in which all data from each BoardReader is written to a local BR computer disk, and triggered data is sent to a central EventBuilder.
2. Do we wish to restrict subsystems to a single destination subsystem? (Note that EventBuilders may still have a destination subsystem and a DataLogger, necessitating the change to NetMonTransport/*NetOutput)
   • [KAB, 14-Nov] It seems like it might be useful to support multiple destination subsystems, but it also seems like it might be complicated (related question below).
3. What issues might occur from incorporating events which pass both trigA and trigB?

Thinking more about this problem, it seems unlikely that an experiment would only want to read out portions of the detector based on a trigger passing or failing. It also seems unlikely that there is a sane configuration for EventBuilder4’s pull mode in the case where events only sometimes pass both trigA and trigB.

1. Is it true that “source” subsystems must always use push mode to send their fragments to destination subsystems?
2. Do we plan to use the Routing Master in the Mu2e DAQ?
3. Will the fragments that are sent from source subsystems to destination subsystems be in binary format? If so, do we have a plan to support extra data products that might be produced in the Mu2e Tracker+Calorimeter trigger code?
4. How will event numbering be handled?