You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/configuration.org
+35-11Lines changed: 35 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,42 +6,66 @@ The GGD system is layered and allows the user/programmer access to each layer.
6
6
7
7
* Configuration File Syntax
8
8
9
-
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 which hold a number of key/value pairs.
9
+
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.
10
10
11
11
#+BEGIN_EXAMPLE
12
-
[section name]
12
+
[name]
13
13
key1 = value1
14
14
#+END_EXAMPLE
15
15
16
16
** Syntax Extensions
17
17
18
-
The GGD configuration layer will evaluate each section of key/value pairs in a limited Python environment. This allows any given value to reference a key from the same section in order to use its value. It also allows expression of complex data structures, units, arithmetic. In principle this allows a high degree of programming and a balance should be struck. In order to keep the configuration simple, complex programming should be put into the builder.
18
+
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 [[./builders.org][builder]] code.
19
+
20
+
*** Evaluation
21
+
22
+
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:
23
+
24
+
#+BEGIN_EXAMPLE
25
+
[mybuilder]
26
+
x = 21
27
+
y = x*2
28
+
#+END_EXAMPLE
29
+
30
+
results in =y= being 42. Referencing a variable before it is defined is an error.
19
31
20
32
*** Specifying units
21
33
22
-
All numerical quantities that have units must have them explicitly given in the configuration. This is done with the =Q()= function ("Q" for "quantity").
34
+
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 [[http://pint.readthedocs.org/en/0.5.1/tutorial.html][=pint.UnitRegistry.Quantity=]] method and as such can be "called" in the configuration file in any manner it could be called directly from Python.
23
35
24
36
#+BEGIN_EXAMPLE
25
-
[builder mydetector]
37
+
[mybuilder]
26
38
width = Q("10m")
27
-
height = 10*width
28
-
depth = 10*height
39
+
height = Q(10, 'meter')
40
+
depth = Q("10*m")
29
41
#+END_EXAMPLE
30
42
43
+
*** Data structures
31
44
45
+
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:
32
46
33
-
The content of the configuration file is parsed into a Python data structure by GGD and then interpreted following these conventions.
47
+
#+BEGIN_EXAMPLE
48
+
[mybuilder]
49
+
offset = [Q("1m"), Q("2m"), Q("3m")]
50
+
#+END_EXAMPLE
51
+
52
+
* Interpretation
53
+
54
+
After the configuration data is parsed and evaluated as above it is interpreted by GGD.
34
55
35
56
** Builder sections
36
57
37
-
Sections starting with "=[builder NAME]=" are interpreted as being for a builder. Any key/value pairs given will be passed to the builder named "=NAME=" if it is created. Certain keys are reserved by GGD:
58
+
Each configuration section corresponds to a single instance of a builder object (see [[./builders.org][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.
59
+
60
+
Certain keys are reserved by GGD for interpretation:
38
61
39
62
- =class= :: The fully qualified class name (eg "=module.submodule.MyBuilderClass=").
40
-
- =subbuilders= :: A space or comma separated list of builder names to be given to the builder as sub-builders.
63
+
- =subbuilders= :: A list of builder instance names to be given to the builder as sub-builders.
41
64
42
65
Beyond these reserved keys each builder is free to expect its own set of keys.
43
66
44
-
** Example
67
+
68
+
* Examples
45
69
46
70
A working example is in the source at [[../python/gegede/examples/lar.cfg][lar.cfg]].
0 commit comments