Fast Simulation Offline Guide

Complete: 4

News box
IMPORTANT: A list of open tasks in the Fast Simulation is available here
WARNING: The Fast Simulation recommended versions are listed here for each release cycle. Summary for the releases series currently used in physics analysis: CMSSW_4_2_8_patch4 and following in 4_2_X (coherent with Summer 2011), CMSSW_4_4_3_patch1 and following in 4_4_X (coherent with Fall 2011), CMSSW_5_2_6 and following in 5_2_X (coherent with Summer 2012), CMSSW_5_3_6 and following in 5_3_X (currently recommended series for the analysis of 2012 data). Physics-wise, 5_2_X and 5_3_X are equivalent for FastSim. Please report any observation to the FastSimulation Hypernews (hn-cms-famos@cern.ch)
Please notice that a new cmsDriver syntax is available since 6_1_X. The new syntax is recommended, and the old one is deprecated, from CMSSW_6_2_X onwards. More details below.
The FAQs have been reorganized and updated; have a look!

Contents:

Contacts

Frequently asked questions (and their answers)

Before reporting a problem, you can check whether it is already mentioned in the FAQs. If not please write either to the hypernews forum or to the contact person (see section above).

(Wo)Manpower needs for the Fast Simulation developments:

Have a look at the Fast Simulation needs

Meetings

Meetings in 2013

Since January 2012, Fast and Full simulations share the same meetings.
Here are listed only the meetings where Fast Simulation issues were discussed:

Previous meetings

Meetings in 2012

More Less Since January 2012, Fast and Full simulations share the same meetings.
Here are listed only the meetings where Fast Simulation issues were discussed:

Meetings in 2011

More Less

Meetings in 2010

More Less

Meetings in 2009

More Less
  • 22nd of January 09: Meeting devoted to developments and status of FastSimulation in 30X Agenda
  • 19th of February 09: Agenda
  • 2nd of April 09: Agenda
  • 28th of May 09: Agenda
  • 23rd of June 09: Agenda During CMS Week
  • 9th of July 09: Agenda Virtual meeting - Status report linked
  • 17th of September: Agenda
  • 1st of October: Agenda
  • 15th of October: Agenda
  • 12th of November: Agenda
  • 26th of November Agenda Virtual Meeting
  • 8th of December: Agenda Meeting during CMS Week

Meetings in 2008

More Less
  • 22nd of January 08 : Agenda and Minutes
  • 12th of February 08 : Agenda
  • 4th of March 08 : Agenda
  • 8th of April 08: Physics Validation meeting Agenda
  • 29th of April 08 : Agenda
  • 3rd of June 08 : Agenda
  • 1st of July 08 : Agenda
  • 15th of July 08 : Virtual Meeting about Validation Agenda
  • 2nd of September 08 : Agenda
  • 15th of October 08 : Agenda
  • 12th of November 08 : Agenda
  • 27th of November 08 : Meeting mostly on Validation Agenda
  • Talk at CMS Week on December 12th 08: Presentation

Meetings in 2007

More Less

Introduction

The Fast Simulation Project definition for 2007 can be found here with the corresponding presentation

In a nutshell, the CMS Fast Simulation is a CMSSW-integrated tool to simulate and reconstruct events with the CMS detector, in view of doing physics analyses, develop and tune reconstruction algorithms, design detector upgrades, ... etc, without being penalized by CPU time 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 (e.g., for tracking), all described in the present documentation and, more importantly, all validated with and tuned to the very detailed GEANT-based CMS simulation (aka full simulation), the complete reconstruction, the result of benchmark physics analyses and the outcome of test-beam 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.

In addition, 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 run with no changes with respect to what would be done otherwise. Analysis code is therefore expected to work in a transparent way with Fast Simulation.

The CMSSW (public) history of Fast Simulation is archived here, together with related general talks describing the status of the algorithms.

Fast Simulation documentation

