LArSoft
v07_13_02
Liquid Argon Software toolkit - http://larsoft.org/
|
basic interface to Geant4 for ART-based software More...
Classes | |
class | ConvertMCTruthToG4 |
class | DetectorConstruction |
class | G4Helper |
class | PrimaryParticleInformation |
class | UserAction |
class | UserActionFactory |
class | UserActionManager |
Typedefs | |
typedef g4b::UserAction *(* | UserActionCtorFuncPtr_t) () |
Variables | |
static G4VisExecutive * | vm_ = 0 |
G4Allocator< PrimaryParticleInformation > | PrimaryParticleInformationAllocator |
basic interface to Geant4 for ART-based software
27-Jan-2009 selig Revised for LArSoft. 2012-08-17: man@ nevis .col umbia .edurhatc Add G4UserStackingAction interfaces her@ fnal. gov
LArG4::UserActionManager.h 18-Sep-2007 Bill Seligman
27-Jan-2009 selig Revised for LArSoft. man@ nevis .col umbia .edu
In my experience, people barely understand what the UserAction interface does. So why do we need a UserActionManager class?
Suppose I've written a class that inherits from UserAction that makes histograms. You've written a class that inherits from UserAction to write events to a disk file. Jane has written an UserAction that makes ntuples. A big massive 500-CPU-hour run of G4 is planned, and we're all planning how to put our user-action classes together.
By using a UserActionManager class, each one of us can develop our own user-action classes independently. Then, when we have the big run, the user-action classes can be put successively called by the UserActionManager without changing any of the classes.
Another feature is the ability to separate different user-action functions. For example, you don't have to mix your code that writes hits with the code that makes histograms; the code can be put into separate classes.
18-Sep-2007: Make this a true "Manager" class by turning it into a singleton. Give the UserAction-derived classes access to the Geant4 user-class managers.
2012-08-17: rhatc Add G4UserStackingAction interfaces. By default these aren't invoked unless the her@ fnal. govUserAction::ProvidesStacking() returns "true". Generally there should be only one such in the managed list, but if there are and they can't agree on the track classification then prioritize them in what seems a sensible manner.
typedef g4b::UserAction*(* g4b::UserActionCtorFuncPtr_t) () |
Definition at line 32 of file UserActionFactory.h.
G4Allocator< PrimaryParticleInformation > g4b::PrimaryParticleInformationAllocator |
Definition at line 13 of file PrimaryParticleInformation.cxx.
|
static |
Definition at line 51 of file G4Helper.cxx.
Referenced by g4b::G4Helper::~G4Helper().