Geometry Description Markup Language and its application-specific bindings

1
Geometry Description Markup Language and its
application-specific bindings

• Witek Pokorski, Radovan Chytracek, Jeremy
  McCormick, Giovanni Santin
• CHEP06, Mumbai, India
• 15.02.2006

2
Outline

• Background
• GDML Schema
• GDML readers/writers
• Some examples
• Conclusion

3
GDML - Motivation

• simulation toolkits come with their native
  geometry description formats
• many (most?) of the users do not implement
  geometry in those formats
• users use their own geometry description formats
  providing more flexibility
• integral parts of experiment software frameworks
• cannot be easily exported in application
  independent way
• therefore GDML has been developed
• to have an application independent and flexible
  geometry format
• to be able to interchange geometry between
  different applications for the purpose of
• physics validation/comparison, visualization,
  debugging

4
GDML design choice - why XML?

• purpose of GDML is to describe data
• to provide persistent form of geometry data
• not procedural, but markup language
• must be easy to read and write
• no heavy I/O system to read GDML
• format must be application independent
• possibility to edit/read geometry files is an
  advantage
• XML file can be edited using any editor
• geometry can be modified easily
• must be easy to extend and be modular

• GDML designed as an application of XML

5
GDML components

• GDML is defined through XML Schema (XSD)
• XSD XML based alternative to Document Type
  Definition (DTD)
• defines document structure and the list of legal
  elements
• XSD are in XML -gt they are extensible
• GDML can be written by hand or generated
  automatically
• 'GDML writer' allows writing-out GDML file
• GDML needs 'reader'
• 'GDML reader' creates 'in-memory' representation
  of the geometry description

user application (1)
GDML writer
GDML Schema
GDML file
GDML reader
user application (2)
6
GDML Schema

• defines document structure and the list of legal
  elements
• materials
• material, isotope, element, mixture
• solids
• box, sphere, tube, cone, polycone, parallepiped,
  trapezoid, torus, polyhedra, hyperbolic tube,
  elliptical tube, ellipsoid
• boolean solids
• volumes
• assembly volumes and reflections
• replicas and divisions
• parameterised volumes (position, rotation and
  size)
• first implementation

7
GDML document

• lt?xml version"1.0" encoding"UTF-8"?gt
• ltgdml xsinoNamespaceSchemaLocation"GDMLSchema/gd
  ml.xsd"gt
• ltdefinegt
• ltposition name"TrackerinWorldpos" unit"mm"
  x"0" y"0" z"100"/gt
• lt/definegt
• ltmaterialsgt
• ltmaterial formula" " name"Air" gt
• ltD value"1.290" unit"mg/cm3"/gt
• ltfraction n"0.7" ref"Nitrogen" /gt
• ltfraction n"0.3" ref"Oxygen" /gt
• lt/materialgt
• lt/materialsgt
• ltsolidsgt
• ltbox lunit"mm" name"Tracker" x"50" y"50"
  z"50"/gt
• lt/solidsgt
• ltstructuregt

positions, rotations
materials
solids
geometry tree
'world' volume
8
GDML reader
give pointer to world volume

• reads geometry from GDML file and creates its
  application specific (ROOT or G4) representation
  in memory
• most logic in application-independent part
• light application-depended bindings

Application (ROOT, G4)
Application binding (ROOT, G4)
create material, volume, etc
XML Engine (SAX)
GDML file
GDML Schema
9
GDML writer
User Application

• starting from 'in-memory' geometry tree (G4 or
  ROOT), generates the GDML file with that geometry
• application independent part generating XML
• containers for materials, solids, structure, etc
• 'light' application dependent bindings
• scanning the geometry tree and adding elements to
  the containers

dump geometry
Application binding (scanning tree)
add volume, etc
Document Builder
write document
GDML file
10
CMS detector G4-gtGDML-gtROOT
19000 physical volumes
snapshot provided by R.Maunder
thanks to Pedro Arce for help with running CMS
simulation
11
LHCb Detector G4-gtGDML-gtROOT
5000 physical volumes
snapshot provided by R.Maunder
12
Using GDML with Geant4

