BgsApp - Detector Geometry, Particle Tracking and Hit Scoring

1. Introduction
2. Bogus in the BaBar Framework
3. Running BgsApp in the BaBar Framework
4. Bogus Detector Subsystems
5. Particle Transport in Bogus

Introduction

BgsApp is a Framework executable based on Bogus, which in turn is the BaBar application layer over the Geant4 simulation toolkit. The purpose of Bogus is to model the BaBar detector geometry and materials, propagate particles through a varying magnetic field, perform particle interactions and decays, and provide scoring of detector hits. As currently implemented, Bogus is a full and detailed simulation, but it was designed to accomodate both fast and parameterized simulations as well. As mentioned in the BaBar simulation overview, BgsApp is the second stage in the full physics simulation procedure. It accepts particle four-vectors from the event generator, processes them and passes on the scored hits to the detector response code, SimApp, which is another Framework executable.

Bogus in the BaBar Framework

BgsApp is the result of adapting Geant4 to work within the run and event management scheme of the BaBar Framework. In doing this, several aspects of Geant4 run management and event generation were modified, and a module for steering the BgsApp phase of the simulation through the Framework was developed. BfmModule in the package BgsFwkModule is responsible for

1. initializing the Geant4 kernel,
2. extracting event generator tracks from the Framework AbsEvent,
3. invoking Geant4 to propagate these tracks through the detector and
4. writing final GTracks and GVertexs into the AbsEvent.

One of the first things done in the initialization stage is to instantiate the BfmRunManager. This class, which is derived from the standard Geant4 run manager, relinquishes event-by-event control to the Framework and only processes a Geant4 event upon the arrival of an AbsEvent. Once instantiated, BfmRunManager then calls the Geant4 user action and initialization methods to set up the detector model, initialize the physics list, and set up the event generator.

Event generation in Bogus is handled by BfmUserPrimaryGen. As required by Geant4, this class is derived from G4VUserPrimaryGeneratorAction and registered by the run manager as the user generator action. It must implement the GeneratePrimaries() method which fills the Geant4 event. In a standalone Geant4 application, this method might invoke a simple particle gun or more complex methods to provide an initial set of four-vectors for Geant4 to propagate. In the BaBar simulation, however, a separate Framework sequence, GfiSequence, in the package GenFwkInt is responsible for generating the four-vectors from the initial interaction and storing them in the AbsEvent. In this case the Bogus event "generator" does not actually initiate particle tracks, but instead retrieves them from the AbsEvent and passes them to the Geant4 event.

In more detail, this is done as follows. For each AbsEvent, the GetInputEvent() method of BfmModule finds the StdHep object stored in the AbsEvent by GfiSequence. Tracks found in StdHep are then stored in the BfmStdHepInputEvent. Because BfmStdHepInputEvent is derived from BgsInputEvent which in turn is derived from G4VPrimaryGenerator, it can be registered as the generator which implements the GeneratePrimaries() method of BfmUserPrimaryGen. The job of converting the StdHep tracks to Geant4 tracks (G4Tracks) is done by the GeneratePrimaryVertex() method of G4VPrimaryGenerator, which is implemented by BgsInputEvent. In turn the GeneratePrimaryVertex() method is used to implement the GeneratePrimaries() method.

Once the initial four-vectors of the interaction have been transferred to the Geant4 event, they can be propagated through the detector setup. During this stage, particles are transported through the materials and magnetic field of the detector, and physics processes defined in the physics list are applied appropriately. Secondary tracks produced during decays or other interactions will be added to the event. These tasks are accomplished in the nextEvent() method of BfmRunManager when the Geant4 event manager invokes the ProcessOneEvent() method.

