docs/pubs/0001-lcdd

--- docs/pubs/0001-lcdd/lcdd-paper.tex	2014-10-20 21:26:08 UTC (rev 3377)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex	2014-10-21 16:06:05 UTC (rev 3378)
@@ -41,6 +41,7 @@

 
 %% target: full-length writeup, shorten as necessary for NIM, CPC, etc.
 \documentclass[preprint,12pt,3p]{elsarticle}

+%\documentclass[final,3p,times,twocolumn]{elsarticle}

 \usepackage{url}
 \usepackage{gensymb}
 \usepackage{graphicx}

@@ -143,7 +144,7 @@

 
 Geant4~\cite{geant4} is a software framework for simulating the detailed interactions of particles with matter and fields. It has become the standard tool for detector response simulations in high energy physics (HEP) and is increasingly being used in other fields, such as medical physics and the aerospace industry. Distributed as a set of source files and examples, the toolkit can be used to assemble a domain-specific application based upon experimental requirements.  This requires a considerable amount of expertise in the C++ language and the details of configuring the framework. Typically, the most complex task is modeling the geometry and detectors, which for complex setups may take hundreds or even thousands of lines of code.  This task can be daunting, and providing a flexible application which can meet the needs of many different users can alleviate these technical barriers.
 

-When geometry descriptions are defined by programming against an interface, the size of the code base will tend to increase greatly over time.  Each major detector variant will usually require its own set of classes or a customization of existing ones, sometimes leading to severe maintenance issues.  These problems may include a great amount of code duplication between different detector models, the treatment of geometries as ``black boxes'' without externally accessible data descriptions, and a lack of separation between procedural code and data. Ideally, the detector description would be provided by a data format rather than a set of compiled classes.  GDML provides an XML language for describing detector geometries \cite{gdml}, but completely describing an experimental apparatus requires much more than the just the geometry.

+When geometry descriptions are defined by programming against an interface, the size of the code base will tend to increase greatly over time.  Each major detector variant will usually require its own set of classes or a customization of existing ones, sometimes leading to severe maintenance issues.  These problems may include a great amount of code duplication between different detector models, the treatment of geometries as ``black boxes'' without externally accessible data descriptions, and a lack of separation between procedural code and data. Ideally, the detector description would be provided by a data format rather than a set of compiled classes.  GDML provides a language for describing detector geometries \cite{gdml}, but completely describing an experimental apparatus requires much more than the just the geometry.

 
 Providing a comprehensive and flexible solution to these problems has been the goal of the Linear Collider Detector Description (LCDD) project. LCDD was introduced to simulate detector models for International Linear Collider (ILC) design studies.  It is now being used successfully by several other groups to model their experiments.  By providing a clear separation between code and detector description data, researchers are freed from needing to know the complex details of the Geant4 APIs.  They may instead focus on defining the detector setup for their particular experiment using a structured data language.
 

@@ -177,19 +178,19 @@

     </gdml>
 \end{verbatim}
 

-GDML's \textit{define} block contains expressions and definitions that are composed of double precision numbers, simple arithmetic operators (* / + -), trigonometric functions, and units.  The CLHEP expression evaluator is used to parse and evaluate these mathematical statements.  The processor predefines standard units for distance, weight, etc., as well as a set of constants such as the speed of light.  Rotations and positions that will be referenced later to create physical volumes may also be included in this section.

+GDML's {\tt define} block contains expressions and definitions that are composed of double precision numbers, simple arithmetic operators (* / + -), trigonometric functions, and units.  The CLHEP expression evaluator is used to parse and evaluate these mathematical statements.  The processor predefines standard units for distance, weight, etc., as well as a set of constants such as the speed of light.  Rotations and positions that will be referenced later to create physical volumes may also be included in this section.

-The \textit{materials} section has a list of \textit{material} and \textit{element} tags 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 optical properties.

+The {\tt materials} section has a list of {\tt material} and {\tt element} tags 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 optical properties.

-The \textit{solids} section contains a collection of shape definitions that are used within the geometry.  GDML has bindings to a large and nearly complete subset of the Constructive Geometry Solids (CSG) solids defined by the Geant4 geometry module, 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 {\tt solids} section contains a collection of shape definitions that are used within the geometry.  GDML has bindings to a large and nearly complete subset of the Constructive Geometry Solids (CSG) solids defined by the Geant4 geometry module, 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} section contains all of the geometry's logical volume definitions.  A logical volume is composed of a shape and material, plus any number of ``child'' sub-volumes, defined by \textit{physvol} tags.  The child volumes must contain a reference to a previously defined logical volume and 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.  The full hierarchy of volumes defines the complete geometric structure for the detector simulation.

