Maria Grazia Pia INFN Genova Geant4 Collaboration X I Giornate sui Rivelatori

1. Maria Grazia Pia INFN Genova Geant4 Collaboration XI Giornate sui Rivelatori Torino, 1-2 March 2001

2. Introduction Author: Maria Grazia Pia Geant4 Training Kit

3. An example of how simulation can be mission-critical Courtesy of NASA/CXC/SAO

4. Chandra X-ray Observatory Status Update September 14, 1999 MSFC/CXC CHANDRA CONTINUES TO TAKE SHARPEST IMAGES EVER; TEAM STUDIES INSTRUMENT DETECTOR CONCERN Normally every complex space facility encounters a few problems during its checkout period; even though Chandra’s has gone very smoothly, the science and engineering team is working a concern with a portion of one science instrument. The team is investigating a reduction in the energy resolution of one of two sets of X-ray detectors in the Advanced Charge-coupled Device Imaging Spectrometer (ACIS) science instrument. A series of diagnostic activities to characterize the degradation, identify possible causes, and test potential remedial procedures is underway. The degradation appeared in the front-side illuminated Charge-Coupled Device (CCD) chips of the ACIS. The instrument’s back-side illuminated chips have shown no reduction in capability and continue to perform flawlessly. An excerpt of a press release Courtesy of NASA/CXC/SAO

5. What can affect CCD’s on X-ray astronomy missions? • Radiation belt electrons? • Scattered in the mirror shells? • Effectiveness of Magnetic “brooms” • Electron damage mechanism? - NIEL? • Other particles? Protons, cosmic rays? • Path to CCD? Wall penetration? • Proposal: set the problem up in Geant4 as a case-study

6. XMM

7. Courtesy of ESA Space Environment & Effects Analysis Section RGS EPIC Q2 Q1 Q1

8. EPIC RGS Courtesy of ESA Space Environment & Effects Analysis Section CCD displacement damage: front vs. back-illuminated. 30 mm Si  ~1.5 MeV p+ 2 mm 30 mm 2 mm 30 mm Active layerPassive layer “Electron deflector” Low-E (~100 keV to few MeV), low-angle (~0°-5°) proton scattering:Obscure problem; not much analysed

9. How well can Geant4 simulate low energy protons? Courtesy of R. Gotta, Thesis

10. What happened next? XMM was launched on 10 December 1999 from Kourou EPIC image of the two flaring Castor components and the brighter YY Gem Courtesy of

11. design of the experimental set-up evaluation and definition of the potential physics output of the project evaluation of potentialrisks to the project assessment of the performance of the experiment development, test and optimisation of reconstruction and physics analysis software contribution to the calculation and validation of physics results The scope of these lectures (and of Geant4) encompasses the simulation of the passage of particles through matter there are other kinds of simulation components, such as physics event generators, detector/electronics response generators, etc. often the simulation of a complex experiment consists of several of these components interfaced to one another The role of simulation Simulation plays a fundamental role in various domains and phases of an experimental physics project

12. Domains of application • HEP, nuclear, astrophysics and astro-particle physics experiments • the most “traditional” field of application • Radiation studies • evaluation of safety constraints and shielding for the experimental apparatus and human beings, on earth and in space • Medical applications • radiotherapy • design of instruments for therapeutic use • Biological applications • radiation effects (in human beings, food etc.), at cellular and DNA level • …and more

13. Modeling the experimental set-up Tracking particles through matter Interaction of particles with matter Modeling the detector response Run and event control Accessory utilities(random number generators, PDG particle information, physical constants, system of units etc.) User interface Interface to event generators Visualisation (of the set-up, tracks, hits etc.) Persistency Analysis What is required

14. Fast and full simulation • Usually in a typical HEP experiment there are two types of simulations • Fast simulation • mainly used for feasibility studies and quick evaluations • coarse set-up description and physics modeling • usually directly interfaced to event generators • Full simulation • used for precise physics and detector studies • requires a detailed description of the experimental set-up and a complex physics modeling • usually interfaced to event generators and event reconstruction • Traditionally fast and full simulation are done by different programs and are not integrated in the same environment • complexity of maintenance and evolution • possibility of controversial results

15. The zoo NMTC HERMES FLUKA EA-MC DPM SCALE GEM MF3D EGS4, EGS5, EGSnrc MCNP, MCNPX, A3MCNP, MCNP-DSP, MCNP4B Penelope Geant3, Geant4 Tripoli-3, Tripoli-3 A, Tripoli-4 Peregrine MVP, MVP-BURN MARS MCU MORSE TRAX MONK MCBEND VMC++ LAHET RTS&T-2000 ...and I probably forgot some more Many codes not publicly distributed A lot of business around MC Monte Carlo codes presented at the MC200 Conference, Lisbon, October 2000

