Geant4 Tools

Collaboration diagram for Geant4 Tools:

Classes
class	tls::DefaultPhysicsList
	Default physics list to be used by multiple Geant4 modules in one offline session. More...
class	DummyProcessAtRest
	class that is used to suppress Error output from Geant4 when deactivating all AtRestDoIt processes. More...
class	tls::G4OutputHandler
	This class redirects Geant4's streams G4cerr and G4cerr to the framework's utl::ErrorLogger. More...
class	tls::G4VPhysicsListCustomization
	Class to specify customization of the standard global PhysicsList that are handled by the Geant4Manager. More...
class	tls::Geant4Customization
	Data structure to hold the different Geant4 global objects required to run a single module. More...
class	tls::Geant4Manager
	class that handles multiple Geant4 runs in one offline session More...
class	tls::GlobalPhysicsList
	G4VUserPhysicsList to aggregate physics lists to be used by multiple Geant4 modules in one offline session. More...

Detailed Description

First things first:

Global variables are evil!

Almost everything in Geant4 is a global variable. These variables specify the state of the Geant4 framework. If we now want to use Geant4 in two modules that will alternate running, we are in pickle. There is now way to guarantee a consistent switch between two states. Period. The current solution is not perfect but it works.

The main class in this group is the tls::Geant4Manager. This class is the singleton class that takes care of setting the Geant4 global variables. Its main use-case is when trying to use more than one Geant4 module in the same run (like simulating SD and AMIGA). It also handles the redirection of output sent to G4cout into the ErrorLogger as well as setting the seed for the CLHEP random engine to the value specified in the framework's configuration.

In the case when we use two different Geant4 modules, we need two separate sets of class instances that may include:

<ul>
<li> Physics list, </li>
<li> Detector construction, </li>
<li> Primary injector, </li>
<li> Optional user-defined actions (Run, Event, Stacking, Tracking, and Stepping). </li>
</ul>

We then need to switch back and forth between them in a simple manner whenever it is needed. Even when a module does not define one of the optional user actions, it is required that the user actions belonging to other modules do not interfere. These tools deal with this issue.

<h2>Issues:</h2>

<ul>

<li> Geant4 uses many global variables, so there are zillions of
possibilities for failure. Things need to be created and deleted
in order (e.g. primary injector must be created after setting the
physics list). Generally speaking, the run manager is the first
thing to be created and it takes ownership of all
actions. Normally the user deletes the run manager. In our case,
the run manager is owned by the Geant4Manager static instance and
this instance gets deleted at exit. It is important then that the
deletion order is correct. We haven't been able to ensure proper
destruction in the Geant4Manager destructor as this seems to
conflict with something in the Geant4 framework. <b>What we have
implemented is a \link tls::Geant4Manager::NotifyDelete
NotifyDelete \endlink method which needs to be called as many
times as the number calls to \link
tls::Geant4Manager::AddCustomization AddCustomization.\endlink
</b> Ugly. </li>

<li> Still, <b> the destructor of the customized geometries is
currently not called.</b> The only destructor that gets called is the
one of the current detector construction. Trying to delete any of
the others before the run manager causes a crash when deleting the
run manager and viceversa. </li>

<li> Just by attaching a particular G4VUserDetectorConstruction to
the run manager, all the materials become accessible to Geant4
classes. Physics processes might potentially request information
on materials, and if the requested material is not provided by the
current construction one might get wrong results. For this reason
Geant4Manager makes sure that <b>geometries are always constructed
before physics list are constructed</b>.  </li>

<li> There can be only one physics list and it needs to be
constructed _after_ all modules had a chance to provide it's
customization but _before_ the primary injectors. </li>

<li> There is a speciall process: DummyProcessAtRest. This process
is needed because when one adds an atRest process to the physics
list, and later disables it, the Geant4 framework will issue a
warning at each step about there being no atRest
process. DummyProcessAtRest then fills this space. However,
DummyProcessAtRest does not work in Geant4.9.1. It does work in
Geant4.9.4. It _might_ work in Geant4.9.2 and later.

<li> Physics list customizations are special physics lists that
inherit from tls::G4VPhysicsListCustomization and provide methods
to activate/deactivate any custom processes. The need need to know
the default list so they do not create conflicts. </li>

<li> Handling of visualization could also be looked into a bit more. </li>

</ul>