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. Numeric constants may be primary or derived. The expression of a primary constant looks like this:

  <prim name= "CsIWidth" value= "26.7"> (Transverse) width of 
  a CsI crytal. Changed from 26.714mm on 18 June, 2003.</prim>
  

  Here is a derived constant:

  <const name="CsIEnvX">  
    <notes>Long dimension of envelope containing a CsI crystal 
           and its diodes</notes>
    <add>
      <refer refTo="CsILength" />
      <mul>
        <const value="2" uType="count"/>
        <refer refTo="diodeX" />
      </mul>
    </add>
  </const>
  

• Materials. Contains all the information needed by a simulator like Geant. The material description for CsI looks like this:

  <composite name="CsI" density = "4.51">
    <addmaterial material="Cesium">
      <natoms n="1" />
    </addmaterial>
    <addmaterial material ="Iodine">
      <natoms n="1" />
    </addmaterial>
  </composite>  

• Volume definitions, including shape, dimensions, materials, and relative location and orientation (relative to containing volume)
• Identifiers 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 more fully described in a tutorial. The files currently in use may be found in the package xmlGeoDbs. See particularly files in the directory xmlGeoDbs/xml/flight/

Note that the identifiers referred to above must exist for all volumes in the description since particles can interact with them, hence they are of interest to the MC propagator. However real data is only read out by active volumes. They are identified for read-out by a different scheme. This document describes the volume identifiers and how they relate to readout identifiers. See the package idents for utilities which convert one sort of identifier to the other.

The Code

The kinds of code involved can be divided into rough classes:

• Utilies which make the information readily available to applications.
• Algorithms or services within Gleam needing detector description to function.
• Stand-alone applications, mostly for examining and debugging the geometry description.

Gleam

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. Xerces functionality is wrapped in the locally-written package xmlBase.
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 (some is handled by xmlUtil) 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. The definition of the interface can be found in the files

   GlastSvc/GlastSvc/GlastDetSvc/IGeometry.h (visitor interface) and
   GlastSvc/GlastSvc/GlastDetSvc/GlastDetSvc.h (queries).

   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 Geant 4 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. (similarly for ACD and CAL)
7. Digi, Recon

Standalone applications

Most important ones are in the special diagnostic package detCheck which depends on detModel, xmlUtil and the rest of the XML machinery, but nothing else. In particular, these diagnostics do not use GlastSvc and are not themselves Gaudi applications. See detCheck's Doxygen mainpage for details.

The Release Manager runs a couple of these programs for each new tag of GlastRelase and puts links to the output on the GlastRelease Summary Page: xml Geometry Parameters (output from constsDoc.exe) and Materials Summary (output from summary.exe).

Joanne Bogart
Last modified: