1. A proposal for a Proposal for a Simulation Framework in BTeV G. Cerati, E. Di Maio, S. Magni, D. Menasce

2. Proposed BTeV-Geant4 simulation framework 2 Introduction What we think is needed… BTeV collaborators will be required, in the near future, to provide their individual detector simulation code and make it available within a common infrastructure in such a way that a complex (Pythia) event can be traced through the whole spectrometer composed by several sub-detectors. Albeit a simple statement, this requirement represents a very complex task which, depending on initial choices, may have far reaching consequences. We present a possible approach to a simulation framework that should simplify, as much as possible, the integration of all sub-detectors within a common simulation environment. B TeV E xperiment A nalysis and Simulation Tool We called our proposal The Beast, which stands for

3. Proposed BTeV-Geant4 simulation framework 3 The driving concept In a conventional approach, a detector simulation is organized as depicted schematically in the following picture: Initialization Generate event Trace event Persistency Reconstruct event Geometry and material of each component of the detector is defined here Physics is generated here (either internally or by reading external Pythia files) The most complex phase: individual particles are traced through the detector taking into account magnetic field, interaction with matter (MCS, showers, …). user This part should be transparent to the user (user: someone in charge of implementing a specific detector within the general simulation framework) The most complex phase: individual particles are traced through the detector taking into account magnetic field, interaction with matter (MCS, showers, …). user This part should be transparent to the user (user: someone in charge of implementing a specific detector within the general simulation framework) Hits fired by an event can be made persistent for a later processing … or can be used directly within the framework (unpractical)

4. Proposed BTeV-Geant4 simulation framework 4 Important considerations, which have driven our design, are: it should be possible to run the simulation switching from one implementation of a detector description to another for comparisons. The switching should be as easy as possible and do NOT involve any code recompilation. it should also be possible to change the configuration of a detector between runs in an easy way. For e.g. produce data for two runs where the number of Silicon Strip planes has changed between runs but within a single execution of the program (one output data file will contain two runs, with the two different configurations). to provide these features, it is necessary a decoupling between the overall tracing framework and each individual detector description. An individual sub-detector should be a sort of plug-in that can be included or excluded on demand in the simulation. The driving concept there should be no coupling between the framework functionality and a detector implementation; the user needs to know very few things about Geant4 and the framework to implement his/her own detector

5. Proposed BTeV-Geant4 simulation framework 5 The driving concept In our proposal, each sub-detector is represented as a plug-in module which can be dynamically loaded upon demand. Its physical and geometrical properties will appear, everywhere they are needed, in a consistent way. Initialization Generate event Trace event Persistency Reconstruct event Pixel, Silicon Strips, Rich and whatever other sub-detector is dynamically loaded in as an external plug-in. Geometry, material and relative positions are thus defined only if the plug-in is requested on demand. Pixel, Silicon Strips, Rich and whatever other sub-detector is dynamically loaded in as an external plug-in. Geometry, material and relative positions are thus defined only if the plug-in is requested on demand. The tracing takes care of all sub-detectors which appear to have been declared in the initialization phase. The tracing takes care of all sub-detectors which appear to have been declared in the initialization phase. Hits of each loaded sub-detector are collected and stored away Information from each sub-detector may or may not be used in the reconstruction process: the plug-in strategy may be used in this case also. Information from each sub-detector may or may not be used in the reconstruction process: the plug-in strategy may be used in this case also.

6. Proposed BTeV-Geant4 simulation framework 6 The underlining framework In order to successfully implement such an ambitious goal, we decided to Geant4 adopt Geant4 as the underlining framework. Much of the basic functionalities needed is already made available to the developer and lots of experience, documentation and tutorials are available. How is a Geant4 simulation program organized in general? RunManager() add detectorConstruction() add physicsList() add primaryGeneratorAction add runAction add eventAction add trackingAction add steppingAction The RunManager is the class that controls the flow of the program anmanages the event loop(s) within a run. Detectors geometry, material, relative positions in space are specified here. Physics processes, that particles are subject to by crossing the detectors, specified Defines what kind of events are to be generated (e.g. Pythia events, geantinos, …) Called at begin/end of each run (e.g. book histograms, …) Called at begin/end of each event (e.g. fill histos/ntuples with event related quantities) Called at begin/end of the process of tracing a particle (both primaries and secondaries) Called at each step of the tracing process for each particle VisualizationManager() UserInterfaceManager() Handles interaction with a visualization tool (external plug-ins) Handles interaction with user (at command-line level, batch or through a GUI) main()

