Geant4 vs External Frameworks: Approaches, Requirements and Constraints in ATLAS, LHCb, CMS, Alice

1. Geant4 versus External FrameworksApproaches, Requirements and Constraints ATLAS, LHCb, CMS, Alice M. Stavrianakou CERN/CMC Geant4 d-review 10.10.2002

2. Experiment simulation frameworks: ATLAS Athena (Gaudi based software framework)  G4Scv  Goofy (G4 based simulation framework)  ATLAS simulation • Scalability: from the simplest test beam simulation to the complete detector simulation • Separation between core software and user implementation: light framework providing maximum user flexibility and freedom  • no geometry; built interactively by user at initialization time • no physics; user implementation and/or selection from catalogue • no kinematics • “dismantling”of standard G4 framework (too static) while maintaining full compatibility with G4 • Services for user plug-in code: • MaterialManager, DetectorFacility, PhysicsListCatalog, VisCenter etc • Geometry wrappers extending G4 functionality • Use of G4 (G)UI facilities for recreating connections • Memory saving: use of proxies and light-weight objects M. Stavrianakou, CMS/CERN

3. Experiment simulation frameworks: LHCb Gaudi (event processing framework)  GiGa (Gaudi simulation service)  Gauss (LHCb simulation application) • G4 control and configuration; actions • communication via transient stores • transient objects  G4 representation • common geometry source • use of common services • ParticlePropertySvc, MagneticFieldSvc etc • access to internal G4 event loop via GiGaRunManager • interaction with G4 via GiGa service abstract interfaces; minimize coupling to G4 • loading of external physics lists • dynamic loading of modular sublists via jobOptions • instantiation (abstract factory pattern) of different actions as plugable components • MCParticles, MCHits from LHCb event model saved in ROOT file M. Stavrianakou, CMS/CERN

4. Experiment simulation frameworks: CMS COBRA (OO framework and toolkit)  Mantis (COBRA interface to G4)  OSCAR (CMS G4 simulation) • toolkit for building or interfacing to detector geometries and sensitive volumes, generators, physics, magnetic fields, actions etc • framework for G4 simulation applications (interactive or batch) • COBRA infrastructure and services for core application steering and control, hits, persistency, histogramming etc • run and event management; • interfaces for loading user libraries using COBRA features and pattern: action on demand, lazy instantiation, abstract factories, dispatchers-observers,… IGUANA (Interactive Graphics for User ANAlysis) IgGeant4 (IGUANA IgModule ¹)  OSCAR visualization ¹IgModules are plug-in modules dynamically loadable by the IGUANA kernel; they provide event display core, application management services and thin adaptors for external software • G4 configuration selection wizard for geometry, magnetic field, generators, physics lists, user actions • G4 volume tree browser; visualization by logical or physical hierarchy, category (sensitive, cooling, cables etc) or material filter; volume location service; volume properties panel; session history; visualization settings M. Stavrianakou, CMS/CERN

5. Experiment simulation frameworks: ALICE AliRoot (ROOT based framework)  Virtual Monte Carlo (interface to MC programs: G3, G4)  ALICE simulation • TVirtualMC: interface to MC program; generalization of G3 functions for definition of simulation task (geometry and physics setup, access to tracked particle properties during stepping, visualization) • run-time selection and dynamic loading of concrete MC; • G4 initialization with configuration file • TVirtualMCApplication: interface to user application; implementation by user: • ConstructGeometry(), InitGeometry(), GeneratePrimaries(), BeginEvent(), …, Stepping(),… • G4 VMC geometry based on G3toG4 • AliRoot UI = ROOT UI   access to all objects processed by CINT  • G4 objects not accessible  • ROOT UI from/to G4 UI interface M. Stavrianakou, CMS/CERN

