Run-dependent Geometry Proposal
The detector geometry, which specifies the location and composition of detector components, is an important component of the reconstruction and simulation software. During the lifetime of an experiment, the geometry can be expected to have major changes, such as the addition or removal of detector components, and minor changes, such as small changes in the location of the target as it is removed and replaced for servicing between runs. Currently, the correct geometry description must be set by hand, and different detector geometries must be handled by the user. This document describes a proposal for implementing and managing run-dependent geometry information using our calibration database, the CCDB.
To start with, we note that this proposal excludes the current default simulation code, which relies on Geant3, from consideration. This program requires a compiled form of the geometry information, and supporting run-dependent geometries is expected to require considerable development. Given that GlueX is expected to transition to a Geant4-based simulation in the near future, it is reasonable to exclude the Geant3-based program from consideration in this discussion.
There are several different schemes in which geometry information can be organized. Currently GlueX stores the "as-built" locations and sizes of detector elements in a static geometry format, with the precision location of detector elements needed for specialized reconstruction routines (primarily charged particle tracking) stored in the CCDB. Because of the complexities of managing and verifying a detector geometry suitable for simulations (e.g., with no overlapping volumes), it is proposed to keep this scheme.
The GlueX software uses the XML-based HDDS package to store geometry information. Currently this information is read from files residing on disk. For example, DANA-based programs read the XML files from the same directory as the top-level geometry file specified by the environmental variable JANA_GEOMETRY_URL. It is proposed to store the contents of these files in the CCDB for use in program executation. The CCDB has robust features for tracking changes, handling run-dependent values, and handling different data variations. For ease of development, as CCDB has no built-in editing functions, the HDDS github repository would remain the canonical source of the geometry description.
--- sdobbs, Sept. 2 2016
