Athena Configuration

Last update: 02 Feb 2023 [History] [Edit]

Introduction

This guide describes Athena configuration system that is intended to be used for Run 3 and later. It is also known as ComponentAccumulator based configuration or New Job Options.

The configuration system of Athena allows us to assemble and customize components (algorithms, services and tools) for a workflow. It is done by creation and manipulation of python objects. Result of the configuration process is a set of settings that are used by Athena to instantiate and appropriately configure C++ components. Even in a small workflow the number of settings can easily be a few hundreds and in a complete reconstruction or HLT setup the number of settings reaches tens of thousands. Such a set of information needs to be properly managed.

The Athena configuration system

In broad terms the configuration system works as follows.

  1. Each C++ component defines a set of configurable parameters (*),
    • There is rich, yet restricted set of types of configurable parameters that are supported,
    • Typically reasonable default values are defined as well.
  2. During compilation a database entry is made containing information about these properties.
  3. During the configuration this database is queried for information about a component and as a result python class is generated with class attributes corresponding to the properties defined in C++.
  4. Set of python script creates python objects and manipulates them (set properties). (*)
  5. Resulting set of python objects produce a serialized/textual representation of the configuration.
  6. The configuration is read in C++ program and populates the global dictionary with all settings.
  7. C++ components during the initialization fetch the values and set configurable parameters (see 1st point) accordingly.

The steps marked with (*) are places where developer intervention is needed. That is to define configurable parameters and to prepare scripts setting them. Other steps are automatized.

The python infrastructure for the new configuration system lives in the package Control/AthenaConfiguration

In comparison to the Run 1-2 configuration system the procedure is technically different in some steps. However the only non-technical change concerned step 4.

Naming and other conventions

For consistency, and to make a clear distinction between the existing configuration files and this new system the following naming convention is used.

  • name of the file containing new configuration code should end with Config.py (e.g. CscOverlayConfig.py)
  • name of the function generating the configuration fragments (ComponentAccumulator instance) should normally start with the name of the component they configure and must end with Cfg and as a first argument that they take must be flags container (see above link)
  • Configuration functions should always accept an instance of configuration flags as first argument (even if they don’t actually rely on flags)
  • Configuration functions should always return an instance of ComponentAccumulator (event if they configure just one private AlgTool)