Sim G4 framework

Below is the proposed framework for the solid simulation in Geant4. Inputs are given in filenames below. Output is given in the form of a ROOT file with at least a TTree with event-by-event information and information about inputs given (ideally with the full input files stored within)

Geant4 User Defined Classes

Geometry

Geometry is defined by user written text files. No materials, geometries, nor detectors are specified within the code.

• Relies on SolidGeoParser class to generate geometry (file specified in Geometry messenger in Geant4 macro)
• Relies on SolidFieldParser class to generate field map (file specified in Geometry messenger in Geant4 macro)
• Relies on SolidDetParser class to generate sensitive detectors (file specified in Geometry messenger in Geant4 macro)

Physics

Physics/particles lists will be done with predefined lists in code. Used list will be determined by messenger. Possible lists are:

• Physics lists:
  • No interactions
  • Energy loss through EM processes (no generation of secondaries)
  • Secondaries generated with full EM
  • Full EM + Hadronic interactions (hadronic package to be determined)

• Particle lists:
  • e-
  • e-, photon, pi+-0, proton, neutron
  • above and K+-0, mu+- (probably don't need anything heavier)

Primary Generator

Primary generator will be specified through messenger. Generators should be defined in their own class and inherit from a common SolidGenerator class. Types of generators:

• DIS
  • flat in cos(th), ph, E'
  • flat in x,y,ph

• Background
  • e- down beamline (number of e- per event specified)

Run Action

Messenger specifies ROOT file name output, output list. Uses SolidOutput class and gives this glass the filesnames given by the messenger.

Event Action

Responsible for event-by-event calling the SolidOutput class to write information. Complicated detector processing?

Helper Classes

SolidGeoParser

Reads in geometry description and creates geometry. Specification outline

SolidFieldMap

Reads in geometry. Should be generic class with SolidPoissonField inheriting for POISSON fieldmaps

=== SolidFieldManager

Handles collections of fields

SolidDetectorParser

Reads in detector class (possibly combined with SolidGeoParser). Meshes with generic detector class through names and named volumes. Should be able to specify more complicated detector association

SolidGenerator

Generic generator class. See PrimaryGenerator Geant4 class

SolidOutput

Uses generic SolidData class to write output to ROOT files. Responsible for setting up ROOT files. Should write all input files into the ROOT file with the intention of being able to completely reconstruct output. Maintains list of SolidData instances for output, which are registered at their creation creation. Matches output definition to variables in SolidData for ROOT files. This class should live as a global variable?

SolidData

Has a "name" and list of output variables. Possible classes to derive from this:

• Track (with three momenta, particle type information, cross section, etc)
• Detector output (hit time, Edep, local position, lab position)

SolidDetector

Generic detector associated with volume which records:

• Particle type
• Time of hit
• Edep
• Particle trajectory
• Hit position (local and global coordinate)

Complicated Detectors

Complicated detector systems should be self contained in their own class (or set of classes). We should specify a class that all complicated detector systems will inherit from (SolidDetector may be sufficient). It may be worthwhile to keep all these classes as a separate library to avoid large recompilation jobs.

SolidSimInfo

Class to hold input file text/information, reconstruct input files. Is written to ROOT tree. The intent of this class is to easily reproduce all input so the data contained in the tree is reproduceable

• Print() function
• Reconstruct() function writes out all input files as they were used

Should be possible to keep subversion file revision numbers here so a simulation version can be fixed with each. This could be an enormous benefit in debugging/reproducing data.

Conventions

General programming practices

• Dangling pointers set to NULL
• All pointers passed as input are checked if NULL in that function
• Functions that can fail should output condition as return type (e.g. -1 if failed, 0 if OK)
• All functions that can fail are checked for error condition
• Functions that fail verbosely write errors to stderr with <class>::<function> and a verbose description of error
• Fix all compilation warnings (unused variables, type mismatches, etc...)
• Tag regions as FIXME where work needs to be done so it's easy to find

Documentation

• Use doxygen [1] to produce documentation (host it on someone's JLab page)
• Each class has a description of its use
• Each function has a description of its purpose, description of all parameters, description of output, possible failure conditions

Naming Conventions

• Classes use Solid... in CamelCase (e.g. SolidThisClass)
• Functions are verbs in CamelCase (e.g. IntegrateAcceptance)
• Class variables are f.... in CamelCase (e.g. fEventType)
• Local class instances start with lower case letter (solidSystem)
• Global variables are g... in CamelCase