+The {\tt structure} section contains all of the geometry's logical volume definitions.  A logical volume is composed of a shape and material, plus any number of ``child'' sub-volumes, defined by {\tt physvol} tags.  The child volumes must contain a reference to a previously defined logical volume and 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 {\tt setup} block using the {\tt world} element.  The full hierarchy of volumes defines the complete geometric structure for the detector simulation.

 
 \subsection{LCDD Document Structure}
 

-LCDD uses GDML to provide the complete physical geometry for the simulation.  The \textit{gdml} root node is embedded as part of the LCDD document.  The GDML language is essentially left intact with only minor additions.  The main point of extension is the \textit{volume} element, which is redefined so that it may contain additional references to LCDD elements.  The child volumes are also redefined so that they may have one or more physical volume identifiers attached to them.  Using this approach, a GDML volume can be associated with important supplementary information such as readout parameters.

+LCDD uses GDML to provide the complete physical geometry for the simulation.  The {\tt gdml} root node is embedded as part of the LCDD document.  The GDML language is essentially left intact with only minor additions.  The main point of extension is the {\tt volume} element, which is redefined so that it may contain additional references to LCDD elements.  The child volumes are also redefined so that they may have one or more physical volume identifiers attached to them.  Using this approach, a GDML volume can be associated with important supplementary information such as readout parameters.

-LCDD is built upon the GDML data format and code infrastructure.  GDML itself uses the Xerces C++ \cite{xerces} XML toolkit for parsing and schema validation.  LCDD extends GDML by using built-in facilities of the XML Schema (XSD) language such as the \textit{xs:redefine} and \textit{xs:extension} elements.  The GDML parser is also used by registering additional element handlers for LCDD types.  This extended parser is then able to read both plain GDML and LCDD documents.

+LCDD is built upon the GDML data format and code infrastructure.  GDML itself uses the Xerces C++ \cite{xerces} XML toolkit for parsing and schema validation.  LCDD extends GDML by using built-in facilities of the XML Schema (XSD) language such as the {\tt xs:redefine} and {\tt xs:extension} elements.  The GDML parser is also used by registering additional element handlers for LCDD types.  This extended parser is then able to read both plain GDML and LCDD documents.

 
 Every LCDD file has the same basic structure that is enforced through XML schema checking at runtime against the document contents.
 

@@ -241,19 +242,19 @@

     </lcdd>
 \end{verbatim}
 

-The LCDD parser checks the input document for correctness against the XML Schema, which is located at a standard URL accessible via the \textit{http} protocol.

+The LCDD parser checks the input document for correctness against the XML Schema, which is located at a standard URL accessible via the {\tt http} protocol.

 
 \begin{verbatim}
     http://www.lcsim.org/schemas/lcdd/1.0/lcdd.xsd
 \end{verbatim}
 

-The \textit{lcdd} root element has a number of sections, most of which contain a list of elements with a specific type.  Each of these elements has a name assigned to it, which can be used as a unique reference within the document.  The GDML volumes may reference these LCDD elements by their names.  In this way, the information in LCDD is linked to specific volumes defined by GDML.

+The {\tt lcdd} root element has a number of sections, most of which contain a list of elements with a specific type.  Each of these elements has a name assigned to it, which can be used as a unique reference within the document.  The GDML volumes may reference these LCDD elements by their names.  In this way, the information in LCDD is linked to specific volumes defined by GDML.

-The \textit{header} has basic meta data about the document, such as a name that can be used an as external tag or ID of the detector.  (It is the only top-level element which has no significant level of sub-structure.)  The \textit{iddict} is a collection of identifier dictionaries that provide encodings for packed, 64-bit IDs, which contain encoded values such as a layer number or a detector ID.  The \textit{sensitive\_detectors} element defines sensitive detectors that can be assigned to volumes, flagging them as readout components capable of producing hits.  The \textit{limits} are sets of physics limits that can be used to tune parameters in the physics engine, such as the maximum step size of a track.  The \textit{display} element contains visualization settings that assign colors and other visibility parameters to logical volumes.  The \textit{gdml} section contains an entire, embedded GDML document, which must conform to that form!
 at's XML syntax.  It may also include the additio[...]

