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.

The geometry files would be stored in the CCDB using the following format:

• A new directory GEOMETRY/ would be created
• Each HDDS XML file would be stored in its own table. For example, main_HDDS.xml would be stored in the table GEOMETRY/main_HDDS, ForwardEMcal_HDDS.xml in GEOMETRY/ForwardEMcal_HDDS, etc.

The following changes to GlueX offline software would be needed:

• A provider class should be added which returns the contents of an HDDS XML file from the CCDB in a memory buffer, given an agreed-upon specification (e.g. the nominal XML file name, such as "main_HDDS.xml")
• JANA should be extended to allow for additional geometry providers to be set.
• A derived class of JGeometryXML should be created that interfaces with the CCDB. This would primarily require modifying the constructor to read the main geometry XML file from the CCDB provider class, and modifying the Xerces interface to files from memory instead of from disk.
• HDGeant4 should be modified to support the CCDB geometry provider class.

--- sdobbs, Sept. 2 2016