Fast Detector Simulation Specification and Usage

From Wiki Les Houches 09

(Difference between revisions)
Jump to: navigation, search
(Comparison/Validation against internal detector simulations)
Line 33: Line 33:
== Comparison/Validation against internal detector simulations ==
== Comparison/Validation against internal detector simulations ==
-
** ATLAS (Atflast) http://www.hep.ucl.ac.uk/atlas/atlfast/  (Simon to add desciption)
+
** ATLAS (Atlfast) http://www.hep.ucl.ac.uk/atlas/atlfast/  (see description below)
** CMS Fast Simulation (see description below)
** CMS Fast Simulation (see description below)
** Tevatron, HERA, LEP...?
** Tevatron, HERA, LEP...?
Line 96: Line 96:
to run on data will automatically work on files made with the Fast
to run on data will automatically work on files made with the Fast
Simulation; no changes are needed.
Simulation; no changes are needed.
 +
 +
=== Description of Atlas Fast Simulation ([http://www.hep.ucl.ac.uk/atlas/atlfast Atlfast-1]) ===
 +
 +
There are multiple fast simulations within Atlas, here I describe the fastest: Atlfast-1 (previously just Atlfast). It is written in C++ and runs inside the Atlas software framework Athena.
 +
 +
Events are read in from the generator in HepMC format. The following physics objects are produced:
 +
 +
* '''Tracks'''

Revision as of 13:20, 16 June 2009

Interested people (session 1) Simon Dean, Jon Butterworth, Peter Loch, Samir Ferrag, Frank-Peter Schilling, Fabio Maltoni, Matthew Schwartz, Steve Mrenna, Andy Buckley, Joanna Weng


While in general it is to hoped that experiments will correct for detector effects, producing particle-level measurements valid within some systematic uncertainty, this is not always the case. Some key measurements only exist in uncorrected form, and a detector smearing or acceptance needs to be applied to theoretical/MC results before they can be compared to the data. Also, in some phenomenological evaluations of possible new measurements, it is desirable to have a rough simulation to estimate their robustness against detector effect.

We propose to evaluate tools in this area, and examine the requirements they might need to meet. A key issue is likely to be a standard output format for "reconstructed" objects such as jets, missing transverse energy etc.

  • Possible physics requirements
    • Acceptance, resolution, trigger and reconstruction efficiency
    • Granularity
    • Magnetic field
    • B-tagging

Contents

Review of Software Requirements (integration into tool chain)

  • Standardized input from generators

The discussion in Session 1 recommended that the input format be HepMC. Detector simulation should be generator independent and so should restrict itself to looking at final state (status code 1) particles.

  • Standardized output to Rivet and/or user code

The discussion in Session 1 suggested ideas based on "Reconstructed Objects" which would be a 4-vector with optional list of numbers for efficiency, isolation etc. How specified should these things be? Do jets point to constituents? Strong preference for keeping it simple.

We should define use cases, when is it a good idea for theorists to worry about detector simulation etc.

Would be useful to define some key plots which maybe could be used to check external sims against the detector in-house versions?


Comparison/Validation against internal detector simulations

Delphes has been validated with respect to CMS. The resolution for electrons/photons/muons is insured by the fast-simulation process itself (i.e. smearing). The jet energy resolution and the MET resolution are based on calorimetric towers and FastJet algorithms. The smearing is performed at the tower level, before applying the reconstruction algorithm, so the agreement would not be a priori straightforward. The resolution for jets and MET in a very good agreement with the results in the (public) Physics TDR of CMS. Simular procedures (using 10 bins in jet p_T for pp -> ggX events) as in the TDR are used for this direct comparison. See the paper for more details. The simulation of the very forward detectors is performed by HECTOR (used by Delphes) and this has already been validated for the LHC beamlines around ATLAS and CMS. The missing piece for ATLAS validation is the comparison of resolutions for jets and missing transverse energy, which is not yet checked. Delphes has never been used outside LHC, but in principle this can be done. http://www.fynu.ucl.ac.be/delphes.html

Maybe a cross-check of ATLFastI or AcerDET and Delphes could be worth.

Description of CMS Fast Simulation

(F.-P. Schilling, J.Weng)

Complex LHC events may take minutes to simulate them with the Full Simulation of the CMS detector. The CMS Fast Simulation, being 100-1000 times faster per event, can be used to produce large statistics data sets necessary for studying background processes and systematic errors.

Simulated particle decays produced by event generators such as PYTHIA are used as inputs in HEPMC format. The resulting final state (status 1) particles are then propagated through the detector.

All physically relevant material effects are included in the Fast Simulation, which is necessary to accurately model the underlying physics. To accurately model the propagation of the particles through the layers of the tracker, material effects such as bremsstrahlung, photon conversions, multiple Coulomb scattering, energy loss through ionization and nuclear interactions are taken into account.

The base of the tracking simulation is the reconstructed hits. The local position resolution and efficiencies of the hits are currently parameterized with input from the Full Simulation, and in the future they will be parameterized to match data. For the silicon strip tracker, the local positions are smeared according to a gaussian. The parameterization for the pixel detectors depends on histograms derived from the Full Simulation, To make tracks, the Fast Simulation emulates the different steps of the standard tracking.

After leaving the layers of the tracker, the particles interact with the calorimeters. To simulate electron showers in the EM calorimeter, the Fast Simulation uses the Grindhammer parameterization, similar to GFLASH. Energy leakage into the inter-crystal gaps or out the back of the EM calorimeter are included in the final measured energy. Photons undergo electron pair conversions within the EM calorimeter based on the number of radiation lengths they have traversed. The electron pairs then undergo showering. To simulate the measured energy, zero suppression and electronics noise are included.

The Shower simulation in the hadron calorimeter is similar to the simulation in the EM calorimeter. A parameterization of the energy response for different types of particles at a variety of energies and pseudo-rapidities is made from the Full Simulation.

Muons are propagated in the magnetic field through the material of the tracker and the calorimeters, with average energy loss and multiple scattering included, before encountering the muon chambers.

The output of the Fast Simulation contains c++ objects with the same format as the standard offline reconstruction. Analysis code designed to run on data will automatically work on files made with the Fast Simulation; no changes are needed.

Description of Atlas Fast Simulation (Atlfast-1)

There are multiple fast simulations within Atlas, here I describe the fastest: Atlfast-1 (previously just Atlfast). It is written in C++ and runs inside the Atlas software framework Athena.

Events are read in from the generator in HepMC format. The following physics objects are produced:

  • Tracks
Personal tools