The boot file reference

To return to the main DAQInterface wiki, click here

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 commented-out lines:

DAQ setup script: name_of_DAQ_setup_script_not_yet_defined

PMT host: localhost
PMT port: 5400

partition_number: 0

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

EventBuilder host: localhost
EventBuilder port: 5235
EventBuilder label: EventBuilder1

EventBuilder host: localhost
EventBuilder port: 5236
EventBuilder label: EventBuilder2

DataLogger host: localhost
DataLogger port: 5265
DataLogger label: DataLogger1

Dispatcher host: localhost
Dispatcher port: 5269
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. It's a good idea to test this script, first by cd'ing into the script's directory, sourcing the script, and then trying to run pmt.rb - DAQInterface relies on this script to work if it's to launch processes.
  • PMT host/port: The host and port of artdaq's Process Management Tool, in charge of the individual artdaq processes
  • debug level: A verbosity level for DAQInterface- the higher, the more info gets sent to screen. 1 is standard, 3 is the highest. 0 not recommended.
  • <proctype> host/port/label: On three lines, the host and port of an instance of the named artdaq process, as well as the stub of the name of the FHiCL document which will sent to that process during the configure transition. Each triplet 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, listen for commands on port 5265, 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.

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:

  • partition_number: This simply tells DAQInterface to take all FHiCL parameters named partition_number it finds in the FHiCL documents from the config it's given, and override their values with the value given in the boot file. This is useful if people want to implement different logic in a fragment generator depending which partition number it's being run in.
  • request_address: The value of request_address is used to override the parameters 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 and use the same configuration in two partitions, the same request_address will be used in both partitions, creating a collision.
  • request_port: Similar to request_address, but the port, rather than the address, which is used for EventBuilders to send requests to BoardReaders.
  • tcp_base_port: Defaulting to 6300 if not set, this is the base port relative to which the TCP port numbers used for interprocess communication are set. For two simultaneously running DAQs, you'd want a large separation (probably at least 1000) to accommodate all the TCP ports - so if you know someone else is using the default, you might want to set this to 7300.
  • routing_base_port: This port, as well as ports 10 and 20 above it - e.g., 13700, 13710 and 13720 - are used in the event that a RoutingMaster artdaq process is included in the DAQ workflow.
  • table_update_address : This address is also used when a RoutingMaster process is included.
  • 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.