Construct a module from components. More...
Functions | |
| G4RunManager * | CreateRunManager (G4String physicsList) |
Construct a module from components.
The exception to be thrown when the generator can't make any more events.
This is an interface to read rooTracker formatted kinematic info.
This is an interface approximate the rock muons entering CAPTAIN.
Select a position and time to be used as the vertex of a primary particle.
Control which particles are actually tracked by G4.
A sensitive detector to create EDepSim::HitSegment based hits.
Provide a root output for the geant 4 events.
Provide control of the physics list and cut parameters.
A Base for class to build elements of the detector. The method get GetPiece() should construct a new unplaced element that is facing up along the Z axis. The caller will then then rotate the object into position and and place the object into an existing mother volume. These are designed to be called "recursively" with one builder calling another builder. A builder will usually use one or more sub-builders to make any new piece.
The builders should follow a single naming convention. All builder classes should be named "EDepSim::<thename>Builder". When builders are used in code, they are declared using the AddBuilder() method which takes a name (string) which is used to reference the builder, and to make macro commands to control the object. The builder name should start with an upper case letter.
Most builders (all should) will define a messenger. The command names are build with the CommandName() method. All command names should begin with a lower case letter.
Construct a component to be used by a EDepSim::ModuleBuilder to build a component.
Create the standard run manager for the detSim detector simulation. The caller is responsible for deleting the run manager. If a valid physics list name is defined, then that will be used for this run.
Handle the command line interface to change the geometry and other parameters associated with the EDepSim::m detector.
Implement the Doke-Birk recombination probability found in NEST in an optimized form for a LAr. The Doke-Birk parameterization is quite accurate for LAr over the important energy ranges for a LArTPC (E more than about an MeV).
When this is called for a material other than LAr, then the G4 Birk's Law implementation (G4EmSaturation) is used.
This file should always be accompanied by the full NEST implementation since this is a direct modification of the NEST code. The NEST code needs to be provided since it is the arbitor of the performance of this code. Where this code deviates from NEST, NEST is right. Finally, if this is used, the NEST authors should be cited. They did all of the physics. This is just an adaptation of their work to LAr so it's faster, but with much less capability.
The standard exception from detsim. This is usually thrown by the EDepSimThrow macro.
A G4VPhysicsConstructor to provide extra physics processes required by detSim such as step length limiters. The extra physics processes must be explicitly added to every physics list (as an EM list) that is created in EDepSim::PhysicsList::AddPhysicsList(); however, this only effects code actually in that method. This class should not be used outside of EDepSim::PhysicsList. Once this is defined, the step length can be limited in logical volumes as they are created by calling G4LogicalVolume::SetUsersLimits(new G4UserLimits(stepLength)).
This is a base class used to save G4Hit objects into a root output file. It contains the global position of the starting point and stopping point of the track segment that created the hit, plus the any fields provided by CP::TG4VHit. The electronics response is simulated in a separate program (library) which will construct the digitized hits. This class is used with the EDepSim::SegmentSD sensitive detector class, and can be requested using the "segment" name from EDepSim::SensitiveDetectorFactor::MakeSD().
Provide control over log and error output. The EDepSim::LogManager class provides a set of static methods which control the amount of output from the logging macros. These macros come in two varieties (logging macros, and error reporting macros). The level of output from the logging and error macros is controlled separately.
The logging macros print the output to the log file with a simple header which allows them to be located using a search tool (like grep). All of these macros accept a Streamish Argument and can produce multiple lines of output. The logging macros are:
The indentation levels of log messages can be controlled using the EDepSim::LogManager::IncreaseIndentation() and EDepSim::LogManager::DecreaseIndentation() static methods. These should be used in pairs.
The error macros print output to the error file with a header indicating the error level (ERROR, SEVERE, WARN, DEBUG, or TRACE), the file and the line of code where the message originated. Error macros should be used to report any problem found during execution. They are particularly useful for debugging. The syntax for the error macros is the same as for the logging macros. The error macros are:
In addition to the default logging and error macros, there are macros that take a "trace" name. The level of output from each type of trace can be controlled separately. The named variety of macro takes two arguments (a Trace Name and a Streamish Argument). The named macros are EDepSimNamedLog(), EDepSimNamedInfo(), EDepSimNamedVerbose(), EDepSimNamedError(), EDepSimNamedSevere(), EDepSimNamedWarn(), EDepSimNamedDebug(), and EDepSimNamedTrace().
The logging (and error) output macros are used like functions, except they take arguments that can be output to a stream variable (a so called Streamish Argument).
If the logging level is set to EDepSim::LogManager::LogLevel produces:
But if the logging level is set to EDepSim::LogManager::VerboseLevel, this writes:
The logging level can be set using the "edeplog.config" file (see The EDepSim::LogManager Configuration File) to define a log level
The named logging macros are used in the same way as the unnamed macros, except that you must provide a string as the first argument. This string is then used to define a "trace" which can be turned on explicitly without causing output from other logging statements.
If the "traceName" logging level is set to EDepSim::LogManager::InfoLevel or above, this produces:
The logging level for traceName can be set using the configuration file statement.
The configuration of the EDepSim::LogManager object can be handled using static methods, or using a configuration file that is read by a call to the EDepSim::LogManager::Configure() method. When the EDepSim::LogManager::Configure() method is called, it will first try to read "edeplog.config" in the local directory. If EDepSim::LogManager::Configure() is called with a file name, the named configuration file will be read after the edeplog.config file and can override any settings.
The EDepSim::LogManager configuration file uses a simple line oriented syntax.
The legal field names are
An example of the edeplog.config file shows how it might be used. This file causes the log messages to be printed in "output.log", and the error messages to be printed in "output.err". The default log level is set to EDepSim::LogManager::InfoLevel so that messages are written from all EDepSimLog(), EDepSimNamedLog(), EDepSimInfo(), and EDepSimNamedInfo() macros. The default error level is set to EDepSim::LogManager::SevereLevel so messages are written from all EDepSimError(), EDepSimNamedError(), EDepSimSevere(), and EDepSimNamedSevere() macros. The error level for the "myTrace" trace is set to EDepSim::LogManager::DebugLevel, so messages are written for any EDepSimNamedWarn() and EDepSimNamedDebug() macro which has a trace argument of "myTrace" (e.g. EDepSimNamedWarn("myTrace","some output") will write "some output" into the log file).
Here is an example of a typical edeplog.config file that would be used during debuging. This assumes that your routine is using the Trace Name MyRoutine (a bad name!), and prints all of the error messages to the terminal.
The available log output levels are:
The available error levels are:
EDepSim::LogManager is singleton class that controls the level of output from the error and logging statements. All of the user visible functions are static.
A "trace name" is a string that can be used to define a group of log (or error) messages that will be printed at the same logging (or error) level. These are used with the "Named" variant of the log macros:
A "streamish argument" is an argument to a logging macro that can be compiled into a stream output statement. For example, a call
has one streamish argument, and will print "A streamish argument" into the log file. The EDepSim::LogManager macros will accept any set of << operator arguments that could be printed to std::cout. NOTE: the streamish argument doesn't start with a << operator.
Writing messages to track the progress of a job, or to help debug software has a few specific requirements. In particular, it needs to meet (at least) the following desiderata.
These desiderata basically the usual log/error output scheme where the basic log code looks like this:
where outputLevel and myStream are global variables. This meets the first requirement since outputLevel is a global variable that can be changed at run-time. The second requirement is met since slowFunction is only called when outputLevel is greater than zero. The second requirement is met since code is only generated when INCLUDE_DEBUGGING_CODE is set.
The final desiderata implies that the ideal source code interface would result in code something like:
Unfortunately, the way C++ processes streams means that this type of interface can't mean the disiderata "2.1", and "3". For instance, even if the run-time verbosity is set so that infoStream will not generate output, the function "SlowFunction()" will be called. It's also not possible for this sort of code to be removed during compilation.
While C Macros are generally discouraged in C++, they provide the only mechanism that meets the design requirements for logging. This results in an interface similar to the one defined by EDepSim::LogManager.
There are several log writing packages available for C++, so why not use one of them? It turns out that several (for an example, google "log4cpp") define an unsatisfactory streams based interface. Other packages I'm aware of tend to have very rich features and a very large number of lines (i.e. log4cplus has 11 KLOC). Many of these packages also bring significant build requirements. By comparison, EDepSim::LogManager is less than 700 lines of code (1200 with comments).
The class is `singleton', with access via G4VPersistencyManager::GetPersistencyManager(). You need to create a single persistency manager for GEANT4 to work right. It must derive from G4VPersistencyManager which will make this object available to the G4RunManager as a singleton. As a singleton, there can only be one persistency manager active at a time. The Store methods will then be called by the G4RunManager::AnalyzeEvent method (the G4RunManager::AnalyzeMethod is protected).
The persistency manager doesn't have to be derived from EDepSim::PersistencyManager, but a lot of the trajectory and hit handling functionality is currently handled by this class, and as of 4.10.2, persistency managers seem to be the only viable hook to allow the event to be summarized after it is fully generated. An alternative might be to summarize the information would be in the G4UserEventAction::EndOfEventAction method and then keep the summary data in the EventUserInformation which is thread local.
Use the G4PhysListFactory to select a physics list for this run. The physics list can be set from the PHYSLIST environment variable, or a macro file. All of the physics lists need to be defined before using the /run/initialize command.
Provide a root output for the geant 4 events. This just takes the summary from EDepSim::PersistencyManager and dumps it as a tree.
Create an object to build a sensitive detector (SD) based on a name and type. The name of the SD will be used by the G4 SD manager to see if the detector already exists. If it doesn't then a new SD of "type" will be built.
Maintain a singleton map of track Id to the trajectory in the trajectory container. THIS IS NOT THREAD SAFE AND CAN NOT BE USED WITH MULTITHREAD GEANT4.
Store a point along a particle trajectory. This is used internally for some bookkeeping, and then is translated into an output class when the event is saved. It keeps track of information like the momentum at the point, the process that occured the the point, the volume containing the point, and the energy deposited at the point.
Hold information that is associated with each primary vertex. This holds the particle reaction code that generated the vertex, the name of the generator that created the vertex, and internal information from the kinematics generator about the physics that generated the vertex.
Copy the vertex position from the source to the destination G4PrimaryVertex object. This has the effect of making the particles in the vertices come from the same location (or vertex). This also has an option to set the position of the destination vertex relative to the source vertex. When this option is used, the source vertex position is added to the destination vertex (i.e. if the source vertex is [10,10,10] and the destination vertex is originally [1,1,1] the destination vertex becomes [11,11,11].
A base class for primary generator classes used in the EDepSim::. This is used by the EDepSim::UserPrimaryGeneratorAction to generate particles which will be tracked by the G4 simulation.
Stores generator mc-truth pass-through information used as input into detsim. This class is a singleton which allows a single tree to persist throughout multiple instantiations of the neutrino primary vertex generators. This is so an exact copy of only the mc-truth information (associated with all primary vertices) used as input for the detsim detector simulation can be made. These primary vertices can come from multiple input files and this class also records bookkeeping information pertaining to the type and name and other useful information, such as POT normalisation, about the input tree and the input file used.
The following illistrates how the entries are copied: First add input trees to TChain by calling,
and then adding a second tree,
for two trees with N_1 and N_2 events and stored in file1 and file2 respectively. These trees corresponding to the trees pointed at in detsim by treePtr1 and treePtr2 respectively. Now calling
(where X can be 1 or 2) will copy the i'th entry from the TChain when X = 1 and the (N_1 + i)'th entry when X = 2. There is no limit to the number of input trees.
Generate one (or more) G4PrimaryVertex objects and add them to the G4Event. This is used by the EDepSim::UserPrimaryGeneratorAction to generate particles which will be tracked by the G4 simulation. This uses the EDepSim::VKinematicsGenerator, ND20VCountGenerator, EDepSim::VPositionGenerator, and EDepSim::VTimeGenerator classes to create the G4PrimaryVertexObjects. The control of the EDepSim::PrimaryGenerator object is through the EDepSim::UserPrimaryGeneratorMessenger class.
A factory to create a time generator to distribute events according to the spill structure. The spill parameters should be set before the generator is created. The spill times are actually generated by an EDepSim::SpillTimeGenerator object.
Generate an interaction time according to the spill parameters. This object is created using the EDepSim::SpillTimeFactory where the spill parameters can be set (there is more documentation there). The time of the interaction is adjusted for the neutrino travel time.
Select a position and time to be used as the vertex of a primary particle, but which is constrained by various standard tests.
A base class used by ND20PrimaryGenerator to select the number of primary vertices to be generated for a G4Event. Classes derived from EDepSim::VCountGenerator are responsible for returning the number of successful calls to be made to the EDepSim::VKinematicsGenerator by the EDepSim::PrimaryGenerator object. Each call to EDepSim::VKinematicsGenerator will create a new "unique" primary vertex; however, it may result in multiple G4PrimaryVertex objects being added to the G4Event. The derived classes must override the (pure virtual) EDepSim::VCountGenerator::GetCount() object. This method must return an integer for the number of verticies to be generated. This count can be zero (or negative), in which case no verticies will be generated.
A base class for specific kinematics generators used by EDepSim::PrimaryGenerator to construct G4PrimaryVertex, and the kinematics for primary particles from that vertex. Classes derived from EDepSim::VKinematicsGenerator are responsible for constructing a G4PrimaryVertex, adding particles to the primary vertex, and adding the vertex to the current G4Event. The derived classes must override the pure virtual methods. The GeneratePrimaryVertex() method does the actual work.
The EDepSim::VKinematicsGenerator derived class should throw an ENoMoreEvents when it runs out of input events.
A base class used by ND20PrimaryGenerator to select candiate vertex positions. Classes derived from EDepSim::VPositionGenerator are responsible for returning new candidate positions that are passed to EDepSim::VKinematicsGenerator by the EDepSim::PrimaryGenerator object. Each call to EDepSim::VKinematicsGenerator will create a new "unique" primary vertex; however, it may ignore the candidate position. The derived classes must override two (pure virtual) EDepSim::VPositionGenerator methods. The EDepSim::VPositionGenerator::GetPosition() must return a G4LorentzVector object which the xyz components filled. The time component will be filled later by a EDepSim::VTimeGenerator derived object. The EDepSim::VPosition::ForcePosition() method must return a boolean to flag whether the EDepSim::PrimaryGenerator should override the position selected by EDepSim::VKinematicsGenerator with the one returned by EDepSim::VPositionGenerator::GetPosition(). The ForcePosition methods should generally return true.
A base class used by ND20PrimaryGenerator to select candiate vertex times. Classes derived from EDepSim::VTimeGenerator are responsible for returning new candidate times that are passed to EDepSim::VKinematicsGenerator by the EDepSim::PrimaryGenerator object. Each call to EDepSim::VKinematicsGenerator will create a new "unique" primary vertex; however, it may ignore the candidate time. The derived classes must override two (pure virtual) EDepSim::VTimeGenerator methods. The EDepSim::VTimeGenerator::GetTime() must return the time which is used to fill the time component of a G4LorentzVector. It takes the candidate vertex position generated by the EDepSim::VPositionGenerator object so that it can correct for time of flight. The EDepSim::VTimeGenerator::ForceTime() method must return a boolean to flag whether the EDepSim::PrimaryGenerator should override the time selected by EDepSim::VKinematicsGenerator with the one returned by EDepSim::VTimeGenerator::GetTime(). The ForceTime method should generally return true.
| G4RunManager * EDepSim::CreateRunManager | ( | G4String | physicsList | ) |
Definition at line 14 of file EDepSimCreateRunManager.cc.
1.8.11
