2. Introduction

3. What is detector simulation? A detector simulation program must provide the possibility of describing accurately an experimental setup (both in terms of materials and geometry) The program must provide the possibility of generating physics events (kinematics) and efficiently track particles through the simulated detector The interactions between particles and matter must be simulated by taking into account all possible physics processes, for the whole energy range The possibility of recording at run time all quantities need for reproducing the experiment functioning must be provided Some graphic support must be in place …and much more...

4. Geant4 - Why? Geant3 was a detector simulation program developed for the LEP era –Fortran, ZEBRA –Electromagnetic physics directly from EGS –Hadronic physics added as an afterthought (and always by interfacing with external packages) –Powerful but simplistic geometry model –Physics processes very often limited to LEP energy range (100 Gev) –(Painfully) debugged with the help and the collaboration of 100s of physicist from all over the world LHC detectors need powerful simulation tools for the next 20 years –reliability, extensibility, maintainability, openness –good physics, with the possibility of extending

5. Geant4 - Why? Geant3 –The geometry model is limited to a pre-defined set of basic shapes. Adding a new shape requires changing the code of several (~20) routines. Interface to CAD systems in not possible –Tracking is the result of several iterations (by different people) and as such it has become a garbled mess. Not for the fainthearted –EM physics is built in, but several processes are missing and their implementation would be very hard –Hadronic physics is implemented via external (and obsolete) packages. Modifications require the author’s intervention Geant4 –The geometry has been based since the beginning on a CAD-oriented model. The introduction of a new shape does not influence tracking –Tracking has been made independent from geometrical navigation, tracking in electromagnetic fields (or any field) has been improved –EM and hadronic physics implemented in terms of processes. A process can be easily added or modified by the user and assigned to the relevant particles with no change in the tracking. The cut philosophy has been changed so as to make result less dependent on the cuts used for the simulation. Framework for physics parameterisation in place

6. Geant4 - How? The principle points behind the Geant4 development have been: –ease of maintainability –openness of the design –performance –development by a rather substantial group of physicists An Object Oriented approach facilitates the achievement of these goals –the problem domain is naturally split into categories which can be tackled by different groups (with different expertise) –the process (if done properly) is self-documenting. The components are relatively independent from each other and can easily be replaced without affecting the whole program too much

7. Geant4 - How? (2) Geant4 is a toolkit –the framework part in Geant4 has been reduced to a minimum, so as to allow the user to implement his/her own program structure –bits and pieces of Geant4 can be used independently from the rest –no main program is provided –libraries have been made as granular as possible, in order to reduce (re-) compilation time and to allow the user to only link against those parts of G4 which are needed C++ as implementation language –de-facto standard for what concerns OO programming these days –high performance –big commercial support, well known in the scientific world –there is practically no Fortran in Geant4 anymore, hence the user must know some elements of C++ in order to get the best from G4

8. Geant4 - How? (3) Make Geant4 as independent as possible from commercial packages –You don’t need an Objectivity license to run Geant4! –Interfaces to commercial products have been provided whenever it was felt appropriate (so you can use Objectivity to store your data) –The only commercial package which was needed to run Geant4 was Rogue Wave’s Tools.h++ which did provide utility classes (as vectors, strings, containers and iterators), waiting for the Standard Template Library to become available. An interface to STL has been made available with the 4.0.1 release, hence Tools.h++ in not needed anymore The Geant4 code is written in reasonable C++ –migration to ISO/ANSI C++ to follow when most of the compilers will deal with it… –for the moment use Stroustrup’s 2nd edition...

9. Geant4 documentation For a complete documentation set go to: –http://wwwinfo.cern.ch/asd/geant4/geant4.html There you’ll find –Information on how to install a Geant4 application –Documentation on how to get started with Geant4 and how to build your detector simulation program –Class diagrams which document the G4 design –A complete Class Documentation set –Useful links Best reference system I found until now is at: –http://purdue-cdf.fnal.gov/CdfCodeand follow the geant4 link

10. Geant4 status In terms of performance and potentiality, Geant4 should be at least at the same level of Geant3 First “production” version (geant4.0.0) released at the end of 1998 –Full of bugs –Several part still under heavy development –Many improvements proposed, A&D cycles still undergoing –Physics part still being improved Several new versions released after that (running 4.3.0R3 now) –Interface to STL in place and running well –Migration to ISO/ANSI C++ is undergoing –Still lots of improvements needed (IMHO) –Physics evaluation programmes going on with some of the major experiments involved –G4 is growing up!

11. A word on STL STL provides a set of utility classes (vectors, lists, maps) to be used as tools No compiler (in 1994-5) could provide a consistent set Tools.h++ was chosen (when the G4 project was started) as an interim replacement for STL, with the idea of migrating to STL as soon as a standard implementation would become available 4.0.1 provides an interface to STL but: –using the ObjectSpace STL on HP and SUN –using the native STL on Linux –STL has been wrapped into a Tools-like interface :( The interface seems to be stable and robust, now the problem is to migrate away from the Tools-like interface.