Configuring the Shifter Interface¶

Setting up environment¶

The runconf_ui YAML files [stored in src/runconf_ui/configuration] are used for two purposes:

Configure the environment used by shifter-view
Tell shifter-view which parts of the configuration correspond to which bit of the detector

Environment setup¶

For now shifter view looks for a configuration YAML called /path/to/runconf_ui/src/configuration/${APPARATUS}_configuration.yml, for example, np02_configuration.yml. This can also be set using the --shifter-interface-config flag at start up.

The environment settings are stored in General. These are settable either as direct paths/variables OR if the interface finds a corresponding environment variable, that variable. In the below config you can see examples of both of these settings. One can also over-ride any of these settings using the CLI at startup.

General:
  # Environment variables

  # Default .data.xml configuration file
  default_config: "SESSION_FILE"
  # Default download directory for DAQ configuration files OR local directory containing configurations
  download_directory: "CONFIG_DIR"
  # Name of TMUX session
  session_name: "SESSION_NAME"

  ## CONFIGURATION MANAGER  SETTINGS

  # Grabs git branch "default_daq_version/default_daq_config"

  # Default DAQ version 
  default_daq_version: "EHN1_DEFAULT_VERSION"
  # Default DAQ configuration file 
  default_daq_config: "EHN1_DEFAULT_CONFIG"

  # URL containing git repos
  base_url: "https://gitlab.cern.ch/dune-daq/online/ehn1-daqconfigs"
  # URL containing git repos for the operation configuration
  operation_url: "https://gitlab.cern.ch/dune-daq/online/np02-configs-operation.git"

Detector Setup¶

The DUNE-DAQ configuration framework does not currently have a natural way of grouping detector components. In order to tell the interface which elements we want to display we need to set these manually. In the language of runconf_ui these grouped into Panels, so called because they generate "panels" in the TUI.

General Panel Attributes¶

The first things that need to be setup in panels are the general settings

Panel: 
    label: "Internal label given to this panel. This must be unique"
    panel_type: We split panels into multisystem and singlesystem. These are detailed below.

Single System Panels¶

Let's look at an example. First let's consider the simplest panel, a single-system panel. These are panels consisting of ALL objects of a single class in the configuration.

  # Dataflow
  Dataflow:
    label: "dataflow"
    panel_type: "singlesystem"
    classes:
      - "DFApplication"

Here is the detector setup for NP02 dataflow applications. This will just list all objects of the class DFApplication. classes is simply a list of all classes we want here and can be extended arbitrarily. This kind of panel view does not generate a schematic map.

Multi-system panels¶

Multi-system panels are used when you have some part of the detector which is not simply defined by a single object in the configuration. For example, the tpg in NP02 is defined several complicated sub-components. In order to handle this we use multi-system panels. An example of thsi can be seen in the trigger for NP02

  Trigger:
    label: "trigger"
    view_panel: "Trigger View"
    panel_type: "multisystem"

    Systems:
      - TPC TPG:
          attributes:
              - id: tp_generation_enabled
                segments: ["tpc-segment", "crp4-segment", "crp5-segment"]
                class: ReadoutApplication

              - id: ta_generation_enabled
                segments: ["tpc-segment", "crp4-segment", "crp5-segment"]
                class: ReadoutApplication

          components:
            - id: tc-maker-tpc
              class: TriggerApplication
            - id: tp-stream-writer
              class: TPStreamWriterApplication

      - PDS TPG:
          attributes:
              - id: tp_generation_enabled
                segments: ["pds-segment"]
                class: ReadoutApplication

              - id: ta_generation_enabled
                segments: ["pds-segment"]
                class: ReadoutApplication

Firstly we have the name of the panel in the TUI, in this case Detector. Firstly we need to specify view_panel, this is the label given to the schematic view generated by this system. All multi-system panels generate schematic views in order to visualise what we mean when we say "this system is switched off". Next we list each system in this panel, these are seen in the TUI as individual on/off buttons, in this case the TPCs for TPG and PDS. Finally we split our systems into attributes and components.

Components correspond to large-scale elements of the DAQ, for example ReadoutApplications and Segments. In OKS these have a specific definition of disabled/enabled. Attributes, meanwhile, are values of elements within the configuration. For example every ReadoutApplication has a tp_generation_enabled attribute which can be enabled/disabled.

Components¶

Firstly let's look more closely at the settings for components

# Required settings
- id: Compoent Name
  class: Class of the component in the configuration
# We also have some optional settings
  seperate_system: Does this component also correspond to an additional subsystem 
  system_label: Label of this subsystem

One can see this more obviously if we look at the TPC

- TPC:
  subsystem_dependent: True

    components:
    - id: tpc-segment
        class: Segment
    - id: crp4-segment
        class: Segment
        system_label: CRP4
        separate_system: True

    - id: crp5-segment
        class: Segment
        system_label: CRP5
        separate_system: True

This will generate the following buttons:

TPC: This will enable/disable all the components in the configuration
CRP4: This will just turn off all components [and attributes] labelled CRP4
CRP5: This will just turn off all components [and attributes] labelled CRP5

Since we've set the subsystem_dependent flag to true, the entire system (tpc-segment) is set to be disabled if the two sub-systems in it (CRP5, CRP4) are disabled.

Attributes¶

Settings for attributes slightly more complex than components. Let's consider the attributes of the TPC TPG

      - TPC TPG:
          attributes:
              - id: tp_generation_enabled
                segments: ["tpc-segment", "crp4-segment", "crp5-segment"]
                class: ReadoutApplication

              - id: ta_generation_enabled
                segments: ["tpc-segment", "crp4-segment", "crp5-segment"]
                class: ReadoutApplication

You can see that these correspond to the following

id: The name of the attribute
class: The class of objects with this attributes we want to find
segments: In which segments should we search for objects with this attribute. If this is not specified it assumes it corresponds to ALL objects of this class in the configuration.

As with components one can also specify system_label and separate_system to make additional buttons in the configuration.

Last git commit to the markdown source of this page:

Author: Henry Wallace

Date: Fri Apr 11 12:13:03 2025 +0100

If you see a problem with the documentation on this page, please file an Issue at https://github.com/DUNE-DAQ/runconf-ui/issues