The detector is built up by defining fundamental solids (boxes of some material or other), locating them in other (envelope) boxes or stacking them, which is just another way of locating them with respect to an implied envelope, then locating these composite volumes until the full detector is built up. Note that the "same" volume may be located many times, which in effect makes copies of it.
Each time a volume (simple solid or composite) is located with respect to another volume one has the opportunity to assign one or more identifier fields, aka idFields, to the located volume. The information associated with the located volume consists of a field name (such as towerPart or tray) and a value. Values are always non-negative integers, though they may have aliases (e.g., tracker might translate to 2). If the idFields are assigned properly, one can form a unique GDD identifier for a particular (located) volume by concatenating the idFields belonging to the volume and all its ancestors in order (some extra bookkeeping is needed to figure out the correct order in case more than one idField is assigned in a single positioning step, but I'll ignore that for now).
The alias-name..value correspondence can be handled by the same facility used for other constants. Only certain sequences of idFields will correspond to actual nesting of volumes. Within such a sequence, the value for a particular idField will typically be constrained to a set of allowed values (what is allowed may depend on the sequence of idFields preceding it).
The constraints described above are expressed in a new part of the XML file called the id dictionary. A complete XML source file describing an instrument now has a coarse structure like this:
Constants
Primary
.. many individual definitions
Derived
.. many individual definitions
Id dictionary
.. many definitions of id fields (names + constraints on values)
.. many definitions of allowable sequences, perhaps including
additional context-dependent constraints on values
Sections (geometry definition proper)
.. many definitions of fundamental solids
.. many compositions of solids
The GDD classes extract information from the XML file, save it in memory, and make it available to client applications. This has been done already for the Constants and Sections parts of the file. In order to complete the design of the XML representation for the Identifier Dictionary, and of the GDD classes which will serve the information in it, we need to know better what the uses of this information will be. Candidates include but are not limited to
What else?
There are at least 3 kinds:
Services are needed to convert from one form to another where appropriate. For example, any Simulator client will need to convert from GDD identifiers to volume ids. Clients reading the hit and digi output may want to obtain more information about the associated volumes, which would require conversions in the opposite direction. Note that the integrating hits can take place in volumes which are usually treated as passive by simulators, leading to an unusually large and arbitrary collection of volumes whose volume ids must be meaningful to several client programs.
Numbering conventions laid out in Steve Ritz's memo should never be contradicted (e.g., never start numbering with an integer other than zero) by any of the kinds of identifiers, and should be strictly followed wherever feasible. However, it might not be possible, especially in the case of GDD identifiers, which are constrained by the somewhat arbitrary way complex volumes are assembled, to be completely in accord with the memo. For example, in GDD identifiers tower "number" must be expressed as two numbers: row and column.