FastSimulation is just another (very similar) cmsRun job like the GEANT-based simulation, with just (some) config file differences. It consists of several steps (or modules): (i) Random number initialization, (ii) Event Generation or reading, (iii) optional Primary vertex smearing, (iv) "FamosSimHit" production (which may or may not include an optional Pile-Up step), (v) optional Pile-Up mixing, (vi) RecHit production, (vii) Misalignement and miscalibration, (viii) L1 and High-Level Trigger, and (ix) Physics Object reconstruction. These steps, which corresponds each to one or more edm::Producer's, are described in turn below, together with accurate instructions for use.

Their inclusion in a python configuration file (_cfg.py) is documented below, first as a global recipe for the impatient user, then with all gory details explained.

Recipes for producing events with the Fast Simulation of CMSSW

Recipe for producing Fast Simulation events with cmsDriver

With cmsDriver you can easily produce python configuration files that you can run with cmsRun to get your event produced. You can start from a generation fragment, like one of those already available in /CMSSW/Configuration/GenProduction, in Configuration/Generator/python, or some other user written one.

Let take a specific example: produce 10 RelVal like TTbar events at 7 TeV, with startup conditions. One has to decide which HLT menu to use in the simulation, and synchronize the customization of the conditions accordingly. The HLT menu can either be the development one (aka GRun), or one of the "frozen" ones. In case of the development HLT menu, the cmsDriver command reads

cmsDriver.py TTbar_Tauola_7TeV_cfi.py -s GEN,FASTSIM,HLT:GRun --conditions=auto:startup_GRun --pileup=NoPileUp --geometry DB --eventcontent=AODSIM --datatier AODSIM -n 10 --no_exec

or, with the new syntax (available from 6_2_X onwards):

cmsDriver.py TTbar_Tauola_7TeV_cfi.py -s GEN,SIM,RECO,HLT:GRun --fast --conditions=auto:startup_GRun --pileup=NoPileUp --geometry DB --eventcontent=AODSIM --datatier AODSIM -n 10 --no_exec

More informations on the available cmsDriver options can be read here and here, or by typing cmsDriver -h.

See below, in this wiki, for more comments about the new syntax in FastSim.

HLT configuration

In case one of the "frozen" HLT menus is wanted instead (this is typically the preferred choice, since the "frozen" menus correspond to one specific data taking period), one should replace the name of the HLT menu and the customized conditions according to either one of the following possible options (as for the 2012 pp menus):

-s GEN,FASTSIM,HLT:5E33v4 --conditions=auto:startup_5E33v4
-s GEN,FASTSIM,HLT:7E33v2 --conditions=auto:startup_7E33v2
-s GEN,FASTSIM,HLT:7E33v3 --conditions=auto:startup_7E33v3
-s GEN,FASTSIM,HLT:7E33v4 --conditions=auto:startup_7E33v4
-s GEN,FASTSIM,HLT:8E33v1 --conditions=auto:startup_8E33v1

or, with the new syntax (from 6_1_X onwards):

-s GEN,SIM,RECO,HLT:5E33v4 --fast --conditions=auto:startup_5E33v4
-s GEN,SIM,RECO,HLT:7E33v2 --fast --conditions=auto:startup_7E33v2
-s GEN,SIM,RECO,HLT:7E33v3 --fast --conditions=auto:startup_7E33v3
-s GEN,SIM,RECO,HLT:7E33v4 --fast --conditions=auto:startup_7E33v4
-s GEN,SIM,RECO,HLT:8E33v1 --fast --conditions=auto:startup_8E33v1

Since FastSimulation/HighLevelTrigger V04-11-02 it is no more necessary to have RECO before HLT in the cmsDriver command. This can save you some execution time is you are working on trigger development and do not need access to reconstructed offline collections.

Alternative syntax, and running in two steps

Since 6_1_0_pre6, more options are available in cmsDriver, including an alternative syntax more similar to the FullSim worksflows, and the possibility to split the jobs either in pure simulation and pure reconstruction or in "simulation + some reconstruction" and "high-level reconstruction".

