Geant4 and a Generic XML Detector Description

The Atlas dtd, known as AGDD, addresses all the more difficult aspects of detector description which GLAST might need. It includes some features we probably don't need or might choose to implement in a somewhat different form, but the basic philosophy appears to be well-matched to our needs and to Geant4. I've made a somewhat stripped-down dtd and a sample xml file describing a possible ACD configuration to get a feel for how we might use AGDD or something like it.

Given such a dtd, how are the xml descriptions to be designed and written? What procedure and what utilities are needed for Geant4 to extract the information from acd.xml or other detector descriptions cast in this generic form? Ideally the utilities should not really be specific to Geant4, but handling the Geant4 case well probably will cast light on how other applications should process the xml.

Writing Generic Geometry in XML

Once the hierarchy of volumes is understood, writing the xml to describe a detector according to the ATLAS dtd is straightforward, though perhaps somewhat tedious if there is not much symmetry. On the other hand, if there is symmetry some intelligence is needed to capture it properly. I don't see any way to automate this process; however, since the number of designs we're likely to handle is small, we don't need to.

Parse

XML parsing can be done via two standard interfaces: SAX (Simple API for XML) or DOM (Document Object Model), both supported by our XML parser Xerces. To date we have been using the DOM model, which creates an in-memory representation of the entire XML document being parsed. Using DOM rather than SAX saves us a significant coding effort at the expense of memory. The format being proposed is considerably more compact that the format used by glast.prs because it is not a dump of detector objects so much as a prescription for how to create those objects. acd.xml is about one quarter the size of the correpsonding part of glast.prs. The new tower descriptions will be much shorter than the old, so even after adding in descriptions for structural components, solar panels, etc., the in-memory representation should be manageable.

Building the Detector

Assume the file has been parsed by a DOM parser so it is all available in memory. All or nearly all generic search and query utilities we might want to extract information from the in-memory representation already exist either as part of Xerces or in the GLAST xml package.

In the remainder of this note an xml element names and attribute names will be displayed as follows: box is an element and topVolume is an attribute.

Each section element is handled as a separate hierarchy, everything being located with respect to its topVolume. All sections may then be located with respect to a single global coordinate system. All instances in the xml file of elements describing simple solid shapes, such as box, composition-type elements such as composition, stackx, etc., and, if we need them, the booleans such as union indicate that a logical volume should be created with corresponding characteristics. Positioning elements such as posXYZ or axisPos signal that one or more physical volumes should be instantiated. The implementation will include a catalog of logical volumes in which the Geant4 logical volume objects will be associated with the name attribute appearing in the xml description. The application discovers and instantiates volumes within a section, starting with the top volume, as follows:

Simple solid

  1. Attempt to look up solid by name in the catalog. If found do nothing.
  2. Otherwise
    1. Create corresponding logical volume
    2. Catalog using its name attribute

Stack

Each stack has an envelope which will be instantiated as a logical volume. For GLAST stacks will typically be extremely simple with multiple identical components displaced along a single axis so the dimensions of the envelope can be readily computed. The overall strategy is then

  1. Instantiate envelope as a logical volume if this hasn't been done already. (Use the name attribute to look up or add the volume to the catalog.)
  2. For each component of the stack (consisting of specification of a volume and its positioning)
    1. If not already instantiated as a logical volume, do so.
    2. Use positioning information to instantiate a physical volume referring to the above logical volume, with mother volume equal to the envelope.

The actual process will be recursive since the components may themselves be stacks or other complex solids. Another complication, if envelopes for simple stacks are to be computed, is that the procedure may take two passes through the child volumes: one to find the dimensions of the envelope so it may be instantiated; another to create the logical and physical volumes for the components.

Composition

The only difference between composition and a simple stack is that there is in general no easy way to find an envelope, so it seems best to require that one be specified in the xml. This simplifies the processing, but opens up the possibility that the designated envelope does not truly contain all the components of the composition.

(Note: In order to simplify processing I've followed the rule that only simple solids like boxes may have a rotation, but the xml document type specification I'm using has no such restriction. It is up to the application to complain if it encounters a rotation of a non-simple solid which it will not handle; the parser has no way to know that it is unacceptable. A Geant4 application probably doesn't care.)

The Code

A modest body of code should be adequate to support this processing. In particular,

What's Missing

Each of the following requires some addition to the dtd and additional code to interpret it.

Ids: I've said almost nothing about names or ids. We need four potentially interdependent types:

  1. A way to identify each logical volume. This is the only sort of name mentioned above. We can use the name attribute of the corresponding simple solid, composition or stack element.
  2. A way to identify each physical volume known to the simulator
  3. A way to identify each volume with a separate read-out
  4. A way to identify parts of volumes (or perhaps unions of volumes) for energy accounting.

The read-out ids are just the things embodied in the new idents classes, so what's required is a way to extract from the xml the information needed to construct them. There appears to be some machinery in the ATLAS dtd which is applicable to this problem (and also to 1.); I'm not sure whether it's sufficient. A couple modest extensions to the ATLAS dtd could be used to handle energy accounting: add attributes or optional subelements to simple solids like box to define number of segments and direction of segmentation, and perhaps add a new grouping element, energyGroup, to describe a collection of solids which are to be lumped together for energy accounting. (Would it be sufficient to group logical volumes or do we need physical volumes? The latter seems more appropriate but could be awkward to implement.)

Bounded solids: The code handling the spacecraft makes a hexagonal solid by adding bounding planes. There is no way to describe this with the current dtd. (By the way, the planes composing the spacecraft appear to have no thickness. Don't the walls need to be simulated?)

Constants: The mechanism (general entities) used in acd.xml for naming constants is limited at best. It is not possible to do arithmetic or even indicate that it needs to be done with the current scheme. If the number of constants needed, typically for the dimensions of volumes or their location, becomes large, or if they are more naturally derived from a different set of constants and it is unacceptable to do the derivation somewhere else, then the xml format and the code interpreting it should be enriched accordingly. I haven't thought very hard about how much work this might entail. If all we need is the ability to do arithmetic it shouldn't be too bad.

Other information currently found in instrument.xml: The new mode of geometry description need not replace all functions of instrument.xml. Information such as thresholds or display colors can still be fetched from a much-reduced version of this file. Alternatively the catch-all parameter mechanism in the ATLAS dtd could probably be used; if so, it could be done at a later time.