Proposal for a Geometry Manager in The Beast Proposal for a Geometry Manager based upon GDML G....

Proposal for a Geometry Manager in The Beast

Proposal for a Geometry Manager based upon GDML

G. Cerati, S. Magni, D. Menasce


Statement of the problemStatement 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 areavailable 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:


The GDML approachThe GDML approach

What has recently emerged as a de-facto standard (at least for Geant4) to handlethis delicate problem of, broadly speaking, geometry description, is GDMLGDML.

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/


The GDML approachThe 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 filewith a detector’s

description

GDML filewith a detector’s

description

Schema file with a definition of thesyntax adopted in

the GDML file

Schema file with a definition of thesyntax adopted in

the GDML file

TheBeastTheBeast

GDMLAPI

GDMLAPI

DBMSDBMS GDMLAPI

GDMLAPI

Reconstr.code

Reconstr.code


A gdml file: detector.gdmlA gdml file: detector.gdml

This is a gdml file which describesglobal quantities needed by TheBeast to define the World (exp. Hall) and all materials used by theexperiment.

This is a gdml file which describesglobal quantities needed by TheBeast to define the World (exp. Hall) and all materials used by theexperiment.


This is a schema file which describesthe syntax of the valid tags used in thegdml file above.

This is a schema file which describesthe syntax of the valid tags used in thegdml file above.

the syntax definition filethe syntax definition file


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 filesadditional syntax definition files


Why a Why a schemaschema file? 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.


DetailsDetails

GDML provides several ways to define materials an to specify a particularmaterial for a detector (closely mimics what G4 provides to this extent)


User-code implementation using GDML APIUser-code implementation using GDML API

In the constructor of the DetectorConstructionIn the constructor of the DetectorConstruction

Initialize the GDML parserInitialize the GDML parser

Specify full path-name of input GDML fileSpecify full path-name of input GDML file

Tag this specific file with a nameTag this specific file with a name

Forward the file handle to the parserForward the file handle to the parser

In the destructor of the DetectorConstructionIn the destructor of the DetectorConstruction

Finalize the GDML parser (release memory)Finalize the GDML parser (release memory)


User-code implementation using GDML APIUser-code implementation using GDML API

In the Construct method of the DetectorConstructionIn the Construct method of the DetectorConstruction

Recover from the gdml file the pointer to the World description (what wastagged as “Detector” in the constructor)

Recover from the gdml file the pointer to the World description (what wastagged as “Detector” in the constructor)

When the user requires thedescription of, in this case,the World, the whole fatherchild relationship describedin the gdml representationis instantiated in the codewith just one call

When the user requires thedescription of, in this case,the World, the whole fatherchild relationship describedin the gdml representationis instantiated in the codewith just one call


Architectural choiceArchitectural choice

We have made an important architectural choice here:

in the current implementation, GDML does not provide support for iterativeoperations, therefore replicas of a logical volume in different space positionsare best implemented in the code rather than the gdml file.

Moreover, different sub-detectors are described in different gdml files, eachbeing parsed by a different instance of the GDML parser. The currentimplementation does not yet provide all pointers needed to combine andmanipulate objects from those different file.

What this means in practice, is that for the time being a detector descriptionis divided between gdml file and code components. Where possible algorithms,as well as numbers, are described in gdml, and the code only implementswhat the gdml syntax does not yet provide.


for example for example

From the gdml file get the total number of Silicon Strip planesFrom 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 DetectorConstructionIn the Construct method of the DetectorConstruction


What is required from the user’s sideWhat is required from the user’s side

As specified in an earlier talk (#3198), each sub-detector’s code resides ina sub-directory of plugins:

Each sub-detector’s directorywill contain one or more gdmlfiles with the complete description of the detector

Correspondingly, thedetector’s code willopen, parse and readthis/these files in orderto implement the detector’s geometry


What has been accomplished so farWhat has been accomplished so far

Both Silicon Strips and Pixel detectors have been described using GDML.


Prospects and to-do listProspects and to-do list

What has been proposed is version 0.0.0 of a Geometry Manager based onthe GDML protocol. Lots of work still needs to be done to fully validate thisapproach 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.


I/O persistency: a sneak pre-viewI/O persistency: a sneak pre-view

A key element still missing in The Beast project is an I/O serializer to implementthe persistency of data generated by the simulation. We are currently evaluating one of the two public interfaces already provided byGeant4, root-I/O (we are not planning studies of the other one, Objectivity, forvery obvious reasons).

The RootIO persistency model provides output files in a format readable bothby 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 headerfiles 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 theirneeds as well.


I/O persistency: a sneak pre-viewI/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 needto 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.

Proposal for a Geometry Manager in The Beast Proposal for a Geometry Manager based upon GDML G....

Documents

Transcript of Proposal for a Geometry Manager in The Beast Proposal for a Geometry Manager based upon GDML G....