Skip to content

Configuration files

Alp edited this page May 19, 2022 · 2 revisions

Configuration files

The construction goal for this framework is to separate as far as possible the analysis logic from any specific parameter values. The dynaconf package is used to provide configurations that can easily be loaded, edited, split by data taking conditions, etc.

Configuration parameters are stored in a single config file like monojet.yaml. The file has a default section, where general parameters can be configured for all years (e.g. if the same jet pt cut is applied for all years you want to look at). To accommodate year-dependent choices (e.g. b tag working points, trigger choices, etc), there are additional configuration sections era2016, era2017, etc, which overwrite the parameter values in the default section. Each of the sections defines an environment. When the each processor is given input data, it should decide which environment to use based on the input dataset. The logic is pretty simple: If the dataset is from 2016, use 2016 settings. If it's from 2017, use 2017 settings. And so forth. This is implemented e.g. here.

Parameter access

It's easiest to understand how to use the configuration from a simple example. Let's say our configuration file has this part in it:

era2016:
  selection:
    signal:
      recoil: 250    # min

The logic here is that all cuts for event selection go under the "selection" header. Cuts for the signal selection go under "signal", and the cut on the recoil variable is 250 GeV. We could also specify minimal and maximal cuts with a further nested layer, but this suffices for now.

To read this configuration in python, we do something along the lines of:

print(cfg.SELECTION.SIGNAL.RECOIL)
# --> 250

The parameters are trivially accessed by using the configuration dictionary keys as attributed to the configuration object. They are given in all caps in order to visually separate them from "normal" python code.