DAQInterface should support fragment generators which return more than one fragment per event
When bookkeeping, DAQInterface sets expected_fragments_per_event in the EventBuilder FHiCL to the number of BoardReaders (*). The underlying assumption here is that each BoardReader sends one fragment per event. However, this is not always the case; SBND, for example, sends multiple fragments per BoardReader per event, which has necessitated their commenting out some of the bookkeeping logic in DAQInterface. It should be possible for experiments to be able to explicitly specify how many fragments a given BoardReader will send per event via the BoardReader's FHiCL document (similar to how it's possible to tell DAQInterface what the max fragment size a BoardReader can send is via the FHiCL document, see Issue #20580). Or, even slicker, it could perhaps deduce this from a fragment_ids FHiCL list.
(*) Or more technically, the number of BoardReaders whose FHiCL documents don't include the line "sends_no_fragments: true"
JCF: modify bookkeeping functionality s.t. if a line of the form
"generated_fragments_per_event: <N>" appears in a BoardReader FHiCL,
then DAQInterface will use that value when calculating
"expected_fragments_per_event" in the EventBuilder FHiCL. Default
assumption is that each BoardReader sends one and only one fragment
per event. Satisfies Issue #21044.
#3 Updated by John Freeman about 2 years ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
Requirements satisfied by commit f0c4eb32924669187107dbbc2818323a43b9fa08 on the develop branch. When calculating "expected_fragments_per_event" in the EventBuilder, DAQInterface will assume a BoardReader sends 1 fragment per event UNLESS in the BoardReader FHiCL it sees either (A) a line of the form "
generated_fragments_per_event: <N>", <N> an integer, or (B) "
sends_no_fragments: true". Here, (A) is the feature which satisfies this Issue, and (B) is an old feature left in for backwards compatibility purposes.