--- docs/pubs/0001-lcdd/lcdd-paper.tex	2014-08-08 22:30:20 UTC (rev 3242)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex	2014-08-08 22:44:13 UTC (rev 3243)
@@ -1,21 +1,20 @@

-%% TODO List
-%% Overhaul of the section organization.  Put the "sensitive detector" etc. sections in their own sub-sections.  Make only 4-5 top level sections.
-%% Reordering of certain sections for the best "flow" of information.
-%% Two column formatting according to NIMA template.
-%% Proper formatting of author section and inclusion of institution info.
-%% Inclusion of all necessary additional references/notes where applicable.
-%% Provide example GDML "schematic" XML similar to existing one for LCDD.
-%% Properly indent the verbatim sections.
-%% Add more text for the nonprojective_cylinder and projective_zplane segmentation sections describing how they work, etc.
-%% Describe the interpolation algorithms for RZ and 3D field maps in their respective subsections.
-%% Add segmentation visualization cartoons.
-%% Add example visualization of solid vs wireframe etc.
-%% Flesh out the HPS section under 13. Examples.  It should be a full paragraph.
-%% Add subsections for CliC and MuColl under Examples.
-%% Add additional detector graphics including (possibly) cutaway view of SiD, replacement for the HPS graphic placeholder, etc.
-%% Add text to the Future Plans.
-

+%% ------- TODO List -------

 %%

+%% Formatting
+%% ---------
+%% -Properly indent the verbatim sections.
+%%
+%% Content
+%% -------
+%% -Add more text for the nonprojective_cylinder and projective_zplane segmentation sections describing how they work, etc.
+%% -Add segmentation visualization cartoons.
+%% -Add subsections for CliC and MuColl under Examples.
+%% -Flesh out the HPS section under Examples.  It should be a full paragraph.
+%% -Add additional detector graphics including (possibly) cutaway view of SiD, replacement for the HPS graphic placeholder, etc.
+%% -Inclusion of all necessary additional references/notes where applicable.
+%%
+%% ------- End TODO List -------
+%%

 %% Copyright 2007, 2008, 2009 Elsevier Ltd
 %%
 %% This file is part of the 'Elsarticle Bundle'.

@@ -100,7 +99,6 @@

 
 % \biboptions{}
 

-

 \journal{Nuclear Physics B}
 
 \begin{document}

@@ -109,32 +107,12 @@

 
 \title{Linear Collider Detector Description}
 

-\author{Jeremy McCormick}
-\author{Norman Graf}

+\author{Jeremy McCormick\fnref{label1}}
+\author{Norman Graf\fnref{label1}}
+\address[label1]{SLAC National Accelerator Laboratory}

-%% \texttt{elsarticle} class\tnoteref{label0}}
-%% \tnotetext[label0]{This is only an example}
-
-%% \author[label1,label2]{Author One\corref{cor1}\fnref{label3}}
-%% \address[label1]{Address One}
-%% \address[label2]{Address Two\fnref{label4}}
-
-%% \cortext[cor1]{I am corresponding author}
-%% \fntext[label3]{I also want to inform about\ldots}
-%% \fntext[label4]{Small city}
-
-%% \[log in to unmask]
-%% \ead[url]{author-one-homepage.com}
-
-%% \author[label5]{Author Two}
-%% \address[label5]{Some University}
-%% \[log in to unmask]
-
-%% \author[label1,label5]{Author Three}
-%% \[log in to unmask]
-

 \begin{abstract}

-Geant4 is a software framework for simulating the interactions of particles with matter and fields. It has become the de facto standard for detector simulation in high energy physics and is increasingly being used in other fields, such as medical physics the aerospace industry.  Geant4 is designed as a toolkit, rather than a pre-packaged executable, so an application must be assembled based upon the user's requirement.  This requires a considerable amount of expertise in the C++ language and the details of configuring the framework. Providing a flexible application which can meet the needs of many different users can alleviate these technical barriers. 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, but completely describing an experimental apparatus requires much more than the just the geometry. We present here the LCDD language and library, which extends GDML[...]

