OscarProducer : Geant4-based Detector Simulation Module

Introduction

Full-scale simulation of the CMS detector is based on the Geant4 toolkit. It relies on a fairly detailed description of the hierarchy of volumes and materials, and knowing which parts are "sensitive detector" (i.e., furnished with a readout) as opposed to "dead materials".

Generated particles are traced through the hierarchy of volumes and materials , and the physics processes that accompany particle passage through matter are modeled. Results of each particle's interactions with matter are recorded in the form of simulated hits. An example of a simulated hit can be energy loss by a given particle within a "sensitive volume" of one of the subdetectors, stored along with several other characteristics of the interaction. Particles can be either "primary" (generated particle) or "secondary" (a result of Geant4-modeled interactions of a primary particle with matter).

The Software

As a software component, it's organized as a single module OscarProducer which plugs directly into the cmsRun framework executable.
In the standard applications the module is labeled "g4SimHits".

The implementation involves a substantial amount of code, which is located in the SimG4Core and SimG4CMS subsystems.

Related mandatory software components are Geometry and Magnetic Field setups. Please visit SWGuideDetectorDescription and SWGuideMagneticField if you wish to learn more details.
Also required are random number engine and seed settings.

If you compose your production-type application with the use of standard cmsDriver utility, all these software components will be included automatically.
However, if your task calls for a custom, "hand-made" application, you may want to learn more details through the links and tips we provide.

Input and Output

As the input, detector simulation takes generated event record in a form of HepMCProduct.
In other words, in order to run CMS detector simulation software one must either read in (via PoolSource) a pre-generated sample, or explicitly have the generation step in the event processing chain.
Please note that a user can actually select a subset of the particles that fit into a certain, user-specified, kinematic region, as described below.

The output of the detector simulation are several edm::Event branches. Of these branches, two are of primary interest to end users doing analysis - edm::SimTrackContainer and edm::SimVertexContainer. They're are kept in the RECO-level production samples. Please visit SWGuideDataFormatSimG4Core for more details.
Knowing of other branches, such as simulated hits, etc., might be useful for a limit set of special-purpose applications. We plan to add more detailed documentation on that in the near future.

Configuration Parameters

As any module, OscarProducer comes with a set of configuration parameters. The standard CMS-approved set of parameters is distributed via in a single file SimG4Core/Application/python/g4SimHits_cfi.py.

The distributed standard configuration must be used for production jobs, and is highly recommended for other applications.
However, one can think of some specific application that should be custom-configured, via modifying parameters or subsets of parameters. Below is (incomplete) list with brief comments:

  • bool UseMagneticField - to turn magnetic field on/off
  • vstring G4commands - to apply Geant4 pre-defined commands
  • PSet CMS.MagneticField - to control precision of tracking in the magnetic field
More Less
  • untracked bool Verbosity - False by default; if True, will allow printouts of various service information
  • bool UseLocalMagFieldManager - False by default; the alternative option (True) is not necessarily practical, because CMS settings for tracking in the magnetic field are optimal (CMS IN-2008/001); the True can be used for some specific, advanced studies, to require particular conditions and accuracies in one or another sub-area of CMS detector; if chosen True, a dedicated subset of parameters to define local magnetic field managed will be needed - instructions will be added on demand
  • PSet ConfGlobalMFM - a subset of parameters to specify accuracy of Geant4 tracking in the magnetic field; as already mantioned above, the default settings are optimal and are NOT recommended to change; the settings apply to the global "mother" volume and propagate to all sub-systems of the CMS detector
  • double delta - expressed in mm and defines magnetic field "caching", i.e. if the Geant4 tracking step is less that delta, the magnetic field is re-used from the previous point rather than being retrieved from the map (or re-calculated from parametrization)

  • PSet Physics - to select pre-fabricated combo of Geant4 physics models, arranged into so-called physics list
More Less
  • string type - this is by far one of the most important parameters, as it selects the physics list, that is a composition of models within Geant4 to simulate interactions with matter of various particles in different energy ranges; the default is "SimG4Core/Physics/QGSP_BERT_EMV", where the SimG4Core/Application tells the loader the location of the physics list, and QGSP_BERT_EMV is the physics list itself; the choice has been made upon very detailed study by the CMS HCAL Simulation Task Force (the link will serve as temporary reference until the Task Force Report is published); in principle, CMS Simulation software provides a variety of other physics lists, such as (old) LHEP, QGSP, QGSP_EMV, etc., as well as "dummy" lists for testing purposes, such as DummyPhysics (EM processes only)
  • double G4BremsstrahlungThreshold -
  • double DefaultCutValue - expressed in cm, default is 1.; this defines minimal distance that a particle must be particle must be able to travel in material, before its kinetic energy runs off; if particle's kinetic energy is not sufficient to travel upon specified distance in a given material, the particle is considered "non-tracebale" and is stopped right there, with its energy to be deposited on the spot
  • bool CutsPerRegion - default is True; it defines that in certain subsystems of the CMS detector specific cuts will apply and will override the "global" default one described right above; those specific cuts are given together with geometry specifications, via dedicated XML sources
  • bool Verbosity - default is False; if True, a large amount of service information will be printed out
  • PSet GFlash - this option is False by default; in principal, this subset of parameters activates parametrized simulation of EM and in perspecive of HAD showers in the CMS Calorimeters; the feature is currently in the stage of fine-tuning for EM showers and in advanced development for HAD showers

NOTE: the whole family of bool parameters starting with 'Flag' are NOT of practical interest to end-users and are there for testing newly-added physics lists, such as QBBC

  • PSet Generator - to select generator's particles to be traced through detector, based on user-defined kinematic cuts
More Less

  • PSet TrackerSD - to customize signal recording in Tracker
  • PSet's CaloSD, ECalSD, HCalSD - to customize signal recording in the Calorimeters
  • PSet MuonSD - to customize signal recording in the Muon systems
  • PSet's HFShower, HFShowerLibrary - usage of parametrized hadronic showers in the HF
  • PSet's CastorSD, TotemSD, ZdcSD, FP420SD - to customize signal recording in the very forward detectors
  • PSet's HCalTB02SD, EcalTBH4BeamSD, HCalTB06BeamSD - to customize signal recording in the Test Beam applications
Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2009-09-02 - JuliaYarba
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    CMSPublic All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback