docs/pubs/0001-lcdd
--- docs/pubs/0001-lcdd/lcdd-paper.tex 2014-08-26 22:10:41 UTC (rev 3279)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex 2014-08-27 04:17:07 UTC (rev 3280)
@@ -44,6 +44,7 @@
\usepackage{gensymb}
\usepackage{graphicx}
\usepackage{amsmath}
+\usepackage{tikz}
\graphicspath{ {images/} }
%% Use the option review to obtain double line spacing
@@ -103,7 +104,7 @@
\begin{frontmatter}
-\title{Linear Collider Detector Description}
+\title{LCDD: A Complete Detector Description Language for Geant4 }%{Linear Collider Detector Description}
\author{Jeremy McCormick\fnref{label1}}
\author{Norman Graf\fnref{label1}}
@@ -142,6 +143,13 @@
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{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.
+
+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.
@@ -171,14 +179,12 @@
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.
-\subsection{LCDD Overview}
+\subsection{LCDD Document Structure}
-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 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 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 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.
-\section{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}
@@ -232,7 +238,7 @@
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.
\begin{verbatim}
-http://www.lcsim.org/schemas/lcdd/1.0/lcdd.xsd
+ 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.
@@ -277,9 +283,13 @@
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, 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.
+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.
This is an example of a simple tracking detector:
@@ -291,13 +301,9 @@
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.
-\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{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.
+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 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.
@@ -314,7 +320,7 @@
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.
-\subsection{Segmentation}
+\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.
@@ -334,17 +340,17 @@
The default grid size value of zero for an axis results in that dimension being left unsegmented, so that the position is reported as zero. This actually translates to the center point along that axis in local coordinates. Typically, this segmentation type divides a plane into a rectilinear grid of cells in two dimensions, such as X and Y, with the third dimension, e.g. Z, left unsegmented.
-\subsection{Projective Cylinder Segmentation}
+\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.
-This is an example of a projective cylinder segmentation that divides the theta and phi regions into 1000 and 2000 bins, respectively.
+This is an example of a projective cylinder segmentation that divides the theta and phi regions into 32 and 32 bins, respectively.
\begin{verbatim}
- projective_cylinder ntheta="1000" nphi="2000" />
+ projective_cylinder ntheta="32" nphi="32" />
\end{verbatim}
-This segmentation is used in geometries where the calorimeter barrel is modeled using a series of nested tubes, rather than modules containing planar layers.
+This segmentation is used, for instance, in geometries where the calorimeter barrel is modeled using a series of nested tubes, rather than modules containing planar layers.
\subsubsection{Non-projective Cylinder Segmentation}
@@ -353,19 +359,86 @@
A \textit{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" />
+ <nonprojective_cylinder grid_size_phi="10.0*mm" grid_size_z="10.0*mm" />
\end{verbatim}
The above segmentation will divide the surface of a cylinder into 10 x 10 mm cells.
+Figure ~\ref{fig:cylinderSeg} shows examples of these two types of cylindrical segmentation.
+
+\def\innerradius{1.5cm}
+\def\outerradius{2.cm}
+\def\zLength{2.5cm}
+\def\nPhiSeg{32}
+\def\nThetaSeg{32}
+\def\zStep{.25cm}
+
+\begin{figure}
+\centering
+ \begin{tikzpicture}
+ % end view....
+ %draw the inner and outer radii
+ \draw[gray] (0,0) circle (\outerradius) circle (\innerradius);
+ % The 'spokes'
+ \foreach \i in {0,...,\nPhiSeg} {
+ \draw [gray,thin] (\i/\nPhiSeg*360:\innerradius) -- (\i/\nPhiSeg*360:\outerradius);
+ }
+ %axes
+ \draw[thick,->] (0,0) -- (\innerradius-0.5cm,0) node[anchor=west] {x};
+ \draw[thick,->] (0,0) -- (0,\innerradius-0.5cm) node[anchor=south] {y};
+ \node [below=0.2cm, align=flush center,text width=4cm] at (0,-\outerradius)
+ {
+ $Projective \: ( \phi ) \: Segmentation$
+ };
+
+ % side view
+ %shifting coordinate
+ \coordinate (shift) at (2*\zLength+2cm, 0);
+ \begin{scope}[shift=(shift)]
+ %projective z segmentation
+ % The 'spokes'
+ \begin{scope}
+ \clip (-\zLength,\innerradius) rectangle (\zLength,\outerradius);
+ \foreach \i in {0,...,\nThetaSeg} {
+ \draw [gray,thin] (\i/\nThetaSeg*180:0.) -- (\i/\nThetaSeg*180:2*\outerradius);
+ }
+ \end{scope}
+ \draw[gray] (-\zLength,\innerradius) rectangle (\zLength,\outerradius);
+
+ %nonprojective z segmentation
+ \draw[gray] (-\zLength,-\innerradius) rectangle (\zLength,-\outerradius);
+ \foreach \i in {0,...,20} {
+ \draw [gray,thin] (-\zLength+\i*\zStep,-\innerradius) -- (-\zLength+\i*\zStep,-\outerradius);
+ }
+ %axes
+ \draw[thick,->] (0,0) -- (\innerradius-0.5cm,0) node[anchor=west] {z};
+ \draw[thick,->] (0,0) -- (0,\innerradius-0.5cm) node[anchor=south] {r};
+
+ %descriptive text
+ \node [above=0.2cm, align=flush center,text width=8cm] at (0,\outerradius)
+ {
+ $Projective \:( \theta ) \: Segmentation$
+ };
+ \node [below=0.2cm, align=flush center,text width=8cm] at (0,-\outerradius)
+ {
+ $Nonprojective \: ( z ) \: Segmentation$
+ };
+ \end{scope}
+ \end{tikzpicture}
+
+\caption{Cylindrical segmentation showing examples of both projective and non-projective segmentation in z.} \label{fig:cylinderSeg}
+\end{figure}
+
+
+
\subsubsection{Projective ZPlane Segmentation}
%% TODO: Section needs more content.
-The \textit{projective\_zplane} segmentation divides an endcap zplane into projective segments, much as a \textit{projective\_cylinder} is used for a barrel.
+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.
\begin{verbatim}
- <projective_zplane ntheta="500" nphi="500" />
+ <projective_zplane ntheta="500" nphi="500" />
\end{verbatim}
%\subsection{Global Grid XYZ Segmentation}
@@ -405,7 +478,7 @@
\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.
+Physics limits can be assigned to volumes in order to tune certain parameters within the Geant4 simulation. For example, the range cut can be increased to limit the production of low-energy secondary particles in divergent electromagnetic processes.
The following example will restrict the step lengths of all particles to 5 mm.
@@ -443,15 +516,50 @@
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.
+\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.
+
+
\subsection{Magnetic Fields}
-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.
+Geant4 can simulate in detail the interaction of particles with electromagnetic fields. \cite{geant4fields} LCDD provides a number of different field types for describing magnetic fields commonly encountered in physics experiments, 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.
\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.
+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 following defines a solenoid with a 5 tesla field strength.
+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.
\begin{verbatim}
<fields>
@@ -490,8 +598,8 @@
\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.
-
+An RZ field map can be used to simulate a cylindrically symmetric field variable in the radial and Z directions.
+The field is input as a map of $B_z$ and $B_r$ on a regular grid of radius and z positions.
\begin{verbatim}
<rz_field_map name="RZFieldMapTest" lunit="cm" funit="kilogauss"
num_bins_r="67" num_bins_z="64" grid_size_z="10.0" grid_size_r="10.0">
@@ -503,28 +611,29 @@
</rz_field_map>
\end{verbatim}
-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.
+The Z and R bins are computed from the global position. Then the B-field ($B_z$, $B_r$) is calculated by linear interpolation in 2 dimensions (Z, R) between these points.
\subsubsection{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 3D Cartesian magnetic field map as a grid of values measured on a regular cartesian grid of 3D points.
-Here is an example that references a data file.
+The field values are contained in an external file with each line defining a point in the map.
\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" />
+ x, y, z, Bx, By, Bz
\end{verbatim}
-The field values are contained in an external file with each line defining a point in the map.
+A 3D interpolation is performed to determine the B-field ($B_x$, $B_y$, $B_z$) at a given point (x, y, z) in the grid, based on an algorithm developed from the PurgMagTabulatedField3D Geant4 code example. \cite{purgemag}
+Since field maps are normally measured or calculated with respect to the physical magnet's coordinate system, we allow for offsets to position the field in global coordinates.
+Here is an example that references an external data file.
+
\begin{verbatim}
- x, y, z, Bx, By, Bz
+ <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}
-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}
-
\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.
@@ -540,7 +649,7 @@
</display>
\end{verbatim}
-\subsection{Using LCDD in an Application}
+\section{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.
@@ -568,40 +677,7 @@
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}
@@ -611,23 +687,27 @@
Linear Collider detector research programs have simulated in detail the response of a number of different detector designs and subdetector technologies. The Silicon Detector (SiD) collaboration has optimized the design of its full detector concept through many different iterations. This required the simulation of widely varying geometric layouts and readout schemes and the development of software to support this flexibility. The current design for its Detector Baseline Document (DBD) is the sidloi3 detector, which is composed of vertex, tracking, and calorimeter sub-systems, as well as supports, masks and various types of dead material. This includes an ECAL with several million readout channels as well as a Silicon Vertex Tracker with thousands of tracking modules per sub-detector. LCDD was used to model and simulate these sub-detectors in a variety of physics scenarios.
\begin{figure}[htpb]
-\caption{The ILC Silicon Detector (SiD).}
\includegraphics[width=0.5\textwidth]{sid_detector}
\includegraphics[width=0.5\textwidth]{sid_detector2}
+\caption{The ILC Silicon Detector (SiD).}
+\label{fig:SiD}
\end{figure}
\begin{figure}[htpb]
+\includegraphics[width=0.5\textwidth]{sidloi3_tracker_barrel}
+\includegraphics[width=0.5\textwidth]{sidloi_Tracker_Cutaway_Closeup}
\caption{The SiD Silicon Tracker Barrel.}
-\includegraphics[width=0.5\textwidth]{sidloi3_tracker_barrel}
+\label{fig:SiDTracker}
\end{figure}
\subsection{Heavy Photon Search}
-The Heavy Photon Search (HPS) is a direct Dark Matter search using a fixed target experiment. The detector has a silicon strip 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 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.
+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.
\begin{figure}[htpb]
-\caption{The HPS Experiment.}
\includegraphics[width=0.5\textwidth]{hps_detector}
+\caption{The Heavy Photon Search detector.}
+\label{fig:HPS}
\end{figure}
%% TODO: Add sections on MuCol and CLiC.