Author: ngraf
Date: Thu Nov 13 13:52:17 2014
New Revision: 3421
Log:
Minor text improvements. Fixed figure refs.
Modified:
docs/pubs/0001-lcdd/lcdd-paper.tex
Modified: docs/pubs/0001-lcdd/lcdd-paper.tex
=============================================================================
--- docs/pubs/0001-lcdd/lcdd-paper.tex (original)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex Thu Nov 13 13:52:17 2014
@@ -144,7 +144,7 @@
Geant4~\cite{geant4} is a software framework for simulating the detailed interactions of particles with matter and fields. It has become the standard tool for detector response simulations in high energy physics (HEP) and is increasingly being used in other fields, such as medical physics and the aerospace industry. Distributed as a set of source files and examples, the toolkit can be used to assemble a domain-specific application based upon experimental requirements. This requires a considerable amount of expertise in the C++ language and the details of configuring the framework. Typically, the most complex task is modeling the geometry and detectors, which for complex setups may take hundreds or even thousands of lines of code. This task can be daunting, and providing a flexible application which can meet the needs of many different users can alleviate these technical barriers.
-When geometry descriptions are defined by programming against an interface, the size of the code base will tend to increase greatly over time. Each major detector variant will usually require its own set of classes or a customization of existing ones, sometimes leading to severe maintenance issues. These problems may include a great amount of code duplication between different detector models, the treatment of geometries as ``black boxes'' without externally accessible data descriptions, and a lack of separation between procedural code and data. Ideally, the detector description would be provided by a data format rather than a set of compiled classes. GDML\cite{gdml} provides a language for describing detector geometries, but completely describing an experimental apparatus requires much more than just the geometry.
+The size of the code base almost always increases over time when geometry descriptions are defined by programming against an interface. 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\cite{gdml} provides a language for describing detector geometries, but completely describing an experimental apparatus requires much more than just the geometry.
Providing a comprehensive and flexible solution to these problems has been the goal of the Linear Collider Detector Description (LCDD) project. LCDD was introduced to simulate detector models for International Linear Collider (ILC) design studies. It is now being used successfully by several other groups to model their experiments. By providing a clear separation between code and detector description data, researchers are freed from needing to know the complex details of the Geant4 APIs. They may instead focus on defining the detector setup for their particular experiment using a structured data language.
@@ -153,7 +153,7 @@
\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 and physics limits and cuts. Visualization attributes are also included to facilitate viewing the detector.
+LCDD was designed to provide a complete description of complex experimental setups using an XML-based textual description. 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.
@@ -180,15 +180,15 @@
GDML's {\tt define} block contains expressions and definitions that are composed of double precision numbers, simple arithmetic operators (* / + -), trigonometric functions, and units. The CLHEP expression evaluator is used to parse and evaluate these mathematical statements. The processor predefines standard units for distance, weight, etc., as well as a set of constants such as the speed of light. Rotations and positions that will be referenced later to create physical volumes may also be included in this section.
-The {\tt materials} section has a list of {\tt material} and {\tt element} tags that bind to the G4Material and G4Element classes for materials and atomic elements. Materials are defined by atomic or mass composition and density. Material parameter sheets may be attached to provide pre-computed values for dEdx calculations and optical properties.
-
-The {\tt solids} section contains a collection of shape definitions that are used within the geometry. GDML has bindings to a large and nearly complete subset of the Constructive Geometry Solids (CSG) solids defined by the Geant4 geometry module, including tubes, boxes, trapezoids, tori, twisted tubes and boxes, polyhedra, and facetted shapes. Boolean subtraction and addition can be used with these primitives to define arbitrarily complex geometries.
+The {\tt materials} section has a list of {\tt material} and {\tt element} tags that bind to the Geant4 G4Material and G4Element classes for materials and atomic elements. Materials are defined by atomic or mass composition and density. Material parameter sheets may be attached to provide pre-computed values for dEdx calculations and optical properties.
+
+The {\tt 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 Solid Geometry (CSG) solids defined by the Geant4 geometry module, including tubes, boxes, trapezoids, tori, twisted tubes and boxes, polyhedra, and facetted shapes. Boolean subtraction and addition can be used with these primitives to define arbitrarily complex geometries.
The {\tt structure} section contains all of the geometry's logical volume definitions. A logical volume is composed of a shape and material, plus any number of ``child'' sub-volumes, defined by {\tt physvol} tags. The child volumes must contain a reference to a previously defined logical volume and an in-lined or referenced position and rotation. The top-level volume or ``world volume'', typically a large box containing the detector envelope volume, is defined in the {\tt setup} block using the {\tt world} element. The full hierarchy of volumes defines the complete geometric structure for the detector simulation.
\subsection{LCDD Document Structure}
-LCDD uses GDML to provide the complete physical geometry for the simulation. The {\tt gdml} root node is embedded as part of the LCDD document. The GDML language is essentially left intact with only minor additions. The main point of extension is the {\tt volume} element, which is redefined so that it may contain additional references to LCDD elements. The child volumes are also redefined so that they may have one or more physical volume identifiers attached to them. Using this approach, a GDML volume can be associated with important supplementary information such as readout parameters.
+LCDD uses GDML to provide the complete physical geometry for the simulation. The {\tt gdml} root node is embedded as part of the LCDD document. The GDML element is essentially left intact with only minor additions. The main point of extension is the {\tt volume} element, which is redefined so that it may contain additional references to LCDD elements. The child volumes are also redefined so that they may have one or more physical volume identifiers attached to them. Using this approach, a GDML volume can be associated with important supplementary information such as readout parameters. The following snippet outlines the structure of an lcdd document.
\begin{verbatim}
<lcdd>
@@ -239,10 +239,9 @@
\end{verbatim}
-LCDD is built upon the GDML data format and code infrastructure. GDML itself uses the Xerces C++ \cite{xerces} XML toolkit for parsing and schema validation. LCDD extends GDML by using built-in facilities of the XML Schema (XSD) language such as the {\tt xs:redefine} and {\tt xs:extension} elements. The GDML parser is also used by registering additional element handlers for LCDD types. This extended parser is then able to read both plain GDML and LCDD documents.
+LCDD is built upon the GDML data format and code infrastructure. GDML itself uses the Xerces C++ \cite{xerces} XML toolkit for parsing and schema validation. LCDD extends GDML by using built-in facilities of the XML Schema (XSD) language such as the {\tt xs:redefine} and {\tt xs:extension} elements. The GDML parser is also used by registering additional element handlers for LCDD types. This extended parser is then able to read both plain GDML and LCDD documents. One can include valid gdml documents into the lcdd document as long as no extensions (such as sensitive detectors or visualization attributes) are required.
Every LCDD file has the same basic structure that is enforced through XML schema checking at runtime against the document contents.
-
The LCDD parser checks the input document for correctness against the XML Schema, which is located at a standard URL accessible via the {\tt http} protocol, viz. {\tt www.lcsim.org/schemas/lcdd/1.0/lcdd.xsd}.
@@ -301,7 +300,7 @@
\subsubsection{Trackers}
-Trackers record information from each step as a track propagates through the material of a volume. The stored information includes the mid-point position, momentum of the track at that point, length of the step, global time, and the energy deposited along that path. A {\tt TrackerHit} object is created and stored into a hit collection to persist this information by event. The Tracker is most commonly used to model non-destructive, low-mass, high-granularity readout technologies used to measure the trajectories of charged particles, such as TPCs or silicon pixel and microstrip detectors. Algorithms for digitizing the hits within the simulation are not provided, as it is assumed this would be done later in a external analysis environment using the stored hit data.
+Trackers record information from each step as a track propagates through the material of a volume. The stored information includes the mid-point position of the G4Step, momentum of the track at that point, length of the step, global time, and the energy deposited along that path. A {\tt TrackerHit} object is created and stored into a hit collection to persist this information event 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:
@@ -385,10 +384,10 @@
grid_size_z="10.0*mm" />
\end{verbatim}
-The above segmentation will divide the surface of a cylinder into 10 x 10 mm cells.
+The above segmentation will divide the surface of a cylinder into 10 mm x 10 mm cells.
Figure ~\ref{fig:cylinderSeg} shows the expected projective $\phi$ segmentation,
-whereas Figure ~\ref{fig:cylinderzSeg} shows examples of both the projective and
+whereas Figure ~\ref{fig:cylinderZSeg} shows examples of both the projective and
non-projective types of cylindrical segmentation along the z axis.
\def\innerradius{1.5cm}
@@ -659,7 +658,7 @@
\subsubsection{Solenoid}
-The {\tt solenoid} is a simplistic representation of a solenoid magnet with a constant component aligned along the z axis. It has an inner and outer radius, and one Bz value is applied within the inner radius, and another between the inner and outer. This field type is commonly employed in collider detectors where charged particles bend in the XY plane.
+The {\tt solenoid} is a simplistic representation of a solenoid magnet with a constant magnetic field component aligned along the z axis. It has an inner and outer radius, and one Bz value is applied within the inner radius, and another between the inner and outer. This field type is commonly employed in collider detectors where charged particles bend in the XY plane.
The following defines a solenoid with a constant 5 Tesla field strength within the inner radius and a return field strength of -0.6 Tesla outside of that.
@@ -820,7 +819,7 @@
\centering
\includegraphics[width=2.8in]{sidloi_TrackerCrossSection}
-\label{fig:SiDxsecCAD}
+\label{fig:sidloiTracker}
\centering
\caption{The Silicon Detector micro-strip outer tracker and pixel vertex detector as shown in the Geant4 model.}
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the LCDET-SVN list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=LCDET-SVN&A=1
|
