6.5 Simulating and Reconstructing events with Fast Simulation

Complete: 4
Detailed Review status

Goals of this page

In the previous sections dedicated to event generation and full simulation, you have learnt how to use the CMSSW framework and the command line cmsRun to generate events, to simulate their interactions with the CMS detector with a very detailed GEANT-based simulation, and to produce digi's as in the real data. These digi's are then readable by the event reconstruction algorithms, which are documented in the pages which follow this one. If you have tried the tutorials, you probably will have noticed that the CPU time needed to execute the whole chain is of the order of xx minutes per ttbar event without pile-up simulation, and that the disk space needed to save the reconstructed events (for subsequent reading by an analysis program) is all but negligible.

The goal of the present tutorial is to quickly enable the CMS physicist to simulate and reconstruct events with the CMS detector, in view of doing physics analyses, develop and tune reconstruction algorithms, design detector upgrades, test new theories, scan parameter space... etc, without being penalized by CPU time considerations and without the need of saving events on disk, while still benefiting from an accurate simulation of the detector effects.

Because this Fast Simulation is just another (very similar) cmsRun job like the GEANT-based simulation, with just (some) config file differences, and because it produces reconstructed events in the very same format as the complete chain, only the differences are described here. You'll learn what the Fast Simulation is all about, how to setup your environment, how to define your simulation and reconstruction sequence, how to run a Fast Simulation job, and where to find further and more detailed documentation to master all ins and outs of this tool.



As mentioned above, the CMS Fast Simulation is a CMSSW-integrated tool to simulate and reconstruct events with the CMS detector, in view of doing physics analysis without being penalized by either CPU time or disk space considerations, while still benefiting from an accurate simulation of the detector effects. To achieve this performance, a number of simplifying assumptions were made, a number of dedicated parametrizations were used, and some optimized reconstruction algorithms were developed. Most of these Fast Simulation- specific features are metioned/described in the present document and, more importantly, all validated with and tuned to (i) a very detailed GEANT-based CMS simulation, (ii) the full reconstruction, (iii) results of benchmark physics analyses, (iv) the outcome of test-beam data, and (v), just started, the outcome of the first collision data. While the Fast Simulation does not depend on the GEANT software at all, the GEANT-based simulation and the subsequent reconstruction, together with the results of test-beam data, are therefore tools that have been, are and will remain essential for (among other things) the existence, the development and the tuning of the Fast Simulation.

It is worth empasizing that the output of the Fast Simulation is based on the same data formats as the output provided by the complete reconstruction of either fully-simulated or real-data events. As a consequence, high-level algorithms like ECAL clustering, particle-flow reconstruction, or b-tagging algorithms, can be used in Fast Simulation without changes. Analysis code is therefore expected to work in a transparent way with Fast Simulation. A very nice bonus is that the present workbook documentation applies with essentially no restrictions to these items, as well as to the event generation step.

This tutorial is expected to work with the latest release (and even pre-release) of CMSSW. However, some earlier CMSSW and Fast Simulation versions may still be used. Please have a look here to see the supported versions.

How to run the Fast Simulation

Fast Simulation is just yet another cmsRun job, steered with a configuration file, to generate, simulate, reconstruct and analyse events in one go. It consists of several steps: (i) Random number initialization, (ii) Event generation or reading, (iii) optional Primary vertex smearing, (iv) SimHit production, which includes an optional Pile-Up step, (v) optional Pile-Up mixing, (vi) RecHit production, (vii) optional misalignement and miscalibration, (viii) L1 and High-Level Trigger condition emulation, and (ix) Physics Object reconstruction, before your analysis program can take over.

Set up your Environment

The documentation written below works for the CMSSW_3_3_6(3_1_6) release (see next section for all supported versions). One can set up the environment by following the next steps one by one.
  • Some most recent versions of the CMSSW (34X series) are available and only for gcc434 compiler and intended for usage on SLC5 Linux machines (e.g. lxplus5.cern.ch) , so that one needs to logon to such a PC (lxplus5):
  • Setup your CMSSW area:
 scramv1 project CMSSW CMSSW_3_3_6 (or  CMSSW_3_1_6) 
  • Go to the src/ directory
 cd CMSSW_3_3_6/src (or CMSSW_3_1_6/src)
  • Define the CVS repository and all necessary symbols, executables, ... compatible with the current CMSSW version
 eval `scramv1 runtime -(c)sh` 
  • Check out the package where configurations and examples are defined
 addpkg FastSimulation/Configuration

Usage of cmsDriver

The recommended tool to produce a full-production (one-go) Fast Simulation configuration file is cmsDriver. You have to pay attention to various specific options (like --pileup, -beamspot , etc.; -n, which sets the number of events to be generated) and provide the generation fragment (Tbar_Tauola_cfi.py in the cases below) from Configuration/Generator/python (default location). Off course, to actually produce the event file you must run the obtained configuration with the cmsRun command.

The cmsDriver syntax to be used in the latest recommended releases is:

for CMSSW_3_1_6:

