simulation framework subproject lcgapp.cern.ch/project/simu/framework

W. Pokorski - EP/SFT Simulation Project 1

Simulation Framework Subproject

http://lcgapp.cern.ch/project/simu/framework/

Witek Pokorski19.09.2006


Outline

• Activities

• Future plans, milestones, people involved

• Conclusion


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


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


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

GDMLSchema GDML file

user application (1)

GDML writer

GDML reader

user application (2)


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


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 ...


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


CAD(STEP) -> GDML converter

ST - ViewerAn interactive tool for viewing

3D CAD information

STEP filesST – Viewer uses an internalfile format (.geom & .tree)

to store geometry info

STEPGDMLLibrary functions created

to convert STEP filesinto GDML files

GDML Output File Equivalent to the original STEP file

Contains only tessellated solids

• 'first order' approach to use CAD geometries for Geant4 simulation


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


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

FLUKA

Inputcard

FluGG

G4geometry

Flukaoutput


'Extended' FluGG

FLUKA

Inputcard

FluGG

OO Hits

GDMLfile

Hits Manager

Root IO


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


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


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


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


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


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


People involved

W. Pokorski (subproject leader) 0.7

B. Lloyd (technical student) 1.0 (GDML)

A. Ribon ~0.1 common effort with Physics Validation subproject (FLUGG)

D. Kruse (summer student)(June-September 2006)

1.0 (GDML)

involvement of W. Pokorski going to be reduced to 0.3 (becoming GENSER project leader)


Milestones for 2005/6GDML package reorganization (allowing independent releases of GDMLSchema and GDML processors); new release of GDML

done

Working example of Python-driven Geant4 application (using Reflex and PyROOT)

done

SF515 GDMLSchema extension to support divisions and reflections

done

SF516 Feasibility study of ROOT based Geant4 geometry persistency

done

SF517 Python implementation of GDML writers for ROOT and Geant4 done for ROOT

not needed for G4

SF537 Introduction of modularization of GDML files allowing selective importation of parts of the geometry

done

SF530 (common milestone with the Physics Validation subproject) FLUGG application to one of the LHC calorimeter testbeam simulation; documentation of general FLUGG usage in the context of testbeam validations

ongoing

SF538 Proposal for universal handling of Monte Carlo truth done


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 framework subproject lcgapp.cern.ch/project/simu/framework

Documents