+The {\tt header} has basic meta data about the document, such as a name that can be used an as external tag or ID of the detector.  (It is the only top-level element which has no significant level of sub-structure.)  The {\tt iddict} is a collection of identifier dictionaries that provide encodings for packed, 64-bit IDs, which contain encoded values such as a layer number or a detector ID.  The {\tt sensitive\_detectors} element defines sensitive detectors that can be assigned to volumes, flagging them as readout components capable of producing hits.  The {\tt limits} are sets of physics limits that can be used to tune parameters in the physics engine, such as the maximum step size of a track.  The {\tt display} element contains visualization settings that assign colors and other visibility parameters to logical volumes.  The {\tt gdml} section contains an entire, embedded GDML document, which must conform to that format's XML syntax.  It!
  may also include the additional elements defin[...]

 
 \subsection{Header Element}
 

-Every document begins with a \textit{header} that provides basic meta data about the file and the detector.

+Every document begins with a {\tt header} that provides basic meta data about the file and the detector.

 
 \begin{verbatim}
     <header>

@@ -265,37 +266,41 @@

     </header>
 \end{verbatim}
 

-The \textit{detector} tag provides a name attribute that can be used as an external ID.  For instance, the name can be written into the run headers of output data files to identify which detector was used to generate those events.  An \textit{author} element gives the names of the authors of the file, as well as an email contact.  The generator provides information about an external program that was used to generate the file, if applicable, including a source file name, a version of that program, and a checksum that could be created with an MD5 algorithm.  Finally, there is a comment block that may be used to provide additional descriptive text about the detector.

