Parameter containers

The parameters are stored in parameter containers which are accessible in the runtime database via their names. To avoid unnecessary initialization and storage, the design of these containers should consider the following aspects:

• The containers should not hold parameters which are fixed, together with parameters which change very often (maybe from run to run).
• Parameters needed by several tasks should be stored separately from the parameters used only by one task.
• To guarantee data consistency, the reading of redundant information into two different containers is not allowed. Only one container should be initialized via reading, the other one (or the redundant part) by copying. (Otherwise only Data Base would guarantee data consistency.)

All container classes are derived from a common base class FairParSet.They are instantiated in the program in the SetParTask() functions of the tasks (not in the constructors!) and added to the list of containers in the runtime database. However, it is also possible to create a container explicitely in a macro, to initialize it and to add it to the list. This feature can be used, when a container should be initialized from a special input and not automatically from one of the inputs defined in the runtime database.
Parameters used privately in a task and calculated completely from other parameters should not be added to the list of parameter containers in the runtime database. Instead, their init() function should be called explicitly in the reinit() function of the task (called automatically after the initialization of all containers for each run).
Each container has overloaded init() and write() functions for the parameter I/O, functions to support the version management, to clear the data and to print information.