When tracks are propagated through sensitive detectors, part of the idealized Monte Carlo information is stored as detector hits (GHits). At the end of the event this information, along with track (GTrack), vertex (GVertex), and trim marker (GTrimMarker) information is written back into the AbsEvent so that it can be passed on to SimApp. The EndOfEvent() method of BgsSensitiveManager is responsible for collecting the track, vertex and trim marker information from all the detector subsystems and putting it into the AbsEvent via proxies. It is called from the event() method of BfmModule. Transferring the GHit information to the AbsEvent is performed by each of the subsystems separately using the EndOfAbsEvent() method in the corresponding BgsXXXFullSD class.

Running BgsApp in the BaBar Framework

BgsApp ../BgsApp/BgsUserExampleBhwide.tcl

• BgsGHitProductionSetup.tcl,
• BgsAppPatches.tcl,
• the decay file to which the environment variable UDECAY points,
• filter files, if any,
• BdbOutputSequence.tcl,
• BdbSequences/BdbWriteTru.tcl, and
• BdbSequences/BdbWriteSim.tcl.

• BgsInitSequence - provides the "standard" set of modules initializing the environment of a Bogus Framework user application. It should generally be invoked before the user's own modules. It is NOT intended to contain various service modules, including PrintModule, DispModule, and regression tests. Modules added in this sequence typically are: BfmInputModule (the input module for Bogus), GenBuildEnv, MatBuildEnv, PdtInit and subsystem initialization sequences, such as SvtBuildEnv.
• BdbSequence
• RandomControl - see documentation
• EidSim
• EvtMixBdbSequence - appended only if background mixing is enabled
• GfiSequence - a utility sequence containing the "standard" set of modules for invoking MC generators provided in the GenFwkInt package. It should generally be invoked before every subsystem module.
• StdHepAsciiDump - currently disabled
• RandomPickerSimulation
• Bogus - the module name for BfmModule, the main steering module for Geant4.
• DchMakeGHit
• QaSimHistsSequence - provides histogramming of GHits and related quantities
• BfmDiagModule - currently disabled

