Author: [log in to unmask]
Date: Thu Mar 12 11:54:52 2015
New Revision: 3572

Log:
Reviewer's comments, our responses, and the revised version.

Added:
    docs/pubs/0001-lcdd/ResponseToReviewersComments.pdf   (with props)
    docs/pubs/0001-lcdd/ResponseToReviewersComments.txt
    docs/pubs/0001-lcdd/Reviewer'sComments.txt
Modified:
    docs/pubs/0001-lcdd/lcdd-paper_v2.tex

Added: docs/pubs/0001-lcdd/ResponseToReviewersComments.pdf
 =============================================================================
Binary file - no diff available.

Added: docs/pubs/0001-lcdd/ResponseToReviewersComments.txt
 =============================================================================
--- docs/pubs/0001-lcdd/ResponseToReviewersComments.txt	(added)
+++ docs/pubs/0001-lcdd/ResponseToReviewersComments.txt	Thu Mar 12 11:54:52 2015
@@ -0,0 +1,101 @@
+Ms. Ref. No.:  NIMA-D-15-00114
+Title: LCDD: A Complete Detector Description Package Nuclear Inst. and Methods in Physics Research, A
+
+Response to reviewer's comments:
+
+
+- Lines 28-30
+  Statement not clear. What does it mean "…when geometry descriptions are defined by
+  programming against an interface"?
+
++  This was clarified as follows: "The size of the code base will increase over time as
+  detector models are added with their own unique C++ code definitions."
+
+- Lines 47-49
+  Can you give examples of more than one (i.e. "several") groups/experiments making use
+  of LCDD other than the ILC/CLIC ?
+
++ Although the simulation software has been successfully used for detector studies for
+  the Muon Collider, a Proton Computed Tomography experiment and a geoparticle study, 
+  these efforts are not well documented. We have removed this statement and now reference
+  only its usage within the LC community and by the Heavy Photon Search experiment.
+
+- Lines 49-52
+  There are also drawbacks in 'data-oriented' solutions (or APIs on top of a software product),
+  as these can limit the potential offered by the underlying software (here Geant4), therefore
+  representing a risk to be carefully evaluated for the kind of applications these may apply.
+  I believe this should be explicitly mentioned.
+
++ We now explicitly mention possible limitations imposed by our development for the HEP 
+  collider application domain and mention that necessary extensions could be added.
+
+- Line 86
+  "… since ecome…"
+  The statement is incorrect. GDML itself in its latest versions has evolved to represent just the
+  schema, while the parsing engine for I/O persistency has become part of Geant4 (or any other
+  client adopting GDML). See http://cern.ch/gdml.
+
++ The typo has been corrected.
+  We have adopted the suggestion. "Originally released as a stand-alone application, the
+  GDML project has evolved to represent just the data schema, while a parsing engine for 
+  I/O persistency has become part of the standard Geant4 distribution."
+
+- Line 110
+  Missing reference to CLHEP.
+
++ Fixed.
+
+- Line 130
+  "Boolean subtraction, addition and intersection…"
+
++ Added.
+
+
+
+
+
+- Line 140
+  The world volume can be of any shape, not just a box.
+
++ Acknowledged.
+ 
+
+- Lines 148-251
+  One powerful property of GDML in order to reduce the need for extensions to the schema is the
+  possibility to use the "Auxiliary Information" block ('auxiliary' tag) which can be applied to volumes
+  to associate specific properties, like in this case, sensitive-detectors, visualisation attributes, regions,
+  user-limits or even fields!  An example on how to do this is also provided in the Geant4 distribution.
+  This would have allowed in your case to make the GDML part of the detector description portable
+  on any program compliant with GDML, without the need of extending the schema.
+  Have you considered that?
+
++ The LC community was one of the first, if not the very first, adopters of GDML within a Geant4 application. 
+  At that time this feature was not available, so we took the Extensible part of XML literally and
+  extended the schema. We can import GDML files created by other applications since the added tags are 
+  optional. 
+
+- Lines 600-611
+  See comment above for 2.2.
+
++ See our response above.
+
+- Lines 623-625
+  It is not clear to me the need for having this extension (which, again, complicates portability of
+  the GDML part), as long as volumes can be uniquely identified through touchables in Geant4.
+
++ The 64-bit identifiers attached to physical volume IDs are also used within reconstruction, analysis 
+  and visualization programs which have no connection to Geant4. 
+
+- Lines 807-809
+  References to figures are not correct. Should be 3. and 4. respectively.
+
++ Fixed.
+
+- In [6] and [8], replace "geant4.web.cern.ch" with "cern.ch"
+
++ Fixed.
+
+- Correct URL in [7] to: https://twiki.cern.ch/twiki/bin/view/Geant4/AdvancedExamplesPurgingMagnet
+
+ + Fixed.
+

