CommandableFragmentGenerator support for multiple Fragment IDs
On feature/CFG_MultipleFragmentsPerRead, I have implemented changes to CommandableFragmentGenerator so that the request modes all support Fragment Generators which generate Fragments for multiple IDs. This feature was requested by SBND for handling their readout of multiple subdetector components through a single hardware interface.
The unit tests have been updated to use the new functionality, but I have not yet made simple_test_configs which demonstrate it in an artdaq system.
#1 Updated by Eric Flumerfelt almost 2 years ago
- Status changed from Work in progress to Resolved
I have tested these changes using artdaq_daqinterface/feature/CFG_MultipleFragmentPerRead, where I have implemented a new simple_test_config: multiple_fragments_per_read. This config is similar to request_based_dataflow_example, with the addition of a RoutingMaster. component02 generates multiple Fragments from the ToySimulator Fragment generator (the SBND use-case where one generator instance is responsible for multiple fragment IDs), and component03 generates multiple Fragments using CompositeDriver (Can be used for number-of-flows-to-EventBuilder reduction, i.e. one BR per host).
I have also run the demo simple_test_config and verified that the system is unaffected by these changes when not using multiple fragments from BRs.
#2 Updated by Kurt Biery over 1 year ago
I've merged the changes associated with this Issue to a branch that is based on the for_dune-artdaq branch so that we can run some tests at protoDUNE. Specifically, the new branch is working/fdaWithMultipleFrags, and it was branched from tag pdune_20190524.
I have not tested the code on this branch yet, neither on a Fermilab test system, nor at protoDUNE, but hopefully we can get to that soon.
#3 Updated by Kurt Biery over 1 year ago
I've done a little bit of testing on mu2edaq01 with the code on the working/fdaWithMultipleFrags branch. I used the following two 'run_demo' commands and verified that the behavior looks the same in an artdaq-demo system both with, and without, these code changes.
sh ./run_demo.sh --config mediumsystem_with_routing_master --bootfile `pwd`/artdaq-utilities-daqinterface/simple_test_config/mediumsystem_with_routing_master/boot.txt --comps component01 component02 component03 component04 component05 component06 component07 component08 component09 component10 --runduration 40 --partition 5 --no_om --runs 3
sh ./run_demo.sh --config pdune_swtrig --bootfile `pwd`/artdaq-utilities-daqinterface/simple_test_config/pdune_swtrig/boot.txt --comps swtrig felix01 felix02 felix03 ssp01 ssp02 ssp03 --brlist `pwd`/artdaq-utilities-daqinterface/simple_test_config/pdune_swtrig/known_boardreaders_list_example --runduration 40 --partition 5 --no_om --runs 3
In order to get these tests to work, I needed to extend the "datalogger timeout" value from 30 to 60 in DAQInterface/settings_example, and I needed to set the expected_art_event_processing_time_us parameter to 60 seconds in the DataLogger1.fcl files in these two simple configs. (These changes were needed for both the old and new software.)
#4 Updated by Kurt Biery over 1 year ago
- artdaq_core - working/22535_protoDFO_testing
- artdaq - working/22535_protoDFO_pduneHacks
- artdaq_core_demo - v1_06_14
- artdaq_demo - feature/CFG_MultipleFragmentsPerRead
- artdaq_mpich_plugin - working/22535_protoDFO_testing
- artdaq-utilities-daqinterface - feature/CFG_MultipleFragmentsPerRead
The repository branches are shown graphically in the attached file.
Since some of the branches include more than just feature/CFG_MultipleFragmentsPerRead, my tests were also an attempt to validate the merges that I did to create the branches that were used in the DFO testing at protoDUNE.
As part of these tests, I made a few modifications in the multiple_fragments_per_read sample system (e.g. renamed componentNN_hw_cfg.fcl go componentNN.fcl; switched from using RootOutput to RootDAQOut, etc.) Those were committed to the feature/CFG_MultipleFragmentsPerRead branch in artdaq-utilities-daqinterface.
In the multiple_fragments_per_read test, I confirmed that each data file had six artdaq fragments, as expected - one generated by component01, two generated by component02, and three generated by component03.
For grins, I ran the simple_test_config/multiple_fragments_per_read config with older software. That gave an exception because the ToySimulator_generator called the singular fragment_id() function even though it was configured to produce two fragments (presumably in component02).