cmsDriver.py TTbar_Tauola_cfi.py -s GEN:ProductionFilterSequence,FASTSIM --pileup=NoPileUp --conditions=FrontierConditions_CMS.GlobalTag,MC_31X_V5::All --eventcontent=FEVTDEBUGHLT --beamspot=Early10TeVCollision --datatier=GEN-SIM-DIGI-RECO -n 10 --no_exec

for CMSSW_3_3_6

cmsDriver.py TTbar_Tauola_cfi.py -s GEN,FASTSIM --pileup=NoPileUp --conditions=MC_3XY_V9A::All --eventcontent=FEVTDEBUGHLT --beamspot=Early10TeVCollision --datatier=GEN-SIM-DIGI-RECO -n 10 --no_exec

For further examples of cmsDriver produced configurations, you may look for the ones prepared for the Fast Simulation CMS.RelVal samples production and listed in Configuration/PyReleaseValidation/data. They contain also the Validation step (-s GEN,FASTSIM,VALIDATION) which produces the Monitoring Elements used in the release validation, and can be removed if not needed. Moreover, from those examples you can have access to the exact configurations and conditions used in every specific release, besides the two listed here.

Usage of the examples provided in FastSimulation/Configuration

Other working examples for producing events with the Fast Simulation can be found in FastSimulation/Configuration/test. The recipe is best exemplified by one of them. Just go there and do

 cmsRun FastSimulation/Configuration/test/Example_cfg.py 

