Commit in docs/pubs/0001-lcdd on MAIN
lcdd-paper.tex+16-123281 -> 3282
rewrite abstract.
restructure Introduction to improve flow.
docs/pubs/0001-lcdd
lcdd-paper.tex 3281 -> 3282
--- docs/pubs/0001-lcdd/lcdd-paper.tex	2014-08-27 04:24:45 UTC (rev 3281)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex	2014-08-27 18:27:55 UTC (rev 3282)
@@ -104,22 +104,23 @@

 
 \begin{frontmatter}
 

-\title{LCDD: A Complete Detector Description Language for Geant4 }%{Linear Collider Detector Description}

+\title{LCDD: A Complete Detector Description Package }%{Linear Collider Detector Description}

 
 \author{Jeremy McCormick\fnref{label1}}
 \author{Norman Graf\fnref{label1}}
 \address[label1]{SLAC National Accelerator Laboratory}
 
 \begin{abstract}

-Geant4 is a software framework for simulating the interactions of particles with matter and fields. It has become the standard tool for detector simulation in high energy physics and is increasingly being used in other fields, such as medical physics and 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 !
 the LCDD language and library, which extends GDML

+LCDD has been developed to provide a complete detector description package for physics detector simulations. All aspects of the experimental setup, such as the physical geometry, magnetic fields,and sensitive detector readouts, as well as control of the physics simulations, such as physics processes, interaction models and kinematic limits, are defined at runtime. Users are therefore able to concentrate on the design of the detector system without having to master the intricacies of C++ programming or being proficient in setting up their own Geant4 application. We describe both the XML-based file format as well as the processors which communicate this information to the underlying Geant4 simulation toolkit.

 \end{abstract}
 

-%% \begin{keyword}

+ \begin{keyword}
+Simulation software \sep Detector modeling \sep XML \sep Geometry \sep GDML \sep LCDD \sep Geant4

 %% keywords here, in the form: keyword \sep keyword
 %% example \sep \LaTeX \sep template
 %% MSC codes here, in the form: \MSC code \sep code
 %% or \MSC[2008] code \sep code (2000 is the default)

-%% \end{keyword}

+ \end{keyword}

 
 \end{frontmatter}
 

@@ -131,17 +132,21 @@

 %% main text
 \section{Introduction}
 

+
+As the size, complexity and cost of modern physics detectors increases, the need for detailed simulations of the experimental setup plays an increasingly important role. Designing detector systems composed of many disparate subsystems requires efficient tools to simulate the detector response and comparisons of different technology options, or geometric layouts, are facilitated if the results can be obtained with a flexible, easy-to-use simulation framework.
+

 %% free the end user from the need to know c++ coding or Geant4 architecture/class specifics
 %% still need to know the Geant4 physics, e.g physics lists, regions, step size...
 %%
 

-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.

+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 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, 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.

+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 issues 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 provides an XML language for describing detector geometries, but completely describing an experimental apparatus requires much more than the 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.

+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 the need 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.

 

-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.

+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 that have used LCDD to model their experimental detectors will be briefly described.  
+%Finally, future plans will be briefly discussed.

 
 \section{Complete Detector Description}
 

@@ -149,7 +154,6 @@

 
 Various types of detectors, from simple test beams to full ``$4\pi$'' HEP detectors, can be modeled to an arbitrary level of detail using the structured XML of the LCDD document.
 

-

 \subsection{GDML}
 
 The Geometry Description Markup Language (GDML) is an XML language for describing detector geometries using materials, mathematical variables and definitions, solids such as boxes and tubes, and a hierarchical structure of logical and physical volumes.  Originally developed as a standalone application, GDML has become part of the Geant4 source distribution. Therefore, it serves as an ideal starting point for a complete detector description language.  The syntax and usage of GDML is fully described in the \textit{GDML User's Guide}~\cite{gdmlguide} but a brief overview is provided here for completeness. Every valid GDML file has the following basic structure.

@@ -243,11 +247,11 @@

 
 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 GDM!
 L document, which must conform to that format's X[...]

+The \textit{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, embed!
 ded GDML document, which must conform to that f[...]

 
 \subsection{Header Element}
 

-Every document begins with a header that provides basic meta data about the file and the detector.

+Every document begins with a \textit{header} that provides basic meta data about the file and the detector.

 
 \begin{verbatim}
     <header>

@@ -501,7 +505,7 @@

 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). \ref{userlimits}

+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). %\ref{userlimits}

 
 \subsection{Regions}
[Note: Some over-long lines of diff output only partialy shown]
SVNspam 0.1

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