16. Pro: the specific issue is treated in great detail sometimes the package is based on a wealth of specific experimental data simple code, usually relatively easy to install and use Contra: a typical experiment covers many domains, not just one domains are often inter-connected Pro: the same environment provides all the functionality Contra: it is more difficult to ensure detailed coverage of all the components at the same high quality level monolithic: take all or nothing limited or no options for alternative models usually complex to install and use difficult maintenance and evolution Integrated suites vs specialised codes Specialised packages cover a specific simulation domain Integrated packages cover all/many simulation domains

17. The Toolkit approach A toolkit is a set of compatible components • each component is specialised for a specific functionality • each component can be refined independently to a great detail • components can be integrated at any degree of complexity • components can work together to handle inter-connected domains • it is easy to provide (and use) alternative components • the simulation application can be customised by the user according to his/her needs • maintenance and evolution - both of the components and of the user application - is greatly facilitated ...but what is the price to pay? • the user is invested of a greater responsibility • he/she must critically evaluate and decide what he/she needs and wants to use

18. The role of Geant • Geant has been a simulation tool, that provides a general infrastructure for • the description of geometry and materials • particle transport and interaction with matter • the description of detector response • visualisation of geometries, tracks and hits • The user develops the specific code for • the primary event generator • the geometrical description of the set-up • the description of the detector response

19. The past: Geant3 • Geant 3 • has been used by most major HEP experiments • frozen since March 1994 (Geant3.21) • ~200K lines of code • equivalent of ~50 man-years, along 15 years • used also in nuclear physics experiments, medical physics, radiation background studies, space applications etc. • The result is a complex system • because its problem domain is complex • because it requires flexibility for a variety of applications • because its management and maintenance are complex • It is not self-sufficient • hadronic physics is not native, it is handled through the interface to external packages

20. High statistics to be simulated robustness and reliability for large scale production Exchange of CAD detector models especially relevant for large scale experiments Transparent physics for validation of physics results Physics extensions to high energies LHC, cosmic ray experiments... Physics extensions to low energies space applications, medical physics, X-ray analysis, astrophysics, nuclear and atomic physics... Reliable hadronic physics not only for calorimetry, but also for PID applications (CP violation experiments) ...etc. New simulation requirements User requirements formally collected and coded according to PSS-05 standard Geant4 User Requirements Document

21. What is Geant4? OO toolkit for the simulation of next generation HEP detectors • ...of the current generation too • ...not only of HEP detectors • already used also in nuclear physics, astrophysics, medical physics, space applications, radiation background studies etc. • It is also a successful experiment of distributed software production and management, as a large international collaboration with the participation of various experiments, labs and institutes • It is also a successful experiment of application of rigorous software engineering and Object Oriented technologies to the HEP environment

22. Milestones: end 1995 OO methodology, problem domain analysis, full OOAD tracking prototype, performance evaluation Milestones: spring 1997 release with the same functionality as Geant 3.21 persistency (hits), ODBMS transparency of physics models Milestone: July 1998 public release Milestone: end 1998 production release: Geant4.0, end of the R&D phase All milestones have been met by RD44 Reconfiguration at the end of the R&D phase International Geant4 Collaboration since 1/1/1999 Management of the production phase Continuing R&D also in the production phase RD44 • Approved as R&D end 1994 • > 100 physicists and software engineers • ~ 40 institutes, international collaboration • responded to DRCC/LCB

23. Atlas, BaBar, CMS, HARP, LHCB CERN, JNL,KEK, SLAC, TRIUMF ESA, Frankfurt Univ., IGD, IN2P3, Karolinska Inst., Lebedev, TERA COMMON (Serpukov, Novosibirsk, Pittsburg etc.) other memberships currently being discussed Collaboration Board manages resources and responsibilities Technical Steering Board manages scientific and technical matters Working Groups maintenance, development, QA, etc. Geant4 Collaboration MoU based Distribution, development and User Support Members of National Institutes, Laboratories and Experiments participating in Geant4 Collaboration acquire the right to the Production Service and User Support For others: free code and user support on best effort basis Budker Inst. of Physics IHEP Protvino MEPHI Moscow Pittsburg University

24. Software engineering Geant4 rigorous approach to software

25. Outline • Motivations for software engineering in HEP • The software process • Components of the software life-cycle • Object Oriented technologies • Brief digression on basic OO concepts • OOAD in Geant4 • Quality Assurance • Standards