7. Proposed BTeV-Geant4 simulation framework 7 What have we added to this schema We provide a black box (a main program defining the underlining framework) RunManager() add detectorConstruction() add physicsList() add primaryGeneratorAction add runAction add eventAction add trackingAction add steppingAction VisualizationManager() UserInterfaceManager() main() A user interested in implementing his/her own sub-detector will never need to look at any of these components (complexity hidden away). During run the detectorConstruction() method we provide will use this external configuration file to dynamically load the requested plug-in modules. He will just implement a few classes, compile them in a plug-in and add the corresponding class (detector) name in a configuration file. Once plugged-in, a sub-detector will be treated in a consistent and coherent way by the underlining framework. Developers will only need to concentrate on details of their own detector component (geometry, hit generation model…)

8. Proposed BTeV-Geant4 simulation framework 8 the framework provides a detectorConstruction() method in the main() program which does the following things: it implements all the components common to the whole BTeV detector, like magnet yoke, detailed magnetic field map, assembly hall, etc… Basic mechanism invokes the construct() method for each module: this should be implemented individually, for each sub-detector, to contain the geometry and material description for that detector component. it also invokes the setSensitiveDetector(), method for each module: this should also be implemented for each sub-detector, to contain the code needed to fire a hit and generate a signal. loads those plug-in modules which are defined in a configuration file (one for each BTeV sub-detector component) what a user needs to do is thus implement a concrete class, inheriting from a virtual VDetector() class, implement the two methods described above, construct() and setSensitiveDetector() and finally build a plug-in module.

9. Proposed BTeV-Geant4 simulation framework 9 Additional features when a new detector is added to the framework, it might be desirable to fill control histograms and/or ntuples specific to that particular detector. To this extent, our framework defines two abstract classes: 1. VRunRootPlugin() 2. VEventRootPlugin() a concrete instance of this class for a specific detector each begin of run is called at each begin of run: here histograms/ntuples booked are booked and added to the overall list of already existing histograms in a root sub-directory a concrete instance of this class for a specific detector end of each event is called at the end of each event: here histograms filled or ntuples are filled with quantities specific of that event (charge or energy realease, hit position etc…) again, what a user needs to do is to implement two concrete classes, inheriting from the virtual VRunRootPlugin() and VEventRootPlugin() classes. The framework will then automatically take care of the whole process of histogram booking and filling.

10. Proposed BTeV-Geant4 simulation framework 10 In practice In the current configuration, these are the steps needed to add a new detector to the framework: add a new subdirectory in the plugins directory (for e.g. Rich ) in the Rich subdirectory create the instances of the concrete classes described before (detector construction, hit firing, histogram booking/filling) (header files in the include subdirectory and source file in src )

11. Proposed BTeV-Geant4 simulation framework 11 specify geometry and material fill histograms store away charge/energy release at each tracing step book histograms collects charge releases in hit signal infromation And that’s it! In practice

12. Proposed BTeV-Geant4 simulation framework 12 Well, almost: last step is to provide a GNUmakefile to compile the plug-in as a dynamic link load library (we provide a template for that) In practice

13. Proposed BTeV-Geant4 simulation framework 13 Perspective Elements missing to complete the framework functionalities: In the current configuration the list of available plug-ins is contained in a flat ASCII file whose name is hard-wired in the code: this should be made into a full fledged configuration file (XML) and subject to a GUI editor to ease the task of starting a simulation cycle (several runs). Detector properties (geometry, material, position etc…) are currently also hard-wired into the code: we would propose a geometry manager to handle the formal description of those properties (GDML) to insure consistency between simulation and reconstruction and to ease the bookkeeping of different simulation runs with different physical setups. We need to establish a convenient sub-detector naming scheme (to avoid potential namespace clashes and make the code easy to interpret) Provide a redundant set of templates and examples to help other members of the collaboration to build their own detector components: to this extent we have already made progress in providing documentation using doxygen, a tool that creates web pages to navigate through the source code (Dario).

14. Proposed BTeV-Geant4 simulation framework 14 How to start Those interested can fetch the Beast from CVS cvs co SiliconStripSimulation Significant documentation can found at http://hal9000.mi.infn.it/~menasce/TheBeast

15. Proposed BTeV-Geant4 simulation framework 15 In this scheme, properties of an individual sub-detector are referenced in several distinct parts of the code, and the reference is usually hard-wired Initialization Generate event Trace event Persistency Reconstruct event Pixel, Silicon Strips, Rich… (geometry, material, relative positions etc…) Each sub-detector responds in a different way to the passage of particles, particularly in the way energy is released and hits are generated according to specific charge-release models Each sub-detector responds in a different way to the passage of particles, particularly in the way energy is released and hits are generated according to specific charge-release models Hits of each sub-detector are collected (event builder) and stored away Information from each sub-detector may or may not be used in the reconstruction process Information from each sub-detector may or may not be used in the reconstruction process Sub-detector details are everywhere: adding or removing them in a consistent way is a head-ache Sub-detector details are everywhere: adding or removing them in a consistent way is a head-ache backup slide