Fast Detector Simulation Specification and Usage

From Wiki Les Houches 09

Jump to: navigation, search

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


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.

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 and least detailed: 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 Truth particles are made into unsmeared tracks. Resolutions are then applied to the track parameters with correlated smearing.
  • Taus are made from a combination of tracks and truth particles, to simulate candidates from the track-based tau reconstruction.
  • Cells are made by extrapolating truth particles through an assumed uniform Inner Detector magnetic field of 2T and then depositing their energy in eta-phi bins of 0.1x0.1 centrally or 0.2x0.2 in the forward direction. Neutrinos and muons do not deposit their energy.
  • Clusters are made by running fastjet on the Cells.
  • Electrons, photons and muons are made by applying a parameterised smearing to the original stable truth particle four-vectors. e/gamma/muon are handled generically by the ReconstructedParticle class. Associations are made between clusters and ReconstructedParticles if they are closer than 0.15 in dR. This association is never made for muons as they do not deposit in the calorimeter. ReconstructedParticles are then found to be isolated if they have less than 10 GeV cell energy within dR<0.2 and no clusters within 0.4 apart from any associated cluster. When a ReconstructedParticle is found to be isolated, the associated cluster is removed from the list.
  • Jets are made from the remaining clusters (ie.. those not associated to isolated electrons and photons) after applying a parameterised smearing. Any non-isolated muons within dR<0.2 of the jet centre is added to the jet four-vector.
  • Missing ET The visible energy (v) is constructed by summing the four-vectors of all jets, isolated electrons, photons and muons, and any cells that were not matched to any particle or jet. The missing energy is then (-vx,-vy,-vz,14 TeV - vE)

Each routine selects the relevant truth particles to use by looping through the complete collection of GenParticles and applying predicates (truth helpers). Pointers to those that return true are kept in a vector. Examples of the truth helpers are IsGenStable, IsStatus(int status) and IsCharged.

The following classes are used to represent Atlfast-1 physics:

  • ReconstructedParticle for electrons, photons and muons. Contains information about the original truth particle as well as particle properties after reconstruction.
  • Jet for jets. As well as basic kinematics, contains information like Y-scale values and links back to jet constituents.
  • MissingMomentum for missing ET. This just contains the missing ET four-vector and scalar missing ET sum.
Personal tools