(Since 6_2_0_pre6 the new syntax is used in all relval productions, and the old syntax is phased out starting from 6_2_0_pre7.)

For example, the following two commands are equivalent (and both do the entire chain from generator to high-level reconstruction in one step):

cmsDriver.py TTbar_Tauola_8TeV_cfi.py -s GEN,SIM,RECO,HLT,VALIDATION  --conditions auto:startup_GRun --eventcontent=FEVTDEBUG -n 100 --fast

cmsDriver.py TTbar_Tauola_8TeV_cfi.py -s GEN,FASTSIM,HLT,VALIDATION  --conditions auto:startup_GRun --eventcontent=FEVTDEBUG -n 100
Notice the new flag --fast in the first case, to differentiate it from FullSim.

Now cmsDriver also contains the option to run the purely Sim part and the purely Reco part as two separate steps. This is usually not needed (the Sim part is one order of magnitude faster than the Reco part, so there is no significant gain in time by reusing existing Sim events), but there are possible use cases.

If you want to run your job in two steps, separating Sim and Reco like in FullSim, there are two ways according to which syntax style you prefer.

With the old-style syntax:

cmsDriver.py TTbar_Tauola_8TeV_cfi.py -s GEN,FASTSIM:sim --conditions auto:startup_GRun --eventcontent=FEVTDEBUG -n 100 --fileout GENSIM.root

cmsDriver.py fastreco -s FASTSIM:reco --filein=file:GENSIM.root --conditions auto:startup_GRun --eventcontent=FEVTDEBUGHLT -n 100 --process FASTRECO
Note: in the second step, the choice is arbitrary for the first parameter (it will just determine the name of the configuration file produced) and for the value of the --process flag (it is only needed because CMSSW prevents you from running two processes of the same name on the same events.)

Important: although the --eventcontent value for step 2 can be whatever the user prefers (and most users only need AODSIM, which is the slimmest available event content), its value for step 1 should be FEVTDEBUG in order to save the collections needed by step 2.

With the new FullSim-like syntax:

cmsDriver.py TTbar_Tauola_8TeV_cfi.py -s GEN,SIM --conditions auto:startup_GRun --eventcontent=FEVTDEBUG -n 100 --fast --fileout GENSIM.root

cmsDriver.py fastreco -s RECO --filein file:GENSIM.root --conditions auto:startup_GRun --eventcontent=FEVTDEBUGHLT -n 100 --fast

You can also include HLT and VALIDATION in the second step.

Since FastSimulation/HighLevelTrigger V04-11-02 it is no more necessary to have RECO before HLT in the cmsDriver command. This can save you some execution time is you are working on trigger development and do not need access to reconstructed offline collections.

Yet another available possibility is to split into simExtended and recoHighLevel. A possible use case are productions with very high pileup (e.g., 200) which are known to have memory issues. By splitting the job in this way, this is significantly mitigated. This option is only available with the old-style syntax, as follows:

cmsDriver.py TTbar_Tauola_8TeV_cfi.py -s GEN,FASTSIM:simExtended --conditions auto:startup_GRun --eventcontent=FEVTDEBUG -n 100 --fileout GENSIMEXTENDED.root

cmsDriver.py fastreco -s FASTSIM:recoHighLevel --filein=file:GENSIMEXTENDED.root --conditions auto:startup_GRun --eventcontent=FEVTDEBUGHLT -n 100 --process FASTRECO

Using LHE files

If you want to use LHE files as input, see the specific instructions in the FAQs

Automatic validation plots

If you also want to produce the Release Validation plots (DQM), the cmsDriver command can include a VALIDATION sequence as follows

cmsDriver.py TTbar_Tauola_7TeV_cfi.py -s GEN,FASTSIM,HLT:GRun,VALIDATION --pileup=NoPileUp --geometry DB --conditions=auto:startup_GRun --eventcontent=FEVTDEBUGHLT --datatier GEN-SIM-DIGI-RECO -n 10 --no_exec

or, with the new syntax:

