The New Geometry, Concept and Status

Concept

The single core idea is that all aspects of detector description be embodied in data, not code. XML was chosen as the source format for this data. This choice has had considerable impact on the implementation, but one should keep in mind that it is just that (an implementation choice) and is not truly fundamental to the design.

Because the description is in the data all applications can and should get their detector description from the same source (i.e., either literally from the same file, or from a file or other physical form automatically derived from the ultimate source).

There are many clients for detector description, including at least documentation-generating programs (since the XML source itself is verbose and difficult to read), visual display programs, simulation and reconstruction. These programs need or want information including

volume physical description (type, dimensions, material)
volume positioning, perhaps relative to containing volumes
visual display properties of volumes such as color (optional since not intrinsic to the detector and can be generated by display program)
properties of materials
identifiers for volumes. These allow a program such as Reconstruction to read back data (hits and digis) generated by Simulation and relate it back to the detector geometry.

Implementation and Status: XML

The XML file (somewhat of a simplification since the design is such that some parts of the information may be split off into a separate file) has several top-level parts, technically known as elements).

<constants>: These are of two types. Primary constants typically correspond to dimensions of components, such as a CsI crystal, counts of objects (number of crystals in a layer), or material names. Derived constants, such as positioning offsets, are defined as an expression involving primary constants, other derived constants and arithmetic operations.
<materials>: Similar in function to PEGS files, this element describes properties of (chemical) elements and of composites, which may reference other materials. Also may include visual display attributes (color and transparency).
<section>: Describes all volumes composing GLAST and their relative positions. May also include volumes other than the detector itself, such as the spacecraft or, for a testbeam set-up, materials involved in producing the beam. When positioned, a volume may be labeled with an identifier field (logically of the form (fieldname, value) ). It can then be identified by concatenating its field on to the fields of its ancestor volumes.
<idDict>: An identifier dictionary spells out the constraints on how identifiers - sequences of identifier fields - may be formed.
<idConverter>: Describes how to convert identifiers suitable for one situation to another; for example, to convert the identifiers assigned in the <section> to identifiers suitable for hits.

Status of flight.xml

The heart of the file is the <section> element. Currently it has descriptions for CAL and TKR which are comparable in completeness to what appears in the old-style description. ACD needs to be updated with current information. Some NAD ("not a detector") volumes are described in the file; we are awaiting specifics for most of the others which will ultimately be in the model. The <constants> are adequate to provide dimensions, offsets and material names for the volumes described in <section>. One <idDict> is described, the one which constrains the identifiers formed in the <section> element. We probably will need at least one more, to describe constraints on hit identifiers.

The <idConverter> elements cannot be finalized until hit and digi identifiers have been fully defined.

Implementation and Status: Utility Classes

Practically all code needed to read, interpret and serve the information in the XML file has been written. Most has been thoroughly tested; however, significant development will continue until integration with Gaudi and with the more demanding clients has been achieved.

The classes most visible to software clients are the ones handling <section>, <constants> (in the detModel package) and, to a lesser extent, those concerned with identifiers (in xmlUtil).

detModel Status

detModel provides a Visitor interface for clients such as simulation or display, which need information about the complete geometry hierarchy. It is also supports queries (return characteristics of a particular named volume, return value of a particular constant, etc.). Several clients using the Visitor interface have already been written, including a first version of a G4 client and several display clients.

What's new

The major part of refactoring of detModel is now complete and in CVS. Improvements include:

New volumes and positioning hierarchy, with more abstract mechanisms (stack and composition are both an envelope and most operations are at the level of envelope, not stack or composition, for example)
New bounding box object
Better algorithms to compute bounding boxes of volumes
New positioning algorithms
A LOT of replicated code eliminated
Simplified Sections Visitor interface
Introduced namespace detModel

Other recent detModel work, somewhat beyond refactoring, includes some new visitors (DAWN and RIB .. coming), materials database support, and a redesigned color scheme. Colors may be specified for materials rather than leaving the visual characteristics wholly up to individual display clients. A more flexible scheme, involving the ability to specify display characteristics for individual volumes, is on the horizon.

xmlUtil Status

xmlUtil builds in-memory models of id dictionaries and id converters. It provides the following services:

individual id query: given an identifier as a sequence of integers, retrieve the corresponding sequence of (fieldname,value) pairs. (Can always be done for valid dictionaries and an identifier belonging to the dictionary.) The service is used by id converters.
id dictionary visitor interface.: Intended for applications needing to traverse the whole dictionary to build their own data structures. An application needing to recover geometry information from a digi id might need to do this.
id conversion: Id converter service returning the new id.

What's new

Classes to serve the information in <constants>, <materials> and <section> are in the detModel package. Classes for <idDict> and <idConverter> are in xmlUtil, as well as some utilities for constants evaluation and substitution. Neither package is the natural "owner" of the file, so a new facility, the XML document manager, was recently written to allow the packages to share the file in a robust and efficient manner.

In its generic form, clients sign up with the Document Manager by specifying the (immediate) child element of the document root that they are interested in, for example <section>. Then when the Document Manager's parse service is invoked, the client will be called back whenever an element of the right name is encountered. (Since this service really has nothing to do with geometry, but makes sense for any xml file, the base DocMan class in the xml package and hence is available to any other collection of clients wishing to share an XML file.) However XML files using the geometry document format, gdd, are special in that they may require some preprocessing before any normal client sees them, in particular constants should be evaluated and references to them resolved. This is done in GDDDocMan, a class derived from DocMan. It has a special privileged "meFirst" client which gets invoked before any normal client.

Integration

To date detModel and xmlUtil have only been used in stand-alone programs. Essentially all the necessary pieces are now in hand; it is time to merge them into the Gaudi environment and make them available to Simulation and Reconstruction. Here is an outline for how this might be done.

Something in GlastDetSvc invokes methods in detModel and xmlUtil which sign up with GDDDocMan. detModel signs up for <constants>, <section>, and <materials>. xmlUtil signs up for <idDict> and <idConverter>.
GlastDetSvc discovers which xml file(s) are to be parsed.
GlastDetSvc parses the file by invoking GDDDocMan::parse
When the parse is complete in-memory representations of all information in the xml file of interest have been built.
The Simulator Visitor can now use detModel services to build its geometry.
Methods within the Simulator which get called back to process hits or digis make use of identifier services.

For Reconstruction, the first four steps are the same. Reconstruction might make use of detModel queries to find out certain fundamental parameters of the detector or, if it includes extrapolation, might need to traverse the full geometry description with a visitor just as Simulation does. Reconstruction will also need identifier conversion services to be able to relate digi identifiers back to the geometry.