docs/pubs/0001-lcdd
--- docs/pubs/0001-lcdd/lcdd-paper.tex 2014-05-23 22:18:05 UTC (rev 3143)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex 2014-05-29 23:13:07 UTC (rev 3144)
@@ -52,7 +52,7 @@
%% \usepackage{epsfig}
%% The amssymb package provides various useful mathematical symbols
-\usepackage{amssymb}
+%%\usepackage{amssymb}
%% The amsthm package provides extended theorem environments
%% \usepackage{amsthm}
@@ -116,7 +116,7 @@
%% \[log in to unmask]
\begin{abstract}
-Geant4 is a powerful framework for simulating the interactions of particles with matter and fields, but it is also large and complex, requiring a considerable amount of expertise to utilize fully. It is advertised as a toolkit rather than an application. Most users want to have a program they may run rather than being required to create their own application. This requires that many of the simulation parameters are defined at runtime rather than embedded into source code. Specifically, in order to remove the requirement of providing customized code to define the experimental setup, the geometry must be defined by a data format rather than via a set of compiled classes. Some applications exist but tend to be domain specific, such as medical physics simulations for radiotherapy. GDML provides an XML geometry description, but not the other require information, which is usually called detector description, such as detectors and fields. !
We present here the Linear Collider Detector Des[...]
+Geant4 is a powerful framework for simulating the interactions of particles with matter and fields, but it is also large and complex. It is designed as a toolkit, rather than a pre-packaged executable. End users must assemble an application based upon their requirements. This requires a considerable amount of expertise both in the C++ language and the details of the framework. Providing a flexible application framework based on Geant4 which can meet the needs of many different users can alleviate this technical hurdle. This requires that many of the simulation parameters be defined at runtime, rather than embedded into source code. Ideally, in an application of this type, the geometry should be defined by a data format, rather than via a set of compiled classes. Some Geant4 applications using flexible input geometry formats do exist, but they tend to be specific to certain domains, such as medical physics simulations. GDML provides !
an XML geometry description, but not the other [...]
\end{abstract}
%% \begin{keyword}
@@ -140,83 +140,62 @@
%% still need to know the Geant4 physics, e.g physics lists, regions, step size...
%%
-Geant4 encapsulates the best knowledge of the interaction of particles with material and fields. It is distributed as a set of source files with compilation instructions, e.g. a toolkit that the user must assemble into a working application based on provided examples and tutorials. However, this can be a daunting task, as it requires expertise not only in the toolkit but in the details of C++ implementations. Typically, the end user must implement their own geometry setup using C++ code and instantiate and configure all the necessary components for the simulation, including physics list, user actions, fields, etc. Freeing the end user from such requirements has been the goal of the LCDD project, in order that they may focus on the physics questions they wish to explore.
+Geant4 is an application framework that has become the primary tool used in HEP for the simulation of particle interactions in matter and fields. It is distributed as a set of source files and examples with compilation instructions. Geant4 is an Object Oriented toolkit which is used to assemble a domain-specific application based on experimental requirements. The most complex and lengthy requirement to fulfill is usually the geometry description, which for complex detector setups can comprise hundreds, or even thousands of lines of custom code. Typically, the user must implement their own geometry setup and configure all the other necessary components for their particular simulation. This task can be daunting, as it requires a considerable level of expertise not only in the toolkit itself, but in the details of C++ syntax and implementations, a skill set that is becoming rarer as more scientific programmers move towards higher level l!
anguages like Java and Python.
-Individual Monte Carlo programs have typically used custom data formats and APIs for detector description, with complex interfaces that define shapes and readouts. User applications based on these frameworks implement their detectors using the programmatic interfaces. Some packages define their own runtime data formats for geometry description. Historically, the lack of standardization in this area of detector description has hindered data interchangeability between different tools. When geometry is defined by computer code, usually along with a set of associated run-time parameters, the user’s simulation package tends to greatly increase in size as the number of detector components grows, leading to maintenance issues and a proliferation of code.
+Some physics simulation programs have used their own custom-defined data input formats for detector description to alleviate some of this complexity. The lack of standardization in this area of detector description has hindered data interchangeability between different tools. When geometry is defined in an application by coding directly against an API such as Geant4's, the overall size of the simulation code base tends to increase greatly over time as more and more detector models and variations are added. This can lead to severe maintenance issues in the application, including a great amount of code duplication, the treatment of specific geometries as a "black box" with no real external data description, and a confusion and lack of separation between the areas of procedural code and data.
+Providing a comprehensive solution to these problems has been the goal of the Linear Collider Detector Description (LCDD) project. This framework was first introduced as a solution for defining and simulating a myriad of detectors and their variants for the International Linear Collider (ILC) project, and it is now being used successfully by several other experiments. By providing a clear and absolute separation between code and input data, researchers are freed from needing to now the complex details of geometry APIs and may instead focus on the defining the structure of their particular experiment.
+
+This paper will start with an overview of the GDML XML language and framework, on which LCDD is based. The LCDD extensions will be explained and described, with an XML example used to show the full document structure. Each primary XML element type will be explained in detail, along with an XML example of its usage. A solution will be given for authoring detector documents using another high-level format or "compact description." Examples will be given of projects that have used LCDD to model their experiments. Finally, future plans will be briefly discussed.
+
\section{GDML}
% topic: GDML/geometry
-%% geometry major part of the simulation setup
-%% solved some time ago with GDML data binding (references/history here)
+
%% how does it answer question? import/export/exchange
%% geometry is only a part of the project; still need regions, physics limits, fields, visualization, etc.
-GDML, or Geometry Description Markup Language, is an XML binding to the Geant4 geometry API, based upon work originally done for the LHCb project. That collaboration’s XML tools were used as the basis for a more generic geometry data format. In addition to Geant4, there is a GDML binding to the ROOT framework. This allows users to define their geometries using a data-driven approach rather than having to write C++ source code. Both frameworks provide services such as locating volumes given 3D points and traversing the geometry hierarchy.
+Geometry Description Markup Language (GDML) is an XML language for geometry description. This format allows users to define hierarchical geometry structures using a data language, rather than C++ source code that is customized for every detector variation. GDML fully describes materials, mathematical variables and definitions, geometric solids such as boxes and tubes, and a hierarchical structure of volumes. Materials are defined as either chemical elements or combinations thereof. Simple constants can be defined, as well as equations that use trigonometric functions. The support for different types of geometric solids is extensive, including Constructive Solid Geometry (CSG) solids defined algorithmically, and boundary representation (BREP) objects defined by planes forming a closed 3D surface. A logical volume is defined by a solid and a material and may optionally contain a tree of "daughter" volumes. A hierarchy of volumes defin!
es the complete detector structure.
-GDML can fully describe materials, variables and definitions, geometric solids, and a hierarchical structure of physical and logical volumes. Materials are defined as either chemical elements or combinations thereof. Simple constants can be defined, as well as equations that use trigonometric functions. The support for different types of geometric solids is extensive, including Constructive Solid Geometry (CSG) solids defined algorithmically, and boundary representation (BREP) objects defined by planes forming a closed 3D surface. A solid plus a material comprises a logical volume that can be used as a template and placed multiple times. The logical volumes are then placed in a nested hierarchy of solids, comprising the structure of the geometry. There is a top volume under which any number of child volumes are placed, which in turn may contain other volumes. Unlike in CAD software, each of these volumes must be bounded, or closed!
, and volumes may not overlap each other.
-
\section{LCDD}
-GDML provides the geometric data binding, but additional information is required to fully describe a detector’s parameters. Usually, this complete set of data is called “detector description”, of which geometry is only one part. Other frameworks that use a data centric approach for the geometry have generally still required other supplementary definitions to be included at runtime in order to fully define the detector. For instance, several experimental frameworks can read geometric XML but then require macros to be executed at runtime to define the readouts. But there are problems with this approach. This information is then not easily recoverable or associated with the appropriate geometry components during a later stage of reconstruction or analysis.
+In addition to the basic geometric layout of the experiment, additional information is required for fully describing a detector at runtime. This complete set of data is usually called "detector description”. Frameworks that use a data language such as GDML for geometry description have generally still required additional, auxiliary information at runtime, for example, through macro commands that define readouts and assign them to volumes. There are inherent problems and limitations to this approach. The supplementary information to the geometry is not easily accessible, if it is embedded in relatively unstructured, procedural macro files. Using ad hoc, runtime commands can also make it difficult to determine later which detector simulation parameters were used to produce a simulation data output file, or what readout parameters should be associated to a particular detector component.
-A more thorough approach is needed to guarantee the consistency and integrity of the detector data. The LCDD format was designed to provide a complete description of a complex physics detector at run-time to a Geant4-based program. It uses the GDML format for the geometric definitions and structure. GDML is then extended to include readouts, visualization, magnetic fields, physics limits, and identifier definitions. Various types of detectors, ranging from simple test beams to full “4 PI” detectors, are describable to an arbitrary level of detail, using only an XML file.
+A more complete approach is required to guarantee the consistency and integrity of the detector data. The Linear Collider Detector Description (LCDD) language was designed to provide a complete description of complex experimental setups. Various types of detectors, ranging from simple test beams to complex “4 PI” HEP detectors, can be modeled to an arbitrary level of detail, using an XML file rather than detector-specific C++ code. LCDD is built upon the GDML data format and C++ parser. It extends GDML’s XML data format by using built-in facilities of the XML Schema (XSD) language. GDML code infrastructure is reused by registering additional element handlers with GDML’s flexible parser class. One benefit of this approach is that the extended parser, without any alteration, can also read in plain GDML files, as well as LCDD.
-LCDD is built upon the GDML data format and C++ parser. It extends GDML’s XML data format by using facilities of the XML Schema (XSD) language. It reuses the GDML code infrastructure by registering additional element handlers with GDML’s parser. The extension point is the volume element, which may contain references to LCDD objects, such as sensitive detectors. One benefit of this approach is that the parser, without any alteration, can also read in plain GDML files.
+LCDD uses GDML to define the core geometric information. The GDML schema is formally extended using the \textit{extension} element so that the textit{gdml} root node appears embedded as part of the LCDD document. The GDML language is essentially left in tact, with an extension added to the schema so that the \textit{volume} element may contain optional references to data types defined in LCDD. The volume can be associated with detector readouts, visualization parameters, a region, physics limits, and other supplementary information, to provide a complete description of the detector to the simulation engine at runtime.
-%% put here a skeleton XML document showing the overall LCDD structure
-%% then work through the example linearly through rest of paper!!!
+\subsection{Document Structure}
-%% mention existence of schema that is checked at runtime with location reference (subsection?)
+Every LCDD document has the same basic structure. The top-level \textit{lcdd} element has a list of sections, one of which includes an entire GDML geometry. Aside from the header, the other sections all contain list of elements with a specific type. These elements can be referenced from the extended GDML language to associate the supplementary information with specific logical volumes defined by the geometry.
-\section{Volume Extension}
-
-%% FIXME: too much technical detail here (appendix?)
-
-The volume element in GDML is the only part of the format that is changed in order to connect it to associated LCDD objects. This is the portion of the XML schema definition that extends this part of GDML.
-
\begin{verbatim}
-<xs:extension base="VolumeType">
- <xs:sequence>
- <xs:element minOccurs="0" maxOccurs="1"
- name="sdref" type="ReferenceType"/>
- <xs:element minOccurs="0" maxOccurs="1"
- name="regionref" type="ReferenceType"/>
- <xs:element minOccurs="0" maxOccurs="1"
- name="limitsetref" type="ReferenceType"/>
- <xs:element minOccurs="0" maxOccurs="1"
- name="visref" type="ReferenceType"/>
- </xs:sequence>
-</xs:extension>
+<lcdd>
+ <header/>
+ <iddict/>
+ <sensitive_detectors/>
+ <limits/>
+ <regions/>
+ <display/>
+ <gdml>
+ <define/>
+ <materials/>
+ <solids/>
+ <structure/>
+ <setup/>
+ </gdml>
+ <fields/>
+</lcdd>
\end{verbatim}
-Aside from this addition, the GDML XML format is unchanged and is simply in-lined within its LCDD container. The LCDD extension classes handle these references. The volume elements can also be read as plain GDML by parser’s such as the one in ROOT, as long as it skips over these extension elements.
+The header has basic meta data about the document, such as who authored it. The \textit{iddict} contains identifier dictionaries that provide encodings for information that can be written into hit objects at runtime, including layer numbers and subdetector IDs. The \textit{sensitive\_detectors} element defines detectors that are assigned via reference to volumes. This allows hits to be written to an output file, containing energy, position and time information. The \textit{limits} are sets of physics limits that determine some behavior in the Geant4 physics engine. The \textit{display} element contains visualization settings that can be used to set colors and visibility of individual geometric volumes. The \textit{gdml} tag defines a GDML document, which must follow that format's syntax. Finally, the \textit{fields} element contains definitions of magnetic field components for the world volume. Each of these element types will be e!
xplained in detail.
-\section{Volume Element}
+The input document is checked by the parser for correctness at runtime against an XML Schema, which is located at a standard URL and can be accessed over the internet via the \textit{http} protocol. The parser is fault tolerant, in that minor errors, such as mis-ordering of child elements, may only result in warning messages. Other, more severe errors within a document, such as references to non-existent elements, will result in fatal exceptions that cause the application to exit.
-%% FIXME: move to end after all elements have been described
-
-LCDD extends GDML by adding optional elements to the volume element. A proper GDML parser will simply ignore these unknown tags when processing the file. There are no other alterations to standard GDML made by LCDD, so the extension is relatively clean. Deriving a valid GDML file from LCDD is therefore quite straightforward. The following example assigns to an example volume a sensitive detector, a set of physics limits, a detector region, a set of visualization attributes, and a region.
-
-\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 LCDD objects named in this volume description are actually references to previously defined elements. For example, the “EcalBarrel” sensitive detector is defined prior to the volume definition, and the parser will retrieve its definition from an in-memory data structure and assign the sensitive detector to the named volume. A similar strategy is used for the other objects referenced by the extended volume element.
-
\section{Header Element}
-Every LCDD file begins with a header that defines basic metadata about the detector. An author tag gives the names of the people who created the file, as well as an optional email contact. The detector tag within the header provides information about the detector, including the name, version, and an external URL, possibly containing additional information about the concept. Also contained in the header is the name of the external program that generated the file. This includes the name of the generator, its version, a reference to the original file that produced the LCDD, if there was one, and a checksum on the file, produced using an MD5 algorithm.
+Every LCDD document begins with a header that provides basic meta data about the file and the detector.
-Here is an example of a header from a detector used for SiD detector studies:
-
\begin{verbatim}
<header>
<detector name=”sidloi3”/>
@@ -227,41 +206,49 @@
</header>
\end{verbatim}
-The name of the detector is “sidloi3”. It was produced by the GeomConverter software package and the author is . The name of the detector is particularly useful, as it can be used as a key for looking up conditions information within reconstruction programs, as well as tagging output data files with the detector that was used to run the simulation. And the generator checksum will show whether two LCDD files are essentially the same.
+An author tag gives the names of the people who created the file, as well as an optional email contact. The detector tag provides a name that can be used as a "tag" of the document. The generator tag gives information about an external program that was used to generate the file, including a source file name, if applicable, a version of the generator, and a checksum that could be generated by an MD5 algorithm. There is a comment block that can contain a description and notes about the detector.
\section{Sensitive Detectors}
-The configuration and assignment of sensitive detectors to geometric volumes is a primary component of most Geant4 user applications. The sensitive detectors are used to accumulate positions and energy measurements from particle interactions in the material. These records can be used to construct hits that are persisted to data files for reconstruction and analysis. LCDD provides XML bindings to classes that implementation G4VsensitiveDetector. Each of these models a particular type of detector. In this scheme, there are three main types of sensitive detectors: trackers, scorers, and calorimeters.
+A "sensitive detector" is assigned to a logical volume to indicate that it is a readout component which is capable of producing hits. When a particle deposits energy into the volume, hit objects may be created and can later be written into an output file for analysis. The sensitive detectors typically accumulate position, time and energy measurements from particle interactions within the material of a volume. Usually these hits are grouped into collections by event.
-All extend a common XML element within the schema, which defines basic settings for every sensitive detector. Each detector has a name, used to uniquely identify it within the document. The name is used to connect individual logical volumes with their sensitive detectors. A sensitive detector also has an associated hits collection where the hits in the sensitive detector will be stored. Different detectors may write into the same hits collection. There is a a flag indicates whether or not the detector is an end cap. An energy cut setting can be used to discard hits that do not reach certain threshold. There is a verbosity setting to control print screen output from the detector while the simulation is running. Except for the name of the detector and its corresponding hit collection, which are required, these settings are all optional. There is also an optional child element on each detector, pointing to the identifier specificat!
ion that will be used to assign unique identifier
+Two primary types of detectors are modeled by the framework. Trackers typically 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 are used for the accumulation of energy in cellular volumes, and typically have much less granular position information. Calorimeters may be virtually segmented into cells using a child \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.
-%% describe abstractly concept of detectors
-%% use calorimeters and trackers as example solutions of a problem
+These types extend a common element which defines basic detector settings. The common settings for all \textit{sensitive\_detector} elements include the following.
+\begin{tabular}{ | l | l | }
+ \hline
+ name & unique string identifying the sub-detector \\ \hline
+ endcap\_flag & indicates if volume is a barrel or endcap \\ \hline
+ ecut & a minimum energy cut for individual hits \\ \hline
+ eunit & energy unit for cut \\ \hline
+ verbose & verbosity setting \\
+ \hline
+\end{tabular}
+
+Each detector has a name that is used to uniquely identify it within the document. This is used to associate logical volumes with a sensitive detector using the \textit{sdref} element. There is a a flag 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 setting can be used for discard hits that do not reach a certain threshold energy. There is a verbosity setting to control print screen output from the detector while the simulation is running. The name of the detector is required, and the rest of the settings are optional.
+
+The detectors have associated hits collections that contain objects which are implementations of the virtual hit class within Geant4. There is no output data binding providing by LCDD itself to persist this information. It is assumed that applications which include LCDD as a dependency will translate from these hit objects into a desired output format such as LCIO.
+
\subsection{Trackers}
-\par
-Trackers record the information from each step of a simulated track as it is propagated in the detector material. This data includes the step mid-point, its start and end points, the time in nanoseconds since the start of the event, and the dEdx. The Tracker is most commonly used to model high-granularity detectors, such as those with pixels or silicon strips. (LCDD does not provide advanced facilities for digitizing the hits within the simulation. This is generally done in a post-production reconstruction environment.) There is an additional option allowing hit aggregation of multiple steps across one volume. The default behavior records a hit for each step. The former is appropriate for cutting down on the size of the output files, whereas the latter can be used to study in detail the path of the particle in the sensor, including multiple scattering at each step.
+Trackers record information from each step of a simulated track as it propagates through a sensitive volume. The stored information includes the mid-point position, direction, length, global time in nanoseconds when the step occurred in the simulation, and the energy deposited along the step length. A \textit{TrackerHit} object is created for each step and stored into a hit collection. The Tracker is most commonly used to model high-granularity detectors, such as those with pixels or silicon strips. Advanced algorithms for digitizing the hits within the simulation are not provided, as it is assumed this would be done later in a reconstruction environment.
-\par
This is the XML for a simple tracking detector, similar to what might be defined for an ILC full detector concept:
\begin{verbatim}
-<tracker name=”SiTrackerBarrel” hits_collection=” SiTrackerBarrelHits”
- endcap_flag=”false” ecut=”0.0” eunit=”MeV” verbose=”0” combine_hits=”false”>
+<tracker name=”SiTrackerBarrel” hits_collection=”SiTrackerBarrelHits”>
<idspecref ref=”SiTrackerBarrelHits/>
</tracker>
\end{verbatim}
-The hits from this detector will not be combined, so that every step in the simulation will result in a hit in the output hits collection. It has no energy cut, so hits of all energies will be recorded. The endcap flag is turned off. The IDs of the hits are constructed using the referenced identifier specification, which is defined in another XML section.
-
\subsection{Scorer}
-The Scorer type is the simplest of the three 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 steps.
+The Scorer type is the simplest of the three 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.
\subsection{Calorimeter}
-The Calorimeter detector type can be used when it would be prohibitively expensive in terms of storage to write out all the individual particle steps like with the trackers. In general, these are sampling or homogeneous calorimeters with readouts using cells of a certain granularity. Within these cells, the energies deposited by particles in the detector are added together across each event to create one hit per cell in the output hits collection. To model the cell segmentation, each calorimeter optionally has an associated segmentation object that performs the readout segmentation on the fly.
+The Calorimeter detector is used to model total energy deposition of showering particles in a volume. These are generally either sampling calorimeters with alternating absorber and sensor layers, or homogeneous calorimeters such as arrays of Lead Tungstate crystals. Energy depositions are accumulated from multiple steps to determine the total energy deposited in the volume for the event. These energy depositions may be accumulated in an entire volume, such as a physical crystal, or the energy may be split across arrays of cells that are created through a virtual segmentation of the volume. In general, when the volumes are segmented, there is one hit object created per cell for the entire event. Each calorimeter may have an associated \textit{segmentation} object that bins the energy depositions by position during the simulation.
The following XML defines a calorimeter with uniform sized cells created by a virtual segmentation class.
@@ -272,14 +259,16 @@
</calorimeter>
\end{verbatim}
-The grid element divides the logical volumes that reference it into cells of that size, in this case 3.5 x 3.5 mm.
+The \textit{grid\_xyz} element will divide the detector's sensor layers into a grid of cells with size 3.5mm x 3.5mm.
\section{Segmentation}
-Sensitive volumes in a calorimeter detector usually require virtual subdivision in order that energy depositions can be summed and saved to hits with the proper granularity of identifier and position. In LCDD, the concept of artificially dividing these volumes is called “segmentation.” For highly segmented calorimeters, such as those found in ILC detector concepts, it would require literally millions of individual cell volumes to model the readouts as built, which could be prohibitive in terms of memory usage, as well as highly complicated to implement in the XML. There are also cases where simulating a complex readout is more straightforward when performed by an algorithm rather than modeling it geometrically, such as with projective readouts that have many different shapes and sizes of cells.
+Sensitive volumes in a calorimeter detector usually require virtual subdivision in order that energy depositions can be accumulated into cells. This concept of dividing geometric volumes is modeled by specific concrete implements of the \textit{segmentation} element. This algorithmic rather than geometric approach to segmented readout has other advantages. Modeling millions of individual cell volumes could be prohibitive in terms of memory usage. There are also cases in which modeling a readout system with an algorithm rather than geometry is more simple, such as in projective towers where there are many different shapes and sizes of cells which would be complicated to model using only solids and volumes.
-All segmentation elements extend a basic type that has no attributes. The parameters defining the size of the cells are specific to the sub-type of segmentation. This element is a child of the calorimeter that will use it, and each calorimeter detector is allowed to have one of these. The implementation classes define names that can be referenced in identifier descriptions for writing the cell field values at a certain position into the output identifiers of the hits. These are called bin values because they are similar to histogram bins.
+%% <=== Continue editing here.
+All segmentation elements extend a basic type which has no attributes. The parameters defining the size of the cells are specific to the sub-type of segmentation. This element is a child of the calorimeter that will use it, and each calorimeter detector is allowed to have one of these. The implementation classes define names that can be referenced in identifier descriptions for writing the cell field values at a certain position into the output identifiers of the hits. These are called bin values because they are similar to histogram bins.
+
\subsection{Grid XYZ Segmentation}
The grid\_xyz is one of the more generic types. It segments a volume into cells along its X, Y, or Z axes, or any combination thereof, creating a regular Cartesian readout grid. The bin values of the cells are available as the fields “x”, “y”, and “z” from the identifier specification. In this type of segmentation, the cell indices are numbered from –N to N, such that no information about the topology or boundaries of the segmented volume is required by the algorithm in order to represent the distance from the origin.
@@ -332,6 +321,10 @@
<global_grid_xyz grid_size_x=”50.0” grid_size_y=”50.0” />
\end{verbatim}
+\section{Hits Processors}
+
+%% TODO
+
\section{Identifiers}
Identifiers associate hits from sensitive detectors to their geometric components, as well as cell indices from the segmentation grid, in the case of calorimeters. Each sensitive detector may have an identifier specification associated with it. This is used to construct a unique 64-bit ID from physical volume numbers, such as layer number, and segmentation values, like X and Y cell indices. The user is ultimately responsible for making sure this combination of values uniquely identifies a hit.
@@ -411,23 +404,50 @@
</display>
\end{verbatim}
+\section{Volume Element}
-%% example N04 in Geant4 (N04.lcdd)
-%% mention compact XML description as way to intermediate between low level description and the user
+LCDD extends GDML by adding optional elements to the volume element. A proper GDML parser will simply ignore these unknown tags when processing the file. There are no other alterations to standard GDML made by LCDD, so the extension is relatively clean. Deriving a valid GDML file from LCDD is therefore quite straightforward. The following example assigns to an example volume a sensitive detector, a set of physics limits, a detector region, a set of visualization attributes, and a region.
+\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 LCDD objects named in this volume description are actually references to previously defined elements. For example, the “EcalBarrel” sensitive detector is defined prior to the volume definition, and the parser will retrieve its definition from an in-memory data structure and assign the sensitive detector to the named volume. A similar strategy is used for the other objects referenced by the extended volume element.
+
+\section{Macro Command Interface}
+
+%% TODO: example of loading an LCDD file using Geant4 macro commands
+
+\section{Compact Detector Description}
+
+%% TODO: information about compact description and why it can help solve issues with manually defining LCDD documents
+
\section{Examples}
+%% TODO: reference DD4Hep's N04.lcdd as implementation matching Geant4's N04 example
+
+\subsection{Linear Collider}
+
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 support, masks and dead material. LCDD was used to model and simulate these sub-detectors in a variety of physics scenarios. This includes an ECAL with several million readout channels as well as a Silicon Vertex Tracker with thousands of tracking modules per sub-detector.
-\begin{figure}[h]
+\begin{figure}[H]
\caption{The SiD Silicon Vertex Tracker Barrel.}
\includegraphics[width=0.5\textwidth]{sidloi3_tracker_barrel}
\end{figure}
+\subsection{Heavy Photon Search}
+
The Heavy Photon Search (HPS) is a direct Dark Matter search. Its test run detector was simulated using LCDD, in a variety of configurations.
-%% This is a placeholder graphic only from an OpenGL screen scrape!
-\begin{figure}[h]
+%% FIXME: This is a placeholder graphic only!
+\begin{figure}[H]
\caption{The HPS Experiment.}
\includegraphics[width=0.5\textwidth]{hps_detector}
\end{figure}
@@ -436,6 +456,10 @@
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.
+\section{Future Plans}
+
+TODO
+
%% \begin{verbatim}
%% \end{verbatim}
@@ -453,7 +477,7 @@
%% References with bibTeX database:
-\bibliographystyle{elsarticle-num}
+% \bibliographystyle{elsarticle-num}
% \bibliographystyle{elsarticle-harv}
% \bibliographystyle{elsarticle-num-names}
% \bibliographystyle{model1a-num-names}
@@ -465,11 +489,49 @@
% \bibliographystyle{model3-num-names}
% \bibliographystyle{model4-names}
% \bibliographystyle{model5-names}
-% \bibliographystyle{model6-num-names}
+% \style{model6-num-names}
+% \bibliography{sample}
-\bibliography{sample}
+% TODO: Use bibtex for bibliography
+\begin{thebibliography}{9}
+\bibitem{gdml} Geometry Description Markup Language for Physics Simulation and Analysis Applications, R. Chytracek, J. McCormick, W. Pokorski, G. Santin IEEE Trans. Nucl. Sci., Vol. 53, Issue: 5, Part 2, 2892-2896
+
+\bibitem{geant4} Geant4 - A Simulation Toolkit, S. Agostinelli et al., Nuclear Instruments and Methods A 506 (2003) 250-303
+
+\end{thebibliography}
+
\end{document}
%%
%% End of file `elsarticle-template-num.tex'.
+
+%% ======== after this is unused content, notes, junk, etc. ========
+
+%\section{Volume Extension}
+%
+%The volume element in GDML is the only part of the format that is changed in order to connect it to associated LCDD objects. This is the portion of the XML schema definition that extends this part of GDML.
+%
+%\begin{verbatim}
+%<xs:extension base="VolumeType">
+% <xs:sequence>
+% <xs:element minOccurs="0" maxOccurs="1"
+% name="sdref" type="ReferenceType"/>
+% <xs:element minOccurs="0" maxOccurs="1"
+% name="regionref" type="ReferenceType"/>
+% <xs:element minOccurs="0" maxOccurs="1"
+% name="limitsetref" type="ReferenceType"/>
+% <xs:element minOccurs="0" maxOccurs="1"
+% name="visref" type="ReferenceType"/>
+% </xs:sequence>
+%</xs:extension>
+%\end{verbatim}
+%
+%Aside from this addition, the GDML XML format is unchanged and is simply in-lined within its LCDD container. The LCDD extension classes handle these references. The volume elements can also be read as plain GDML by parser’s such as the one in ROOT, as long as it skips over these extension elements.
+
+%% ===============================================================
+
+%% table examples
+%% http://en.wikibooks.org/wiki/LaTeX/Tables#Basic_examples
+
+%% ===============================================================
\ No newline at end of file
[Note: Some over-long lines of diff output only partialy shown]