GLAST Geometry Primer

Introduction

GLAST uses a generic, if in some respects limited, geometry description format. Low-level code has no hard-coded assumptions; all geometry information is obtained from the description. Even in top-of-the-food-chain application code, such assumptions are few and far between. The same description is used by simulation, reconstruction, or as input to a small program which generates a HepRep file suitable for use with visualization programs like FRED.

The Data

The description uses an XML format descended from the Atlas Generic Detector Descsription language, AGDD (as it was a few years ago, described in this presentation from 1999 and this one from 2000), with some significant additions. The information which can be represented comes in several categories.

• Constants. These may be numeric (integer or floating point) or strings, for example material names.
• Materials. Contains all the information needed by a simulator like Geant
• Volume definitions, including shape, dimensions, materials, and relative location and orientation (relative to containing volume)
• Indentifiers as they are attached to volumes. The description may also contain a separate identifier dictionary which can be used to validate individual identifiers

The format is described in a tutorial. This document describes our volume identifiers and how they relate to readout identifiers.

The Code

The XML input undergoes several stages of processing:

1. Parse, typically with Xerces parser, to validate and to produce in-memory representation, essentially identical in content to the physical xml files. The representation (DOM) is a W3C standard which is completely general, having nothing to do with physics, geometry, etc.
2. Convert to more recognizable (to a detector physicist) form where primitives are things like "box" or "material" rather than "xml attribute" or "xml element". This form is still very general, with no particular relation to GLAST. Call it the detModel form since detModel is the name of the software package which does most of the work and provides the interface to higher levels. detModel provides query functionality for some of the information (you can ask for the value of a particular constant or the location of a particular sensitive volume) and a comprehensive visitor interface. The heprep generator uses this interface directly.
3. The GlastSvc package wraps detModel query functions and provides a more limited visitor interface suitable for higher-level applications; Unlike detModel, GlastSvc is a Gaudi package; that is, it makes use of Gaudi services, extends Gaudi classes, etc.
4. The G4Generator package uses the GlastSvc Geometry Visitor interface to get the geometry information it needs to make a G4 geometry, and also provides G4 geometry information to clients (via an interface called IG4GeometrySvc)
5. The G4Propagator package uses the IG4GeometrySvc of G4Generator to get information it needs about the created G4 geometry.
6. The TkrUtil package uses the services provided by GlastSvc to collect various bits of Tracker-specific geometry information.

The above isn't a complete list, but should give you an idea of how we handle detector description.

Joanne Bogart
Last modified: