Configuration system for GGD
The GGD system is layered and allows the user/programmer access to each layer. The top-most layer is one that provides a human-oriented configuration mechanism. Configuration takes the form of a simple text file. It is parsed into a data structure and then interpreted by GGD. The interpretation makes some assumptions about conventions that the author of the configuration file must follow. This interpretation results in creation of the builders which make up the lower GGD layer. This layer then performs geometry object construction and these objects are used for exporting the information to some target form.
The GGD configuration file syntax is parsed by Python’s configparser module. This syntax is also sometimes known as “INI”. It consists of a number of named sections each holding a number of key/value pairs.
[name] key1 = value1
The GGD configuration layer will process the file in a series of steps that add some features beyond the basic syntax. Care should be exercised in exploiting these features. If the configuration becomes complex consider if it would be better to move this complexity into the builder code.
The values in the parsed configuration file are evaluated by the Python interpreter in order. Within one section, prior keys may be referenced in subsequent values. For example:
[mybuilder] x = 21 y = x*2
results in y being 42. Referencing a variable before it is defined is an error.
All numerical quantities that have units must have them explicitly given in the configuration. If not, they will be caught as an error during geometry generation. Units are specified with the Q() function (“Q” is for “quantity”). This is an abbreviation for the =pint.UnitRegistry.Quantity= method and as such can be “called” in the configuration file in any manner it could be called directly from Python.
[mybuilder]
width = Q("10m")
height = Q(10, 'meter')
depth = Q("10*m")
Because values are evaluated by the Python interpreter the configuration values may take the form of any valid Python data structure. One particularly useful one is a list to give a vector of values. For example:
[mybuilder]
offset = [Q("1m"), Q("2m"), Q("3m")]
After the configuration data is parsed and evaluated as above it is interpreted by GGD.
Each configuration section corresponds to a single instance of a builder object (see Builders) of the same name. Any key/value pairs given will be passed to the builder for that name, if it is created. Builder creation starts at a given builder section or the first section if none is given.
Certain keys are reserved by GGD for interpretation:
class- The fully qualified class name (eg ”
module.submodule.MyBuilderClass”). subbuilders- A list of builder instance names to be given to the builder as sub-builders.
Beyond these reserved keys each builder is free to expect its own set of keys.
A working example is in the source at lar.cfg.