• to write
• include "WriterG4/G4GDMLWriter.h"
• G4GDMLWriter g4writer("GDMLSchema/gdml.xsd",
  "g4test.gdml")
• g4writer.DumpGeometryInfo(g4worldvolume)
• to read
• SAXProcessor sxp
• sxp.Initialize()
• ProcessingConfigurator config
• config.SetURI( "g4test.gdml" )
• sxp.Configure( config )
• sxp.Run()

instantiate GDML writer
pass the 'top' volume to the writer
instantiate and configure the processor
get pointer to 'top' volume
13
GDML processing - performance

• GDML G4reader/G4writer (C) tested on
• complete LHCb and CMS geometries
• parts of ATLAS geometry
• problem with full ATLAS geometry - use of custom
  solids
• for LHCb geometry (5000 physical volumes)
• writing out 10 seconds (on P4 2.4GHz)
• reading in 5 seconds
• file size 2.7 Mb (40k lines)
• for CMS geometry (19000 physical volumes)
• writing out 30 seconds
• reading in 15 seconds
• file size 7.9 Mb (120k lines)

14
GDML reader/writer in Python

• Python - an interesting alternative to C for
  implementing the GDML processing code
• dealing with XML in Python much easier (less code
  needed)
• Python very good for 'glueing' different
  applications together
• very easy interaction with C objects through
  generic Python bindings (PyROOT Reflex)
• used for G4-gtGDML-gtROOT geometry exchange
• enables running Geant4 GDML reader/writer
  ROOT from common Python prompt

15
GDML for ROOT (in Python)
Python SAX parser
import xml.sax import ROOT import
GDMLContentHandler ROOT.gSystem.Load("libGeom") g
eomgr ROOT.TGeoManager("World","GDMLGeo") gdml
handler GDMLContentHandler.GDMLContentHandler()
xml.sax.parse('test.gdml',gdmlhandler) geomgr.Set
TopVolume(gdmlhandler.WorldVolume()) geomgr.CloseG
eometry() gdmlhandler.WorldVolume().Draw()
PyROOT
GDML-specific parser extension
Standard TGeo
GDML parsing
get world volume from GDMLContentHandler
16
GDML facilitates physics validation

• we want to compare Geant4 with FLUKA in the case
  of Atlas TileCal testbeam
• we need a common geometry source
• we have G4 geometry 'in-memory'
• we export GDML
• GDML binding added to FluGG (Fluka Geant4
  Geometry interface)
• FLUKA (FLUGG) job run with GDML geometry
• GDML solves the problem of reimplementing geometry

17
GDML as primary geometry source

• Linear Collider - Jeremy McCormick, SLAC
• Linear Collider Detector Description (LCDD)
  extends GDML with Geant4-specific information
  (sensitive detectors, physics cuts, etc)
• GDML/LCDD is generic and flexible
• several different full detector design concepts,
  including SiD, GLD, and LDC, where simulated
  using the same application

SiD
LDC
GLD
18
GDML as primary geometry source

• Space Research - Giovanni Santin, ESA
• all geometry models for Geant4
• component degradation studies (JWST,
  ConeXpress,...)
• GRAS (Geant4 Radiation Analysis for Space)
• enables flexible geometry configuration and
  changes
• main candidate for CAD to G4 exchange format

ConeXpress
JWST NIRSpec
19
GDML as primary geometry source

• Anthropomorphic Phantom Project - Giorgio
  Guerrieri, Maria Grazia Pia, Susanna Guatelli,
  INFN
• Modelization of the human body and anatomy for
  radioprotection studies
• no hard-coded geometry, flexible configuration

20
Future developement

• support for new solids
• 'twisted' solids recently added to G4
• handling of multiple files
• enable splitting of GDML description into several
  files (containing different parts of the
  detector, etc)

21
Conclusions

• GDML is an application-independent, extensible
  geometry description language
• GDML proving very useful as the geometry
  interchange format
• geometries can be extracted from
  experiment-specific frameworks and then used in
  generic applications
• physics validation
• geometries can be moved between Geant4 and ROOT
• geometry visualization using ROOT
• GDML is used by several Geant4 users as the
  primary geometry description language
• avoids hard-coding the geometry
• allows running easily the same application with
  several different geometries