+The {\tt detector} tag provides a name attribute that can be used as an external ID.  For instance, the name can be written into the run headers of output data files to identify which detector was used to generate those events.  An {\tt author} element gives the names of the authors of the file, as well as an email contact.  The generator provides information about an external program that was used to generate the file, if applicable, including a source file name, a version of that program, and a checksum that could be created with an MD5 algorithm.  Finally, there is a comment block that may be used to provide additional descriptive text about the detector.

 
 \subsection{Sensitive Detectors}
 
 A sensitive detector is assigned to a logical volume to designate it as a readout component that is capable of producing hits.  When a particle deposits energy into that volume, hits are created, which may later be written into an output file for analysis.  (Providing these output data formats is not one of LCDD's features.)  The sensitive detectors accumulate position, time and energy measurements from particle interactions within the material.  Hits are grouped by event and added to collections based on their volume's assigned sensitive detector.
 

-Two primary types of detectors are modeled by the framework.  Trackers store output from the simulation that corresponds closely to individual steps within a volume.  This information can be used later to reconstruct in detail the exact particle momentum at the hit location. Calorimeters record the total accumulation of energy by event and typically have much less granular position information.  Calorimeter volumes may be virtually segmented into cells using a \textit{segmentation} element.  There is also a third type of detector called a \textit{scorer} which is essentially a simplified tracker.  It can be used to insert scoring planes to derive flux counts.

+Two primary types of detectors are modeled by the framework.  Trackers store output from the simulation that corresponds closely to individual steps within a volume.  This information can be used later to reconstruct in detail the exact particle momentum at the hit location. Calorimeters record the total accumulation of energy by event and typically have much less granular position information.  Calorimeter volumes may be virtually segmented into cells using a {\tt segmentation} element.  There is also a third type of detector called a {\tt scorer} which is essentially a simplified tracker.  It can be used to insert scoring planes to derive flux counts.

-Sensitive detectors extend a common element which defines basic settings, including the following.

+Sensitive detectors extend a common element which defines basic settings, including those shown in Table~\ref{table:sensitiveDetectors}.

+\begin{table}[ht]
+\centering

 \begin{tabular}{ | l | l | }
 \hline

-name & unique string identifying the sub-detector \\ \hline
-endcap\_flag & indicates if volume is a barrel or endcap \\ \hline
-ecut & a minimum energy cut for individual hits \\ \hline
-eunit & energy unit for cut \\ \hline
-verbose & verbosity setting \\

+{\tt name} & unique string identifying the sub-detector \\ \hline
+{\tt endcap\_flag} & indicates if volume is a barrel or endcap \\ \hline
+{\tt ecut} & a minimum energy cut for individual hits \\ \hline
+{\tt eunit} & energy unit for cut \\ \hline
+{\tt verbose} & verbosity setting \\

 \hline
 \end{tabular}

+\caption{Sensitive Detectors}
+\label{table:sensitiveDetectors}
+\end{table}
+Each sensitive detector has a name uniquely identifying it within the document.  The {\tt sdref} element of a volume references this name to associate the volume with a specific sensitive detector.  There is a flag which indicates whether or not the detector is an end cap.  (This is primarily a concept relevant for HEP collider-detectors.)  An energy cut can be used to discard low-energy hits that do not reach a certain threshold.  There is a verbosity setting to control print screen output while the simulation is running e.g. for debugging.  The name of the sub-detector is required, and the other settings are optional.

-Each sensitive detector has a name uniquely identifying it within the document.  The \textit{sdref} element of a volume references this name to associate the volume with a specific sensitive detector.  There is a flag which indicates whether or not the detector is an end cap.  (This is primarily a concept relevant for HEP collider-detectors.)  An energy cut can be used to discard low-energy hits that do not reach a certain threshold.  There is a verbosity setting to control print screen output while the simulation is running e.g. for debugging.  The name of the sub-detector is required, and the other settings are optional.

+Each sensitive detector has one or more hits collection containing objects which are implementations of Geant4's virtual hit class, G4VHit.  The {\tt CalorimeterHit} class is used to store hits in the calorimeters, and a list of {\tt HitContribution} objects keeps the information about each energy deposition made in a cell.  The {\tt TrackerHit} class is used to store information from trackers.  (There is no specific output data binding provided by LCDD itself to persist this information.)  It is assumed that applications which include LCDD as a dependency would translate from the provided hit objects into an output format such as LCIO \cite{lcio}.

-Each sensitive detector has one or more hits collection containing objects which are implementations of Geant4's virtual hit class, G4VHit.  The \textit{CalorimeterHit} class is used to store hits in the calorimeters, and a list of \textit{HitContribution} objects keeps the information about each energy deposition made in a cell.  The \textit{TrackerHit} class is used to store information from trackers.  (There is no specific output data binding provided by LCDD itself to persist this information.)  It is assumed that applications which include LCDD as a dependency would translate from the provided hit objects into an output format such as LCIO \cite{lcio}.
-

 \subsubsection{Scorers}
 
 The scorer type is the simplest of the sensitive detector implementations.  It records the passage of particles through a volume.  The main difference between the tracker and the scorer is that the latter will only record one hit for each unique G4Track that passes through it, whereas the tracker class records all separate steps as individual hits.  The scorer simply provides a way to determine if a given track passed through the volume.
 
 \subsubsection{Trackers}
 

-Trackers record information from each step as a track propagates through the material of a volume.  The stored information includes the mid-point position, momentum of the track at that point, length of the step, global time, and the energy deposited along that path.  A \textit{TrackerHit} object is created and stored into a hit collection to persist this information by event.  The Tracker is most commonly used to model non-destructive, low-mass, high-granularity readout technologies used to measure the trajectories of charged particles, such as TPCs or silicon pixel and microstrip detectors.  Algorithms for digitizing the hits within the simulation are not provided, as it is assumed this would be done later in a external analysis environment using the stored hit data.

+Trackers record information from each step as a track propagates through the material of a volume.  The stored information includes the mid-point position, momentum of the track at that point, length of the step, global time, and the energy deposited along that path.  A {\tt TrackerHit} object is created and stored into a hit collection to persist this information by event.  The Tracker is most commonly used to model non-destructive, low-mass, high-granularity readout technologies used to measure the trajectories of charged particles, such as TPCs or silicon pixel and microstrip detectors.  Algorithms for digitizing the hits within the simulation are not provided, as it is assumed this would be done later in a external analysis environment using the stored hit data.

 
 This is an example of a simple tracking detector:
 

@@ -309,9 +314,9 @@

 
 \subsubsection{Calorimeters}
 

-The calorimeter is used to record the energy depositions of particle showers in homogeneous or sampling detectors.  Typically these showers are composed of many individual steps, the details of which are normally not of interest.  The energy depositions from all these steps are accumulated to determine the total energy deposited in the volume for that event.  The energies may be summed for an entire volume, as in a physical crystal or pad, or assigned to bins within an array of virtual cells.  When volumes are artificially segmented, there is at most one \textit{CalorimeterHit} object created per virtual cell for the entire event.

+The calorimeter is used to record the energy depositions of particle showers in homogeneous or sampling detectors.  Typically these showers are composed of many individual steps, the details of which are normally not of interest.  The energy depositions from all these steps are accumulated to determine the total energy deposited in the volume for that event.  The energies may be summed for an entire volume, as in a physical crystal or pad, or assigned to bins within an array of virtual cells.  When volumes are artificially segmented, there is at most one {\tt CalorimeterHit} object created per virtual cell for the entire event.

-The following XML defines a calorimeter with uniform sized cells created by a virtual segmentation class.  The \textit{grid\_xyz} element will divide the detector's sensor layers into a grid of 3.5mm x 3.5mm cells.

+The following XML defines a calorimeter with uniform sized cells created by a virtual segmentation class.  The {\tt grid\_xyz} element will divide the detector's sensor layers into a grid of 3.5mm x 3.5mm cells.

 
 \begin{verbatim}
     <calorimeter name="EcalBarrel"� hits_collection="EcalBarrelHits">

@@ -324,21 +329,21 @@

 
 \subsubsection{Hits Processors}
 

-Each sensitive detector has one or more \textit{hits\_processor} objects to process step information into hits, allowing flexibility in how different types of particles and physics are handled.  For instance, an optical calorimeter may write out separate hits collections for the scintillation and Cherenkov energy depositions using two different hits processors.  The tracker and calorimeter detectors each have a default hits processor that uses the associated segmentation, sensitive detector, and identifier objects to construct hits.  It is anticipated that the hits processor could provide an extension point for future development of flexible digitization algorithms with complex requirements and input parameters.

+Each sensitive detector has one or more {\tt hits\_processor} objects to process step information into hits, allowing flexibility in how different types of particles and physics are handled.  For instance, an optical calorimeter may write out separate hits collections for the scintillation and Cherenkov energy depositions using two different hits processors.  The tracker and calorimeter detectors each have a default hits processor that uses the associated segmentation, sensitive detector, and identifier objects to construct hits.  It is anticipated that the hits processor could provide an extension point for future development of flexible digitization algorithms with complex requirements and input parameters.

 
 \subsubsection{Segmentation}
 
 %% TODO: Include images that show how each segmentation works, e.g. projective, grid, etc.  This can include the specific numbering about the origin as in grid_xyz's scheme.
 

-Sensitive volumes in a calorimeter, such as planar layers, usually require virtual subdivision.  The \textit{segmentation} element models this division of geometric volumes into cells.  The algorithmic approach has some advantages over using purely geometric constructs.  Simulating millions of individual cell volumes could be expensive in terms of memory usage.  There are also certain cases in which it is simpler to describe a readout system with an algorithm rather than pure geometry.  For instance, projective calorimeter towers have many different shapes and sizes of cells depending on the radial distance of a layer from the origin, and this would be complicated to construct using only solids and volumes.

+Sensitive volumes in a calorimeter, such as planar layers, usually require virtual subdivision.  The {\tt segmentation} element models this division of geometric volumes into cells.  The algorithmic approach has some advantages over using purely geometric constructs.  Simulating millions of individual cell volumes could be expensive in terms of memory usage.  There are also certain cases in which it is simpler to describe a readout system with an algorithm rather than pure geometry.  For instance, projective calorimeter towers have many different shapes and sizes of cells depending on the radial distance of a layer from the origin, and this would be complicated to construct using only solids and volumes.

-The \textit{segmentation} element occurs as a child of the calorimeter element, and each calorimeter may have only one of these associated objects.  The specific segmentation types extend an abstract XML element.  The parameters which define the dimensions of the cells are specific to a certain type.  The values of the fields from the segmentation at a certain hit position can be written into the identifiers of the hits by referencing their names in the identifier specification.

+The {\tt segmentation} element occurs as a child of the calorimeter element, and each calorimeter may have only one of these associated objects.  The specific segmentation types extend an abstract XML element.  The parameters which define the dimensions of the cells are specific to a certain type.  The values of the fields from the segmentation at a certain hit position can be written into the identifiers of the hits by referencing their names in the identifier specification.

 
 \subsubsection{Grid XYZ Segmentation}
 

-The \textit{grid\_xyz} segmentation divides a volume into cells along any combination of its X, Y, or Z axes, creating a regular grid of box-like virtual volumes.  The indices are signed integer values, numbered about the natural origin of the volume's solid, which is its center point in local coordinates.  Only the position with respect to this origin is used to compute an index value at a particular point in the grid, so no additional geometric information, such as the bounds of the current solid, is required by this algorithm to compute the bin values.

+The {\tt grid\_xyz} segmentation divides a volume into cells along any combination of its X, Y, or Z axes, creating a regular grid of box-like virtual volumes.  The indices are signed integer values, numbered about the natural origin of the volume's solid, which is its center point in local coordinates.  Only the position with respect to this origin is used to compute an index value at a particular point in the grid, so no additional geometric information, such as the bounds of the current solid, is required by this algorithm to compute the bin values.

-The following XML shows a \textit{grid\_xyz} segmentation that divides a volume along the X and Y axes.

+The following XML shows a {\tt grid\_xyz} segmentation that divides a volume along the X and Y axes.

 
 \begin{verbatim}
     <grid_xyz grid_size_x="1.0*cm" grid_size_y="1.0*cm" />

@@ -348,7 +353,7 @@

 
 \subsubsection{Projective Cylinder Segmentation}
 

-The \textit{projective\_cylinder} segmentation divides cylinders into projective towers.  Unlike most other types of segmentation, this does not result in cells with uniform sizes.  The size of a given cell in a projective segmentation depends on its distance from the origin.  The \textit{nphi} parameters determines how many phi bins are created within the full $360\degree$ in azimuth.  Similarly, \textit{ntheta} specifies the number of theta bins, covering the $180\degree$ in polar angle.

+The {\tt projective\_cylinder} segmentation divides cylinders into projective towers.  Unlike most other types of segmentation, this does not result in cells with uniform sizes.  The size of a given cell in a projective segmentation depends on its distance from the origin.  The {\tt nphi} parameters determines how many phi bins are created within the full $360\degree$ in azimuth.  Similarly, {\tt ntheta} specifies the number of theta bins, covering the $180\degree$ in polar angle.

 
 This is an example of a projective cylinder segmentation that divides the theta and phi regions into 32 and 32 bins, respectively.
 

@@ -362,7 +367,7 @@

 
 %% TODO: Section needs more content.
 

-A \textit{nonprojective\_cylinder} segmentation element will divide the surface of a cylinder into cells of equal size along its length.

+A {\tt nonprojective\_cylinder} segmentation element will divide the surface of a cylinder into cells of equal size along its length.

 %% TODO is the segmentation in phi really in r*phi?
 \begin{verbatim}
     <nonprojective_cylinder grid_size_phi="10.0*mm" grid_size_z="�10.0*mm"� />

@@ -441,7 +446,7 @@

 
 %% TODO: Section needs more content.
 

-The \textit{projective\_zplane} segmentation divides an endcap zplane into projective angular segments specified by the number of phi and theta bins, much as a \textit{projective\_cylinder} is used for a barrel.

+The {\tt projective\_zplane} segmentation divides an endcap zplane into projective angular segments specified by the number of phi and theta bins, much as a {\tt projective\_cylinder} is used for a barrel.

 
 \begin{verbatim}
     <projective_zplane ntheta="�500" nphi="�500" />

@@ -451,7 +456,7 @@

 
 %% TODO: Section needs more content.
 

-%The \textit{global\_grid\_xyz} segmentation divides a global space into regular sized rectilinear cells.

+%The {\tt global\_grid\_xyz} segmentation divides a global space into regular sized rectilinear cells.

 
 %\begin{verbatim}
 %<global_grid_xyz grid_size_x="��50.0*mm"�� grid_size_y="50.0*mm" />

@@ -461,9 +466,9 @@

 
 \subsection{Identifiers}
 

-Identifier dictionaries define formats for bit-packed integers used to associate hits with specific detector information like layer numbers and sub-detector IDs, so that these values are accessible in an external framework by decoding the IDs of the hits.  The \textit{physvolid} values or calorimeter segmentation bins may be referenced by these definitions.  Each sensitive detector may have only one identifier specification, which is used to create a 64-bit integer for each of its hits at runtime.  The user is ultimately responsible for ensuring that the given combination of packed field values uniquely identifies the hit in their external application.

+Identifier dictionaries define formats for bit-packed integers used to associate hits with specific detector information like layer numbers and sub-detector IDs, so that these values are accessible in an external framework by decoding the IDs of the hits.  The {\tt physvolid} values or calorimeter segmentation bins may be referenced by these definitions.  Each sensitive detector may have only one identifier specification, which is used to create a 64-bit integer for each of its hits at runtime.  The user is ultimately responsible for ensuring that the given combination of packed field values uniquely identifies the hit in their external application.

-All of the identifier specifications are contained in the \textit{iddict}.  Every ID dictionary has a corresponding element called the \textit{idspec} with a list of \textit{idfield} tags.  Each \textit{idfield} defines a single field of the identifier, such as a layer number or a field from the segmentation.  The individual fields can be from 1 to 32 bits long and may be signed or unsigned.

+All of the identifier specifications are contained in the {\tt iddict}.  Every ID dictionary has a corresponding element called the {\tt idspec} with a list of {\tt idfield} tags.  Each {\tt idfield} defines a single field of the identifier, such as a layer number or a field from the segmentation.  The individual fields can be from 1 to 32 bits long and may be signed or unsigned.

 
 Below is an example of an identifier definition for a calorimeter.
 

@@ -480,7 +485,7 @@

     </idspec>
 \end{verbatim}
 

-The first five fields of the above identifier derive from the \textit{physvolid} values.  The ``x''� and ``y''� values are read from the segmentation bins at the hit position.  The concatenation of these values identifies a unique readout channel in the detector.  The packed values can be subsequently decoded within an external framework to retrieve the associated detector information for a specific hit.

+The first five fields of the above identifier derive from the {\tt physvolid} values.  The ``x''� and ``y''� values are read from the segmentation bins at the hit position.  The concatenation of these values identifies a unique readout channel in the detector.  The packed values can be subsequently decoded within an external framework to retrieve the associated detector information for a specific hit.

 
 \subsection{Physics Limits}
 

@@ -498,20 +503,25 @@

 
 Each limit has a name that identifies the simulation parameter, a double value, a unit applied to that value, and a comma-delimited list of particles.  The names of the particles in the list are defined within Geant4.
 

+The available limits include the maximum step length, the maximum track length, the maximum particle lifetime, the minimum particle kinetic energy, and the minimum range (or ``range cut''� in Geant4 terminology). These are shown in Table~\ref{table:limits}. %\ref{userlimits}
+
+\begin{table}[ht]
+\centering

 \begin{tabular}{ | l | l | }
 \hline

-step\_length\_max & maximum length of a single step \\ \hline
-track\_length\_max & maximum length of a single track \\ \hline
-time\_max & maximum lifetime of a track \\ \hline
-ekin\_min & minimum track kinetic energy \\ \hline
-range\_min & range cut \\ \hline

+{\tt step\_length\_max} & maximum length of a single step \\ \hline
+{\tt track\_length\_max} & maximum length of a single track \\ \hline
+{\tt time\_max} & maximum lifetime of a track \\ \hline
+{\tt ekin\_min} & minimum track kinetic energy \\ \hline
+{\tt range\_min} & range cut \\ \hline

 \end{tabular}

+\caption{User Settable Limits}
+\label{table:limits}
+\end{table}

-The available limits include the maximum step length, the maximum track length, the maximum particle lifetime, the minimum particle kinetic energy, and the minimum range (or ``range cut''� in Geant4 terminology). %\ref{userlimits}
-

 \subsection{Regions}
 

-Regions are assigned to geometric volumes using the \textit{region} element, defining collections of volumes that share similar characteristics.  A flag specifies whether or not secondary particles produced in the simulation are stored into the output particle collections.  The following example defines a region in which all secondary particles will be stored into the output.  This is typically called a ``tracking region.''

+Regions are assigned to geometric volumes using the {\tt region} element, defining collections of volumes that share similar characteristics.  A flag specifies whether or not secondary particles produced in the simulation are stored into the output particle collections.  The following example defines a region in which all secondary particles will be stored into the output.  This is typically called a ``tracking region.''

 
 \begin{verbatim}
     <regions>

@@ -537,7 +547,7 @@

     </volume>
 \end{verbatim}
 

-The referenced LCDD objects are previously defined in the document.  For instance, the ``EcalBarrel'' sensitive detector is defined prior to the volume definition, and the parser will retrieve its object from an in-memory data structure and then assign the sensitive detector to the named volume.  A similar strategy is used for the other objects referenced by the extended volume element.  In this way, the supplementary information defined by LCDD can be assigned to the appropriate GDML \textit{volume} elements.

+The referenced LCDD objects are previously defined in the document.  For instance, the ``EcalBarrel'' sensitive detector is defined prior to the volume definition, and the parser will retrieve its object from an in-memory data structure and then assign the sensitive detector to the named volume.  A similar strategy is used for the other objects referenced by the extended volume element.  In this way, the supplementary information defined by LCDD can be assigned to the appropriate GDML {\tt volume} elements.

 
 \subsection{Physical Volume IDs}
 

@@ -554,7 +564,7 @@

     </volume>
 \end{verbatim}
 

-Any number of \textit{physvolid} elements can be added to a single \textit{physvol}, so the assignment of these identifier values need not be limited by the hierarchical structure of the detector.

+Any number of {\tt physvolid} elements can be added to a single {\tt physvol}, so the assignment of these identifier values need not be limited by the hierarchical structure of the detector.

 
 
 \subsection{Magnetic Fields}

@@ -563,7 +573,7 @@

 
 \subsubsection{Solenoid}
 

-The \textit{solenoid} is a simplistic representation of a solenoid magnet with a constant component aligned along the z axis.  It has an inner and outer radius, and one Bz value is applied within the inner radius, and another between the inner and outer.  This field type is commonly employed in collider detectors where charged particles bend in the XY plane.

+The {\tt solenoid} is a simplistic representation of a solenoid magnet with a constant component aligned along the z axis.  It has an inner and outer radius, and one Bz value is applied within the inner radius, and another between the inner and outer.  This field type is commonly employed in collider detectors where charged particles bend in the XY plane.

 
 The following defines a solenoid with a constant 5 Tesla field strength within the inner radius and a return field strength of -0.6 Tesla outside of that.
 

@@ -593,7 +603,7 @@

 
 \subsubsection{Box Dipole}
 

-The \textit{box\_dipole} is used to define a set of fixed component values in a box-like region.

+The {\tt box\_dipole} is used to define a set of fixed component values in a box-like region.

 
 \begin{verbatim}
     <box_dipole name="AnalyzingDipole"

@@ -621,7 +631,7 @@

 
 \subsubsection{Field Map 3D}
 

-The \textit{field\_map\_3d} represents a 3D Cartesian magnetic field map as a grid of values measured on a regular cartesian grid of 3D points.

+The {\tt field\_map\_3d} represents a 3D Cartesian magnetic field map as a grid of values measured on a regular cartesian grid of 3D points.

 
 The field values are contained in an external file with each line defining a point in the map.
 

@@ -642,7 +652,7 @@

 
 \subsection{Visualization}
 

-Geant4 has a number of built-in mechanisms for visualizing detectors.  These range from real-time visualization using OpenGL to the generation of graphics file formats such as VRML.  LCDD can assign visualization attributes to geometric volumes using the \textit{visref} element.  The supported settings include line style (broken or unbroken), drawing style (wireframe or solid), the visibility of daughter volumes, and whether the volume itself is visible.  The color of volumes may also be specified with RGB values from 0.0 to 1.0, as well as the transparency or alpha.  An alpha value of 0.0 would render the component invisible and 1.0 would be completely opaque.

+Geant4 has a number of built-in mechanisms for visualizing detectors.  These range from real-time visualization using OpenGL to the generation of graphics file formats such as VRML.  LCDD can assign visualization attributes to geometric volumes using the {\tt visref} element.  The supported settings include line style (broken or unbroken), drawing style (wireframe or solid), the visibility of daughter volumes, and whether the volume itself is visible.  The color of volumes may also be specified with RGB values from 0.0 to 1.0, as well as the transparency or alpha.  An alpha value of 0.0 would render the component invisible and 1.0 would be completely opaque.

 
 The following is an example of visualization attributes.
 

@@ -669,7 +679,7 @@

     /lcdd/url http://www.lcsim.org/detectors/sidloi3/sidloi3.lcdd
 \end{verbatim}
 

-Local files can also be read in by using the \textit{file://} protocol.

+Local files can also be read in by using the {\tt file://} protocol.

 
 \begin{verbatim}
     /lcdd/url file:///local/path/to/sidloi3.lcdd

@@ -681,7 +691,7 @@

     /lcdd/url /local/path/to/sidloi3.lcdd
 \end{verbatim}
 

-The detector document must be specified in the pre-initialization phase, and then the geometry is setup when initialization occurs, either through calling the initialization method on the run manager directly or executing the \textit{/run/initialize} macro command.

+The detector document must be specified in the pre-initialization phase, and then the geometry is setup when initialization occurs, either through calling the initialization method on the run manager directly or executing the {\tt /run/initialize} macro command.

 
 
 \pagebreak

[Note: Some over-long lines of diff output only partialy shown]