12-Jun-2018, KAB

There are several reasons to consider upgrading the CommanderInterface to support a couple of new commands. The overall goal would be to allow us to specify parts of the configuration archive that is stored in the art/ROOT file, instead of sending it to logging processes all at once. One of the reasons to consider this is to avoid the trouble that we’re seeing in the protoDUNE DAQ in which the JCOP-based Run Control is unable to handle the very long string that contains all of the configuration FHiCL files. Another reason is to allow us to add parts of the overall FHiCL configuration to the configuration archive at various times in the life cycle of the DAQ.

I propose the addition of two new CommanderInterface commands:

1. add_config_archive_entry(string key, string value)
2. clear_config_archive()

Corresponding new methods would be added to the Commandable interface.

The first method could be called at Configuration (INIT) time or BeginRun (START) time by Run Control for each of the artdaq processes in the system. For example,

• add_config_archive_entry(“EventBuilder1”, “”)
• add_config_archive_entry(“DataLogger4”, “”)
• add_config_archive_entry(“”, “”)

It could also be called by Run Control to store run-specific parameters, like a run type, at begin-run time:

• add_config_archive_entry(“RunType”, “beam”)

The “clear” method could be used to clear out all of the entries at the appropriate time, such as when the full system is reconfigured.

The artdaq applications which would need to support these new operations are the ones that can write raw data to disk. These are primarily DataLoggers and EventBuilders, but in principle the Dispatcher could do it, too. As such, I believe that it makes sense to add functionality to the DataReceiverCore class to accept and store the configuration archive entries. I’m imagining that we’ll add a simple std::map<std::string, std::string> data member to this class.

The configuration of the art processes associated with the DataLoggers and EventBuilders is handled by the DataReceiverCode class and the SharedMemoryEventManager instance that it manages. My proposal is to modify the interface between these two classes so that the art configuration is passed at begin-run time instead of, or in addition to, configuration (INIT) time.

As with our earlier implementations of the configuration archive in the art/ROOT file, the primary DataLogger ParameterSet would be what the user specified, and there would be additional FHiCL that would list the configuration of each of the processes.

Here is what the full FHiCL string might look like:

# start of "normal" DataLogger configuration
daq: {
   aggregator: {
      auto_suppression_enabled: false
      buffer_count: 20
      event_queue_wait_time: 5
      expected_art_event_processing_time_us: 1e7
      expected_fragments_per_event: 1
      is_data_logger: true
      max_fragment_size_bytes: 1e8
      onmon_event_prescale: 1
      print_event_store_stats: true
      routing_token_config: {
         use_routing_master: false
      }
      sources: { ... }
      subrun_duration: -1
      subrun_event_count: 0
      subrun_size_MB: -1
   }
   metrics: {
      aggFile: {
         fileName: "/nfs/sw/work_dirs/artdaq-demo_test_artdaq_v3/daqdata/aggregator/agg_%UID%_metrics.log"
         level: 3
         metricPluginType: "file"
         uniquify: true
      }
      dim: {
         DIMServerName: "DataLogger1"
         DNSNode: "np04-srv-010.cern.ch"
         DNSPort: 2505
         Verbose: false
         level: 5
         metricPluginType: "dim"
         reporting_interval: 5
      }
   }
}
outputs: {
   normalOutput: {
      compressionLevel: 0
      fastCloning: false
      fileName: "/data0/test/np04_raw_run%06r_%#_dl1.root"
      fileProperties: {
         maxEvents: 1000
         maxRuns: 1
         maxSize: 8e6
         maxSubRuns: 1
      }
      module_type: "RootOutput"
   }
   rootNetOutput: {
      module_type: "RootNetOutput"
   }
}
physics: { ... }
process_name: "DAQDL"
services: { ... }
source: {
   module_type: "NetMonInput"
}
# end of "normal" DataLogger configuration

# start of archived configuration information

configuration_documents: {

    toysimulator33: "<FHiCL string>"

    EventBuilder1: "<FHiCL string>"

    DataLogger5: "<FHiCL string>"

    RunType: "beam"

    ...

}

# end of archived configuration information

Questions:

1. Do we want to store the individual archived configuration documents as ParameterSets, rather than strings, when that is appropriate?
2. Does the name “configuration_documents” seem reasonable? In the initial implementation, this key string was “run_documents”, but since we’d like to add dataflow configuration to the archive, it seems like it would be nice to expand the scope of the name.