1. Proposal for a Geometry Manager in The Beast Proposal for a Geometry Manager based upon GDML G. Cerati, S. Magni, D. Menasce

2. Proposal for a Geometry Manager in The Beast Statement of the problem The description of the BTeV detector (geometry, materials and placement of it’s subcomponents) must be stored externally to both simulation and reconstruction, absolutely not be hardwired in the code. Changes in the detector, with time, should be tracked and properly taken care of by a DBMS, the only authoritative source of the detector status at any given time. Simulation and reconstruction both need to share the ‘same’ description of the detector (although the word ‘same’ needs some caution in it’s definition) Tools could be developed to suitably validate any given description a user needs to feed to the simulation/reconstruction in order to trap inconsistencies in the setup at an early analysis stage (allows for fixes to be dealt with appropriately). Once stated that geometry should be defined in external files, several options are available to suitably implement means to read/and write these files and make values available in memory (several parsers exist on the market). This statement originates from the following requirements:

3. Proposal for a Geometry Manager in The Beast The GDML approach What has recently emerged as a de-facto standard (at least for Geant4) to handle GDML this delicate problem of, broadly speaking, geometry description, is GDML. There are many frameworks in High Energy Physics (HEP) which need the geometrical description of detectors. The geometry description very often comes in the form of source code the frameworks and applications are implemented (FORTRAN,C,C++,Java,Python) or is kept in various proprietary formats (formatted text, databases of each sort). If a geometry description is encoded in one of these forms it can't be easily or even impossible to share the whole or some part of the description by two or more frameworks/applications to save the user's time, space and effort. In addition when encoded in the implementation language, it makes the development cycle and testing of the geometry description even longer due to the fact that one has to rebuild the library or application each time the geometry has been modified. The extensible mark-up language (XML) comes very handy in this context because it gives the framework/application developers and users the way they can design the geometry description independently from the particular framework/application thus increase designer's productivity make maintenance easier and provide the possibility to build a set independent tools like editors, import/export components, visualization tools etc. There are many frameworks in High Energy Physics (HEP) which need the geometrical description of detectors. The geometry description very often comes in the form of source code the frameworks and applications are implemented (FORTRAN,C,C++,Java,Python) or is kept in various proprietary formats (formatted text, databases of each sort). If a geometry description is encoded in one of these forms it can't be easily or even impossible to share the whole or some part of the description by two or more frameworks/applications to save the user's time, space and effort. In addition when encoded in the implementation language, it makes the development cycle and testing of the geometry description even longer due to the fact that one has to rebuild the library or application each time the geometry has been modified. The extensible mark-up language (XML) comes very handy in this context because it gives the framework/application developers and users the way they can design the geometry description independently from the particular framework/application thus increase designer's productivity make maintenance easier and provide the possibility to build a set independent tools like editors, import/export components, visualization tools etc. Excerpt from http://savannah.cern.ch/projects/gdml/http://savannah.cern.ch/projects/gdml/

4. Proposal for a Geometry Manager in The Beast The GDML approach GDML is essentially two things: 1.an XML dictionary, where a syntax is defined to suitably describe geometry, materials, relationships etc... (this syntax definition is also called a Schema) 2.an API, bundled with an XML parser, to easily manage the read/write of a particular instance of a GDML file (like, for e.g., the description of a particular sub-detector) Before delving into details, let’s briefly describe the technique by an example: GDML file with a detector’s description GDML file with a detector’s description Schema file with a definition of the syntax adopted in the GDML file Schema file with a definition of the syntax adopted in the GDML file TheBeast GDML API GDML API DBMS GDML API GDML API Reconstr. code Reconstr. code

5. Proposal for a Geometry Manager in The Beast A gdml file: detector.gdml This is a gdml file which describes global quantities needed by The Beast to define the World (exp. Hall) and all materials used by the experiment. This is a gdml file which describes global quantities needed by The Beast to define the World (exp. Hall) and all materials used by the experiment.

6. Proposal for a Geometry Manager in The Beast This is a schema file which describes the syntax of the valid tags used in the gdml file above. This is a schema file which describes the syntax of the valid tags used in the gdml file above. the syntax definition file

7. Proposal for a Geometry Manager in The Beast It includes additional specific syntax definition files for entities like materials solids … It includes additional specific syntax definition files for entities like materials solids … additional syntax definition files

8. Proposal for a Geometry Manager in The Beast Why a schema file? A schema file serves two purposes: 1)provides a backbone for the parser: it defines the valid grammar of a gdml file, specifying tag types, tag names, father-child relationships among tags… 2)allows the parser to check the syntax and the integrity of a given gdml file, relieving the user from this tedious task. Appropriate error and warning messages are issued by the gdml parser when an error is detected in an input file. This is of great help for maintenance.

9. Proposal for a Geometry Manager in The Beast Details GDML provides several ways to define materials an to specify a particular material for a detector (closely mimics what G4 provides to this extent)

