GLAST Geometry Primer

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.

See:

• Fred --> Geometry Display Objects

Also see:

• trapSideTiles.png, which shows how the trapezoidal ACD tiles on the sides fit together.

Note: The blue dots on the top are screws in the top tiles. (The top tiles, themselves, are not visible)

• Index of /exp/glast/ground/LATSoft/geometry/pictures/SC for some of the spacecraft components.

Note: Most of the spacecraft components can be seen in the following screenshot:

The Data

The description uses an XML format descended from the Atlas Generic Detector Description (AGDD) language (see Hands on AGDD presentation by Stan Bentvelsen, page 4) 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 (e.g., material names). Numeric constants may be primary or derived. Examples of primary and derived numeric constants are shown below.

• Primary Constant:

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

• 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.

Note: The identifiers must exist for all volumes in the description, since particles can interact with them; hence, they are of interest to the MC propagator. Real data, however, is only read out by active volumes, and are identified for read-out by a different scheme.

See:

• Geometry Ids and Ritz Ids for a description of the volume identifiers and how they relate to readout identifiers.

• idents for utilities which convert one sort of identifier to the other.

• xmlGeoDbs for files currently in use; in particular, see the files in the xmlGeoDbs/flight subdirectory.

Also see:

• xmlUtil

• Writing XML Geometry Files for a more complete description of the format.
  

The Code

The code involved can be roughly divided into:

• Utilities, 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.

1. Parse – Parsing is typically done with the Xerces parser to validate and to produce in-memory representation that is essentially identical in content to the physical xml files. The representation (DOM) is a W3C standard, and is completely general in nature, having nothing to do with physics, geometry, etc.

Xerces functionality is wrapped in the locally-written package xmlBase.

2. Conversion – Conversion is done to convert the DOM representation to a 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 (though some is handled by xmlUtil); detModel provides the interface to higher levels, and it provides query functionality for some of the information (i.e., you can ask for the value of a particular constant or the location of a particular sensitive volume). It also provides a comprehensive visitor interface.

The heprep generator uses this interface directly.

See:

• HepRepSvc

• HepRepXml

• HepRepCorba

3. GlastSvc package – 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. G4Generator package. The G4Generator package uses the GlastSvc Geometry Visitor interface to get the geometry information it needs to make a Geant 4 geometry; the G4Generator also provides G4 geometry information to clients (via an interface called IG4GeometrySvc).

5. G4Propagator package. The G4Propagator package uses the IG4GeometrySvc of G4Generator to get information it needs about the created G4 geometry.

6. TkrUtil package. The TkrUtil package uses the services provided by GlastSvc to collect various bits of Tracker-specific geometry information.

Note: Similar functionality is employed by AcdUtil and CalUtil.

7. Digi, Recon ????

Standalone applications

The most important standalone applications 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.

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).