BgsAppPatches.tcl allows users to communicate with Geant4 by sending instructions to the Bogus (BfmModule module. To do so, BgsAppPatches.tcl should be copied from the BgsApp directory to workdir and then modified by adding stanzas like

mod talk Bogus
  command1
  command2
  .
  .
exit

talkto Bogus {
  command1
  command2
  .
  .
}

BdbOutputSequence.tcl defines and enables the output module, BdbEventOutput, for the application. BdbSequences/BdbWriteSim.tcl invokes for each detector subsystem the transformation of transient GHits into persistent ones and writes them into the Sim database. BdbSequences/BdbWriteTru.tcl is intended to write Monte Carlo truth information into the Tru database, but it is not yet implemented for the detectors.

Bogus Detector Subsystems

In order to define a detector subsystem in Bogus, a material model and a corresponding scheme for storing hits and Monte Carlo truth must be provided. Multiple material models are supported for each subsystem, and are managed by a model manager class. A list of available subsystem models is provided here. Note that currently the only model which is guaranteed to work for all subsysytems is full-model. Some of the other models are being resurrected for use in fast Monte Carlo development.

• PEP (BgsPepSim package)
  • full-model: detailed model of beam pipe, support tube and magnets. No hit scoring.
  • fast-cylinder: model based on an empty cylinder. No hit scoring.
  • fast-model: model implementing a simple geometry for the beam-pipe and the support tube. The geometry parameters are retrieved from the conditions database.
• SVT (BgsSvtSim package)
  • full-model: implements full SVT geometry for detailed simulation. Produces GHits.
  • fast-cylinder: model based on an empty cylinder. No hit scoring.
  • fast-model: model implementing a simplified geometry of wafers and retrieving geometry from the conditions database.
  • fast-param: fast-parametrized model of the SVT. Uses the BgsCEPack algorithm for geometry navigation and tracking, bypassing Geant4.
• DCH (BgsDchSim package)
  • full-model: implements full DCH geometry for detailed simulation. Produces GHits.
  • fast-cylinder: model defining the chamber as a simple cylindrical volume. No hit scoring.
  • cylinder: model containing a detailed description of the materials. The gas volume is a simple cylindrical sensitive volume.
  • layer: model containing a detailed description of the materials. The gas volume is made of 40 sensitive volumes (one for each layer).
• DRC (BgsDrcSim package)
  • full-model: implements full DRC geometry for detailed simulation. Produces GHits.
  • fast-cylinder: model based on an empty cylinder which can hold SST and CST. No hit scoring.
  • very-fast: model without SOB. Has SST, CST, bar boxes and bars filled with true materials. It produces track hits and PID hits.
  • fast-empty: model containing only bars description, no materials inside. Same hits produced in the "very-fast" model.
• EMC (BgsEmcSim package)
  • full-model: retrieves detector geometry through the Euclid (BgsEucIntfce) interface. Produces GHits.
  • sliced-cylinder: simplified full geometry based on a single cylinder volume sliced in such a way that it mimics the real EMC crystal numbering. Barrel and the end-cap are in the cylinder and the geometry is non-projective. Produces GHits.
  • fast-param-cylinder: model based on an empty cylinder envelope. Produces fast hit collections.
  • fast-param-PCone: model based on a (G4Polycone) volume envelope. Produces fst hit collections.
  • fast-cylinder: model based on an empty cylinder. No hit scoring.
  • fast-Pcone: model based on a CSG PCone solid. No hit scoring.
• IFR (BgsIfrSim package)
  • full-model: full geometry of IFR and external iron for detailed simulation. Produces GHits.
  • fast-cylinder: model based on an empty cylinder. This model implements fast parameterization and produces "fast-hit" collections.

By default full-model is chosen for all subsystems. Other models may be chosen for each subdetector by specifying the model name in BgsAppPatches.tcl. Models designed for fast simulation cannot be mixed together with models designed for full simulation and vice versa. A subsystem can be totally excluded by specifying "none" as its model name. An example of the stanza required in BgsAppPatches.tcl to remove a subsystem is given here.

mod talk Bogus
  ifrModel set "none"
exit

In Bogus the detector subsystems are built from parameters which are stored in and retrieved from database federations by proxies. Schemas for defining persistent data have been implemented, as well as an intermediate layer of transient objects designed to make proxies and persistent data classes totally independent of Geant4. For the retrieval of material data a factory class BgsMatFactory has been implemented using the MatEnv package and automatic building of G4Material transient objects according to the needs of each subsystem. Data retrieved through MatEnv are also used in the reconstruction phase of the simulation.

Putting the information into the database in the first place requires that a loader be written for each subsystem. The loader typically reads parameters from an ascii file and converts them into transient objects which are then made persistent.

Particle Transport in Bogus

In early versions of Bogus the default Runga-Kutta stepper provided by the Geant4 toolkit was used to propagate particles through the BaBar magnetic field. It was realized though, that this stepper could not, in a reasonable amount of execution time, provide the micron-level tracking precision required for the detailed simulation. Noting that the BaBar field was almost uniform throughout most of the detector volume, a specialized, alternative stepper was developed which avoids the Runga-Kutta integration. Tracks are treated either as straight lines or perfect helices. Where the field is nearly uniform, large helical steps may be taken. Where the field begins to change, the helical step size is reduced until the expected deviation from a perfect helix in that region of the field falls below a preset limit.

The use of perfect helices also allows a more precise calculation of volume boundary crossings. A simple intersection between track and boundary is found and, in one step, the particle is brought to the edge. With the default Geant4 stepper, the step size is continually reduced as a particle approaches a boundary, until it falls within a preset distance.

The alternative stepper, BgsTransportation, is found in the package BgsG4Extension, and is implemented as a Geant4 process in the same way as the default stepper. Although it is easy to switch back and forth between steppers, BgsTransportation is set as the default BaBar stepper in BgsGHitPhysicsList.tcl as follows:

talkto Bogus { 
  useBgsTran set 1
}

Downstream Modules