[LBNE, Mu2e] Investigate ways to provide a two-stage artdaq system
In discussions with both LBNE and Mu2e, the idea of having a two-level (or two-stage, or double) artdaq system has come up as a way to meet the needs of their DAQ.
In LBNE, the need is to run software algorithms in art on a zero-suppressed copy of the raw data and use the output of those algorithms to trigger the readout of the non-zero-suppressed copy of the data for the events of interest. The goal is to balance the desire to have all of the data for the small number of events that are really interesting without having to transfer all of the data all of the time within the DAQ system.
In Mu2e, the need is to analyze the raw data from the tracker and calorimeter in art modules, and for events that pass these algorithms, trigger the readout of the cosmic ray veto detector.
The model that we've come up with so far is to have one set of BoardReaders that read out the initial set of raw data and send it to a first set of EventBuilder processes. In those EB nodes, events are built and art modules are run, as usual. When events are accepted in these EBs, messages are sent to a second set of BoardReaders which read out the additional data that is required. That data is sent to a second set of EventBuilder processes which build a second set of events and write them to disk (probably with very little processing).Some of the many questions include:
- how to transmit the "trigger" message from the first set of EBs to the second set of BRs
- how to identify the data that should be read out by the second set of BRs
- how to ensure that latency of the trigger decisions in the first set of EBs don't extend beyond the buffer length in the second set of BRs (or the hardware or software that they talk to)
- how to transmit the data from the first level EBs to the second level EBs so that fully complete events can be built (if needed)
If/when we have time, we should start prototyping a small demo system that could demonstrate some of these types of functions.
Initially, it probably makes sense to have both levels of BRs and EBs (and whatever Aggregator functionality that we want) all be part of the same MPI program.