docs/pubs/0001-lcdd

--- docs/pubs/0001-lcdd/lcdd-paper.tex	2014-09-03 17:27:59 UTC (rev 3297)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex	2014-09-03 20:52:25 UTC (rev 3298)
@@ -143,22 +143,22 @@

 
 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, especially if the number of different detectors is large.  These issues 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, 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 an XML 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 the need 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.

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

 
 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 that have used LCDD to model their experimental detectors will be briefly described.
 %Finally, future plans will be briefly discussed.
 
 \section{Complete Detector Description}
 

-LCDD was designed to provide a complete description of complex experimental setups using an XML language. In addition to the physical geometry, information such as detector identifiers, definitions of sensitive detectors, and descriptions of electromagnetic fields, if any, is required to describe a full detector. For the Geant4 detector response simulation, one also needs to be able to define attributes such as regions, physics limits and cuts, and physics list definitions. We have also included visualization attributes to facilitate viewing the detector.

+LCDD was designed to provide a complete description of complex experimental setups using an XML language. In addition to the physical geometry, information such as detector identifiers, definitions of sensitive detectors, and descriptions of electromagnetic fields, if any, is required to describe a full detector. For the Geant4 detector response simulation, one also needs to be able to define attributes such as regions and physics limits and cuts. Visualization attributes are also included to facilitate viewing the detector.

 
 Various types of detectors, from simple test beams to full ``$4\pi$'' HEP detectors, can be modeled to an arbitrary level of detail using the structured XML of the LCDD document.
 
 \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 syntax and usage of GDML is fully described in the \textit{GDML User's Guide}~\cite{gdmlguide} but a brief overview is provided here for completeness. Every valid GDML file has the following basic structure.

+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} but a brief overview is provided here for completeness. Every valid GDML file has the following basic structure.

 
 \begin{verbatim}
     <gdml>

@@ -183,7 +183,7 @@

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

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

 
 \subsection{LCDD Document Structure}
 

@@ -249,7 +249,7 @@

 
 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 \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 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, emb!
 edded GDML document, which must conform to that f[...]

+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 format!
 's XML syntax.  It may also include the additio[...]

 
 \subsection{Header Element}
 

@@ -285,7 +285,7 @@

 \hline
 \end{tabular}
 

-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 sensitive detector.  The name of the sub-detector is required, and the other settings are optional.  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.

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

@@ -309,7 +309,7 @@

 
 \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 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 \textit{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.
 

@@ -324,7 +324,7 @@

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

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

 
 \subsubsection{Segmentation}
 

@@ -461,7 +461,7 @@

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

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

 
 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.
 

@@ -470,12 +470,12 @@

 \begin{verbatim}
     <idspec name="EcalBarrelHits" length="64">
         <idfield signed="false" label="system" length="6" start="0"/>

-            <idfield signed="false" label="barrel" length="3" start="6"/>
-            <idfield signed="false" label="module" length="4" start="9"/>
-            <idfield signed="false" label="layer" length="6" start="13"/>
-            <idfield signed="false" label="slice" length="5" start="19"/>
-            <idfield signed="true" label="x" length="16" start="32"/>
-            <idfield signed="true" label="y" length="16" start="48"/>

+        <idfield signed="false" label="barrel" length="3" start="6"/>
+        <idfield signed="false" label="module" length="4" start="9"/>
+        <idfield signed="false" label="layer" length="6" start="13"/>
+        <idfield signed="false" label="slice" length="5" start="19"/>
+        <idfield signed="true" label="x" length="16" start="32"/>
+        <idfield signed="true" label="y" length="16" start="48"/>

         </idfield>
     </idspec>
 \end{verbatim}

@@ -743,7 +743,7 @@

 \subsection{Heavy Photon Search}
 
 The Heavy Photon Search (HPS) experiment is a direct Dark Matter search using a fixed target detector.  The detector has a silicon microstrip tracker and a lead tungstate crystal calorimeter which have both been modeled to a high level of detail in simulation. LCDD has been used throughout the design process to study numerous detector models and variations for the 2012 Test Run as well as the full experiment, scheduled to run in the fall of 2014.  In particular, LCDD has been invaluable for testing different configurations of the silicon tracker modules, including variations on the number of total layers and the layout of the sensors.

-Figure~\ref{fig:HPS} shows the detector layout as currently constructed. 

+Figure~\ref{fig:HPS} shows the detector layout as currently constructed.

 
 \begin{figure}[htpb]
 \begin{center}

@@ -825,7 +825,7 @@

 
 \bibitem{sid}
     http://silicondetector.org

-    

+

 \bibitem{ilc}
 http://www.linearcollider.org
 

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