Artdaq "wish list" December 2016

As I've mentioned, there is talk of having a protoDUNE vertical slice test at CERN at the end of January. I'm going to jot down my wish-list regarding how a user would interact with the control and configuration subsystems on Jan 30 and how things would work behind-the-scenes. As background, please take a look at the attached presentation, which has my slides from a couple of weeks ago.

This is a wish-list, so there can be places where we compromise. But, I'd like everyone to be in agreement about where we are headed. So, if there are correction or additions to the list, please send them around.

An aside from JCF: I've added the Artdaq "wish list" responses wiki page, where we can put our responses concerning the status of the wish list items

I would like there to be:

  1. a computer running CentOS7 that has artdaq, lbne-artdaq, nodeJS, MongoDB, artdaq-database, etc. already installed. This computer would be connected to a SLAC RCE with a 10 Gb link, could be connected to the CERN public network (or at least has a well-defined path in and out), and has a moderately large disk that can be used for writing data. [this may be out of our control, but I've included it to set the stage]
  2. an instance of artdaq-database running in MongoDB that has pre-populated entries for
    1. the list of available components: e.g. 1 or more RCEs, 1 or more SSPs, 1 or more FELIX cards
    2. the locations where various BoardReaders should run
    3. the possible locations of EventBuilders
    4. possible location(s) of Aggregators
    5. any other dataflow configuration parameters that are needed
    6. a sample RCE BoardReader and electronics configuration - this can be a shell of what will be needed
  3. the ability for an expert user to add another RCE to the list of components or modify the value of a dataflow parameter (mentioned in 2.5)
  4. the ability for an expert user to add parameters to one or more RCE boards in the RCE BR/electronics configuration and the ability to add more boards to the configuration (mentioned in 2.6) [ideally, this would be more sophisticated than "export the FHiCL file, edit it, and import it"]
  5. a user interface that can present the list of available components to a user, when requested (this user interface and the ones mentioned below do not need to be graphical)
  6. a user interface that allows a user to pick a set of components to use for a given DAQ session
  7. a user interface that allows the startup all of the artdaq processes
  8. a user interface that shows the list of available Run configurations (also known as Detector/Electronic configurations) to the user and allows him/her to select one
  9. a process that is smart enough to build the FHiCL files that need to be sent to the artdaq processes, given the selected Run configuration and readout components
  10. a user interface that allows the configuration all of the artdaq processes
  11. a (possibly simple) mechanism for automatically assigning unique run numbers
  12. a user interface that allows a user to begin a run (without having to explicitly provide a run number)
  13. archiving of the configuration that is used in each run
  14. archiving of some amount of run history information, such as begin-run time, end-run time, and number of events in the run
  15. a user interface that allows end run; and later, shutdown
  16. as shown on slide 13, the "run control" scripts/application should interact with the Cfg Mgmt system to get the list of available components, etc.
  17. I presume that the Process Manager that is mentioned in the slides will be John's DAQInterface plus pmt.rb
  18. The FHiCL Document Creator may need to be created or DAQInterface may fulfill that role