The boot file reference

To return to the main DAQInterface wiki, click on Artdaq-daqinterface

As you've already seen, whenever you send the boot transition to DAQInterface, you provide as an argument the name of an ASCII file which contains various parameters. The most important of these parameters is the name of the script DAQInterface will source before attempting to launch artdaq processes but there are other parameters which will also be described here. Look at the boot.txt file from before when we made our edits (less $ARTDAQ_DAQINTERFACE_DIR/docs/boot.txt); note that here I've left out most commented-out lines:

DAQ setup script: name_of_DAQ_setup_script_not_yet_defined

# debug level can range from 0 to 3 (increasing order of verbosity)
debug level: 1

EventBuilder host: localhost
EventBuilder label: EventBuilder1

EventBuilder host: localhost
EventBuilder label: EventBuilder2

DataLogger host: localhost
DataLogger label: DataLogger1

Dispatcher host: localhost
Dispatcher label: Dispatcher1

These parameters mean the following:

  • DAQ setup script: The fully-qualified name of a script which, when sourced, will allow DAQInterface to use the pmt.rb command found in artdaq_mpich_plugin to launch artdaq processes (if $DAQINTERFACE_PROCESS_MANAGEMENT_METHOD is set as "pmt") or will allow DAQInterface to directly launch the artdaq processes (if $DAQINTERFACE_PROCESS_MANAGEMENT_METHOD is set as "direct").
  • PMT host: If $DAQINTERFACE_PROCESS_MANAGEMENT_METHOD is set as "pmt", this defines the host of artdaq-mpich-plugin's Process Management Tool, in charge of the individual artdaq processes. Note that this should not be changed to anything different than "localhost". If $DAQINTERFACE_PROCESS_MANAGEMENT_METHOD is set as "direct", this parameter is meaningless and gets ignored.
  • debug level: A verbosity level for DAQInterface- the higher, the more info gets sent to screen. Values from 1 to 3 should be chosen, where level 1 corresponds to standard output, level 2 provides output useful for experiments to perform debugging, and level 3 provides output useful for DAQInterface developers.
  • <proctype> host/label: On two lines, the host of an instance of the named artdaq process, as well as the stub ("label") of the name of the FHiCL document which will sent to that process during the configure transition. Each pair of lines defines a new process - e.g., in the example above, we've specified two EventBuilders, a DataLogger and a Dispatcher. In the case of the DataLogger, e.g., it will run on the same host as DAQInterface, and during the configure transition, DAQInterface will look in the named configuration (e.g., "demo") for a FHiCL file called DataLogger1.fcl whose contents it will send to the DataLogger. Not shown in the above boot file example is a RoutingMaster process.

There are also optional parameters which can be set; most of these are designed to make it easy to partition a DAQ, i.e., run two independent DAQInterface sessions simultaneously, without causing port collisions, etc:

  • EventBuilder portand also DataLogger port and Dispatcher port. Basically, DAQInterface will assign the XML-RPC ports that artdaq processes listen for commands on, determining their values as a function of the partition its on. However, one can override these defaults by adding a line describing the desired port, e.g.
    EventBuilder host: localhost
    EventBuilder label: EventBuilder1
    EventBuilder port: 9999
  • PMT port Similar to the artdaq process ports, but for the Process Management Tool. Again, only meaningful if we have $DAQINTERFACE_PROCESS_MANAGEMENT_METHOD set to "pmt"
  • request_address: DAQInterface overrides the parameter of the same name found in FHiCL documents. You'd find this parameter in FHiCL documents written to configure BoardReaders to run in window request mode; it's the address used for EventBuilders to send the requests up to BoardReaders. If you don't set this parameter then DAQInterface will default override the parameter with the value 227.128.<partition number>.129
  • disable recovery: If set to true, then if some failure occurs (e.g., a fragment generator throwing an exception, or a process dying), then DAQInterface will not attempt to stop the processes, or kill them - it will leave things as untouched as possible. The advantage of this is that it's easier to debug an issue if all processes aren't killed off; the disadvantage is that you'll need to manually kill them off later on.
  • manage processes: Defaulting to true, if set to false, DAQInterface will not launch the artdaq processes with pmt.rb, nor will it send them transitions - this is left up to the experiment to do. Note that the decision to set this to false should NOT be taken lightly, as many of the features of DAQInterface (e.g., the ability for it to determine where the logfiles are, saving them in the metadata, printing the warnings it finds in them, etc.) will be lost.

Another feature of the boot file is that if you add an arbitrary FHiCL "key: value" pair on a line, it will override that value in the FHiCL documents during the configuration transition. For example, if you add a line like:

experiment_specific_register: 0xffffaaaa

...then anywhere in the FHiCL documents the "experiment_specific_register" FHiCL parameter is found, whatever value it was set to will be overwritten with 0xffffaaaa

Finally, if you wish to use different subsystems in your DAQ - described essentially as a "feature of artdaq which allows different parts of detector data to be incorporated into the data stream at different times" on the artdaq wiki at - click here.