+Geant4 is a software framework for simulating the interactions of particles with matter and fields. It has become the standard tool for detector simulation in high energy physics and is increasingly being used in other fields, such as medical physics and the aerospace industry.  Geant4 is designed as a toolkit, rather than a pre-packaged executable, so an application must be assembled based upon the user's requirement.  This requires a considerable amount of expertise in the C++ language and the details of configuring the framework. Providing a flexible application which can meet the needs of many different users can alleviate these technical barriers. 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 dete!
 ctor geometries, but completely describing an experimental apparatus requires much more than the just the geometry. We present here the LCDD language and library, which extends GDML[...]

 \end{abstract}
 
 %% \begin{keyword}

@@ -166,9 +144,9 @@

 
 An overview of the LCDD language and framework will be provided, with a schematic of the full document structure. The extensions to GDML will be explained and described along with simple examples.  Each primary XML element type will be explained in detail along with an example of its usage.  Several projects will be briefly described that have used LCDD to model their experimental detectors.  Finally, future plans will be briefly discussed.
 

-\section{GDML}

+\subsection{GDML}

-The Geometry Description Markup Language (GDML) is an XML language for describing detector geometries using materials, mathematical variables and definitions, solids such as boxes and tubes, and a hierarchical structure of logical and physical volumes.  Originally developed as a standalone application, GDML has become part of the Geant4 source distribution. Therefore, it serves as an ideal starting point for a complete detector description language.

+The Geometry Description Markup Language (GDML) is an XML language for describing detector geometries using materials, mathematical variables and definitions, solids such as boxes and tubes, and a hierarchical structure of logical and physical volumes.  Originally developed as a standalone application, GDML has become part of the Geant4 source distribution. Therefore, it serves as an ideal starting point for a complete detector description language.  The syntax and usage of GDML is fully described in the \textit{GDML User's Guide}.  \cite{gdmlguide}

 
 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.
 

@@ -178,78 +156,14 @@

 
 The \textit{structure} section contains all of the geometry's logical volume definitions.  A logical volume is composed of a shape plus a 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.
 

-\section{LCDD}

+\subsection{LCDD Overview}

 
 In addition to the geometry, additional information is required to describe a full detector simulation at runtime.  LCDD was designed to provide a complete description of complex experimental setups using an XML language.  Various types of detectors, from simple test beams to full, ``4 PI'' HEP detectors, can be modeled to an arbitrary level of detail using structured XML.  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 uses GDML to provide the complete 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.
 

-\subsection{Using LCDD in an Application}

+\section{Document Structure}

-The LCDD framework implements G4VUserDetectorConstruction, which is a required class for Geant4 user applications.  Using LCDD is simply a matter of registering its detector construction class with the Geant4 run manager.
-
-\begin{verbatim}
-theRunManager->SetUserInitialization(new LCDDDetectorConstruction());
-\end{verbatim}
-
-This allows the detector document to be specified using a macro command, such as the following, which will load a document from a remote URL.
-
-\begin{verbatim}
-/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.
-
-\begin{verbatim}
-/lcdd/url file:///local/path/to/sidloi3.lcdd
-\end{verbatim}
-
-Arguments to this macro command without a protocol are interpreted as local files.
-
-\begin{verbatim}
-/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.
-
-\subsection{GDML Volume Element}
-
-LCDD extends GDML by adding additional, optional elements to volumes.  The following example assigns to a volume a sensitive detector, a region, visualization attributes, and physics limits.
-
-\begin{verbatim}
-<volume name="EcalBarrel_layer0">
-    <materialref ref="Silicon"/>
-    <solidref ref="¯EcalBarrel_layer0_box"/>
-    <sdref ref="EcalBarrel"/>
-    <limitsetref ref="CalLimits"/>
-    <visref ref="CalVis"€¯/>
-    <regionref ref="CalRegion"/>
-</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.
-
-\subsection{Physical Volume IDs}
-
-Physical volumes in GDML are also extended so that they may have one or more physical volume IDs associated with them.  These values can be used in 64-bit identifiers that are attached to hits.  For instance, this is an example of assigning a layer number to a volume.
-
-\begin{verbatim}
-<volume name="DetectorEnvelope">
-    <materialref ref="Air"/>
-    solidref ref="DetectorEnvelopeBox"/>
-    <physvol>
-        <volumeref ref="LayerVolume"/>
-        <physvolid field_name="layer" value="1"/>
-    </phyvol>
-</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.
-
-\pagebreak
-
-\subsection{Document Structure}
-

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

@@ -310,7 +224,7 @@

 
 The 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 Geant4 sensitive detectors which are assigned to volumes, flagging them as readout components.  Hits in that volume will be accumulated by event into hits collections.  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 tha!
 t format's X[...]
 

-\section{Header Element}

+\subsection{Header Element}

 
 Every document begins with a header that provides basic meta data about the file and the detector.
 

@@ -326,7 +240,7 @@

 
 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.
 

-\section{Sensitive Detectors}

+\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.
 

@@ -348,7 +262,7 @@

 
 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}.
 