26. The benefits of software engineering The goal: producing better software at lower cost, within predictable resource allocations and time estimates, and happier users of the software • the peopleinvolved • the organization of the development process • the technology used Three key components: • The way to progress is to study and improve the way software is produced • better technology only helps once the organizational framework is set • there is evidence that going for new technology instead of improving the process can make things worst • The practices of SPI are well established, and have been applied in a large number of organizations for several years • the results prove that the economical benefits are largely worth the investment • early defect detection, time to market, and quality also improve, to the point that the return on investment for SPI is about 500%

27. Various phases: User Requirements definition Software Requirements definition Architectural Design Detailed Design and construction Delivery to the user Operations Frequently the tasks of different life cycle phases are performed somewhat in parallel to consider them disjoint in time is a simplification It is however important to distinguish them logically to identify documents that are the outcome of the various phases Software life-cycle

28. The software process • Complex domain, evolving, with many types of models available • Examples of software process models: • The Waterfall model • analysis  design  coding • each phase starts following the completion of the previous one • The Iterative Incremental Development model • cycles of analysis  design  coding, with incremental refinement It is the set of actions, tasks and procedures involved in producing a software system, through its life-cycle

29. Capability Maturity Model Software Engineering Institute SPICE, ISO 15504 the path to an international standard PSS-05, ECSS ESA Development or Engineering processes: system and software requirements analysis, software design, software construction, software integration and unit testing, software maintenance Documentation Configuration and Change Management Problem Resolution Quality Assurance and Measurement System Testing, Acceptance and Releasing Verification and Validation Reviews, Audits and Joint Reviews Project tasks Management Improvement Process Process Establishment Human resource Management Infrastructure User Support, Distribution Software process standards Process categories Primary life-cycle of software development Supporting life-cycle Management process Organizational life-cycle User-supplier processes etc.

30. Why software engineering in HEP? • Software engineering is somewhat new to the HEP environment • other engineering branches more consolidated in this environment (mechanics, electronics, accelerators etc.) • Benefits derive from a rigorous approach to software • the lesson can be learned from the world of software professionals! • even the most talented professionals need an organized environment to do cooperative work • advanced technology cannot be fully effective without an organizational framework Software Engineering plays a fundamental role in Geant4 Software process SPI User requirements OOAD Quality Assurance

31. OOAD testing implementation The software process in Geant4 • a large international collaboration • complex software • mature categories in production and maintenance mode as well as categories in full development • sensitive and mission-critical user applications • product with a long life-time • Spiral-type life-cycle model adopted in most domains • both iterative and incremental A challenge: • Software Process Improvement • understand, determine and propose procedures to software development and maintenance • gradual process, life-cycle driven • regular assessment, according to the ISO 15504 model

32. Requirements Requirements are the quantifiable and verifiable • behavioursthat a system must possess • constraintsthat a system must work within User requirements • this phase defines the scope of the system Software requirements • this is the analysis phase of a software project • builds a model describing what the software has to do (not how to do it) • Requirements are subject to evolution in the lifetime of a software project! • ability to cope with the evolution of the requirements

33. Geant4 requirements • Geant4 has adopted a rigorous approach to requirements • user requirements collected from the user communities in the initial phase • coded according the PSS-05 software engineering standard • continuously updated • Geant4 User Requirements Document

34. Object Oriented technology • OO technology is built upon a sound engineering foundation, whose elements are called the object model • The object model encompasses the principles of • abstraction • encapsulation • modularity • hierarchy • typing • concurrency • persistence • brought together in a synergistic way Geant4 is based on Object Oriented technology

35. What is an object? G. Booch (in OOAD with Applications): • “An object has state, behavior and identity; the structure and behavior of similar objects are defined in their common class”.

36. Some fundamental concepts in OOD -1 • The Open Closed Principle • Open for extension, Closed for modification • A software module that is designed to be reusable, maintainable and robust must be extensible without requiring modification • new features are added by adding new code, rather than by changing old, already working, code • The primary mechanisms behind are abstraction and polymorphism • The Liskov Substitution Principle • Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it • Derived types must be substitutable for their base types • It is an important feature for conforming to the OCP

37. Some fundamental concepts in OOD -2 • The Dependency Inversion Principle • Modules that implement high level policy should not depend on the modules that implement low level details • Both high level policy and low level details should depend on abstractions • This ensures reusability and maintainability • The interdependence makes a design rigid, fragile and immobile: a single change triggers a cascade of changes in dependent modules • The Interface Segregation Principle • Clients should not be forced to depend on interfaces that they do not use • Polluted interfaces generate unnecessary couplings • We want to separate interfaces whenever possible to avoid the disadvantages of couplings

