Simulation Framework Subproject lcgapp.cern.ch/project/simu/framework/

1. Simulation Framework Subprojecthttp://lcgapp.cern.ch/project/simu/framework/ Witek Pokorski 19.09.2006 Simulation Project

2. Outline • Activities • Future plans, milestones, people involved • Conclusion Simulation Project

3. Activities • main activities • Geometry Description Markup Language (GDML) - R. Chytracek, W. Pokorski, B. Lloyd, (J. McCormick) • FLUGG applications/extensions - M. Gallas, W. Pokorski, A. Ribon • additional activities (W. Pokorski) • Python interface to Geant4 • Geant4 Geometry persistency using ROOT • Universal Monte Carlo truth handling Simulation Project

4. 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, but: • they are integral parts of experiment software frameworks • cannot be easily exported in application independent way • 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 Simulation Project

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 -> they are extensible • GDML files 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) Simulation Project

6. GDML Geant4 binding(1/2) • new autoconf/make based build system • support for new solids added • tetrahedron, tessellated solid, twisted box, twisted tube, twisted trapezoid • all Geant4 solids are now supported • support for optical surfaces and material property sheets added • matrices introduced • loops (for multiple placements) introduced Simulation Project

7. GDML Geant4 binding (2/2) • support for modular GDML geometries • several standalone GDML files can now be combined together within another 'top level' GDML file • GDML writer can now split geometry in modules LHCb HCal Ecal Muon ... Module1 Module2 ... Simulation Project

8. GDML ROOT binding • preliminary version of GDML binding integrated within ROOT (starting from 5.12/00) • fully transparent use following standard import/export mechanism for geometry in ROOT • support for all ROOT solids and geometry constructs • no support yet for modular GDML description • no support for loops • GDML->ROOT reader presently undergoing major re-engineering to improve speed Simulation Project

9. ST - Viewer STEP files An interactive tool for viewing 3D CAD information ST – Viewer uses an internal file format (.geom & .tree) to store geometry info GDML Output File STEPGDML Equivalent to the original STEP file Contains only tessellated solids Library functions created to convert STEP files into GDML files CAD(STEP) -> GDML converter • 'first order' approach to use CAD geometries for Geant4 simulation Simulation Project

10. FLUGG extensions - motivation • to compare FLUKA simulation output with Geant4 simulation output in a real-life setup (test-beam validation) • in order to reduce the implementation effort (and number of bugs) the maximum number of elements should be common to both G4 and FLUKA applications • common source of geometry • same format of the simulation output allowing common digitization/analysis • to come up with a reusable setup which is as much application-independent as possible Simulation Project

11. FluGG • Fluka Geant4 Geometry Interface (FluGG) developed by P.Sala and S.Vanini • GDML 'detector construction' for FLUGG has been implemented • allows loading any GDML geometry file into FLUGG • HitsManager implemented to mimic Geant4 'sensitive detectors' • ROOT I/O added for hits persistency • RootIO class deals with storing the hits • the .root file can then be read by any other application (digitization) performing processing and analysis of the hits G4 geometry Input card FluGG FLUKA Fluka output Simulation Project

12. 'Extended' FluGG GDML file Input card FluGG FLUKA Hits Manager OO Hits Root IO Simulation Project

13. Pythonization of G4 - motivation • to use Python for the construction of Geant4 simulation applications • to allow quick prototyping and testing • to add flexibility in the configuration • to make the application setup more homogenous • to use Python shell as a powerful user interface for interactive running of Geant4 • to use Python as the 'glue' between simulation and analysis applications • to allow interactive simulation and analysis sessions • to facilitate debugging of the simulation setups Simulation Project

14. G4 pythonization using PyROOT • we have demonstrated that with Reflex/PyROOT, Python binding for Geant4 comes for free • Reflex dictionary provides fully non-intrusive introspection for Geant4 classes • PyROOT uses that dictionary to provide dynamic Python binding • the Reflex dictionary for Geant4 classes could be build during standard installation procedure • improves modularization of Geant4 applications • provides natural support for dynamic loading of components Simulation Project

15. G4 geometry persistency using ROOT • Geant4 does not come with a concrete built-in persistency mechanism for the geometry objects • the Geant4 geometry tree has to be 'rebuilt' each time • our goal: provide way of quick saving and reading back the G4 geometry in/from a (binary) file using ROOT I/O • nicely extends the functionality of the toolkit • remark: this is a different use-case from GDML, where universality of the format was top-priority and not the speed Simulation Project

16. G4 geometry persistency - status • a number of technical issues has been identified and solved both in Geant4 and ROOT • final fixes/extensions in ROOT expected to be implemented in the near future • with Reflex dictionary generated automatically during Geant4 build procedure, persistency for G4 geometry classes will become available as standard functionality of the toolkit • geometry could be loaded/saved by a simple command from the Geant4 prompt Simulation Project

17. MC Truth handling • two aspects • particle 'filtering' mechanism within the event loop • event record for MC truth • implemented example 'MCTruthManager' • eventually can be added to Geant4 as a possible solution • studied HepMC as event record • several experiments already using it • seems to satisfy most of the requirements Simulation Project

18. Future plans • reimplementation of GDML reader for ROOT using ROOT native XML parser • expected performance improvement • adding support for modular GDML description in ROOT (reader & writer) • complete GDML documentation • release FLUGG extensions • release MCtruth handling example/tool Simulation Project

19. People involved involvement of W. Pokorski going to be reduced to 0.3 (becoming GENSER project leader) Simulation Project

20. Milestones for 2005/6 Simulation Project

21. Conclusions • Simulation Framework subproject is providing tools for the development and validation of Monte Carlo simulation applications • GDML project is well advanced with Geant4 binding being complete and first version of ROOT binding integrated within the ROOT package • FLUGG has been successfully used in the context of Atlas TileCal validation and a number of reusable 'add ons' has been developed • it has been demonstrated that the Python binding for Geant4 classes can be easily realized using Reflex/PyROOT machinery • a number of technical issues has been solved in order to use ROOT I/O for Geant4 geometry persistency • this nicely adds a new functionality to the Geant4 toolkit • future tasks of the Simulation Framework will consists of further development of GDML and maintenance of the other packages Simulation Project