Added: docs/pubs/0001-lcdd/Reviewer'sComments.txt
 =============================================================================
--- docs/pubs/0001-lcdd/Reviewer'sComments.txt	(added)
+++ docs/pubs/0001-lcdd/Reviewer'sComments.txt	Thu Mar 12 11:54:52 2015
@@ -0,0 +1,114 @@
+Ms. Ref. No.:  NIMA-D-15-00114
+Title: LCDD: A Complete Detector Description Package Nuclear Inst. and Methods in Physics Research, A
+
+Dear Dr. Graf,
+
+I have received the reviewers' comments on your paper that are appended below. They are advising that 
+you revise your manuscript before it can be published.  If you are prepared to undertake the work 
+required, I would be pleased to consider the revised submission.  
+ 
+If you decide to revise the work, please submit a list of changes or a rebuttal against each point 
+raised when you submit the revised manuscript.
+
+The revision should be submitted by
+21 Apr 2015 
+
+Revisions that do not address reviewer comments point-by-point will not be considered.
+
+To submit a revision, please go to http://ees.elsevier.com/nima/ and click "login" underneath the 
+journal title banner.  You may then type in your user name/password and click "Author Login." 
+
+Your username is: [log in to unmask] If you need to retrieve password details, please go to: 
+http://ees.elsevier.com/nima/automail_query.asp        
+
+On your Main Menu page is a folder entitled "Submissions Needing Revision".  You will find your 
+submission record there.  Also, the reviewer(s) may have uploaded detailed comments on your manuscript. 
+Click on the "Submissions Needing Revision" from your main menu, then click on "View Reviewer Attachments" 
+to access any detailed comments from the reviewer(s) that may have been included. 
+
+PLEASE NOTE: Nuclear Inst. and Methods in Physics Research, A would like to enrich online articles by 
+displaying interactive figures that help the reader to visualize and explore your research results. 
+For this purpose, we would like to invite you to upload figures in the MATLAB .FIG file format as 
+supplementary material to our online submission system. Elsevier will generate interactive figures 
+from these files and include them with the online article on SciVerseScienceDirect. If you wish, you 
+can submit .FIG files along with your revised submission.
+
+With best regards,
+
+Fabio Sauli
+Editor
+Nuclear Inst. and Methods in Physics Research, A
+
+Reviewers' comments:
+
+
+Reviewer #1: Summary:
+The content in the manuscript well describes the problem domain, providing a clear explanation with right 
+level of details of the basic ideas based on Geant4 for detector simulation and the motivations behind the 
+LCDD project. Some of the solutions chosen, with explicit extensions to the GDML schema are in some sense 
+unfortunate and could have been avoided in favour of a better compatibility with GDML and consequently 
+better exchange power for the pure geometrical part of the detector description (see comments below).
+The overall impression is positive and the manuscript's structure well balanced.
+
+1. Introduction
+- Lines 28-30
+  Statement not clear. What does it mean "…when geometry descriptions are defined by
+  programming against an interface"?
+- Lines 47-49
+  Can you give examples of more than one (i.e. "several") groups/experiments making use
+  of LCDD other than the ILC/CLIC ?
+- Lines 49-52
+  There are also drawbacks in 'data-oriented' solutions (or APIs on top of a software product),
+  as these can limit the potential offered by the underlying software (here Geant4), therefore
+  representing a risk to be carefully evaluated for the kind of applications these may apply.
+  I believe this should be explicitly mentioned.
+
+2.1 GDML
+- Line 86
+  "… since ecome…"
+  The statement is incorrect. GDML itself in its latest versions has evolved to represent just the
+  schema, while the parsing engine for I/O persistency has become part of Geant4 (or any other
+  client adopting GDML). See http://cern.ch/gdml.
+- Line 110
+  Missing reference to CLHEP.
+- Line 130
+  "Boolean subtraction, addition and intersection…"
+- Line 140
+  The world volume can be of any shape, not just a box.
+
+2.2 LCDD Document Structure
+- Lines 148-251
+  One powerful property of GDML in order to reduce the need for extensions to the schema is the
+  possibility to use the "Auxiliary Information" block ('auxiliary' tag) which can be applied to volumes
+  to associate specific properties, like in this case, sensitive-detectors, visualisation attributes, regions,
+  user-limits or even fields!  An example on how to do this is also provided in the Geant4 distribution.
+  This would have allowed in your case to make the GDML part of the detector description portable
+  on any program compliant with GDML, without the need of extending the schema.
+  Have you considered that?
+
+2.8 GDML Volume Element
+- Lines 600-611
+  See comment above for 2.2.
+
+2.9 Physical Volume IDs
+- Lines 623-625
+  It is not clear to me the need for having this extension (which, again, complicates portability of
+  the GDML part), as long as volumes can be uniquely identified through touchables in Geant4.
+
+4.1 Linear Collider
+- Lines 807-809
+  References to figures are not correct. Should be 3. and 4. respectively.
+
+References
+- In [6] and [8], replace "geant4.web.cern.ch" with "cern.ch"
+- Correct URL in [7] to: https://twiki.cern.ch/twiki/bin/view/Geant4/AdvancedExamplesPurgingMagnet
+
+
+
+
+
+
+For further assistance, please visit our customer support site at http://help.elsevier.com/app/answers/list/p/7923. 
+Here you can search for solutions on a range of topics, find answers to frequently asked questions and learn more 
+about EES via interactive tutorials. You will also find our 24/7 support contact details should you need any further 
+assistance from one of our customer support representatives.