38. Analysis Webster definitions: • separation or breaking up of a whole into its fundamental elements or component parts • a detailed examination of anything complex • the practice of proving a mathematical proposition by assuming the result and reasoning back to the data or already established principles In the software world: • it is the decomposition of a problem into its constituent parts • it is accomplished by beginning with a set of stated requirements, and reasoning back from those requirements to a set of established software components and structures • OOA is the act of determining the abstractions that underlie the requirements • In OOA the components are objects and their collaborations

39. Design • Design embodies the set of decisions that determine how the components will look like • In OOD typically class inheritance and composition hierarchies are among the decisions • OOA and OOD cooperate synergically • they are best done concurrently • The output of OOAD is a set of class and object diagrams, showing • the static structure • the collaborations

40. UML: Unified Modeling Language UML is theindustry-standard language for specifying, visualising, constructing and documenting the design of software systems • UML represents a unification of the concepts and notations previously in use (Booch, OMT, Jcobson) • UML has a standard data representation (the Meta-Model) • the Meta-Model is a description of UML in UML • it describes the objects, attributes and relationships necessary to represents the concepts of UML within a software application • UML notation is comprised of two major subdivisions: • a notation for modeling thestatic elementsof a design (classes, attributes, relationships...) • a notation for modeling thedynamic elementsof a design (objects, messages, finite state machines...)

41. C++ • OO technology and C++ are not equivalent! • OO methodologies can be implemented in a variety of languages, not only in C++ • One can write procedural code in C++, that is not object oriented • C++ provides many features that make it suitable for OO implementations of large scale software projects • An overview of C++ language features and OO technology is beyond the scope of these lectures • Many textbooks, courses and online material are available as learning aids, eg. • I. Pohl, OO programming using C++ • S. B. Lippman, J. Lajoie, C++ primer • B. Stroustrup, The C++ programming language • G. Booch, OO analysis and design • R. Martin, Designing OO C++ applications using the Booch method

42. Openness to evolution Extensibility, implementation of new models and algorithms without interfering with existing software The user can extend the toolkit with his/her model and data Transparency decoupling from implementation OO technology in Geant4 OO design fundamental for distributed parallel approach • Every part can be developed, refined, maintained independently • Problem domain decomposition and OOAD result into a unidirectional dependency of class categories Booch methodology adopted for OOAD • choice resulting from a thorough study of various models Flexibility • alternative models and implementations Interface to external software, without dependencies • databases for persistency • visualisation libraries • tools for UI • etc.

43. Geant4 architecture exploits advanced Software Engineering techniques and Object Orientedtechnology to achieve transparency of physics implementation.

44. OO design: an example of top level design

45. OO design: an example of a detailed design Class diagram of Low Energy e.m. processes: hadrons

46. Commercial tInsure++, CodeWizard, Workshop etc. C++ coding guidelines scripts to verify their applications automatically Code inspections within working groups and across groups Walk-throughs with specialized tools for monitoring against violations of coding rules Checks on run-time memory management Checks forviolations of the dependency structure of categories Performance benchmarks and monitoring Testing Unit testing in most cases down to class level granularity Integration testing sets of logically connected classes Test-bench for each category eg.: test-suite of 375 tests for hadronic physics parameterised models System testing exercising all Geant4 functionalities in realistic set-ups Physics testing comparisons with experimental data Quality Assurance Extensive use of QA systems in Geant4 fundamental for a toolkit of wide public use

47. Units Geant4 is independent from the system of units all numerical quantities expressed with their units explicitly user not constrained to use any specific system of units Standards Geant4 adopts standards, ISO and de facto • OpenGL e VRML for graphics • CVSfor code management • C++as programminglanguage • STEP engineering and CAD systems • ODMG RD45 Have you heard of the “incident” with NASA’s Mars Climate Orbiter ($125 million)?

48. Data libraries • Systematic collection and evaluation of experimental data from many sources worldwide • Databases • ENDF/B, JENDL, FENDL, CENDL, ENSDF,JEF, BROND, EFF, MENDL, IRDF, SAID, EPDL, EEDL, EADL, SANDIA, ICRU etc. • Collaborating distribution centres • NEA, LLNL, BNL, KEK, IAEA, IHEP, TRIUMF, FNAL, Helsinki, Durham, Japan etc. • The use of evaluated data is important for the validation of physics results of the experiments

49. Physics From the Minutes of LCB (LHCC Computing Board) meeting on 21 October, 1997: “It was noted that experiments have requirements for independent, alternative physics models. In Geant4 these models, differently from the concept of packages, allow the user to understand how the results are produced, and hence improve the physics validation. Geant4 is developed with a modular architecture and is the ideal framework where existing components are integrated and new models continue to be developed.”

50. The approach to physics • Ample variety of independent, alternative physics models available in Geant4 • No more black boxes of packages • The users are directly exposed to the physics they use in their simulation • This approach is fundamental for the validation of the experiments’ physics results