\section{Detector Geometry}
\label{mc:geometry}

One of the most basic requirements for the simulation is access to a
detailed description of the geometry of the experiment.  Included in
geometry is the shape and location of all relevant components, their
properties in terms of material composition, density, etc., and the
map of the magnetic field.  Any objects with which beam particles may
interact on their way to a detector are a part of the geometry, starting
with the primary collimator and ending with the photon beam dump.
Any application within the \hd\ framework that needs access to
detector geometry data obtains that information through one unified
interface.  This interface is specified in the form of a xml
{\em document type definition} (DTD) which details what tags exist
in the document, what are their arguments, and their structural
relationships.  The basic structure of the DTD was borrowed from the
ATLAS experiment at CERN and adapted for the needs of \hd.  It describes
the detector as a tree of volumes, each with specified shape, size,
position and material properties.  It allows elements to be grouped
together and positioned as a unit, so that a survey datum can be
expressed by a single element. More details on the interface can be
found in Ref.~\cite{hdds}.

Application code has access to geometry data through the standard xml
libraries.  Programs can scan the entire tree or ask for specific
pieces of information, such as the position of the center of the
target.  At present the only consumers of geometry information are
the simulation codes.  The Geant simulator (see section \ref{mc:hdgeant})
is capable of modeling any geometry, provided that the xml conforms
to the DTD.  The MCFast simulator (see section \ref{mc:hdfast}) supports
a more limited geometrical description.  A special set of tags in the
geometry DTD have been created to describe the detector elements in
simplified terms for MCFast, in places where the translation from
the hierarchical description require some imagination.  As more
applications are created that depend upon access to specific pieces
of geometry information, it will be necessary to extend the interface
beyond the DTD to specify the presence and location of specific
tags.  Investigation is underway to determine if these more complex
constraints might be better expressed using xml schema than the DTD.

At present the geometry description is implemented in a set of
plain xml text files and organized under a sequential version
system.  In the future they will probably be stored in a database
and indexed by date or run number. 
