--- docs/pubs/0001-lcdd/lcdd-paper.tex	2014-06-27 00:14:27 UTC (rev 3160)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex	2014-06-27 05:35:36 UTC (rev 3161)
@@ -155,14 +155,23 @@

 %% how does it answer question? import/export/exchange
 %% geometry is only a part of the project; still need regions, physics limits, fields, visualization, etc.
 

-The Geometry Description Markup Language (GDML) is an XML language for geometry description.  This format allows users to define hierarchical geometry structures using a data language rather than C++ source code that is customized for every detector variation.  GDML fully describes materials, mathematical variables and definitions, geometric solids such as boxes and tubes, and a hierarchical structure of logical and physical volumes.  Materials are defined as either chemical elements or combinations thereof.  Simple constants can be defined, as well as equations that use trigonometric functions
-and basic mathematical operators.  The support for different types of geometric solids is extensive, including simple shapes such as boxes and tubes or more complex tesselated volumes formed from an arbitrary number of surfaces.  A logical volume is defined by a solid and a material and may optionally contain a tree of ''daughter'' physical volumes.  A hierarchy of volumes then defines the complete detector structure. GDML provides bindings to the core geometry classes of GEANT4, and has become part of the Geant4 source distribution. It therefore serves as an ideal starting point for a complete detector description language.

+The Geometry Description Markup Language (GDML) is an XML language for geometry description.  This format allows users to define hierarchical geometry structures using a data language rather than C++ source code that is customized for every detector variation.  GDML fully describes materials, mathematical variables and definitions, geometric solids such as boxes and tubes, and a hierarchical structure of logical and physical volumes.  
+%Materials are defined as either chemical elements or combinations thereof.  Simple constants can be defined, as well as equations that use trigonometric functions and basic mathematical operators.  The support for different types of geometric solids is extensive, including simple shapes such as boxes and tubes or more complex tesselated volumes formed from an arbitrary number of surfaces.  A logical volume is defined by a solid and a material and may optionally contain a tree of ''daughter'' physical volumes.  
+GDML’s \textit{define} block contains expressions and definitions read into the CLHEP Expression Evaluator.  These expressions may contain double precision numbers, simple arithmetic operators (* / + -), trigonometric functions, and units.  The processor predefines a number of standard units for distance, weight, etc.  Important primary constants such as the speed of light are also predefined.  Rotations and positions that will be referenced later to create physical volumes are also included in this area.

+The \textit{materials} section has \textit{material} and \textit{element} elements that bind to the G4Material and G4Element classes for materials and atomic elements.  Materials are defined by atomic or mass composition and density.  Material parameter sheets may be attached to provide pre-computed values for dEdx calculations and similar algorithms.  The materials defined here are referenced by \textit{volume} elements in the \textit{structure} area.
+
+The \textit{solids} block contains shape definitions that are also referenced by the GDML volumes.  Constructive Geometry Solids (CSG) are the most common type of shapes used in GEANT4 geometries.  (Boundary Represented Solids (BREPS) are also available but are not supported by the GDML system.)  GDML has bindings to a large and nearly complete subset of the CSG solids defined by the GEANT4 geometry subsystem, including tubes, boxes, trapezoids, tori, twisted tubes and boxes, polyhedra, and facetted shapes.  Boolean subtraction and addition can be used with these primitives to define arbitrarily complex geometries.
+
+The \textit{structure} block contains a nested hierarchy of geometric volumes.  A volume is composed of a shape plus its material and may contain any number of sub-volumes, defined with the \textit{physvol} tag.  The volumes in the \textit{physvol} elements are called “child” volumes of their “parent” volume.  The child volumes must contain a reference to a logical volume, plus an in-lined or referenced position and rotation.  The top-level volume or “world volume”, typically a large box containing the detector envelope volume, is defined in the \textit{setup} block using the \textit{world} element.
+
+A hierarchy of volumes thus defines the complete detector structure. Originally developed as a standalone application, GDML has become part of the Geant4 source distribution. It therefore serves as an ideal starting point for a complete detector description language.
+

 \section{LCDD}
 
 In addition to the geometric layout of an experiment, additional information is required to fully describe a valid detector setup at runtime.  This complete set of data is usually called ''detector description.''  Frameworks that use a data language such as GDML for geometry description have generally still required additional, auxiliary information at runtime, for example, through macro commands that define readouts and assign them to volumes.  There are inherent problems and limitations to this approach.  The supplementary information to the geometry is not easily accessible if it is embedded in relatively unstructured, procedural macro files.  Using ad hoc runtime commands can also make it difficult to determine later which detector simulation parameters were used to produce an output file or what readout parameters should be associated to a particular detector component.
 

-A more complete approach is required to guarantee the consistency and integrity of the detector data.  LCDD was designed to provide a complete description of complex experimental setups.  Various types of detectors, ranging from simple test beams to complex HEP detectors, can be modeled to an arbitrary level of detail using an XML file rather than detector-specific C++ code.  LCDD is built upon the GDML data format and C++ parser.  It extends GDML’s data format by using built-in facilities of the XML Schema (XSD) language.  The GDML code infrastructure is reused by registering additional element handlers with GDML’s flexible parser class.  The extended parser, without any alteration, can also read in plain GDML files, as well as LCDD.

+A more complete approach is required to guarantee the consistency and integrity of the detector data.  LCDD was designed to provide a complete description of complex experimental setups.  Various types of detectors, ranging from simple test beams to complex HEP detectors, can be modeled to an arbitrary level of detail using an XML file rather than detector-specific C++ code.  LCDD is built upon the GDML data format and C++ parser.  It extends GDML’s data format by using built-in facilities of the XML Schema (XSD) language.  The GDML code infrastructure is reused by registering additional element handlers with GDML’s flexible parser class.  The extended parser, without any alteration, can also read in plain GDML files, as well as LCDD, so a file with \textit{gdml} as the top element is considered valid within the LCDD processing fr!
 amework. .

 
 LCDD uses GDML to define the core geometric information about the experiment.  The LCDD schema formally extends GDML using the \textit{extension} element, so the \textit{gdml} root node is embedded as part of the document.  The GDML language is essentially left intact, with a single point of extension added to the \textit{volume} element, which may then contain optional references to additional LCDD elements.  The volume can be associated with detector readouts, visualization parameters, a region, physics limits, and other supplementary information, to provide a complete description of the detector to the simulation engine at runtime.