-\subsection{Trackers}

+\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, direction 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 high-granularity readout technologies, such as pixels or silicon strips.  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.
 

@@ -362,11 +276,11 @@

 
 Essentially the tracker is a relatively simple implementation of a sensitive detector that records the information from individual steps.  The persisted information can then be used later as input to more sophisticated digitization algorithms.
 

-\subsection{Scorer}

+\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.
 

-\subsection{Calorimeter}

+\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 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 one CalorimeterHit object created per virtual cell for the entire event.
 

@@ -381,11 +295,11 @@

 
 The calorimeter hits each have a list of individual energy contributions that correspond to single steps in the simulation, recording the PDG code of the particle and the positional information about that step, e.g. its endpoints.  Depending on the user requirements, this low-level step data can be saved into the output data, as it might be useful if the readout response depends on the distance of an energy deposition from the edge of the cell, etc.  The energy contributions may also be summed to obtain the total energy deposition in the cell for that event.
 

-\subsection{Hits Processors}

+\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 may use the segmentation, sensitive detector, and identifier classes 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.
 

-\section{Segmentation}

+\subsection{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.
 

@@ -393,7 +307,7 @@

 
 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.
 

-\subsection{Grid XYZ Segmentation}

+\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.
 

@@ -417,7 +331,7 @@

 
 This segmentation is used in geometries where the calorimeter barrel is modeled using a series of nested tubes, rather than modules containing planar layers.
 

-\subsection{Non-projective Cylinder Segmentation}

+\subsubsection{Non-projective Cylinder Segmentation}

 
 %% TODO: Section needs more content.
 

@@ -429,7 +343,7 @@

 
 The above segmentation will divide the surface of a cylinder into 10 x 10 mm cells.
 

-\subsection{Projective ZPlane Segmentation}

+\subsubsection{Projective ZPlane Segmentation}

 
 %% TODO: Section needs more content.
 

@@ -449,9 +363,9 @@

 %<global_grid_xyz grid_size_x="€¯50.0*mm"€¯ grid_size_y="50.0*mm" />
 %\end{verbatim}
 

-%Unlike most other segmentations, this algorithm uses the origin of the world volume rather than the volume's center.

+Unlike most other segmentations, this algorithm uses the origin of the world volume rather than the volume's center.

-\section{Identifiers}

+\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 it is accessible in an external framework.  The \textit{physvolid} elements or calorimeter segmentations may be referenced by these definitions.  Each sensitive detector may have 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 field values results in globally unique values for each hit.
 

@@ -474,7 +388,7 @@

 
 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.
 

-\section{Physics Limits}

+\subsection{Physics Limits}

 
 Physics limits can be assigned to volumes in order to tune certain parameters within the simulation.  For example, the range cut can be increased to limit the production of low-energy secondary particles in divergent electromagnetic processes.
 

@@ -499,12 +413,10 @@

 range\_min & range cut \\ \hline
 \end{tabular}
 

-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).