cmsDriver.py TTbar_Tauola_7TeV_cfi.py -s GEN,SIM,RECO,HLT:GRun,VALIDATION --fast --pileup=NoPileUp --geometry DB --conditions=auto:startup_GRun --eventcontent=FEVTDEBUGHLT --datatier GEN-SIM-DIGI-RECO -n 10 --no_exec

and you should further harvest on the ME produced there with

cmsDriver.py step3 -s HARVESTING:validationHarvestingFS --harvesting AtJobEnd --conditions=auto:startup  --filein file:TTbar_Tauola_7TeV_cfi_GEN_FASTSIM_HLT_VALIDATION.root

Pileup configuration

The possible pile-up scenarios currently available in cmsDriver are:

  • NoPileUp
  • Scenarios with the FamosPileup module (default):
    • LowLumiPileUp (poissonian distributed number of Minimum Bias events superimposed, with 7.1 pile-up events in average)
    • FlatDist10_2011EarlyData_inTimeOnly (flat distribution up to 10, then decreasing smoothly; coherent with Summer11 fullsim); note: until 6_0_0_pre3 it was labeled FlatDist10_2011EarlyData_50ns, but this was a misnomer
    • E7TeV_Fall2011_Reprocess_inTimeOnly (coherent with Fall11 fullsim)
    • E7TeV_ProbDist_2011Data_inTimeOnly (corresponds to the actual pileup profile in the full 2011 dataset)
    • 2012_Startup_inTimeOnly (coherent with Spring12 fullsim)
    • 2012_Summer_inTimeOnly (coherent with Summer12 fullsim)
  • Scenarios with the MixingModule applied at GEN level (not fully validated yet):
    • mix_2012_Startup_inTimeOnly (coherent with Spring12 fullsim)
    • mix_2012_Summer_inTimeOnly (coherent with Summer12 fullsim)

If the MixingModule is used, you must also specify the input minimum bias files to be used for pileup, for example --pileup_input dbs:/RelValProdMinBias/CMSSW_5_2_1-START52_V4-v1/GEN-SIM-RAW works if you are working on lxplus. You can also create a minimum bias file locally (it is sufficient to create them at GEN level, which is very fast and occupies little disk space), with cmsDriver.py MinBias_8TeV_cfi  --conditions auto:startup -s GEN --datatier GEN -n 10000  --eventcontent RAWSIM, and then again feed it to the Fast Simulation via --pileup_input file:your_minbias_file.root

We suggest to verify in Configuration/StandardSequences/python/Mixing.py whether their definition changed, or some new scenario showed up in the meanwhile.

Recipes for obsolete versions

Just take a look here .

Testing without cmsDriver:

Warning: normally one uses FastSim with cmsDriver (see sections above), therefore what follows is only recommended for special use cases.

cmsRun FastSimulation/Configuration/test/IntegrationTest_cfg.py  
cmsRun FastSimulation/Configuration/test/IntegrationTestWithHLT_cfg.py
cmsRun FastSimulation/Configuration/test/IntegrationTestIdealWithHLT_cfg.py
cmsRun FastSimulation/Configuration/test/Example_cfg.py 
cmsRun FastSimulation/Configuration/test/ExampleWithHLT_GRun_cfg.py 
cmsRun FastSimulation/Configuration/test/ExampleWithRealTracking_cfg.py

