src.commonalities.ConfigHandler module

This module is responsible for handling the user configurations.

It includes one class ConfigHandler. See details in its own documentation and in the overall documentation in the doc folder.

This module is generally independent of the selected config file format, since it uses dictionaries as inputs after loading the config files. We currently use json files, since they are the outcome of json form generators.

The config handler contains the validation of the user config to prevent wrong inputs and to make the code robust. However, since this software is created for scientific phd research and not a series product, there are definitely options for the user to break the dependencies. Since the config validations are centralized within this config handler and called at the start of the main script, we do not repeat all the checks within the individual code modules. Instead, we only add the required checks so that the software control structures work, and a few additional checks for safety reasons.

Contact person: Stefan Riedmaier Creation date: 29.05.2020 Python version: 3.8

class src.commonalities.ConfigHandler.ConfigHandler(config)

Bases: object

This class handles the software configuration.

It includes a main method called “process”. See details in its own documentation.

extend()

This function extends the user configuration.

Typical use cases are: - Converting to new data types. Sometimes one data type is preferred for the user to input the config, while another data type is preferred at specific code snippets to process the config. This is mostly the case for arrays here. - Deriving new keys, such as the number of parameters. - Setting values that should not be configurable by the user at the moment.

It makes sense to only perform these extensions once and not everywhere in the code where they are processed.

There are two major design choices: 1) In-place dict extension versus copying and extending a new dict. 2) Decentral config handling in each framework block instance versus central config handling for all sections.

The copy-solution has the disadvantage that not only the extensions have to be coded but also the copy keys have to be routed through. This makes the code more cumbersome. Thus, we use the in-place solution here.

The decentral solution has the advantage that we can create dedicated config dicts for each block. However, this does not work well in case of correlations. There are cases where one block needs configs from another block possibly even earlier in the vvuq process. This causes semantically wrong assignments from the config sections to the block instances and/or code duplicates. In addition, the decentral solution leads to redundant executions of specific config extensions in case they are the same for all domains, e.g., assessment. Thus, we go for the central solution.

The latter means we have to imitate the config structure within this function here instead of it being given automatically by the block instances.

We do not perform all config extensions within this single function here. Instead we outsource the extension of large config sections into separate internal functions.

full_domain_list = ['verification', 'validation', 'application']

get_property(property_name)

This function returns the value to a respective config key.

Parameters:

property_name – name of a config key / property

Returns:

config value of that key

instance_list = ['experiment', 'simulator']

major_domain_list = ['validation', 'application']

process()

This function runs through several steps to handle the user configuration.

The steps include: 1) a validation of the config against a schema definition, 2) an extension of the config to adapt it towards the code, and 3) additional validations that go beyond the schema.

The second step is added to convert from a config targeted to the user to a config targeted to the code. Otherwise, either the user actions or specific code sections would sometimes be cumbersome.

The third step is necessary to cover specific limitations of the schema definition by means of python code.

Returns:

validate()

This function performs validations of the config that go beyond the schema.

validate_schema()

This function validates the config file against the schema file.