The goal is to come up with a sufficiently compact and self-contained xml detector description that multiple programs may just parse the xml, as opposed to current paradigm where glastsim takes a small number of parameters specified in instrument.xml plus a lot of internal information about which components to expect and how they fit together, then can dump a very explicit detector description (glast.prs) for use by reconstruction.
What's missing from instrument.xml is
On the other hand, the information in glast.prs could be expressed much more compactly. For example, scintillator volumes really come in only 12 shapes (i.e., varieties of box). One could describe the 12 shapes, then refer to them as needed, rather than repeating dimensions over and over. Also, multiple instances of collections of 5 scintillators appear in the same configuration except for a translation. One could refer to a standard configuration plus a translation vector rather than repeating the configuration specification. However, these compact expressions no longer mention each volume, so cannot explicitly include an id as is done in glast.prs. Hence the need for a compact way to describe the algorithm for generating the ids.
What is considered to be an atomic piece of the detector depends on context. For hit simulation program, the smallest interesting piece is a volume whose boundaries must be acknowledged as particles propagate. For energy accounting, one may want to segment the simulation volumes or combine them, or some of each. For readout, the interesting pieces are those objects which can produce a digitized value. They can be conincident with simulation volumes or might come from segmenting simulation volumes.
Energy accounting volumes and readout volumes must each have a unique id which can be associated with the correct volume by both Simulation (where here is meant not just the generation of hits but also energy accounting and digitization) and Reconstruction/Analysis since the first writes data associated with these ids and the second reads it.
For simulation volumes we need primitives to describe standard solids and also ways to combine them and locate them. The Atlas Collaboration has a DTD (Document Type Description, a way to describe a collection of XML tags) which addresses all these requirements and is very well documented. The overall design is excellent; I would consider making minor changes here and there.
We still need a mechanism for describing the generation of ids for all classes of "pieces" mentioned above. If not the algorithm itself, then at least its paramterization should be representable as part of the XML file describing the detector. Among other requirements on these ids, at least the ones pertaining to energy accounting and readout, is Eric's request that all such ids be unique over time, so that a new readout configuration is accompanied by a new wholly disjoint set of ids. I see no practical way to implement this other than to allow specification of an offset to be added to all generated ids. The offset is essentially a version number for the configuration.
Joanne Bogart
4 December 2000