1 Problem description

VecGeom [1] is a new software toolkit for geometry modeling, which aims to exploit fine-grained parallelism for computing and provide a standard for geometry description in a range of HEP toolkits including GeantV and ROOT. The Geometry Description Markup Language (GDML) [2] is a specialized XML-based language designed as an application-independent readable persistent format for describing the geometries of detectors associated with physics measurements. Currently I/O of VecGeom geometry is possible via ROOT geometry. We need to implement a standalone GDML I/O module to have geometry persistency without ROOT.

2 Methods

GDML is an XML schema, thus we can use standard tools for handling files and process the in-memory representation. Since the size of the files is relatively small and we need both reading and writing files, it is more convenient to work with the DOM XML representation. Also the validation of GDML files before processing allows to omit some checks, thus it is more convenient to use a validating XML parser. All the above motivates us to build the I/O on top of Xerces-C [3] parser. The Xerces-C library is distributed under the Apache 2.0 license which coincides with the most probable license of VecGeom (private communication).

The library will be split into the backend and the frontend. The Xerces-C backend will be used to read GDML files into DomDocument objects and to write them back. The backend can be tested by comparing loaded and then saved files with the original ones. Later one can add a backend based on libxml2, which is a bit faster and spread more widely, but lacks the validation capability.

The frontend will traverse the DomDocument to construct VecGeom geometry when loading, and visit all volumes in GeoManager to add them to the DomDocument when saving. The frontend can be implemented gradually starting from a small subset of GDML and finishing with the full GDML schema. The progress can be tracked by a set of test examples from a single sphere to the full CMS geometry.

3 Timeline

• April 23 – May 14 (Before the official coding time):
  • Familiarize myself with VecGeom package, GDML schema, XML standard, Xerces-C library, XML DOM, ROOT and Geant4 GDML integration.
  • Assemble a set of test cases of GDML files and minimal sub-GDML schemas each of them conforms to.
• May 14 – June 11 (Official coding period starts):
  • Design the interface. Write unit tests that compare native geometry loading and loading via ROOT. Write tests that compare loaded-and-saved files with the original.
  • Implement the backend.
  • Start the implementation of the frontend. Pass simple test cases (with only a couple of solids and without transformations or attributes).
• June 11 – June 15:
  • Prepare documentation.
  • Discuss the results with the mentors.
• June 15 – July 9 (Second coding period):
  • Support all solids present in VegGeom and GDML. Optionally do it by generating code based on the information in the GDML schema and VecGeom CppExporter.
  • Support transformations such as scaling, loops, rotations, Boolean operations.
• July 9 – July 13:
  • Prepare documentation.
  • Discuss the results with the mentors.
• July 13 – August 6 (Third coding period):
  • Add auxiliary information support.
  • Treat unforeseen special cases.
  • Pass most of the tests, including loading and saving the CMS geometry.
• August 6 – August 14 (Final Week):
  • Finish the code documentation.
  • Prepare the final GSoC report.
• August 14 – August 21:
  • Discuss the results with the mentors.
  • Make a conference presentation and other out-of-code documentation.

References