Simulation

This page is a draft, please help complete it!

This page page needs expert review!

Introduction

The simulation of particles in the detector are used for many purposes. Standard model physics is simulated to estimate the backgrounds we can expect. Conversion electrons are simulated to study the efficiency for detecting new physics processes. Other simulations might tell us if a detector component will receive a survivable radiation dose. Still others might be used to optimize detector design or reconstruction algorithms.

Simulations start with a generator step. This step creates the initial particles to simulate, for example, protons approaching the primary target or cosmic rays approaching the top of the detector. Our generators include protons hitting the primary target, cosmic rays, and particle guns. Once the initial particles are set in motion, the details of the particle interactions with magnetic fields and materials are simulated by the geant package, which has been used widely in HEP for years and is the industry standard. Geant steps particles forward in time and at each steps allows for particles to scatter, range out, decay or interact with the material and produce more particles to trace. The processes are drawn from physics models using random numbers to to determine quantities which are only known statistically, such as scattering angles, which of several processes might occur, and decay times. The careful use random number seeds insures that the simulated events are statistically independent. In this way, the code builds up each event consisting of many particles traced through the material in as much detail as is needed by the user's analysis.

The process of simulation is considered done once random numbers are no longer used. So the particles are traced and all their true paths, steps, and energy deposits are known. At this point, the amount of energy that is recorded by the detector also has to be simulated with some measurement error, which will include randomness. The detector measures are recorded in data products called digis. The digi products are what we will see in real beam data. After this step, the reconstruction algorithms are performed, which do no use random numbers.

The following sections are high-level overviews of topics in simulation. The design of simulation project can be complicated and practical techniques have been developed.

Practical techniques

Detailed simulation can be computationally expensive. The collaboration may need to run grid jobs for months to create enough statistics - it all depends on the needs of the project. Since there may be many demands on a simulation, several techniques have been developed to create and use simulation efficiently, not doing more computing than needed.

• Staging
  • simulation may be stopped and started again, for various practical reasons
  • Examples: stop simulation just outside the detectors, write it out
• Mixing
  • simulate different parts of an event, for example a conversion electron and everything else, simulated up to a certain point, and mix these simulations together to one event with an electron and all the standard model noise.
  • Example: simulate all standard model physics in a event and a conversion electron separately, then mix them
• Time simulation
  • The decay of particles may be turned off, or delayed
  • Example: stop simulation when muons stop in the target - decay/interact them in later jobs
• Resampling
  • Take the output of a stage and simulate it many times with different random number seeds.
  • Example, a fairly small set of stopped muons can be used over and over again. This works as long as the variations in the events are significant. In the example of stopped muons, each resampling decays a muon with the electron launched into a different direction. This leads to very different result for hits in the detector even though the same stopped muon was used.
• Filtering
  • Only write events which pass some criteria
  • Examples: require high-momentum e-, or some activity in tracker before saving a cosmic ray event
• Dropping
  • Do not write out all data products
  • Example: drop MC digi truth information, drop the digis after tracks are made
• Multiple streams
  • Write some events to one output file, some to another
  • Example: events w/stopped muons to one file, the rest of the particles to another
• Variants
  • Run one simulation stage with variations in the detector geometry or physics parameters
  • Example: repeating background measurements with different calorimeter designs
• Compression
  • Compress particle lists, removing unneeded entries
  • Example: Compress large EM showers into smaller summary products; remove particles that do not leave any trace in a detector
• Error flagging
  • flag events as having errors or producing extremely long particle lists
  • Example: cosmic ray events with more than 100K particles are stopped and written to "truncated" output stream

See also practical grid job planning.

Products

The output of simulation includes high-level truth products which describe the event, and low-level product that describe each step of each relevant particle.

GenParticle

This product includes information about the type of generator and the particles produced by the generator. For primary protons, this will include the position and momentum of the primary particle.

SimParticle

Simparticle product includes the initial and final time, position, momentum, and type of all particles geant traced. It records the physics process that created or destroyed the particle. If a particle decays or interacts to produce more particles, then those new particles will point to the original particle as their parent.

If a simulation is stopped, when it is restarted, the code will find SimParticles that are still viable, and start tracing them again. Each particle will have a unique number. Typically, each simulation stage N will number its particles starting with (N-1)*100,000.

The SimParticle product can become very large, especially in events with EM showers, such that it can create memory or storage issues. The SimParticle product is often purged of any particles that don't leave energy in a detector, or produce particles that leave energy in a detector.

StepPointMC

This product records the time, positions and energy loss of a geant step. It is only recorded while the particle is in a sensitive detector: a straw, a calorimeter cell, or CRV bar. These steps are used to create the digis, the products in the events from real data detector readout. A StepPointMC is also used as a way to record where a particle crossed a boundary of a virtual detector, for studies or staging, such as the virtual volume enclosing the DS, or the tracker.

Geometry

For geant to run efficiently, it requires that all surfaces and volumes are described in its geometry hierarchy. The geometry is determined by the fcl services entry:

services : {
   GeometryService        : { inputFile      : "JobConfig/cd3/geom_baseline.txt" }
}

See the geometry pages for how to specify and modify geometries.

overlaps, different geometries for different stages, geomtry visualiztion

sensitive detectors

Sensitive detectors are a list geometry objects that we are particularly interested in. The basic sensitive detectors are places where energy is measured: straws, calorimeter cells and CRV bars. Each sensitive detector can produce an art product that contains StepPointMC's that occur in that sensitive detector. These StepPointMC's are used to create digi's which are the energies as read out by the detector channels. If the staging of a simulation is designed so that a detector is not simulated that sensitive detector should be left disabled.

A typical sensitive detector configuration

physics : {
   producers: {
      g4run : {
        SDConfig: {
            enableSD: [ tracker, calorimeter, calorimeterRO, CRV, virtualdetector ]
         }
      }
   }
}

A typical resulting set of StepPointMC products

Friendly Class Name                    Module Label        Instance Name   Process Name     Product ID
mu2e::StepPointMCs                           g4run                  CRV  AllPatRecReco           1:40
mu2e::StepPointMCs                           g4run              tracker  AllPatRecReco           1:43
mu2e::StepPointMCs                           g4run          calorimeter  AllPatRecReco           1:41
mu2e::StepPointMCs                           g4run        calorimeterRO  AllPatRecReco           1:42
mu2e::StepPointMCs                           g4run      virtualdetector  AllPatRecReco           1:44

persistence

The story of CompressPV.