The files named "IntegrationTest" are run automatically at every integration build towards a new release, therefore they are always guaranteed to work out of the box in all CMSSW releases, while there is no strict guarantee for the "Example" files, although of course they are supposed to work too (and if they don't, please report that on hypernews!).

In general, the "Example" files are more intended for expert users. A very special case is ExampleWithRealTracking_cfg.py, which shows how to perform the real tracking (including the real digitization and the real local reconstruction) after having created the simhits with FastSim. Although this is not of interest of the majority of users (because it is much slower), there are some use cases for that.

The files named "Example*" and "IntegrationTestIdealWithHLT" contain MC Ideal conditions, while those named "IntegrationTest" and "IntegrationTestWithHLT" work with MC STARTUP conditions and contain miscalibration and misalignement capability. "ExampleWithHLT_GRun_cfg.py" does not do any reconstruction and is well suited to test and validate L1 and low-lumiHLT.

Fast Simulation supported tags and release notes

Supported FastSimulation versions/tags and correspondence with CMSSW versions are listed here.

Random number initialization (RandomNumberGeneratorService)

See SWGuideFastSimRandNumGen.

Event Generation or reading (Source)

See SWGuideFastSimEvtGen.

Vertex smearing (Famos internal or VtxSmeared)

See SWGuideFastSimVtxSmear

Pile-Up mixing (PileUpProducer or MixingModule)

See SWGuideFastSimPileUp for extensive documentation

The detector simulation in FastSim: FamosSimHit production (FamosProducer)

See SWGuideFastSimSimHit for extensive documentation.

Muon SimHit production (MuonSimHitProducer)

See SWGuideFastSimMuonSimHit for documentation

RecHit production

More Less

TrackingRecHit production

See extensive documentation here

CaloRecHit production

See extensive documentation here

MuonRecHit production

Not documented yet

(Mis)Alignement and (mis)calibration.

More Less

Tracker misalignment

See the documentation here

ECAL miscalibration

See the documentation here (under development)

HCAL miscalibration

See the documentation here

Muon misalignment

See the documentation here

L1 Trigger simulation

More Less The L1 trigger simulation is available from CMSSW_1_8_0_pre6 onwards both for calorimeter (via the L1CaloEmulator) and for muons (originally via parameterized L1 muons, moved to the L1MuonEmulator since releases CMSSW_3_1_5, CMSSW_3_3_6 -not yet out, indeed...- and CMSSW_3_4_0_pre4) . It can be invoked with the hltBegin sequence, defined with
include "FastSimulation/HighLevelTrigger/data/common/HLTSetup.cff"
More detailed documentation will come soon, but L1 data formats are just identical to those coming out of the full simulation.

Proton taggers

See the documentation here

BCS trigger emulator for comparison with Data

More Less Fast Simulation does not include BSC detector simulation and hence no BSC L1 trigger bits are set. Instead, a BSC-emulator is available, based on the HF Reco information. It is an EDFilter which needs to be included in the Fast Simulation MC sample reading before user analyser :

process.filterFastBSC = cms.EDFilter("FastSimDataFilter")
process.p = cms.Path(process.filterFastBSC * process.SomeUserAnanlyser...)
The filter above is already included in CMSSW 35X/36X, but can be also used in 33X/34X by checking out first (and compiling):
CMSSW_3_6_6/src/>  cvs co -r V00-01-08 FastSimulation/ForwardDetectors
cd FastSimulation/ForwardDetectors
scramv1 b 
More information can be found in the presentation here

Physics Object reconstruction

All physics object are delivered by Fast Simulation in the exact same format as in the complete reconstruction. Please refer to the official physics object documentation if you want to use them.

High-Level Trigger simulation

All HLT paths have been integrated in Fast Simulation, from CMSSW_1_8_0_pre6 onward.

From CMSSW_1_8_0 up to CMSSW_2_2_X they can be invoked with

include "FastSimulation/HighLevelTrigger/data/common/HLTSetup.cff"
include "HLTrigger/Configuration/data/main/HLTpaths.cff

In CMSSW_3_1_0 the HLT group decided to mantain two lean trigger tables, 8E29(default) and 1E31, that have both been integrated as well (as the corresponding L1 Menus). Since CMSSW_3_5_X, also a third menu (GRun) has been integrated in FastSim.

More detailed documentation can be found here, but all HLT data formats (and most of the algorithms used therein) are just identical to those of the full HLT reconstruction.

Configuration of the Fast Simulation

See the documentation here

How to compare the fast and the GEANT-based simulation on a event-by-event basis ?

This part of documentation does not apply to 3_1_X. In principle, the Fast Sim should smoothly be able to run on fully simulated event files (to be confirmed). Please contact the conveners if you are encountering troubles to do so.

The old documentation can be found below:

More Less

It is possible to run the fast simulation on a fully-simulated-event file. It allows precise comparisons to be done event by event. Obviously, this event sample must have been produced with a release compatible with the current fast simulation release. In this case, the MC truth is read from the original file, and the (fast) simulation and reconstruction are carried out. Two collections of all the objects produced are thus obtained, the original one, and the one that has just be created by the fast simulation. Each of the collection can be retrieved independently with an appropriate getByLabel in the analysis code.

Caveat: the Mixing Module (MM) is used in the Fast Simulation to access the collections of simulated objects (SimHits, PCaloHits). To ensure that the MM does not mix together the hits from the Fast and the Full Sim, the following replace should be added in the configuration file.

replace  mix.Label="famosSimHits"
This recipe is safe only in CMSSW_1_6_X

WARNING As of CMSSW_1_8_X, this solution has been dangerous. Indeed, the hits used in the muon from hits, are produced by a different producer, and the previous replace cannot be used anymore.

As a result, the RECOMMENDED SOLUTION, working for all the versions consists in proceeding in two steps:

1) First, create a new file from the original fully simulated sample containing only the Monte-Carlo information (HepMCProduct, or genParticleCandidates), with a

 untracked vstring outputCommands = { 
        "drop *", 
        "keep *_source_*_*" 
in the PoolOutputModule. This one will keep the HepMCProduct, otherwise, put the name of the genParticleCandidates producer.

2) Run the Fast Sim on the file which has just thus obtained.