Modified: docs/pubs/0001-lcdd/lcdd-paper_v2.tex
 =============================================================================
--- docs/pubs/0001-lcdd/lcdd-paper_v2.tex	(original)
+++ docs/pubs/0001-lcdd/lcdd-paper_v2.tex	Thu Mar 12 11:54:52 2015
@@ -152,7 +152,7 @@
 
 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. A large number of different detector designs were simulated without having to write customized C++ code for each model. 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. The framework was designed to support the requirements of HEP collider detector studies and does not, at present, provide data bindings of all related Geant4 classes. However extensions can be added if and when the need arises.
 
-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.
+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.  Its application to two different HEP experiments, one a collider detector, the other a fixed-target detector, will be briefly described.
 %Finally, future plans will be briefly discussed.
 
 \section{Complete Detector Description}
@@ -188,7 +188,7 @@
 
 The {\tt solids} section contains a collection of shape definitions that are used within the geometry.  GDML has bindings to a large and nearly complete subset of the Constructive Solid Geometry (CSG) solids defined by the Geant4 geometry module, including tubes, boxes, trapezoids, tori, twisted tubes and boxes, polyhedra, and facetted shapes.  Boolean subtraction, addition and intersection can be used with these primitives to define arbitrarily complex geometries.
 
-The {\tt structure} section contains all of the geometry's logical volume definitions.  A logical volume is composed of a shape and material, plus any number of ``child'' sub-volumes, defined by {\tt physvol} tags.  The child volumes must contain a reference to a previously defined logical volume and an in-lined or referenced position and rotation.  The top-level volume or ``world volume'', typically a large box containing the detector envelope volume, is defined in the {\tt setup} block using the {\tt world} element.  The full hierarchy of volumes defines the complete geometric structure for the detector simulation.
+The {\tt structure} section contains all of the geometry's logical volume definitions.  A logical volume is composed of a shape and material, plus any number of ``child'' sub-volumes, defined by {\tt physvol} tags.  The child volumes must contain a reference to a previously defined logical volume and an in-lined or referenced position and rotation.  The top-level volume or ``world volume'', typically but not necessarily a large box containing the detector envelope volume, is defined in the {\tt setup} block using the {\tt world} element.  The full hierarchy of volumes defines the complete geometric structure for the detector simulation.
 
 \subsection{LCDD Document Structure}
 
@@ -243,7 +243,7 @@
 \end{verbatim}
 
 
-LCDD is built upon the GDML data format and code infrastructure.  GDML itself uses the Xerces C++ \cite{xerces} XML toolkit for parsing and schema validation.  LCDD extends GDML by using built-in facilities of the XML Schema (XSD) language such as the {\tt xs:redefine} and {\tt xs:extension} elements.  The GDML parser is also used by registering additional element handlers for LCDD types.  This extended parser is then able to read both plain GDML and LCDD documents. One can include valid gdml documents into the lcdd document as long as no extensions (such as sensitive detectors or visualization attributes) are required.
+LCDD is built upon the GDML data format and code infrastructure.  GDML itself uses the Xerces C++ \cite{xerces} XML toolkit for parsing and schema validation.  LCDD extends GDML by using built-in facilities of the XML Schema (XSD) language such as the {\tt xs:redefine} and {\tt xs:extension} elements.  The GDML parser is also used by registering additional element handlers for LCDD types.  This extended parser is then able to read both plain GDML and LCDD documents. One can include valid GDML documents directly into the lcdd document as long as no extensions (such as sensitive detectors or visualization attributes) are required.
 
 Every LCDD file has the same basic structure that is enforced through XML schema checking at runtime against the document contents.
 
@@ -639,7 +639,7 @@
 
 \subsection{Physical Volume IDs}
 
-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.  
+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.
 These IDs, unlike a ''touchable'' within the Geant4 geometry hierarchy, can be decoded by an external analysis program to provide information such as a layer number. For instance, this is an example of assigning a layer number to a volume.
 
 \begin{verbatim}

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