Project

General

Profile

Requirements for artdaq Demo

In the following, the words "should," "must," and "will" are interchangeable.
The demo will be used by both people/experiments who wish to learn/evaluate artdaq and by the artdaq development team to test various configurations and do general development. The latter may/will necessitate advanced options and commands.

  1. "The demo" (a series of a small number of commands) should be "turn key". The current list of commands and arguments (from the main artdaq Demo wiki, reproduced here) meets the definition of "turn key," but is not exclusive.
  2. The demo installation should be contained with a single directory structure (i.e. be "rooted" at a particular directory). This is referred to as a "demo installation."
    1. When running the demo, temporary files may be created in /tmp, but must not conflict with other instances of a demo run, in whole or part, on that system.
  3. Once a demo installation has been establish, a user will be able to log out and back in and re-establish a "demo build" or "demo mrb" environment" from which he/she can rebuild the demo software.
  4. It should be assumed that the demo installation may be establish on an NFS file system and therefore, the same installation should be runnable from multiple nodes, where the ups environment may be not be exactly the same, but will be equivalent.
  5. Given different partitions, multiple users (or even the same user) should be able to run demo instances (different or the same with proper permissions) on the same set (or overlapping set) of nodes.
  6. The run_demo.sh script should control its environment -- it should be able to determine the demo instance in which it is installed.
  7. The run_demo.sh environment control should allow running a version of the database utility which has dependencies which would otherwise conflict with artdaq dependencies.
  8. The run_demo.sh environment control should allow running a version of the an online monitoring art module which has dependencies which would otherwise conflict with artdaq dependencies. (KAB: this implies an artdaq enhancement, so we should discuss it.)
  9. The demo should support selecting from one of many configurations (currently simple_test_configs).
  10. When using the database utilities, if a configuration is specified which is not in the database, but is a simple_test-config, the configuration should be automatically imported.
  11. 'mrb install' should be the default model for building the demo software, and the use of the built UPS products in the localProducts area should be the default model for running the demo. This implies the existence of two setup scripts, one for building and one for running.
  12. The installation script should make use of previously-installed copies of needed UPS products, by default, but users should be able to over-ride this choice.
  13. We should have the ability to specify the list of artdaq packages that are installed in the MRB srcs area.
  14. The file system database should be the default.
Question: is it reasonable to expect that the running of two simultaneous demo partitions from the same account would work? Sample commands here:
  • in one shell window:
    • "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 --no_om --runduration 400"
  • in a second shell window (soon after starting the command in the first window):
    • "sh ./run_demo.sh --config mediumsystem_with_routing_master --bootfile `pwd`/artdaq-utilities-daqinterface/simple_test_config/mediumsystem_with_routing_master/boot2.txt --comps component01 component02 component03 component04 component05 component06 component07 component08 component09 component10 --no_om --runduration 40 --partition=3"

Testing

  • establish on mu2edaq01, run on mu2edaq<other_than_01>