Global Timing (lxplus, 2 GHz, 64 bits)

More Less

To give an order of magnitude, the example given in the "Recipe for impatient users" produces events with pile-up with a rate of 0.421 second / event on a regular 2GHz lxplus 64-bit machine, with a breakdown as follows for the CMSSW_1_6_5 release (the numbers for CMSSW_1_5_0 are given in parentheses):

  • Generation (Pythia) : 21 (21) ms/event
  • Add pile-up/particle propagation/interactions in the tracker : 17 (22) ms/event
  • PSimHit production : 17 (19) ms/event
  • PCaloHit production : 290 (410) ms/event (e/gamma : 230 (290), hadrons : 60 (120))
  • Tracker RecHit production : 2.5 (3) ms/event
  • TrackCandidate production : 2.1 (3) ms/event
  • Track production : 37 (50) ms/event
  • Calo RecHit creation : 2.6 (4) ms/event
  • Ecal cluster production : 26 (42) ms/event
  • Writing an output file with the module EDProducts (not counted in the total above): ?? ms/event
A specific optimization effort is currently going on for the PCaloHit simulation, which mostly involves a tricky interface with the ECAL geometry. A large reduction factor is certainly to be expected in the next weeks/months. (A reduction from 560 to 290 ms/event was already achieved since 27-May-07.) It can be seen that the event writing would be the next-to-dominant CPU eater, soon to become the leading contributor as more modules are added (CaloTower producer, jet clusterization, particle flow, electrons, muons, ...etc).

A more complete evaluation was performed on several physics processes, as shown in the table below, where the time spent in generation, pile-up simulation (low-lumi) configuration, and in famos-specific code (propagation, simulation, RecHit production, and Track reconstruction) is given, for CMSSW_1_6_7. (The numbers in parentheses are for CMSSW_1_6_0.)

Physics process Generation (ms) Famos-specific w/o PU (ms) Low-lumi PU (ms) Total (ms)
Minimum Bias 6 36 (39) -- 42 (45)
H -> ZZ -> llll 26 185 (237) 153 (193) 338 (456)
ttbar 30 288 (388) 153 (193) 441 (610)
QCD 80-120 26 220 (318) 153 (193) 373 (536)
QCD 600-800 26 398 (476) 153 (193) 551 (695)

For ttbar events with pile-up, the detailed timing breakdown for simulation and various reconstruction items (electrons/photons, muons, jets, particle flow, b tagging and tau tagging) is given below, in CMSSW_1_7_0. (Watch out, there are many more things evaluated there than in the default configuration file.) The evaluation with CMSSW_1_6_7 (CMSSW_1_6_0) is shown between brackets.

