Feature #22388

DAQInterface should allow for a child subsystem to have more than one parent subsystem

Added by John Freeman about 2 years ago. Updated almost 2 years ago.

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


Estimated time:


Right now, DAQInterface bookkeeping is set up so that a given subsystem can only have one parent subsystem. This requirement should be loosened so that a subsystem can have multiple parents. The requirement that a subsystem can have only one child subsystem, however, will be kept. (5.08 MB) Configuration Graph Eric Flumerfelt, 06/24/2019 12:26 PM

Related issues

Blocked by artdaq - Bug #22451: DataSenderManager eliminates entry in routing_table_ after sending just one fragmentClosed04/25/2019


#1 Updated by John Freeman about 2 years ago

  • % Done changed from 0 to 80
  • Status changed from New to Work in progress

I've created issue branch feature/issue22388_multiple_parent_subsystems to handle this. Right now, with commit 3cc0ab787d4cf8758dbec1e81c81677e54d8ebda, I've been able to do the following:

  • Sanity check: recreate the dune_sample_system FHiCL produced before my work on Issue #22555 (i.e., when Kurt's DFO-specific bookkeeping was in place). Details in mu2edaq01:/home/jcfree/run_records/2575; compare with /home/jcfree/run_records/2543
  • Added a subsystem 5 to dune_sample_system, consisting of a boardreader (felixHF02, basically a copy of felixHF01) and eventbuilder (EventBuilder4, a copy of Eventbuilder{1,2,3} but with routing_master functionality stripped out). Subsystem 5 sends to subsystem 4, i.e., subsystem 4 receives data from two subsystems. No unusual warnings, data writes fine to disk. Details in mu2edaq01:/home/jcfree/run_records/2574

Having said that, I'm getting warnings under other circumstances which may or may not be a problem with the implementation on this issue branch - e.g., when I try to add a sixth subsystem to feed the DFO in subsystem 3. Before I mark this issue as resolved I want to understand these not-perfect runs a little better.

#2 Updated by John Freeman about 2 years ago

  • % Done changed from 80 to 100
  • Status changed from Work in progress to Resolved

I consider this issue to be resolved and ready for review. Relevant notes are in the previous entry on this Issue. One thing to note is that I was running into problems when a parent subsystem's eventbuilder was handling more than one fragment AND a routing_master was mediating data transfer between the parent subsystem's eventbuilder and child subsystem's eventbuilder (Issue #22451), but it looks like this is something which can be fixed on the artdaq side.

#3 Updated by John Freeman about 2 years ago

After discussing with Eric, it turns out that in order to run with an eventbuilder in a parent subsystem sending more than one fragment per event to an eventbuilder in a child subsystem when a routing_master is involved, artdaq's feature/CFG_MultipleFragmentsPerRead branch currently needs to be used. When this change to artdaq is made, feature/issue22388_multiple_parent_subsystems can handle this scenario just fine.

#4 Updated by Eric Flumerfelt almost 2 years ago

  • Blocked by Bug #22451: DataSenderManager eliminates entry in routing_table_ after sending just one fragment added

#5 Updated by Eric Flumerfelt almost 2 years ago

The code changes make sense and the example runs and builds the expected configuration.

#6 Updated by John Freeman almost 2 years ago

With Eric's review, I've merged feature/issue22388_multiple_parent_subsystems into develop. I had to resolve a couple of conflicts, but now on the head of develop (8caf59662521674e3bf7508a9da32c9ea751fcf1) I've performed a couple of successful sanity checks:
-Bookkeeping for run 1001771 is in agreement with 8396 on the ProtoDUNE cluster (a proof-of-DFO-concept run using protoDFO_SWTrig_Test00002)
-Bookkeeping for run 2659 is in agreement with 2574 on mu2edaq01 (run 2574 described in earlier entry in this Issue)
-Bookkeeping for run 2660 is in agreement with 2575 on mu2edaq01 (run 2575 described in earlier entry in this Issue)

Agreement doesn't mean physical agreement, but logical agreement - e.g., on mu2edaq01, for the newer runs I had to rename DFO "DEffO" so DAQInterface wouldn't yell at me for having a DFO process in a parent subsystem of a subsystem with a routing_master.

Also available in: Atom PDF