On this page, the code related to the infrastructure of gnomon will be discussed which is mostly contained in the base of the gnomon package. Please see the User Documentation for information on the processors.
At a basic level, the core of gnomon is either code to satify Geant4 interfaces (EventActions, etc.) or internal bookkeeping (configuration, etc.).
Manage how gnomon configures itself and its proceesors
This class is used within gnomon to tell various classes how to configure themselves. Each Configuration class will generate or retrieve a JSON file that is used afterwards by various other classes.
Any proposed configuration JSON file is compared against a configuration schema. The schema requires certain attributes be specified in order to start gnomon. The schema checker is forgiving in that new configuration keys are allowed without changing the schema; the schema only requires certain things be defined, it doesn’t prevent you from defining new things.
Any new configuration must inherit from ConfigurationBase.
Base class for all configuration classes
If the run number is zero, replace it with a random run number
Return configuration as a dictionary
Permanently set the JSON configuration
Unable to call twice.
alias of LocalConfiguration
Read a configuration from disk and overload if necessary
Mock configuration for testing
This is just a copy of LocalConfiguration for now
Fetch the Configuration schema information
Finds the schema file, loads the file and reads the JSON, then converts to a dictionary that is returned
Find the data directory that stores geometries, cross sections, etc.
Find the directory used for saving log files
Find where the truth path to the directory containing the Configuration module source code
It can be useful to know the full path to the Configuration module’s source code in order to try to guess where the data and log files are stored. It does this by inspecting the current running python instance.
Add commandline arguments to parser from schema
Use a schema to populate a command line argument parser
Construct a detector within Geant4
This module deals with creating detectors (geometries, sensitive detectors, etc.) and interfacing them with Geant4. There is, for example, a class that loads geometries from GDML.
TODO: can box construction and calorimeter construction be superclassed? Ideally with superclass handling the Geant4 interface and the subclasses tweaking the detector for their specific need.
The EventAction is used by Geant4 to determine what to do before and after each MC event.
A Geant4 interface that subclasses G4UserEventAction and runs processors over Geant4 events
Save event number
At the end of an event, grab sensitive detector hits then run processor loop
Hook to the sensitive detector class
User for fetching hits from sensitive detector to pass to processor loop
Shutdown each processor
Generator actions
These classes are used to tell Geant4 what particles it is meant to simulate. One always has to inherit from a UserPrimaryGeneratorAction base class in Geant4 and then define the function GeneratePrimaries.
Generator base class
Generate events from a Genie ntuple
A Genie ntuple that already knew the GDML would be useful. Otherwise, we run gevgen per material and have to do nasty geometry stuff here
Geant4 interface class
Baseclass for gnomon particle generators
Deriving from scipy.stats failed, so just overloaded rvs. This really should hook into the GDML or something since it is geo dependent this way
Return material of last rvs call
Lookup the charge current partner
Takes as an input neutrino nu_pid is a PDG code, then returns the charged lepton partner. So 12 (nu_e) returns 11. Keeps sign
Take each key (ie. point) in the graph and for that point create an edge to every point downstream of it where the weight of the edge is the tuple (distance, angle)
Returns a dictionary object with keys that are 2tuples represnting a point.
node is start node
Handle routing output, errors, and exceptions to disk and screen
Fake file-like stream object that redirects writes to a logger instance.
Add log level arguments to command line parser
This is not in the schema because the log level needs to be known when setting up the Configuration classes
Return log levels that Python’s logging facilities understands
Toroid Field from Bob Wands simulation parameterization
scale has the sign of the field. Focus signal with scale = 1, focus background with scale = -1. Have 80% field with scale = 0.8
B0, B1, B2, and H are fit parameters.
Default values from Ryan Bayes, March 15th, 2012, talk to Valencia grp. B0 = 1.36 # T B1 = 0.0406 # T m B2 = 0.8 # T H = 0.16 # 1/m
Field to field map from Bob Wands, 1 cm plate, Jan. 30, 2012
Fit to field map
A phenomenological fit by Ryan Bayes (Glasgow) to a field map generated by Bob Wands (FNAL). It assumes a 1 cm plate. This is dated January 30th, 2012. Not defined for r <= 0
Emits hits without energy deposit
Useful for testing purposes
SD for scint bar
Return the number of bars per view
Return the number of layers in z, where a layer is steel plus two views
Determine the detector view starting with a G4LogicalVolume