Module Of which Time / event Sub-contribution
Simulation   368 (378 (481))  
Event writing   230 (277 (460))  
GSF electrons   388 (415 (437))  
  GSF fitting   243 (305 (284))
  Ecal clustering   62 (63 (63))
  Electron Id   74 (38 (79))
  Cluster-Pixel Matching   9 (6 (11))
  Track Candidates   <1 (2 (2))
  Photons   <1(--)
Calo Jets & MET   306 (211 (--))  
  Sis Cone Algo   181 (-- (--))
  Mid Point Algo   76 (179 (--))
  Iterative Cone algo   15 (12 (--))
  Fast Jet algo   20 (8 (--))
  CMS.CaloTowers   9 (6 (5))
  GenParticleCandidate   4 (-- (--))
  MET   1 (<1 (--))
BTagging   258 (161 (217))  
  Primary Vertices   97 (64 (83))
  Tracks   69 (44 (65))
  Combined SV   82 (40 (58))
  Track IP   8 (12 (8))
  Jet/Track association   1 (1 (3))
Particle Flow   127 (105 (241))  
  Electron preId (mostly GSF)   85 (71 (189))
  PF Clusters   29 (23 (36))
  PF Blocks   13 (11 (12))
Tau Reco/Tagging   15 (37 (--))  
  Combined Tau Tag   -- (33 (--))
  PF Tau Reco/Tag   7 (-- (--))
  Calo Tau Reco/Tag   8 (-- (--))
  Cone Isolation   (<1 (4 (--))
!RecHits   12 (6 (9))  
  Tracker   8 (3 (6))
  ECAL+HCAL   4 (3 (3))
!MixingModule (not used!) 3 (3 (3))
Parametrized muons   << 1  
       
Total (without writing events)   1482 (1361 (1451))  
  Reconstruction   1114 (983 (980))
  Simulation   368 (378 (481))
  Generation   30 (30 (30))
Total (with writing events)   1712 (1638 (1911))  

Instructions for timing measurements: see here

Fast Simulation Tuning Tutorials

How to tune Iterative Tracking

See FastSimTuningIterativeTracking

How to tune ECAL noise

Starting from 6_1_0_pre6, the ECAL digitizer from FullSim is integrated with FastSim, and therefore there is no need anymore to simulate ECAL noise in FastSim (the digitizer takes care of that).

If you are interested in how this was done in previous releases, see FastSimTuningECALNoise

How to tune HCAL signal response

See FastSimTuningHCALSignal

How to tune HCAL noise

Starting from 6_1_X, the HCAL digitizer from FullSim is integrated with FastSim, and therefore there is no need anymore to simulate HCAL noise in FastSim (the digitizer takes care of that).

If you are interested in how this was done in previous releases, see FastSimTuningHCALNoise

How to tune the response to neutral hadrons in Particle Flow

See this series of talks by Federica Primavera: 1 - 2 - 3

Fast Simulation Physics Validation

  • For a summary of the Validation of FastSimulation in the most recent releases look here.
  • List of pages with detailed reports of the results of the Validation of the FastSimulation can be found here

Performance reports

Fast Simulation for the Upgrades

Towards the new paradigm of job splitting

Old Famos documentation and links

Note: Famos, the old simulation based on COBRA and ORCA is no longer supported. It only exists on SLC3. The binaries are compatible with SLC4, but the compilation can only be done on a SLC3 platform. The links below are aimed at the users already familiar with Famos. The new users should directly start with the new "FastSimulation" package.

The old Famos web page can be accessed from here. A userguide is available: from the old Famos webpage, select a release and choose the postscript or pdf version. A how-to has also been written: RutherfordFAMOSHowTo .

eXTReMe Tracker

Edit | Attach | Watch | Print version | History: r492 < r491 < r490 < r489 < r488 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r492 - 2014-03-28 - 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-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