+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}

-%% TODO: Include reference to Geant4 webpage descriping the physics limits.

+\subsection{Regions}

-\section{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.''
 
 \begin{verbatim}

@@ -516,14 +428,11 @@

 
 The above example also specifies that particles which would not travel more than 10 millimeters will not be produced, and it also establishes an energy cut of 1 MeV for storing particles to the output.
 

-\section{Magnetic Fields}

+\subsection{Magnetic Fields}

-%% TODO: Section needs a lot of work!
-%% TODO: Add information on dipole, RZ and Cartesian maps.
-

 Geant4 can simulate in detail the interaction of particles with electromagnetic fields.  \cite{geant4fields}  LCDD provides a number of different field types for describing B-fields, ranging from simple approximations using fixed values to full three-dimensional grids.  Fields are defined globally in a list, and when their regions of validity overlap in space, the components are added at that point to compose an overlay.
 

-\subsection{Solenoid}

+\subsubsection{Solenoid}

 
 The \textit{solenoid} is a simplistic representation of a solenoid magnet with a Bz component.  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 can be used for collider-detectors where charged particles bend in the XY plane.
 

@@ -537,7 +446,7 @@

 </fields>
 \end{verbatim}
 

-\subsection{Dipole}

+\subsubsection{Dipole}

 
 The dipole models a Bx field that varies in the Z dimension given a list of coefficients, using a simple polynomial fit with an arbitrary number of terms.
 

@@ -553,7 +462,7 @@

 </dipole>
 \end{verbatim}
 

-\subsection{Box Dipole}

+\subsubsection{Box Dipole}

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

@@ -564,7 +473,7 @@

     bx="0.0" by="-1.5" bz="0.0" />
 \end{verbatim}
 

-\subsection{RZ Field Map}

+\subsubsection{RZ Field Map}

 
 An RZ field map can be used to simulate a variable field in the radial and Z directions with a uniform phi.
 

@@ -579,34 +488,30 @@

 </rz_field_map>
 \end{verbatim}
 

-The Z and R bins are computed from the global position, and an interpolation is performed to compute the B-field components at that point.

+The Z and R bins are computed from the global position.  Then the B-field (Bz, Br) is calculated by linear interpolation in 2 dimensions (Z, R) between these points.

-%% TODO: Add description of interpolation algorithm.

+\subsubsection{Field Map 3D}

-\subsection{Field Map 3D}

+The \textit{field\_map\_3d} represents a 3D Cartesian magnetic field map as a grid of values measured at 3D points.

-The \textit{field\_map\_3d} represents a full 3D Cartesian field map as a grid of $B_x, B_y$ and $B_z$ values at 3D points.

+Here is an example that references a data file.

-Here is an example.
-

 \begin{verbatim}
 <field_map_3d name="FieldMap3DTest" lunit="mm" funit="tesla"
     filename="data/HPS_b18d36_unfolded.dat"
     xoffset="2.117" yoffset="0.0" zoffset="45.72" />
 \end{verbatim}
 

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

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

 
 \begin{verbatim}
 x, y, z, Bx, By, Bz
 \end{verbatim}
 

-A full 3D interpolation is performed to determine the B-field component at a given point in the grid.

+A 3D interpolation is performed to determine the B-field (Bx, By, Bz) at a given point (x, y, z) in the grid, based on an algorithm developed from the PurgMagTabulatedField3D Geant4 code example. \cite{purgemag}

-%% TODO: Add description of interpolation algorithm.

+\subsection{Visualization}

-\section{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.
 
 The following is an example of visualization attributes.

@@ -620,6 +525,70 @@

 </display>
 \end{verbatim}
 

+\subsection{Using LCDD in an Application}
+
+The LCDD framework implements G4VUserDetectorConstruction, which is a required class for Geant4 user applications.  Using LCDD is simply a matter of registering its detector construction class with the Geant4 run manager.
+
+\begin{verbatim}
+theRunManager->SetUserInitialization(new LCDDDetectorConstruction());
+\end{verbatim}
+
+This allows the detector document to be specified using a macro command, such as the following, which will load a document from a remote URL.
+
+\begin{verbatim}
+/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.
+
+\begin{verbatim}
+/lcdd/url file:///local/path/to/sidloi3.lcdd
+\end{verbatim}
+
+Arguments to this macro command without a protocol are interpreted as local files.
+
+\begin{verbatim}
+/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.
+
+\subsubsection{GDML Volume Element}
+
+LCDD extends GDML by adding additional, optional elements to volumes.  The following example assigns to a volume a sensitive detector, a region, visualization attributes, and physics limits.
+
+\begin{verbatim}
+<volume name="EcalBarrel_layer0">
+    <materialref ref="Silicon"/>
+    <solidref ref="¯EcalBarrel_layer0_box"/>
+    <sdref ref="EcalBarrel"/>
+    <limitsetref ref="CalLimits"/>
+    <visref ref="CalVis"€¯/>
+    <regionref ref="CalRegion"/>
+</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.
+
+\subsubsection{Physical Volume IDs}
+
+Physical volumes in GDML are also extended so that they may have one or more physical volume IDs associated with them.  These values can be used in 64-bit identifiers that are attached to hits.  For instance, this is an example of assigning a layer number to a volume.
+
+\begin{verbatim}
+<volume name="DetectorEnvelope">
+    <materialref ref="Air"/>
+    solidref ref="DetectorEnvelopeBox"/>
+    <physvol>
+        <volumeref ref="LayerVolume"/>
+        <physvolid field_name="layer" value="1"/>
+    </phyvol>
+</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.
+
+\pagebreak
+

 \section{Examples}
 
 \subsection{Linear Collider}

@@ -649,9 +618,9 @@

 
 LCDD is a robust and complete system for modeling detectors using the Geant4 simulation toolkit.  It has been used by a variety of experimental physics collaborations to prototype various detector designs.  In particular, LCDD has become part of the common set of tools used to simulate ILC detector designs for CLiC, SiD and ILD.  The usage of GDML allows the framework to model geometries to an arbitrary level of detail while providing all the required, extra information for a complete detector description language.
 

-\section{Future Plans}

+%\subsection{Future Plans}

-The DD4HEP \cite{dd4hep} is a project from creating a new, common detector framework for HEP.  LCDD will be integrated with this system by implementing XML bindings for some of its key concepts, including segmentation.  This will allow LCDD to be used as part of a common simulation framework for that project.

+%The DD4HEP \cite{dd4hep} is a project from creating a new, common detector framework for HEP.  LCDD will be integrated with this system by implementing XML bindings for some of its key concepts, including segmentation.  This will allow LCDD to be used as part of a common simulation framework for that project.

 
 %% \begin{verbatim}
 %% \end{verbatim}

@@ -700,6 +669,12 @@

 
 \bibitem{xerces} http://xerces.apache.org/xerces-c/
 

+\bibitem{purgemag} http://geant4.cern.ch/support/source/geant4/examples/advanced/purging\_magnet/
+
+\bibitem{userlimits} https://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForApplicationDeveloper/html/ch05s07.html
+
+\bibitem{gdmlguide} http://lcgapp.cern.ch/project/simu/framework/GDML/doc/GDMLmanual.pdf
+

 \end{thebibliography}
 
 \end{document}