The boot file reference¶
To return to the main DAQInterface wiki, click on Daqinterface instructions
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 PMT host: localhost # 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. 1 is standard, 4 is the highest. 0 not recommended.
<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.fclwhose contents it will send to the DataLogger. Not shown in the above boot file example is a RoutingMaster process; note that if you add one, you can add only one, otherwise DAQInterface will throw an exception.
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
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 portSimilar 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
request_port: Similar to
request_address, but the port, rather than the address, which is used for EventBuilders to send requests to BoardReaders. Unlike
request_address, there's no default override.
table_update_address: Similar to
request_address, except that (A) it concerns use of the RoutingMaster, and (B) it has a default override value of 227.129.<partition number>.129
routing_base_port: Used to override the
routing_token_port(note the different name) parameter found in FHiCL documents, also related to routing. Note that if this override is used, then the other routing-related FHiCL parameters
table_acknowledge_portget automatically overridden with values 10 and 20 greater than
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.
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 https://cdcvs.fnal.gov/redmine/projects/artdaq/wiki/Subsystems - click here.