10. Proposal for a Geometry Manager in The Beast User-code implementation using GDML API In the constructor of the DetectorConstruction Initialize the GDML parser Specify full path-name of input GDML file Tag this specific file with a name Forward the file handle to the parser In the destructor of the DetectorConstruction Finalize the GDML parser (release memory)

11. Proposal for a Geometry Manager in The Beast User-code implementation using GDML API In the Construct method of the DetectorConstruction Recover from the gdml file the pointer to the World description (what was tagged as “Detector” in the constructor) Recover from the gdml file the pointer to the World description (what was tagged as “Detector” in the constructor) When the user requires the description of, in this case, the World, the whole father child relationship described in the gdml representation is instantiated in the code with just one call When the user requires the description of, in this case, the World, the whole father child relationship described in the gdml representation is instantiated in the code with just one call

12. Proposal for a Geometry Manager in The Beast Architectural choice We have made an important architectural choice here: in the current implementation, GDML does not provide support for iterative operations, therefore replicas of a logical volume in different space positions are best implemented in the code rather than the gdml file. Moreover, different sub-detectors are described in different gdml files, each being parsed by a different instance of the GDML parser. The current implementation does not yet provide all pointers needed to combine and manipulate objects from those different file. What this means in practice, is that for the time being a detector description is divided between gdml file and code components. Where possible algorithms, as well as numbers, are described in gdml, and the code only implements what the gdml syntax does not yet provide.

13. Proposal for a Geometry Manager in The Beast for example From the gdml file get the total number of Silicon Strip planes From the gdml file get the total number of Silicon Strip planes From the gdml file get the position and the rotation angle of each Silicon Strip plane From the gdml file get the position and the rotation angle of each Silicon Strip plane In the Construct method of the DetectorConstruction

14. Proposal for a Geometry Manager in The Beast What is required from the user’s side As specified in an earlier talk (#3198), each sub-detector’s code resides in a sub-directory of plugins : Each sub-detector’s directory will contain one or more gdml files with the complete description of the detector Correspondingly, the detector’s code will open, parse and read this/these files in order to implement the detector’s geometry

15. Proposal for a Geometry Manager in The Beast What has been accomplished so far Both Silicon Strips and Pixel detectors have been described using GDML.

16. Proposal for a Geometry Manager in The Beast Prospects and to-do list What has been proposed is version 0.0.0 of a Geometry Manager based on the GDML protocol. Lots of work still needs to be done to fully validate this approach and declare it the standard tool for BTeV. 1.as mentioned previously, Geant4 provides a plethora of methods to define volumes and place their replicas in space. Since GDML is rapidly evolving, our approach to divide algorithmic definitions between GDML and code needs careful monitoring over time. It may happen that GDML evolves in such a way to fully implement all Geant4 possibilities: this would greatly simplify the code, and we would therefore be happy to take advantage of interesting and useful development. 2.we have not yet tried to write a GDML file (to simulate the extraction of data from a DBMS repository). We would like to provide a template soon. 3.we definitely expect other groups to contribute to this effort. In particular the most urgent topic is the definition of the major geometrical items of each sub-detector (the Silicon Strip detector can be used as a template) Giuseppe is the right contact-person/tutor.

17. Proposal for a Geometry Manager in The Beast I/O persistency: a sneak pre-view A key element still missing in The Beast project is an I/O serializer to implement the persistency of data generated by the simulation. We are currently evaluating one of the two public interfaces already provided by Geant4, root-I/O (we are not planning studies of the other one, Objectivity, for very obvious reasons). The RootIO persistency model provides output files in a format readable both by stand-alone programs as well as root CINT scripts (good for quick debugging). To read-back a RootIO file, a stand-alone program needs a few Geant4 header files and one G4 library. This is a rather light-weight approach: after all a home-brewed I/O package will also come with his own header files and his library. The good thing about RootIO is that it already has a good reputation as an excellent I/O package, well supported and extensively used. On the other hand people already have programs that expect a different input format from a simulation package (like xdrio), and we need to address their needs as well.

18. Proposal for a Geometry Manager in The Beast I/O persistency: a sneak pre-view There are two ways to accomplish this: - we just cut-and paste pieces of code used to make data persistent in BTeVGeant and accommodate those in TheBeast. This can be done quickly but will be difficult to make it coexist with other persistency methods. - we try to interface these components to the abstract Geant4 interface so that later-on switching from one format to another one becomes easy. This requires substantial more time, but can be a paradigm to add more persistency models later (this approach offers more evolution options) Again, we are trying to cope with a situation were good design efforts need to coexist, for some time, with the need of people to accomplish things quickly. Both aspects are important of course, so we’ll try to do our best to make progress on both fronts, keeping the code flexible and efficient, allowing people to make real progress quickly while preserving a solid structure to the whole project.