6. Approaches and concerns in common (I) • The ATLAS, CMS and LHCb approaches are very similar despite differences between the underlying frameworks and the actual implementations • So are the concerns raised over G4 architectural aspects and the workarounds adopted by the experiment frameworks The ALICE approach is quite different; some commonalities may however be identified and some concerns may be shared • The commonalities in approach: • Application control and steering by experiment rather than G4 framework; • Existing experiment infrastructure¹ for major services such as persistency, generators, magnetic field, hit creation and formatting, visualization etc; ¹ chosen for good reasons: functionality, transparency, compatibility, ease of use… • Modular and flexible run management by experiment implementation of run manager; • Maximum component decoupling (geometry, physics, generators…) and separation from core • Event definition and management; • Registration or notification mechanisms M. Stavrianakou, CMS/CERN

7. Approaches and concerns in common (II) • Static nature of G4 framework and degree of internal coupling affect flexibility and scalability • Experiment frameworks need to provide for a dynamic changing world that cannot be driven by static construction • from simplest setup to test beam to partial or full system simulation (geometry, field…) • for any “beam” (generator, physics, cuts and tuning…) • for any measurements (sensitive detectors and hits, user actions…) • with any tools (visualization, persistency…) • From the user side anybody may be observing or modifying anything • Need a very light-weight framework • independent of any user applications • with minimal internal coupling • able to run with(out) any UI M. Stavrianakou, CMS/CERN

8. Perceived shortcomings of current G4 architecture… • several G4 components know too much about each other and appear to be too closely coupled to the G4 kernel • several G4 managers are too “monolithic”or “intrusive” in the context of experiment frameworks • G4RunManager with a UserInitialization of a G4VUserDetectorConstruction, a G4VUserPrimaryGeneratorAction (essentially for passing MC vertices/particles to G4Event) and a UserInitialization of a G4VUserPhysicsList, as well as the registration of all types of user actions • while their abstract counterparts, if available, provide too limited functionality • e.g the G4VisManager (too intrusive for visualization toolkits such as IGUANA) vs the G4VVisManager • the G4Event cannot be customized or efficiently bypassed • must be generated in the G4RunManager • but offers no hook for non-G4 hit collections • workarounds, usually possible, often at a price • need for dummy actions when bypassing G4 expected initializations • costly copy or conversion operations • increased maintenance cost, waste of manpower, divergence M. Stavrianakou, CMS/CERN

9. Requirements, suggestions for improvements… • UI, command structure included, should be decoupled from the G4 kernel (see arguments in previous sections) • G4RunManager should be dismantled and modularized esp. in what concerns currently mandatory initializations (geometry, generators, physics) • G4Event (too close to G4 kernel to be easily modularized) should be hidden by providing direct hook for generated event (e.g. HepMC event in the HEP case) and allowing user event to take over more efficiently • Services and operations should be factored out and generalized; duplications must be eliminated • e.g. factor out geometry traversal, volume processing etc duplicated in geometry and visualization • Notification for entity changes at any granularity must come from the sources that manage the entities rather than high level managers; such notification should not be limited to entities pertaining to global states • e.g. notification for world volume changes from the G4TransportationManager would greatly facilitate interactive geometry construction and visualization M. Stavrianakou, CMS/CERN

10. Other concerns and constraints • Most LHC experiments need and want G4 simulation • They already know what they want (or are learning very fast) • They already have a large software base in terms of frameworks, toolkits, services etc • Their needs in terms of flexibility and scalability as well as their fundamental architectural choices imply that they need to adapt G4 simulation to their environment rather than vice versa • Their timescales for release and deployment are ~10 shorter than G4 • To meet official milestones • To proceed with detector construction • To run productions indispensable for • testing other/all components of their software • carrying out detector/physics studies for various TDRs • testing and adapting their production and analysis environments and tools • Most LHC experiments don’t need (want to) reinvent every instance of the same wheel for themselves; they would much rather find common solutions provided in the G4 context • But they have to continue developing and deploying in their own timescales • Can we find ways to collaborate within these constraints? We must. M. Stavrianakou, CMS/CERN