 |
 |
| Commit in docs/pubs/0001-lcdd on MAIN | |||
| lcdd-paper.tex | +123 | -79 | 3213 -> 3214 |
Another round of edits on LCDD paper.
--- docs/pubs/0001-lcdd/lcdd-paper.tex 2014-08-04 16:36:12 UTC (rev 3213) +++ docs/pubs/0001-lcdd/lcdd-paper.tex 2014-08-04 22:05:20 UTC (rev 3214) @@ -123,7 +123,7 @@
%% \[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 applied to other disciplines, such as medical physics and applications in the aerospace industry. Since Geant4 is designed as a toolkit, rather than a pre-packaged executable, an application must be assembled based upon the user's requirements, requiring a considerable amount of expertise, both in the details of configuring the framework, and in the C++ language. Providing a flexible application which can meet the needs of many different users can alleviate these technical barriers. Ideally, the complete 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 mor! e than the just the geometry. We present here the[...]
+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 th! e LCDD language and library, which extends GDML[...]
\end{abstract}
%% \begin{keyword}
@@ -147,43 +147,41 @@
%% still need to know the Geant4 physics, e.g physics lists, regions, step size... %%
-Geant4 is a software framework developed for HEP, used to simulate the detailed interactions of particles in matter and fields. Distributed as a set of source files and examples, the toolkit is used to assemble a domain-specific application based upon experimental requirements. 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, as it requires a considerable level of expertise in the relevant APIs and the C++ language.
+Geant4 is a software framework for simulating the detailed interactions of particles in matter and fields. Distributed as a set of source files and examples, the toolkit can be used to assemble a domain-specific application based upon experimental requirements. 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, as it requires a considerable level of expertise in the relevant APIs and the C++ language.
-When geometries are defined by programming against an interface, the size of the code base will tend to increase greatly over time. Each major detector variant usually require its own set of classes. The ``pure code'' approach may lead to severe maintenance issues: a great amount of code duplication between different detector models; the treatment of specific geometries as a ``black boxes'' with no data description that is externally accessible; and a lack of separation between procedural code and data.
+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 issue 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.
-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 the code and the 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.
+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.
-This paper will provide an overview of the LCDD language and framework, with an example showing the full document structure. The extensions to GDML will be explained and described along with 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 discussed.
+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}
-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.
-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 a number of 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.
+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.
-The \textit{materials} section has a list of \textit{material} and \textit{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. Every logical volume in the geometry must have a material assigned to it.
+The \textit{materials} section has a list of \textit{material} and \textit{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 \textit{solids} block 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{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} block contains a nested hierarchy of geometric volumes. A volume is composed of a shape plus its material and may contain any number of sub-volumes, each of which has its own \textit{physvol} tag. The volumes in the \textit{physvol} elements are called ``child'' volumes of their ``parent'' volume. The child volumes must contain a reference to a logical volume, plus 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. This hierarchy of volumes thus 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 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}
-In addition to the geometry of an experiment, additional information is required to describe a full detector setup at runtime. This complete set of data is usually called ``detector description.'' Frameworks that use a data language such as GDML for geometry description generally still require additional information about the detector. For instance, macro commands might be executed that define readouts and assign them to previously defined volumes. But there are inherent problems and limitations to this approach. The supplementary information is not easily accessible outside the application, as it is embedded in unstructured macro files, making it difficult to determine later from an external environment which detector simulation parameters were used to produce an output file, or what readout parameters should be associated to a particular detector component.
+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 was designed to provide a complete description of complex experimental setups at runtime using an XML language. Various types of detectors, from simple test beams to full HEP detectors, can be modeled to an arbitrary level of detail using an XML file rather than macros or detector-specific C++ code. LCDD is built upon the GDML data format and its C++ parser, which is built using the Xerces \cite{xerces} XML framework. LCDD formally 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 parsing infrastructure is reused by registering additional element handlers for LCDD types with its parser class. The extended parser is able to read in plain GDML, as well as LCDD.
+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 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, with the main point of extension being the \textit{volume} element, which may contain optional references to additional XML elements defined outside of the GDML section. Using this approach, a volume can be associated with a sensitive detector, visualization parameters, a region, physics limits, and other supplementary information.
-
\subsection{Using LCDD in an Application}
-The LCDD framework implements G4VUserDetectorConstruction, which is a required class for user applications. This means that using LCDD is only a matter of registering this detector construction class with the Geant4 run manager.
+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 will then allow the detector document to be specified using a macro command, such as the following, which will load a document from a remote URL.
+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
@@ -201,33 +199,29 @@
/lcdd/url /local/path/to/sidloi3.lcdd
\end{verbatim}
-The detector document must be set 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{/control/initialize} macro command.
+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{/control/initialize} macro command.
-\subsection{Volume Element}
+\subsection{GDML Volume Element}
-LCDD extends GDML by adding additional, completely optional elements to the volume. (A plain GDML parser will simply ignore these unknown tags when processing the file or possibly emit warning messages.) Deriving valid GDML file from LCDD is therefore quite straightforward.
+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.
-The following example assigns to a volume a sensitive detector, set of physics limits, region, visualization attributes, and physics limits. -
\begin{verbatim}
<volume name="EcalBarrel_layer0">
- <materialref ref="Silicon"/>
+ <materialref ref="Silicon"/>
<solidref ref="EcalBarrel_layer0_box"/>
- <sdref ref="EcalBarrel"/> - <limitsetref ref="CalLimits"/>
+ <sdref ref="EcalBarrel"/> + <limitsetref ref="CalLimits"/>
<visref ref="CalVis"/>
- <regionref ref="CalRegion"/>
+ <regionref ref="CalRegion"/>
</volume>
\end{verbatim}
-The LCDD objects referenced in this volume description are previously defined XML elements in the document. For example, 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} and \textit{physvol} elements.
+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 extended so that they may have one or more physical volume IDs. These values can be used in 64-bit identifiers that are attached to hits (described later).
+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.
-For instance, this is an example of assigning a layer number to a volume. -
\begin{verbatim}
<volume name="DetectorEnvelope">
<materialref ref="Air"/>
@@ -239,41 +233,72 @@
</volume>
\end{verbatim}
-Any number of \textit{physvolid} elements can be assigned to a \textit{physvol}, so the assignment of these identifier values need not be limited by the hierarchical structure of the detector.
+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}
-The LCDD parser checks the input document for correctness against the XML Schema, which is located at a standard URL accessible over the internet via the \textit{http} protocol.
+Every LCDD file has the same basic structure that is enforced through XML schema checking at runtime against the document contents.
\begin{verbatim}
-http://www.lcsim.org/schemas/lcdd/1.0/lcdd.xsd
-\end{verbatim}
-
-Every LCDD file has the same basic structure that is enforced through XML schema checking at runtime against the document contents. The top-level \textit{lcdd} element has a list of sections, most of which contain a list of elements of a specific type such as sensitive detectors or regions. Each of these elements has a name assigned to it which is used as a unique ID within the document. There is a complete, embedded GDML geometry, and its volumes may reference previously defined LCDD elements such as sensitive detectors. In this way, the information in LCDD is linked by reference to volumes within GDML.
-
-The following snippet of pseudo-XML outlines the top-level structure of an LCDD file.
-
-\begin{verbatim}
<lcdd>
<header/>
- <iddict/> - <sensitive_detectors/> - <limits/> - <regions/> - <display/>
+ <iddict> + <idspec> + <idfield/> + </idspec + </iddict> + <sensitive_detectors> + <calorimeter/> + <tracker/> + <scorer/> + </sensitive_detectors> + <limits> + <limitset> + </limit> + </limitset> + </limits> + <regions> + <region/> + </regions> + <display> + <vis/> + </display>
<gdml>
<define/>
<materials/>
<solids/>
- <structure/>
+ <structure> + <volume> + <sdref/> + <limitsetref/> + <regionref/> + <visref/> + </volume> + </structure>
<setup/>
</gdml>
- <fields/>
+ <fields> + <solenoid/> + <dipole/> + <box_dipole/> + <rz_field_map/> + <field_map_3d/> + </fields>
</lcdd>
\end{verbatim}
-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 may 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. 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} tag is an embedded GDML document, which must conform to th!
at format's XML syntax. It may include the addit
+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
+\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.
+
+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}
Every document begins with a header that provides basic meta data about the file and the detector.
@@ -292,11 +317,11 @@
\section{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 automatically created, which may later be written into an output file for analysis. (Providing these 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 into collections by their sensitive detector and are grouped by event.
+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.
-Two primary types of detectors are modeled by the framework. Trackers store output from the simulation that corresponds closely to individual steps within a volume. This information can be used later to reconstruct in detail the exact particle momentum at the hit location. Calorimeters record the total accumulation of energy by event and typically have much less granular position information. Calorimeter volumes may be virtually segmented into cells using a \textit{segmentation} element. There is also a third type of detector called a \textit{scorer} which is essentially a simplified tracker. It can be used to insert scoring planes to derive simple flux counts.
+Two primary types of detectors are modeled by the framework. Trackers store output from the simulation that corresponds closely to individual steps within a volume. This information can be used later to reconstruct in detail the exact particle momentum at the hit location. Calorimeters record the total accumulation of energy by event and typically have much less granular position information. Calorimeter volumes may be virtually segmented into cells using a \textit{segmentation} element. There is also a third type of detector called a \textit{scorer} which is essentially a simplified tracker. It can be used to insert scoring planes to derive flux counts.
-These sensitive detectors extend a common element which defines basic settings, including the following.
+Sensitive detectors extend a common element which defines basic settings, including the following.
\begin{tabular}{ | l | l | }
\hline
@@ -308,13 +333,13 @@
\hline
\end{tabular}
-Each sensitive detector has a name that is used to uniquely identify it within the document. The \textit{sdref} element uses this name in order to associate a volume with a sensitive detector. The name of the 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 that is 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 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 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 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}.
+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}
-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. A \textit{TrackerHit} object is created and stored into a hit collection to persist this information. 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, 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.
This is an example of a simple tracking detector:
@@ -332,7 +357,7 @@
\subsection{Calorimeter}
-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 energy depositions may be summed for an entire volume, such as a physical calorimeter crystal. Or the energy depositions in one volume may be binned into an array of virtual cells. When volumes are artificially segmented, there is one calorimeter hit 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 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 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.
@@ -343,7 +368,7 @@
</calorimeter>
\end{verbatim}
-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, the 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.
+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.
\section{Hits Processors}
@@ -355,7 +380,7 @@
Sensitive volumes in a calorimeter, such as planar layers, usually require virtual subdivision. The \textit{segmentation} element models this division of geometric volumes into cells. The algorithmic approach has some advantages over using purely geometric constructs. Simulating millions of individual cell volumes could be expensive in terms of memory usage. There are also certain cases in which it is simpler to describe a readout system with an algorithm rather than pure geometry. For instance, projective calorimeter towers have many different shapes and sizes of cells depending on the radial distance of a layer from the origin, and this would be complicated to construct using only solids and volumes.
-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.
+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}
@@ -367,7 +392,7 @@
<grid_xyz grid_size_x="1.0*cm" grid_size_y="1.0*cm" />
\end{verbatim}
-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, say X and Y, with the third dimension, e.g. Z, left unsegmented.
+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}
@@ -383,6 +408,8 @@
\subsection{Non-projective Cylinder Segmentation}
+%% TODO: Section needs more content. +
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}
@@ -393,6 +420,8 @@
\subsection{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.
\begin{verbatim}
@@ -401,6 +430,8 @@
\subsection{Global Grid XYZ Segmentation}
+%% TODO: Section needs more content. +
The \textit{global\_grid\_xyz} segmentation divides a global space into regular sized rectilinear cells.
\begin{verbatim}
@@ -411,7 +442,7 @@
\section{Identifiers}
-Identifiers define formats for bit-packed numbers used to associate hits with their geometric and detector information. The values from physical volume IDs or segmentation bins may be written into these IDs. Each sensitive detector may have one identifier specification, which is used to create this 64-bit integer from detector information within the simulation. The user is ultimately responsible for making sure that the given combination of field values in the ID specification 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 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.
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.
@@ -430,7 +461,7 @@
</idspec>
\end{verbatim}
-The first five fields of the above identifier derive from the \textit{physvolid} values. The ``x'' and ``y'' fields are read from the segmentation bins at the hit position. Together, these values identify a unique cell and can be subsequently decoded within an external framework to find the detector information for a hit.
+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}
@@ -457,11 +488,13 @@
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).
+%% TODO: Include reference to Geant4 webpage descriping the physics limits. +
\section{Regions}
-Regions are assigned to geometric volumes using the \textit{region} element. These are collections of volumes sharing 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.''
+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}
<regions>
@@ -477,11 +510,11 @@
%% TODO: Section needs a lot of work! %% TODO: Add information on dipole, RZ and Cartesian maps.
-Geant4 can simulate 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 detailed grids of B-field component values. Fields are defined globally in a list. When their regions of validity overlap, the field components are added to make 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 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}
-The \textit{solenoid} is a simplistic representation of solenoid magnet with Bz component. It has an inner and outer radius. One Bz value is applied within the inner radius and another between the inner and outer. This field can be used for collider-detectors where charged particles should bend in the XY plane.
+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 following defines a solenoid with a 5 tesla field strength.
@@ -495,7 +528,7 @@
\subsection{Dipole}
-The dipole models a Bx field that varies in the Z dimension given a list of coefficients, using the following formula. This is a simple polynomial fit with an arbitrary number of terms.
+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.
$B_x=\sum_{i=1}^{n} zc_i$
@@ -511,12 +544,12 @@
\subsection{Box Dipole}
-The \textit{box\_dipole} is used to define a set of fixed B component values in a box region.
+The \textit{box\_dipole} is used to define a set of fixed component values in a box-like region.
\begin{verbatim}
-<box_dipole name="AnalyzingDipole" - x="2.117*cm" y="0*cm" z="45.72*cm" - dx="50.0*cm" dy="50.0*cm" dz="50.0*cm"
+<box_dipole name="AnalyzingDipole" + x="2.117*cm" y="0*cm" z="45.72*cm" + dx="50.0*cm" dy="50.0*cm" dz="50.0*cm"
bx="0.0" by="-1.5" bz="0.0" />
\end{verbatim}
@@ -525,7 +558,7 @@
An RZ field map can be used to simulate a variable field in the radial and Z directions with a uniform phi.
\begin{verbatim}
-<rz_field_map name="RZFieldMapTest" lunit="cm" funit="kilogauss"
+<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">
<rzB z="0.0" r="0.0" Bz="50.011" Br="0.0" />
<rzB z="10.0" r="0.0" Bz="49.996" Br="0.0" />
@@ -535,17 +568,19 @@
</rz_field_map>
\end{verbatim}
-The Z and R bins are computed from the global position, and a simple interpolation is performed to compute the B-field components at that point.
+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.
-\subsection{Field Map 3D}
+%% TODO: Add description of interpolation algorithm.
-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.
+\subsection{Field Map 3D}
+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.
\begin{verbatim}
-<field_map_3d name="FieldMap3DTest" lunit="mm" funit="tesla" - filename="data/HPS_b18d36_unfolded.dat"
+<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}
@@ -557,17 +592,19 @@
A full 3D interpolation is performed to determine the B-field component at a given point in the grid.
+%% TODO: Add description of interpolation algorithm. +
\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 allows one to attach visualization attributes to geometric volumes with an XML element that binds to the G4VisAttributes class. The supported visualization attributes include line style (broken or unbroken), drawing style (wireframe or solid), whether or not daughter volumes should be visible, and whether the volume itself is visible. The color of volumes may also be assigned using individual 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.
+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.
\begin{verbatim}
<display>
- <vis name="CalVis" line_style="unbroken" drawing_style="wireframe" - show_daughters="true" visible="true"> - <color R="1.0" G="0.0" B="0.0" alpha="1.0"/>
+ <vis name="CalVis" line_style="unbroken" drawing_style="solid" + show_daughters="true" visible="true"> + <color R="1.0" G="0.0" B="0.0" alpha="1.0"/>
</vis>
</display>
\end{verbatim}
@@ -587,7 +624,7 @@
The Heavy Photon Search (HPS) is a direct Dark Matter search. Its test run detector was simulated using LCDD, in a variety of configurations.
-%% TODO: Include more in this section.
+%% TODO: Include more about HPS in this section.
%% FIXME: This is a placeholder graphic only!
\begin{figure}[htpb]
@@ -595,6 +632,8 @@
\includegraphics[width=0.5\textwidth]{hps_detector}
\end{figure}
+%% TODO: Add sections on MuCol and CLiC. +
\section{Conclusion}
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.
@@ -709,6 +748,11 @@
%% ===============================================================
+%% Frameworks that use a data language such as GDML for geometry description generally still require additional information about the detector. For instance, macro commands might be executed that define readouts and assign them to previously defined volumes. But there are inherent problems and limitations to this approach. The supplementary information is not easily accessible outside the application, as it is embedded in unstructured macro files, making it difficult to determine later from an external environment which detector simulation parameters were used to produce an output file, or what readout parameters should be associated to a particular detector component. + + +%% =============================================================== +
%% table examples %% http://en.wikibooks.org/wiki/LaTeX/Tables#Basic_examples[Note: Some over-long lines of diff output only partialy shown]
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