Author: ngraf
Date: Mon Nov 10 11:07:40 2014
New Revision: 3416
Log:
cleaning up references
Modified:
docs/pubs/0001-lcdd/lcdd-paper.tex
Modified: docs/pubs/0001-lcdd/lcdd-paper.tex
=============================================================================
--- docs/pubs/0001-lcdd/lcdd-paper.tex (original)
+++ docs/pubs/0001-lcdd/lcdd-paper.tex Mon Nov 10 11:07:40 2014
@@ -114,7 +114,7 @@
\address[label1]{SLAC National Accelerator Laboratory}
\begin{abstract}
-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.
+LCDD has been developed to provide a complete detector description package for physics detector simulations using Geant4. 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}
@@ -130,13 +130,13 @@
%%
%% Start line numbering here if you want
%%
- \linenumbers
+%%\linenumbers
%% 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.
+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. 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...
@@ -144,7 +144,7 @@
Geant4~\cite{geant4} is a software framework for simulating the detailed interactions of particles with matter and fields. It has become the standard tool for detector response simulations in high energy physics (HEP) and is increasingly being used in other fields, such as medical physics and the aerospace industry. Distributed as a set of source files and examples, the toolkit can be used to assemble a domain-specific application based upon experimental requirements. This requires a considerable amount of expertise in the C++ language and the details of configuring the framework. Typically, the most complex task is modeling the geometry and detectors, which for complex setups may take hundreds or even thousands of lines of code. This task can be daunting, and providing a flexible application which can meet the needs of many different users can alleviate these technical barriers.
-When geometry descriptions are defined by programming against an interface, the size of the code base will tend to increase greatly over time. Each major detector variant will usually require its own set of classes or a customization of existing ones, sometimes leading to severe maintenance issues. These problems may include a great amount of code duplication between different detector models, the treatment of geometries as ``black boxes'' without externally accessible data descriptions, and a lack of separation between procedural code and data. Ideally, the detector description would be provided by a data format rather than a set of compiled classes. GDML provides a language for describing detector geometries \cite{gdml}, but completely describing an experimental apparatus requires much more than the just the geometry.
+When geometry descriptions are defined by programming against an interface, the size of the code base will tend to increase greatly over time. Each major detector variant will usually require its own set of classes or a customization of existing ones, sometimes leading to severe maintenance issues. These problems may include a great amount of code duplication between different detector models, the treatment of geometries as ``black boxes'' without externally accessible data descriptions, and a lack of separation between procedural code and data. Ideally, the detector description would be provided by a data format rather than a set of compiled classes. GDML\cite{gdml} provides a language for describing detector geometries, but completely describing an experimental apparatus requires much more than just the geometry.
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.
@@ -159,7 +159,7 @@
\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.
+The Geometry Description Markup Language (GDML) is a 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 stand-alone 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.
\begin{verbatim}
<gdml>
@@ -777,14 +777,14 @@
\section{Using LCDD in an Application}
The LCDD framework implements G4VUserDetectorConstruction, which is a required class for Geant4 user applications. Using LCDD is simply a matter of registering its detector construction class with the Geant4 run manager, viz. {\tt theRunManager->SetUserInitialization(new LCDDDetectorConstruction());}.
-This allows the detector document to be specified using a macro command, which will load a document from a remote URL, viz.
+This allows the detector document to be specified using a macro command, which will load a document from a remote URL, viz.
%\begin{verbatim}
/lcdd/url http://www.lcsim.org/.../det.lcdd
%\end{verbatim}
-Local files can also be read in by using the
-{\tt file://} protocol:
+Local files can also be read in by using the
+{\tt file://} protocol:
%\begin{verbatim}
/lcdd/url file:///local/path/to/det.lcdd
@@ -805,28 +805,6 @@
\subsection{Linear Collider}
Detectors designed to exploit the physics discovery potential of lepton collisions at the Terascale will need to perform precision measurements of complex final states. The ability to model numerous detector geometries using LCDD was a crucial element in the design of the Silicon Detector~\cite{sid}, one of the two concepts currently being investigated to study the physics of high energy electron-positron collisions at the International Linear Collider (ILC)~\cite{ilc} and Compact Linear Collider (CLIC)~\cite{clic}. The optimization process for the tracker design started out with a number of simplified geometries, with the complexity of the simulations increasing as the designs became more mature. The current model is quite sophisticated, including most of the details of the engineering models for the support and assembly of the detectors, as well as the electronic readouts currently being considered. Figure ~\ref{fig:SiDxsecCAD} shows a cross section of a CAD model of the c
entral tracker. The corresponding Geant4 model is shown in Figure ~\ref{fig:sidloiTracker} .
-
-%\begin{figure}[ht]
-%\centering
-%\abovecaptionskip 0pt
-%\belowdisplayskip 0pt
-%\mbox{
-%\subfigure[SiD CAD cross section]{
-%\includegraphics[width=2.4in]{SiDTracker_cad_c}
-%\label{fig:SiDxsecCAD}
-%}\quad
-%\subfigure[SiD Geant4 model]{
-%\includegraphics[width=2.8in]{sidloi_TrackerCrossSection}
-%\label{fig:sidloiTracker}
-%}
-%}
-%\centering
-%\abovecaptionskip 0pt
-%\belowdisplayskip 0pt
-%\caption{The Silicon Detector micro-strip outer tracker and pixel vertex detector.}
-%\label{fig-all}
-%\end{figure}
-
\begin{figure}[ht]
\centering
@@ -850,18 +828,7 @@
\end{figure}
-%An orthographic cutaway view of the complete detector as implemented in the sidloi model is shown in Figure~\ref{fig:sidloiCutaway}.
-%\begin{figure}[ht]
-%\centerline{\includegraphics[width=7.5in]
-% {sidloiCutaway}}
-%\caption{Cutaway view of the Silicon Detector as implemented
-%in sidloi. Some support structures and layering details in the calorimeters
-%have been hidden to improve the visibility of the model.} \label{fig:sidloiCutaway}
-%\end{figure}
-
-
-%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~\cite{sid} has optimized the design of its full detector concept through many different iterations. This required the simulation of widely varying geometric layouts and readout schemes and the development of software to support this flexibility. The current design for its Detector Baseline Document (DBD) %is the sidloi3 detector, which
-%is composed of vertex, tracking, and calorimeter sub-systems, as well as supports, masks and various types of dead material. This includes an Electromagnetic Calorimeter with several million readout channels as well as a Silicon Vertex Tracker with thousands of tracking modules per sub-detector. LCDD was used to model and simulate these sub-detectors in a variety of physics scenarios.
+
A similar process was employed in the design of the calorimeters and instrumented return yoke, which functions as a muon detector. The flexibility of LCDD enabled the performance of various absorber materials, readout technologies and detector layouts to be studied all within the same simulation program. Figures~\ref{fig:SiDYZ}, \ref{fig:SiDXY}, \ref{fig:SiDTrackerCutaway} and \ref{fig:SiDCutaway} show the level of complexity supported by the LCDD package.
\begin{figure}[htpb]
\includegraphics[width=0.5\textwidth]{sidloi_YZ_Quadrant}
@@ -895,7 +862,7 @@
\subsection{Heavy Photon Search}
-The Heavy Photon Search (HPS) experiment is a direct Dark Matter search using a fixed target detector. The detector has a silicon microstrip tracker and a lead tungstate crystal calorimeter which have both been modeled to a high level of detail in simulation. LCDD has been used throughout the design process to study numerous detector models and variations for the 2012 Test Run as well as the full experiment, scheduled to run in the fall of 2014. In particular, LCDD has been invaluable for testing different configurations of the silicon tracker modules, including variations on the number of total layers and the layout of the sensors.
+The Heavy Photon Search (HPS)\cite{hps} experiment is a direct Dark Matter search using a fixed target detector. The detector has a silicon microstrip tracker and a lead tungstate crystal calorimeter which have both been modeled to a high level of detail in simulation. LCDD has been used throughout the design process to study numerous detector models and variations for the 2012 Test Run as well as the full experiment, scheduled to be commissioned in the fall of 2014. In particular, LCDD has been invaluable for testing different configurations of the silicon tracker modules, including variations on the number of total layers and the layout of the sensors.
Figure~\ref{fig:HPS} shows the detector layout as currently constructed.
\begin{figure}[htpb]
@@ -958,23 +925,23 @@
\begin{thebibliography}{9}
+\bibitem{geant4} Geant4 - A Simulation Toolkit, S. Agostinelli et al., Nuclear Instruments and Methods A 506 (2003) 250-303
+
\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
+\bibitem{gdmlguide} http://lcgapp.cern.ch/project/simu/framework/GDML/doc/GDMLmanual.pdf
+
+\bibitem{xerces} http://xerces.apache.org/xerces-c/
\bibitem{lcio} LCIO - A persistency framework for linear collider simulation studies, Computing in High Energy and Nuclear Physics, 24-28 March 200
\bibitem{geant4fields} https://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForApplicationDeveloper/html/ch04s03.html
-\bibitem{dd4hep} http://aidasoft.web.cern.ch/DD4hep
-
-\bibitem{xerces} http://xerces.apache.org/xerces-c/
-
\bibitem{purgemag} http://geant4.cern.ch/support/source/geant4/examples/advanced/purging\_magnet/
+
\bibitem{userlimits} https://geant4.web.cern.ch/geant4/UserDocumentation/UsersGuides/ForApplicationDeveloper/html/ch05s07.html
-\bibitem{gdmlguide} http://lcgapp.cern.ch/project/simu/framework/GDML/doc/GDMLmanual.pdf
\bibitem{sid}
http://silicondetector.org
@@ -985,71 +952,10 @@
\bibitem{clic}
http://clic-study.org/
+\bibitem{hps}
+https://confluence.slac.stanford.edu/display/hpsg/Heavy+Photon+Search+Experiment
+
\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.
-
-%% ===============================================================
-
-%\section{Compact Detector Description}
-
-%% TODO Flesh this out more
-%Though LCDD solves a certain problem, certain complexities are introduced. The format, especially the embedded GDML document, is highly verbose, and complex structures can be tedious to hand-code. For this reason, an intermediate format that translates from high level concepts and parameters to the low-level representation of LCDD can be helpful and time-saving.
-
-%A compact detector description has been used for ILC work and in the HPS experiment to represent many different detector variations.
-
-%\begin{verbatim}
-%<detector id="7" name="HcalBarrel"
-% type="PolyhedraBarrelCalorimeter2" readout="HcalBarrelHits"
-% vis="HcalBarrelVis" calorimeterType="HAD_BARREL">
-% <dimensions numsides="12" rmin="1419.0" z="3018.0 * 2"/>
-% <layer repeat="40">
-% <slice material = "Steel235" thickness = "1.89*cm" />
-% <slice material = "PyrexGlass" thickness = "0.11*cm" />
-% <slice material = "RPCGasDefault" thickness = "0.12*cm" sensitive = "yes" limits="cal_limits" />
-% <slice material = "PyrexGlass" thickness = "0.11*cm" />
-% <slice material = "G10" thickness = "0.3*cm" />
-% <slice material = "Air" thickness = "0.16*cm" />
-% </layer>
-%</detector>
-%\end{verbatim}
-
-%A Java library of converters is able to translate from the terse description into the hierarchical volume structure defined by LCDD.
-
-%% ===============================================================
-
-%% 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
-
-%% ===============================================================
########################################################################
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
|
