a proposal for a proposal for a simulation framework in btev g. cerati, e. di maio, s. magni, d....

A proposal for a

Proposal for a Simulation Framework in BTeV

G. Cerati, E. Di Maio, S. Magni, D. Menasce

Proposed BTeV-Geant4 simulation framework 2

IntroductionIntroduction

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 commoninfrastructure 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 shouldsimplify, as much as possible, the integration of all sub-detectors withina common simulation environment.

BTeV Experiment Analysis and Simulation Tool

We called our proposal The Beast, which stands for


The driving conceptThe driving concept

In a conventional approach, a detector simulation is organized as depictedschematically in the following picture:

InitializationInitialization

Generate eventGenerate event

Trace eventTrace event

PersistencyPersistency

Reconstruct eventReconstruct event

Geometry and material of each component of the detector is defined hereGeometry and material of each component of the detector is defined here

Physics is generated here (either internally or by reading external Pythia files)Physics is generated here (either internally or by reading external Pythia files)

The most complex phase: individual particles are traced through the detectortaking into account magnetic field, interaction with matter (MCS, showers, …).This part should be transparent to the user (useruser: someone in charge of implementing a specific detector within the general simulation framework)

The most complex phase: individual particles are traced through the detectortaking into account magnetic field, interaction with matter (MCS, showers, …).This part should be transparent to the user (useruser: 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 processingHits fired by an event can be made persistent for a later processing

… or can be used directly within the framework (unpractical)… or can be used directly within the framework (unpractical)


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.


• 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



In our proposal, each sub-detector is represented as a plug-in module whichcan be dynamically loaded upon demand. Its physical and geometrical properties will appear, everywhere they are needed, in a consistent way.






Pixel, Silicon Strips, Rich and whatever other sub-detector is dynamicallyloaded in as an external plug-in. Geometry, material and relative positionsare thus defined only if the plug-in is requested on demand.

Pixel, Silicon Strips, Rich and whatever other sub-detector is dynamicallyloaded in as an external plug-in. Geometry, material and relative positionsare 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 awayHits 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.


The underlining frameworkThe underlining framework

In order to successfully implement such an ambitious goal, we decided toadopt Geant4Geant4 as the underlining framework. Much of the basic functionalitiesneeded 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()RunManager()

add detectorConstruction()add detectorConstruction()

add physicsList()add physicsList()

add primaryGeneratorActionadd primaryGeneratorAction

add runActionadd runAction

add eventActionadd eventAction

add trackingActionadd trackingAction

add steppingActionadd steppingAction

The RunManager is the class that controls the flow of the program anmanages the event loop(s) within a run.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. Detectors geometry, material, relative positions in space are specified here.

Physics processes, that particles are subject to by crossing the detectors, specified 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, …)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 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 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 begin/end of the process of tracing a particle (both primaries and secondaries)

Called at each step of the tracing process for each particleCalled at each step of the tracing process for each particle

VisualizationManager()VisualizationManager()

UserInterfaceManager()UserInterfaceManager()

Handles interaction with a visualization tool (external plug-ins)Handles interaction with a visualization tool (external plug-ins)

Handles interaction with user (at command-line level, batch or through a GUI)Handles interaction with user (at command-line level, batch or through a GUI)

main()main()


What have we added to this schemaWhat have we added to this schema

We provide a black box (a main program defining the underlining framework)

RunManager()RunManager()

add detectorConstruction()add detectorConstruction()

add physicsList()add physicsList()

add primaryGeneratorActionadd primaryGeneratorAction

add runActionadd runAction

add eventActionadd eventAction

add trackingActionadd trackingAction

add steppingActionadd steppingAction

VisualizationManager()VisualizationManager()

UserInterfaceManager()UserInterfaceManager()

main()main() A user interested in implementing his/her ownsub-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, compilethem in a plug-in and add the correspondingclass (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 concentrateon details of their own detector component (geometry, hit generation model…)


the framework provides a detectorConstruction() method in the main() programwhich 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 mechanismBasic 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.


Additional featuresAdditional features

when a new detector is added to the framework, it might be desirable to fillcontrol 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 detectoris called at each begin of runeach begin of run: here histograms/ntuplesare bookedbooked and added to the overall list of already existing histograms in a root sub-directory

a concrete instance of this class for a specific detectoris called at the end of each eventend of each event: here histogramsor ntuples are filledfilled 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.


In practiceIn practice

In the current configuration, these are the steps needed to add a new detectorto 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)


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!And that’s it!



Well, almost: last step is to provide a GNUmakefile to compile the plug-inas a dynamic link load library (we provide a template for that)



PerspectivePerspective

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


How to startHow 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


In this scheme, properties of an individual sub-detector are referenced inseveral distinct parts of the code, and the reference is usually hard-wired






Pixel, Silicon Strips, Rich… (geometry, material, relative positions etc…)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 accordingto 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 accordingto specific charge-release models

Hits of each sub-detector are collected (event builder) and stored awayHits 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 processInformation from each sub-detector may or may not be used in the reconstruction process

Sub-detector details are everywhere: adding orremoving them in a consistent way is a head-acheSub-detector details are everywhere: adding orremoving them in a consistent way is a head-ache

backup slide

backup slide

a proposal for a proposal for a simulation framework in btev g. cerati, e. di maio, s. magni, d....

Documents

simulation framework

detector implementation

individual subdetector

simulation toolwe

geant4 simulation program

underlining framework

hisher ownsubdetector

framework functionality