In this example, 100 gg -> H -> ZZ -> eeee, eemumu and mumumumu events are generated with PYTHIA, in-time pile-up events are superimposed with an average of five events per bunch crossing, simulated hits are created in the tracker and calorimeters, and reconstructed calorimetry hits (RecHit's) are produced. It uses MC conditions and no HLT trigger is simulated. Other processes (like ttbar events, minimum bias events, QCD multijet events) can be simulated by replacing

(in the above Example_cfg.py file) by one of the other configuration files present in the Configuration/Generator/python directory (e.g., TTbar_cfi, QCD_Pt_80_120_cfi, etc...). Another example without HLT, but with STARTUP condition, can be found in the configuration file
 cmsRun FastSimulation/Configuration/test/IntegrationTest_cfg.py
it uses TTbar_cfi generator fragment and more complete detector simulation and reconstruction with tracks (and muons) and various types of high-level objects (calo clusters, MET etc.). This configuration also makes use of calo miscalibrations and tracker misalignment.

If you further edit and scrutinize the Example_cfg.py configuration file, you will certainly notice that all is done with the famosWithCaloHits sequence, while IntegrationTest_cfg.py with the famosWithEverything sequence. Other self-explanatory sequences (more or less specialized for concrete tasks) can be found in FastSimulation/Configuration/python/FamosSequences_cff.py :

  • famosWithTrackerHits
  • famosWithTrackerAndCaloHits
  • famosWithTracks
  • famosWithTracksAndMuonHits
  • famosWithCaloHits
  • famosWithEcalClusters
  • famosWithTracksAndCaloHits
  • famosWithTracksAndEcalClusters
  • famosWithParticleFlow
  • famosWithCaloTowers
  • famosWithTracksAndCaloTowers
  • famosWithJets
  • famosWithSimpleJets
  • famosWithCaloTowersAndParticleFlow
  • famosWithElectrons
  • famosWithPhotons
  • famosWithElectronsAndPhotons
  • famosWithBTagging
  • famosWithTauTagging
  • famosWithPFTauTagging
  • simulationWithFamos
  • simulationNoMuonDigiWithFamos
  • reconstructionWithFamos
  • famosWithEverything
The active user will soon discover a need for other sequences. For example, (s)he may want to produce electrons and muons in the same job. All the lego blocks needed to do so are available in FastSimulation/Configuration/python/FamosSequences_cff.py to produce the relevant sequence. In this particular example, the proper sequence can be defined as
sequence famosWithElectronsAndMuons = {
and can be used to replace the famosWithTracksAndEcalClusters of the example.

Among other examples one can find:

  • Run the complete reconstruction, MC conditions, no misalignment/miscalibration, no HLT
 cmsRun FastSimulation/Configuration/test/IntegrationTestFake_cfg.py 
  • Run the complete reconstruction, STARTUP conditions, complete HLT with 8E29 menu
 cmsRun FastSimulation/Configuration/test/ExampleWithHLT_8E29_cfg.py
  • Run the complete reconstruction, MC conditions, complete HLT with 1E31 menu
 cmsRun FastSimulation/Configuration/test/ExampleWithHLT_1E31_cfg.py
  • Run the complete reconstruction, STARTUP conditions, complete HLT with 8E29 menu, misalignment/miscalibration is on
 cmsRun FastSimulation/Configuration/test/IntegrationTestWithHLT_cfg.py 


After running the above examples, local directory will contain the output *.root files and two additional txt files, namely:

  1. NuclearInteractionOutputFile.txt
  2. PileUpOutputFile.txt
The *.txt files can be safely ignored by the beginner and by the normal user/developer. They are meant, however, to help debugging in case a crash occurs at N-th event, so as to ensure reproducibility when restarting the production at this very event. (More details can be found in the Software Guide, if you are really interested). Please, keep these files if you have a bug to report.

The actual output *.root files are normally produced, as their snippets are present and uncommented in configuration files. In the Example_cfg.py mentioned in a previous chapter one can find:

process.o1 = cms.OutputModule(
    fileName = cms.untracked.string("MyFirstFamosFile_1.root"),
    outputCommands = cms.untracked.vstring("keep *",
                                           "drop *_mix_*_*")
process.outpath = cms.EndPath(process.o1)

While some other examples, like ExampleWithHLT_8E29_cfg.py or ExampleWithHLT_1E31_cfg.py, write AOD content :

process.o1 = cms.OutputModule("PoolOutputModule",
    fileName = cms.untracked.string('AODWithHLT.root')
process.outpath = cms.EndPath(process.o1)
# Add endpaths to the schedule

The Fast Simulation is so fast, that there is in general no need to write events onto disk before analysing them. It's enough to add the module name of your own Analyser in the sequence as follows:

process.p1 = cms.Path(process.famosWithElectronsAndMuonAndJets * process.myTopAnalysis)
to generate, simulate, reconstruct and analyse the events in one go.

Analysing the output

The very same analysis examples that run on Full Simulated and Reconstructed samples can be run also on Fast Simulation samples. It may happen that a few InputTags are different between Fast and Full Simulation data samples. As a rule of thumb, if your FullSim analyser complains because of missing collections when run on FastSim, just have a look at the correct InputTag used for that collection in the produced FastSim events, and substitute it where needed in your analysis module.

You can find actual examples of analysis modules in FWLite Analyses and for PAT in PAT Analyses

Fast Simulation for Upgrade

This part will be devoted to the usage of Fast Simulation for Upgrade

Recipe for CMSSW_6_2_0_SLHC5

cmsrel CMSSW_6_2_0_SLHC5
cd CMSSW_6_2_0_SLHC2/src

git-merge-topic Vlandr57:Segm_FastSim01
git cms-addpkg FastSimulation/Configuration

User can create the new branch

git checkout -b  "new branch name" 
scram b -j4

And then go to the test directory

cd FastSimulation/Configuration/test

copy the necessary python file and run the job

cp  /afs/cern.ch/user/a/andreevv/public/CMSSW_6_2_0_SLHC5/FSIM_upgrade_cfg.py .
cmsRun FSIM_upgrade_cfg.py

Supported/Recommended versions

Please use one of the following Fast Simulation versions, acssociated to the corresponding CMSSW version, to do your analysis. The latest CMSSW version is usually the recommended one. It is likely to contain bug fixes with respect to previous versions, but might also contain some new bug(s) as Fast Simulation is developing fast. The versions other than supported/recommended must not be used.

CMSSW Version Date Comments Status
CMSSW_3_3_6 8-Dec-2009 Similar to 3_1_6 in many aspects. Main difference: OI tracking, HLT menues, CMS.CaloTowers thresholds Recommended; validation is still ongoing
CMSSW_3_1_6 23-Nov-2009 Numerous changes compared to 2_2_X series Recommended; validation is still ongoing
CMSSW_2_2_13 07-june-2009 Very similar to 2_2_3 used in Winter'09 FastSimulation production Of limited use, soon to be replaced with 3XY versions

Performance evaluation

Typical Fast Simulation job with several thousand ttbar events fully processed in the entire production chain: generation+simulation+RecHits+L1+HLT+high-level objects requires approximately 1.2 GB of RAM. An evaluation of the timing has been performed on two quite different physics processes: ttbar (with and without low-lumi pileup with on average 5 min. bias events admixed to the signal event in-time) and Minimum Bias. The table below shows the time spent in (i) generation, (ii) most of the famos-specific code (particles propagation and simulation) and (iii) total time per event, including fast reconstruction + high-level general reconstruction + L1+HLT triggers as with production-like cmsDriver command described above with parameters -s GEN,FASTSIM . The time unit is milliseconds per event. These numbers are taken from the results of [[http://cmsperfvm:8086][the CMSSW performance suite] for CMSSW_3_3_4 obtained on a dedicated PC with four-core Xeon processor running at 3 GHz with RAM of 8 GB.

Physics process Generation (ms) Famos simulation, (ms) Total, including Fast Reco, general Reco and Trigger (ms)
Minimum Bias 3 26 331
ttbar without pileup 15 209 2,265
ttbar with low-lumi pileup 15 408 3,511

Further documentation

More detailed documentation for the Fast Simulation can be found in the SoftwareGuide.

Review status

Reviewer/Editor and Date Comments
Aresh - 28 Feb 2008 last image was uncorrectly tagged
PatrickJanot - 14 Jul 2007 Output description
PatrickJanot - 11 Jul 2007 How to run Fast Simulation

Responsible: ?
Last reviewed by: SalavatAbdoulline - 2 December 2009
Last reviewed by: PatriziaAzzi - 20 February 2008

eXTReMe Tracker

Edit | Attach | Watch | Print version | History: r59 < r58 < r57 < r56 < r55 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r59 - 2014-07-08 - LukasVanelderen
    • 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-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback