Using XML Generic Detector Description

How are the xml descriptions designed and written? What procedure and what utilities are needed for a program to extract the information from acd.xml or other detector descriptions cast in this generic form?

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

In what follows I will be assuming the client program is a simulator or other application wanting to know about all volumes. Other programs such as Reconstruction might choose to ignore some volumes but would otherwise follow a similar procedure.

The application discovers volumes by starting at the top of the hierarchy and traversing a tree. In the case of acd.xml the root is the volume named acdEnvelope, which can be found by looking at the topVolume attribute of the section element. The application would follow the same procedure for each section.

Procedure Unrolled

Once the root volume is found, processing for gismo would consist of traversing the entire tree (note this tree may have many more nodes than the DOM tree since the latter typically has only one instance of volumes to be replicated for the simulation), accumulating positioning information along the current path. When a leaf node (in our case, always a box) is encountered, it is instantiated as an object of the appropriate simulator class and the accumulated positioning information is applied. In particular, for acd.xml the procedure would start like this:

Find top volume, acdEnvelope.
This volume is a composition, so process each of its components in turn.
The first is a reference to the volume EWside with a displacement. Save the displacement (e.g., in a stack) and look up the EWside volume.
EWside is also a composition. Its first component is row1 and it has a displacement. Save the displacement and look up row1.
row1 is again a composition. Its first component is box1 and it has a rotation in addition to a displacement. Save them both and look up box1
box1 is actually a box, that is, a simple solid which may be instantiated directly. Instantiate it, applying the rotation and accumulation of translations. (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 a rotation of a non-simple solid is requested; the parser has no way to know that it is unacceptable.) I believe handling for gismo and GEANT4 diverge somewhat here. For GEANT4 several physical volumes may refer to the same logical volume. In acd.xml the only distinct logical volumes are the boxes. During the processing one needs an auxiliary hash table or other structure to keep track of logical volumes which already exist so that extra copies are not instantiated unnecessarily.
Pop the rotation/translation information associated with the solid whose processing was just completed off the stack.
Move on to the next component of row1 and process similarly
When all components of row1 have been processed, pop its translation information off the stack and begin processing of the next component of its parent EWSide, namely row2 with a displacement
...and so forth

The Code

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

Something to process a section: find its topVolume and invoke the proper solid-handling code.
Something to maintain the stack of translations and rotations.
Something to handle composition elements; perhaps also stackx and so forth. It needs to communicate with the translation/rotation handler and step through processing of its own subcomponents.
Something for each fundamental solid element type (e.g., box) which might occur in the xml file.

What's Missing

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

A way to identify each physical volume known to the simulator
A way to identify each volume with a separate read-out
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. An extension to the ATLAS dtd, probably a rather simple one, will be needed for energy accounting.

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.