survey-geom.tex

\section{Geometry Information Management}

% \fixme{(authors: Brett, ??)}

\subsection{Description}

Almost every HEP experiment requires some system for geometry
information management.  Such systems are responsible for providing a
description of the experiment's detectors (and sometimes their
particle beamlines), assigning versions to distinct descriptions,
tracking the use of these versions through processing and converting
between different representations of the description.  

The geometry description is consumed mainly for the following
purposes:

\begin{itemize}
\item Simulate the passage of particles through the detector or
  beamline.  
\item Reconstruct the kinematic parameters and particle identity
  likely responsible for a given detector response (real or
  simulated).
\item Visualize the volumes to validate the description and in the
  context of viewing representations of detector response and
  simulation truth or reconstructed quantities.
\end{itemize}

The prevailing model for geometry information in HEP is Constructive
Solid Geometry (CSG).  This model describes the arrangement of matter
by the placement of volumes into other volumes up to a top level
``world'' volume.  It is typical to describe this as a daughter volume
being placed into a mother volume.  The placement is performed by
providing a transformation (translation plus rotation) between
conventional coordinate systems centered on each volume.  A volume may have
an associated solid shape of some given dimensions and consist of some
material with bulk and surface properties.  With no such association
the volume is considered an ``assembly'', merely aggregating other
volumes.

While this model is predominant, there is no accepted standard for
representing a description in this model.  Instead, there are a
variety of applications, libraries and tools, each of which makes use
of their own in-memory, transient object or persistent file formats.  

For example, Geant4 is a dominant particle-tracking Monte Carlo
simulation likely used by a majority of HEP experiments.  It defines a
set of C++ classes for the description of a geometry and it can import
a representation of a description in the form of an XML file following
the GDML schema.  It has various built-in visualization methods and
can export to some number of other formats for consumption by others.

Another common example are the \texttt{TGeo} classes provided by ROOT.
These can be constructed directly or via the import of a GDML file
(with some technical limitations).  Like Geant4 objects, ROOT provides
means to track rays through the geometry as well as a few
visualization techniques.

There are stand-alone visualization tools such as HepRApp (which take
HEPREP files that Geant4 can produce), GraXML (which can read GDML
with some limitations or AGDD XML).  There are also CAD programs that
can read OpenInventor files which can be produced.  In experiments
that make use of Gaudi and DetDesc, the PANORAMIX OpenInventor based
visualization library can be used.

\subsection{Unified System}

This variety has lead to a ``tower of babel'' situation.  In practice,
experiments limit themselves to some subset of tools.  Developing
their own solutions is often seen as the least effort compared to
adopting others.  This of course leads to an ever larger tower.  Some
common ground can be had by converting between different
representations.  This is the approach taken by the Virtual Geometry
Model (VGM)\cite{vgm} and the General Geometry Description (GGD)\cite{gdd}.

VGM provides a suite of libraries that allow for applications to be
developed which populate one system of geometry objects (eg, Geant4 or
ROOT).  These can then be converted to a general representation and
finally converted to some end-form.  Care must be taken to keep
implicit units correct and in an explicit system of units (the one
followed by GEANT3).  There is no facilities provided for the actual
authoring of the geometry description and that is left to the
application developer.

Addressing this need for an authoring system is a main goal of GGD.
This system provides a layered design.  At the top is a simple
text-based configuration system which is what is expected to be
exposed to the end user.  This drives a layer of Python builder
modules which interpret the configuration into a set of general
in-memory, transient objects.  These objects all follow a strict CSG
schema which is conceptually compatible with that of Geant4.  This
schema includes specifying an object's allowed quantities and provides
a system of units not tied to any particular ``client'' system.  A
final layer exports these objects into other representations for
consumption by other applications, typically by writing a file.
Access to both the set of general geometry objects and any
export-specific representation is available for access in order to
implement validation checks.  Thus, in GGD the source of geometry
information for any ``world'' is the Python builder modules and the
end-user configuration files.

\subsection{Problems with CAD}

It is not unusual for an experiment at some point to consider
integrating CAD to their geometry information management system.  CAD
provides far better authoring and visualization methods than most HEP
geometry software.  It is typical that a CAD model for an experiment's
detectors or beamline must be produced for engineering purposes and it
is natural to want to leverage that information.  However, there are
several major drawbacks to this approach.

CAD models sufficient for engineering purposes typically contain
excessive levels of information for HEP offline software purposes.
Applied to a tracking simulation this leads to an explosion in the
number of objects that must be queried on each step of the particle's
trajectory.  It leads to large memory and CPU requirements with
minimal or incremental improvements in the quality of the simulation
or reconstruction results.

Use of CAD usually requires expensive, proprietary software with
significant expertise required to use.  This limits which individuals can
effectively work on the geometry and tends to lock in the success of
the experiment to one vendor's offering.  It is typical for the geometry
description to require modification over a significant portion of the
experiment's lifetime and these limitations are not acceptable.

Finally, the use of a CSG model is uncommon in CAD.  Instead a
surface-oriented description is used.  For its use in Geant4, a CSG
model is required.  Converting from surfaces to CSG is very
challenging particularly if the CAD user has not attempted to follow
the CSG model in effect, if not in deed.

There is, however, potential in using CAD with HEP geometries.  This
is being explored in GGD in the production of OpenInventor files which
can be loaded into FreeCAD, a Free Software CAD application.  While
FreeCAD can currently view an OpenInventor CSG representation it can
not be used to produce them.  However, FreeCAD is extensible to new
representation types.  With effort, it may be extended to produce and
operate on a suite of novel CSG objects which follow a schema
similarly to that required by Geant4.


\subsection{Opportunity for improvement}

The ``tower of babel'' situation should be addressed by putting effort
in to following areas:

\begin{itemize}
\item Form a small working group from geometry system experts to
  develop a formal data schema to describe the CSG objects that make
  up a general geometry system.  This schema should be independent
  from any specific implementation but be consistent with major
  existing applications (specifically Geant4 and ROOT).  The schema
  should be presented in a generic format but made available in a form
  that can be directly consumed (eg, JSON or XML) by software.
\item A general, transient data model for use in major programming
  languages (at least C++ and Python) should be developed which
  follows this schema.  Independent and modular libraries that can
  convert between this data model and existing ones (GDML, ROOT)
  should be developed.  One possibility is to further develop VGM in
  this direction.
\item Develop a general purpose geometry authoring system that can
  produce objects in this transient data model.
\end{itemize}