Project

General

Profile

Daqinterface subsystem instructions

Subystems, in the context of the artdaq ecosystem, can be described as a "feature of artdaq which allows different parts of detector data to be incorporated into the data stream at different times" (see the relevant section of the artdaq wiki, https://cdcvs.fnal.gov/redmine/projects/artdaq/wiki/Subsystems, for more). If you wish to take advantage of subsystems in your experiment's artdaq workflow, you'll need to provide information to DAQInterface assigning the artdaq processes to different subsystems and additionally describing how the subsystems depend on one another; this is accomplished by editing the file passed on the boot transition as well as the known boardreaders list.

Describing the relationship of the subsystems

A subsystem definition is done in the boot file, and looks something like the following:

Subsystem id: 2
Subsystem source: 1
Subsystem destination: 3

i.e., there are essentially three pieces of information to describe a subsystem: an integer id for the subsystem itself ("Subsystem id"), and then the integer id of the subsystem from which it receives fragments ("Subsystem source"), and the integer id of the subsystem to which it sends fragments ("Subsystem destination"). These last two are optional; if "Subsystem source" is left out, then DAQInterface will ensure the subsystem doesn't receive fragments from an upstream subsystem, and if "Subsystem destination" is left out, then DAQinterface will ensure the subsystem doesn't send fragments to a downstream subsystem. Note that technically speaking, one can think of a traditional DAQ which doesn't have different subsystems as consisting of one subsystem with no source and no destination subsystem; while this could be represented as just defining the single subsystem as
Subsystem id: 1

...for reasons of backwards compatibility and simplicity, this can be left out.

Be aware that while a subsystem can have multiple sources (also known as "parent subsystems") a subsystem can only have one destination (also known as a "child subsystem").

Assigning artdaq processes to the subsystems

In the boot file, one can add an optional line to a process description specifying what subsystem that process is part of. E.g., if we have an eventbuilder:

EventBuilder host: myhost.fnal.gov
EventBuilder label: EventBuilder17

then we can assign it to a subsystem by adding a line like the following:
EventBuilder host: myhost.fnal.gov
EventBuilder label: EventBuilder17
EventBuilder subsystem: 2

where in this example we've assigned the eventbuilder to subsystem 2. If a subsystem line is left out, then DAQInterface automatically assigns the process to subsystem 1; note that this is consistent with the convention that if you just want one subsystem for the entire DAQ, you're not required to add Subsystem id: 1 to your boot file.

Since information about boardreader processes, unlike other artdaq processes, is assigned in the known boardreaders list (i.e., the file referred to by $DAQINTERFACE_KNOWN_BOARDREADERS_LIST), to assign a boardreader to a subsystem you provide the subsystem id in the fourth column, e.g. like so:

component08 localhost -1 3

where here we're saying that component08 is part of subsystem 3.