docs/pubs/0001-lcdd
--- docs/pubs/0001-lcdd/lcdd-paper.tex 2014-07-02 00:26:43 UTC (rev 3168)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex 2014-07-03 00:45:20 UTC (rev 3169)
@@ -142,7 +142,7 @@
Geant4 is an application framework that has become the primary tool used in HEP for the simulation of particle interactions in matter and fields. It is distributed as a set of source files and examples with compilation instructions. Geant4 is an Object Oriented toolkit which is used to assemble a domain-specific application based on experimental requirements. The most complex requirement is usually the modeling of the geometry and detectors, which for complex setups can comprise hundreds, or even thousands of lines of custom code. Typically, the user must implement their own geometry structure and configure all the other supplementary components for their particular simulation. This task can be daunting, as it requires a considerable level of expertise not only in the toolkit itself, but in the details of C++ syntax.
-When geometry is defined in an application by coding directly against an application programming interface (API) the size of the code base tends to increase greatly over time as more detector models and variants are added. Essentially, each detector variation tends to require its own set of classes. This can lead to severe maintenance issues in the application, including a great amount of code duplication between detector models; the treatment of specific geometries as a ''black box'' with no real external data description; and a confusion and lack of separation between the domains of procedural code and the data upon which it operates. Some physics simulation programs use their own custom-defined data input formats for detector descriptions to alleviate some of this complexity. But the lack of standardization in this area has hindered data interchangeability between different tools and requires learning new formats for each applicat!
ion.
+When geometry is defined in an application by coding directly against an application programming interface (API) the size of the code base tends to increase greatly over time as more detector models and variants are added. Essentially, each detector variation tends to require its own set of classes. This can lead to severe maintenance issues in the application, including a great amount of code duplication between detector models; the treatment of specific geometries as a ''black box'' with no real external data description; and a confusion and lack of separation between the domains of procedural code and the data upon which it operates. Some physics simulation programs use their own custom-defined data input formats for detector descriptions to alleviate some of this complexity. But the lack of standardization in this area has hindered data interchangeability between different tools and requires learning new formats for each applicatio!
n.
Providing a comprehensive and flexible solution to these problems has been the goal of the Linear Collider Detector Description (LCDD) project. This framework was first introduced to simulate detector designs and their variants for the International Linear Collider (ILC). It is now being used successfully by several other experiments. By providing a clear separation between code and detector description, researchers are freed from needing to know the complex details of the Geant4 APIs. They may instead focus on defining the simulation inputs for their particular experiment such as the detector geometry.
@@ -155,8 +155,8 @@
%% how does it answer question? import/export/exchange
%% geometry is only a part of the project; still need regions, physics limits, fields, visualization, etc.
-The Geometry Description Markup Language (GDML) is an XML format for geometry description. This format allows users to define hierarchical, geometry structures using a data language. GDML fully describes materials, mathematical variables and definitions, geometric solids such as boxes and tubes, and a hierarchical structure of logical and physical volumes.
-%Materials are defined as either chemical elements or combinations thereof. Simple constants can be defined, as well as equations that use trigonometric functions and basic mathematical operators. The support for different types of geometric solids is extensive, including simple shapes such as boxes and tubes or more complex tesselated volumes formed from an arbitrary number of surfaces. A logical volume is defined by a solid and a material and may optionally contain a tree of ''daughter'' physical volumes.
+The Geometry Description Markup Language (GDML) is an XML format for geometry description. This format allows users to define hierarchical, geometry structures using a data language. GDML fully describes materials, mathematical variables and definitions, geometric solids such as boxes and tubes, and a hierarchical structure of logical and physical volumes.
+%Materials are defined as either chemical elements or combinations thereof. Simple constants can be defined, as well as equations that use trigonometric functions and basic mathematical operators. The support for different types of geometric solids is extensive, including simple shapes such as boxes and tubes or more complex tesselated volumes formed from an arbitrary number of surfaces. A logical volume is defined by a solid and a material and may optionally contain a tree of ''daughter'' physical volumes.
GDML's \textit{define} block contains expressions and definitions read into the CLHEP Expression Evaluator. These expressions may contain double precision numbers, simple arithmetic operators (* / + -), trigonometric functions, and units. The processor predefines a number of standard units for distance, weight, etc. Important primary constants such as the speed of light are also predefined. Rotations and positions that will be referenced later to create physical volumes are also included in this area.
The \textit{materials} section has \textit{material} and \textit{element} elements that bind to the G4Material and G4Element classes for materials and atomic elements. Materials are defined by atomic or mass composition and density. Material parameter sheets may be attached to provide pre-computed values for dEdx calculations and similar algorithms. The materials defined here are referenced by \textit{volume} elements in the \textit{structure} area.
@@ -211,7 +211,7 @@
\begin{verbatim}
<header>
<detector name="sidloi3"/>
- <generator name="GeomConverter" version="1.0"
+ <generator name="GeomConverter" version="1.0"
file="./detectors/sidloi3/compact.xml" checksum="2152839912"/>
<author name="Jeremy McCormick" email="[log in to unmask]">
<comment>The SiD detector</comment>
@@ -262,7 +262,7 @@
\subsection{Calorimeter}
-The Calorimeter detector is used to record the energy depositions of particle showers. Typically these showers are composed of many individual steps, the details of which are usually not of interest. The energy depositions from all of the steps are accumulated to determine the total energy deposited in the volume. The energy may be accumulated in an entire volume, such as a physical crystal or may be split across arrays of virtual cells. When the volumes are artificially segmented, there is generally one hit object created per virtual cell for the entire event.
+The Calorimeter detector is used to record the energy depositions of particle showers. Typically these showers are composed of many individual steps, the details of which are usually not of interest. The energy depositions from all of the steps are accumulated to determine the total energy deposited in the volume. The energy may be accumulated in an entire volume, such as a physical crystal or may be split across arrays of virtual cells. When the volumes are artificially segmented, there is generally one hit 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.
@@ -438,6 +438,23 @@
The LCDD objects named in this volume description are actually references to previously defined elements. For example, the "EcalBarrel" sensitive detector is defined prior to the volume definition, and the parser will retrieve its definition from an in-memory data structure and assign the sensitive detector to the named volume. A similar strategy is used for the other objects referenced by the extended volume element.
+\section{Physical Volume IDs}
+
+Physical volumes in GDML are extended so that they may have one or more physical volume IDs. These can be used in the output of 64-bit identifiers attached to hits.
+
+For instance, this can be used to assign layer numbers.
+
+\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}
+
\section{Using LCDD in an Application}
LCDD implements the Geant4 class G4VUserDetectorConstruction so that using it in an application becomes very simple. It is simply a matter of registering the LCDD detector construction class with the Geant4 run manager.