|
|
Overview of the BaBar Simulation
The BaBar simulation reproduces in detail the generation of events at the
interaction point, the propagation of the resulting particles through the
detector and the response of the detector to these particles. Detector
response quantities are then used to construct candidate events which may
analyzed as if they were real data.
The simplified architecture of the BaBar simulation is shown below.
There are four main stages in producing a simulated event:
- Generation of the physics event
- The physics of the e+ e- collision is performed by one of several
event generators. The generators provide a set of four-vectors which
represents the final state of the collision near the e+ e- interaction
point. B0B0bar events, for example, are simulated by the routine
EvtGen which is part of the GenFwkInt framework package. Other events
which are routinely generated are dimuons (Bkqed) and Bhabha scattering
(Bhwide). More information about event generators can be found at
Event Generators .
- Particle transport and hit scoring
- The four-vectors from the generator stage are transported through the
simulated detector, where energy loss, production of secondaries,
multiple scattering and decay can occur. As these particles pass
through sensitive regions of the detector, energy, charge and angle
information is used to calculate positions and idealized energy
deposits in the detector. These quantities, referred to as "GHits"
are stored in persistent containers in the Objectivity database for
later use in calculating the detector response. The software package
which handles the above tasks is called Bogus (BaBar
Object-oriented Geant4-based Unified
Simulation). Bogus is an
application layer built on the Geant4 toolkit. Geant4 provides the
physics processes listed above as well as the means to build the
detector geometry. It also provides several particle transport
methods, but currently BaBar uses its own customized transportation.
Source code, documentation and user support for Geant4 can be found at
Geant4 . An overview
of Bogus can be found at Bogus.
- Detector Response and Background Mixing
- At this stage idealized GHits are retrieved from the database and
digitized, that is, transformed into realistic signals which mimic
those collected from the detector electronics. Real background
events, stored in the database, may be mixed in with the simulated
event to more closely reproduce signal data. The digitized background
event is aligned in time with the simulated signal event before they
are combined. The final outcome from this stage is a set of raw data
objects called "digis" which are stored in the database for the
reconstruction phase. These functions are performed by the
SimApp
application.
- Reconstruction
- The reconstruction stage is performed by the Bear application. For
each event Bear retrieves the raw digis from the database and combines
them into candidate events consisting of particle tracks, energy
clusters, and probable particle identifications, among other things.
The above architecture describes an event simulation system based on three
executables, BgsApp (Bogus), SimAppApp (SimApp) and BearApp (Bear), which
may be run separately, provided the previous stage has been completed. This
requires the intermediate data to be retrieved from and stored to the database
between stages. In order to reduce the number of database transactions and
improve the simulation speed, the three executables have been combined into
the single executable, Moose (Monolithic Object-Oriented
Simulation Executable). In Moose, the intermediate data are
stored internally between stages and only the final event candidates are
persisted to the database. Moose is currently being tested for simulation
production and is expected to be deployed for SP5.
The development of the current simulation code has concentrated on the
correctness of the physics and the detector material model, and not
necessarily on execution speed. Improvement in this area will be the next
major focus of the simulation group. Several avenues will be pursued
including
- speeding up the current simulation by optimizing coding
- implementing parameterized showers
- developing new (or re-using old) simulation codes which simplify the
detector geometry or parameterize the physics, or both.
Page author:
Dennis Wright,
| Last significant update: 20 September 2002 |
Expiration date: |
|
|