PaperlayerView exact revision on arXiv

Source-linked AI summary

The ATLAS Simulation Infrastructure

The ATLAS Collaboration

arXiv:1005.4568v1physics.ins-dethep-ex

TL;DR

ATLAS needed a detailed, scalable simulation infrastructure for producing detector-like events across diverse physics processes. The paper reviews its Athena-integrated generation, detector simulation, digitization, geometry, validation, and fast-simulation components. The resulting system was ready for data, with continual Grid production and a validation program producing a high-quality simulation sample.

  • Problem

    ATLAS required an infrastructure combining event generators, detector-response simulation, digitization, geometry, and validation for large-scale event production.

  • Method

    The paper reviews a configurable Athena and Geant4 simulation infrastructure covering detector geometry, event generation, digitization, fast simulation, and software and physics validation.

  • Results

    Generation, simulation, and digitization tasks run continually on the Grid, and validation has produced a high-quality simulation sample for ATLAS data.

  • Takeaways & Limitations

    The infrastructure provides flexible full and fast simulation options for ATLAS production and physics studies as detector, machine, and cavern conditions vary.

  • Takeaways & Limitations

    ATLFAST-I cannot model detector-based quantities, reconstruction efficiency, or misidentification rates, so genuine objects are overestimated and fake objects are largely absent.

Abstract

from arXiv · show

The simulation software for the ATLAS Experiment at the Large Hadron Collider is being used for large-scale production of events on the LHC Computing Grid. This simulation requires many components, from the generators that simulate particle collisions, through packages simulating the response of the various detectors and triggers. All of these components come together under the ATLAS simulation infrastructure. In this paper, that infrastructure is discussed, including that supporting the detector description, interfacing the event generation, and combining the GEANT4 simulation of the response of the individual detectors. Also described are the tools allowing the software validation, performance testing, and the validation of the simulated output against known physics processes.

1 Introduction

ATLAS developed a detailed, Athena-integrated Geant4 simulation that carries generated events through detector response and digitization to data-like output. The infrastructure supports realistic detector conditions, large-scale production, fast-simulation alternatives, and systematic validation.

  • The simulation carries events from generation through detector response and digitization into output identical to true detector data.
  • The simulation chain comprises event generation, detector and physics simulation, and digitization, which may run as separate steps or one job.
  • ATLAS uses database-driven geometry and conditions data to emulate detector construction, operating conditions, test stands, and installation configurations.
  • Detailed detector simulation requires substantial computing resources, motivating several fast-simulation varieties tailored to particular use cases.
  • The paper reviews the ATLAS simulation software and geometry used for large-scale production in 2008.

2 ATLAS Offline Software Overview

ATLAS Offline Software provides a configurable framework for assembling simulation components from event generation through digitization and reconstruction. Its data-flow design separates algorithms from persistent objects while supporting validation, reproducibility, and scalable processing.

  • Athena integrates configurable C++ algorithms and objects through Python scripting within the Gaudi-based ATLAS software framework.
  • The simulation project depends on core framework, conditions, detector-description, and event projects, grouping generation and digitization within one release project.
  • Athena jobs initialize services and algorithms, process events sequentially, and finalize by terminating components and reporting tracked statistics.
  • Runtime scripts configure algorithms and services without recompilation, enabling distinct configurations across simulation-chain steps and maximizing shared infrastructure.
  • The simulation flow converts generated events into HepMC, propagates particles through Geant4, records detector hits, and creates SDOs linking hits to truth particles.
  • Digitization overlays signal and background hits, adds detector noise, and generates detector signals for subsequent readout and trigger processing.
  • Separating generation, simulation, and digitization improves resource use and validation by allowing stored events to be rerun across software versions or detector configurations.

3 Event Generation Overview

ATLAS interfaces multiple external event generators to a common Athena simulation workflow. Generated events are standardized in HepMC, with runtime configuration, lifetime-based decay handling, and generator-specific translation where needed.

  • Event generation runs within Athena while ATLAS-specific packages provide simple interfaces to externally maintained generators.
  • Large-scale production uses Pythia, Herwig, Sherpa, Hijing, Alpgen, MC@NLO, and AcerMC, with Tauola, Photos, and EvtGen for specialized decays and radiation.
  • Particles with cτ > 10 mm are treated as stable by the generator and propagated for detector interactions, while shorter-lived particles decay before simulation.
  • Generator parameters can be passed through Python fragments at runtime, allowing one fixed software release to produce different physics configurations.
  • HepMC provides a connected event-history record containing generator particles and their relationships, while stable particles supply the detector-simulation input.
  • Exact reproducibility is limited to jobs run on the same processor type because pseudo-random-number generators depend on chip architecture.
  • FORTRAN generators require separate HEPEVT-to-HepMC translations, whereas C++ generators may produce HepMC directly.

3.2 General Purpose Generators

ATLAS combines general-purpose generators with specialized tools to model complete events and improve selected final states. Pythia is the default because of its ease of use, speed, and robustness, while other generators address different physics or production needs.

  • General-purpose generators produce complete events from proton or nuclear initial states, including hard processes, radiation, hadronization, and long-distance QCD modeling.
  • Pythia and PythiaB: ATLAS uses Pythia’s newer showering model by default, which produces somewhat more jet activity and therefore busier events than the older model.
  • Pythia and PythiaB: Pythia 6.4 is ATLAS’s default generator because its ease of use, speed, and robustness support production at very large scale.Many hundreds of millions of events have been generated with Pythia.
  • Pythia and PythiaB: PythiaB improves B-physics efficiency by reusing showers containing b- or c-quarks and hadronizing them multiple times.
  • Herwig, Sherpa, Hijing, and single-particle generators supplement Pythia for supersymmetric processes, high-multiplicity jets, heavy-ion or beam-gas events, and detector studies.Herwig uses ISAWIG for supersymmetric generation; Sherpa matches matrix elements to showers; Hijing models re-interactions in dense nuclei; single-particle generators support calibration and testing.

3.3 Specialized Generators

Specialized generators and decay packages improve the modeling of selected final states or decays while interfacing with general-purpose generators through standard event formats and Athena workflows.

  • Specialized generators do not produce complete events directly; they work with general-purpose generators to improve specific decays or final states.Several use the Les Houches format, producing standalone ASCII files of partonic four-vectors.
  • ISAJET supplies supersymmetric masses and decay modes to Herwig through ISAWIG, after which Herwig generates complete final states.
  • Photos and Tauola: Tauola handles tau decays after general-purpose generators treat taus as stable, with generator-dependent interfaces preserving helicities and polarization information.
  • Photos and Tauola: Photos models electromagnetic radiation and is required by Tauola; generator radiation is switched off in relevant decays to avoid double counting.
  • EvtGen provides more complete B-meson and hadron decay modeling through measured branching ratios, theoretical models, and angular correlations.
  • Specialized hard-process generators: Alpgen, MC@NLO, and AcerMC target specialized hard processes, including multijet W/Z production, top events, and W/Z events with b-jets.Alpgen can be very inefficient for final states with many jets, making generation time significant.

3.4 New C++ Generators

ATLAS evaluates newer C++ generator technologies as alternatives or complements to established FORTRAN generators, with capabilities spanning updated showers, multiple interactions, and specialized process input.

  • Pythia 8 rewrites Pythia in C++ and adds expanded physics models, a new interface, transverse-momentum-ordered showers, and interleaved multiple interactions.It is interfaced to Athena and used for generator studies, but requires further tuning before replacing Pythia6 as a leading generator.
  • POWHEG provides physics similar to MC@NLO while producing events with only positive weight.It is expected to replace MC@NLO after broader process coverage and validation.
  • Herwig++ is the C++ replacement for Herwig, supporting selected Standard Model, supersymmetric, and universal-extra-dimensions processes.Additional hard processes can enter through Les Houches input, and users can add decay models.
  • Herwig++ is planned for W and Z and supersymmetric production because it includes full spin correlations and QCD radiation in supersymmetric decay chains.Its underlying-event model extends Jimmy with soft scatters and can potentially generate minimum-bias physics.

3.5 Parton Distribution Functions

ATLAS standardizes parton-distribution inputs through LHAPDF while preserving generator-specific PDF choices and tuning relationships. The HepMC record carries generator and simulation truth, but much of its metadata remains generator-specific.

  • ATLAS uses LHAPDF as a replacement for PDFLIB, with CTEQ PDFs as the default external input for event generators.MC@NLO uses NLO PDFs, while other generators use LO PDFs.
  • PDF choices are correlated with tuning parameters, so generator configurations must be treated as linked sets rather than independently adjusted values.The paper warns that arbitrary changes to a few parameters can produce inconsistent results.
  • The complete HepMC event tree is stored as Monte Carlo truth, while only stable particles are propagated through simulation.Status codes 1 and 2 have general meanings; other status codes vary between generators.
  • Simulation copies the generator HepMC tree and adds particles from Geant4, changing status codes and offsetting identifiers to distinguish simulation secondaries.
  • ATLAS tunes generator parameters against data and distributes new tunings through Athena releases, with underlying-event modeling among the most important tuning areas.Tunings can be varied at runtime, overridden when needed, or reverted to previous defaults.

4 ATLAS Detector Description

The ATLAS detector description models the detector’s detailed geometry, materials, magnetic fields, configurations, and operating conditions for simulation and related workflows. A common infrastructure supports full-detector, commissioning, and test-stand layouts while balancing realism, memory use, and simulation-time constraints.

  • Magnetic field: The detector description includes a 2.0 T solenoid and toroidal magnets providing approximately 2.5 Tm barrel and 5 Tm endcap bending power.The magnetic-field map required about 30 MB of memory during a simulation run.
  • Production scope: Standard production omits luminosity detectors because retaining particles at high pseudorapidity increases simulation time by approximately 50% per unit of |η| per event.The luminosity detectors can instead be simulated in dedicated jobs.
  • Geometry representation: The simulation geometry is organized into solids, logical volumes, and physical volumes, with parameterization and nesting producing hundreds of thousands of physical and total volumes.This detailed description supports modeling missing transverse energy, tracking efficiencies, and calorimeter response.
  • Geometry constraints: The complete Geant4 geometry requires almost 300 MB, and overlaps or touching surfaces can create stuck tracks that lose events.Small gaps can prevent this problem but add an extra particle step through transition regions.
  • Configurations and validation: Multiple detector layouts, including cosmic-ray, commissioning, and test-stand configurations, are maintained in the same infrastructure and selectable at run time.Shared Geant4 versions, physics lists, and common elements allow test-beam tuning to be applied directly to full-detector simulation.

5 Core Simulation

ATLAS core simulation combines Geant4 with Athena-specific interfaces, configurable detector layouts, event-generation inputs, and runtime controls. The infrastructure supports commissioning and test-stand configurations, reproducibility, detector-response validation, and performance optimization.

  • Simulation framework: Geant4 supplies particle transport and physics models, while ATLAS-specific code constructs detector geometry and records subsystem-sensitive-detector scoring through Athena.FADS adds Python-based configuration for Geant4 classes, detector descriptions, sensitive-detector assignments, and range cuts without recompiling libraries.
  • Event generation: The simulation accepts events from files, concurrently configured external generators, or a configurable single-particle generator.Generated events can be smeared, shifted, rotated, and filtered by particle position or momentum before detector simulation.
  • Detector configurations: Detector layouts can represent the standard detector, commissioning configurations, and test stands, with runtime selection determining available simulation options.These configurations include cosmic-ray layouts with shifted calorimeter and muon endcaps, and combined or standalone test-beam setups.
  • Configuration and control: ATLAS simulation jobs expose staged initialization and configurable run conditions so users can modify simulation settings largely through job options.Random seeds for Geant4, Athena, and particle generators can be controlled or persisted, making a complete job reproducible.
  • Validation and optimization: A step-limitation process in the inner detector improved agreement with test-beam and cosmic-ray data for QGSP EMV, while QGSP BERT’s equivalent process agreed equally well.QGSP BERT used about 2.5 times the CPU time of QGSP EMV; QGSP BERT HP used approximately five times more and was unsuitable for standard simulation.
  • Validation and optimization: Calorimetry produced 95% of sensitive-region hits but comprised only 25% of the hit file after compression.The comparison illustrates how hit volume and stored disk space differ across detector subsystems.

6 Digitization

ATLAS digitization converts simulated detector hits into readout-like responses while modeling subdetector electronics, noise, conditions, and pile-up. Its configurable workflow produces RDOs and related truth information for downstream studies, but cavern-background simulation has documented issues.

  • Digitization workflow: Digitization converts simulation hits into detector responses called digits when readout signals exceed configured thresholds within defined time windows.Some subdetectors retain detailed signal shapes, while others record only threshold crossings.
  • Digitization workflow: Subdetector-specific algorithms model charge collection, cross-talk, electronic noise, and channel-dependent response under uniform top-level Python configuration.The algorithms are tuned to reproduce detector response characteristics.
  • Output formats: Digits are written as Raw Data Objects, while Simulated Data Objects can retain particles and noise contributing to each signal.Some subdetectors convert digits to RDOs through a second algorithm; others produce RDOs directly from hits.
  • Configuration: Digitization is highly configurable through Python, including event selection, subdetector activation, noise, random seeds, metadata, background overlays, beam properties, geometry, and conditions.The detector layout defaults to the version recorded in the hard-scattering hit-file metadata.
  • Cavern background: Cavern-background simulation suffers from outdated particle-density modeling, limited event statistics, excess monitored-drift-tube hits, and multiple counting of neutral-particle hits.Available samples range from 40,000 events at safety factor 1 to 5,000 at safety factor 10.

7 Fast Simulations

ATLAS developed several fast simulations because detailed Geant4 modeling is too computationally expensive for the statistics required by many studies. The variants trade simulation detail and reconstruction compatibility differently.

  • Motivation: Fast simulation complements full Geant4 simulation because detailed detector geometry and physics prevent sufficient simulated statistics for many studies.Each fast-simulation variety is designed for a particular use case.
  • Simulation variants: Fast G4 Simulation accelerates calorimeter modeling, while ATLFAST-I targets very large-statistics parameter scans without full-simulation detail.ATLFAST-II combines fast tracking and fast calorimeter components while retaining standard reconstruction compatibility.
  • Simulation variants: ATLFAST-I smears truth objects to produce reconstructed-like physics objects without detailed efficiencies and fake-object simulation.It achieves a factor of 1000 speed increase over full simulation for many general studies.

7.1 Fast G4 Simulation

Fast G4 Simulation speeds calorimeter-dominated Geant4 simulation by replacing selected electromagnetic shower tracking with parameterized, library-based, or single-hit treatments. Its output remains compatible with the full simulation workflow.

  • Performance and compatibility: A factor-of-three CPU reduction is achieved even in hadronic events, and the resulting output format matches full Geant4 simulation identically.The output can therefore use the same tests, digitization, trigger, and reconstruction software.
  • Shower treatments: Fast G4 applies three electromagnetic-shower treatments: parameterization above 10 GeV, libraries from 10 MeV to 1 GeV, and single-hit deposition below 10 MeV.The treatments can be enabled separately in each calorimeter compartment.
  • Configuration: The shower strategies are optimized per calorimeter compartment to maximize CPU improvement with minimal complexity while balancing memory use and shower-shape fidelity.The 1 GeV library upper bound balances memory use with speed and avoids less accurate high-energy tails.

7.2 ATLFAST-I

ATLFAST-I produces high-statistics samples by replacing detailed detector simulation and reconstruction with parameterizations. This makes rapid studies possible, but limits detector-based measurements and requires care with efficiencies, fakes, and pile-up.

  • Purpose: ATLFAST-I parameterizes detector and reconstruction effects to minimize CPU time for large signal and background samples.It is intended for parameter scans and studies where full-simulation detail is unnecessary.
  • Scope and limitations: ATLFAST-I is the least detailed simulation method and does not provide a realistic detector description, reconstruction efficiencies, or general misidentification rates.Genuine physics objects can be overestimated and fake objects are not modeled, except for b-jets and taus through tagging procedures.
  • Input and tracking: Input is read in HepMC format and filtered by processing stage, such as retaining charged final-state particles for tracking.This allows ATLFAST-I to read output from all ATLAS generators.
  • Input and tracking: Tracks are selected with pT > 500 MeV and |η| < 2.5, then assigned parametrized resolutions derived from fully simulated events.Hadronic non-Gaussian tails are modeled with double-Gaussian correlated smearing, while no vertex smearing is applied.
  • Object reconstruction: Calorimeter cells use unity, uniform response without resolution smearing, while electron, photon, muon, and jet observables receive object-specific parameterized treatment.The calorimeter map uses η × φ granularity of 0.1 × 0.1 up to |η| < 3.2 and 0.2 × 0.2 for 3.2 < |η| < 5.0.
  • Object reconstruction: Default jet resolution functions omit pile-up, although a high-luminosity mode adds a jet-size-dependent pile-up term.The correction is constant with respect to jet transverse energy.
  • Object reconstruction: Jet labels identify light-quark, b-quark, c-quark, or tau origins through truth-level matching with ΔR < 0.3.Hadronic tau labels additionally require the visible-to-reconstructed energy ratio to exceed 1 − 2σ.

7.3 ATLFAST-II

ATLFAST-II combines simplified detector simulation with standard Athena reconstruction to approximate full simulation while reducing computational cost. Its Fatras and FastCaloSim components use parameterized or simplified detector descriptions, with validation against full simulation ongoing.

  • ATLFAST-II: ATLFAST-II directly simulates the input to standard Athena reconstruction algorithms, enabling full and fast simulated events to be analyzed together.Its default configuration uses full simulation for the inner detector and muon system and FastCaloSim for calorimetry.
  • Fatras: ATLFAST-IIF uses Fatras for the inner detector and muon system, where simplified detector layers preserve sensitive-detector accuracy while approximating other material.Fatras models effects including multiple scattering, ionization, radiation, photon conversion, and hadronic interactions using simplified methods and parameterizations.
  • Validation: Fatras was initially established as a validation tool for inner-detector reconstruction, while validation against full simulation for first-collision data remained ongoing.It had also been used for tracker noise studies and simulations of a potential inner-detector upgrade.
  • FastCaloSim: FastCaloSim deposits single-particle shower energy using parameterized longitudinal and lateral profiles rather than simulating particle interactions directly.Its parameterizations are derived from 30 million fully simulated single-photon and charged-pion events spanning 200 MeV to 500 GeV and |η| < 5.0.
  • FastCaloSim: FastCaloSim uses about 200MB of memory, takes a few microseconds per calorimeter particle, and requires a few seconds for a typical t¯t event.Most of its simulation time is spent numerically integrating lateral shape functions.
  • Comparison: FastCaloSim differs from Fast G4 Simulation in geometry coverage and hit placement: it fills ATLAS readout geometry, whereas Fast G4 places Geant4-like hits in the full detector but only applies to calorimeter sampling material.These approaches therefore represent detector material and calorimeter response differently.

7.4 Computing Performance

Fast simulation substantially reduces event-processing time relative to full simulation, with the largest reduction from ATLFAST-IIF. CPU accounting must include the differing digitization and reconstruction steps required by each configuration.

  • Measurement setup: The reported timings were measured on Sun Fire X2200 M2 systems with dual dual-core 2.6 GHz AMD Opteron 2218 processors.The table reports event times in kSI2K seconds.
  • Simulation time: ATLFAST-II reduces simulation time by factors of 20–40, while ATLFAST-IIF reduces it by a factor of 100.Fast G4 reduces time by a factor of ten or more for single central electrons and by factors of 2–5 for hard-scattering events.
  • Simulation time: FastCaloSim contributes about 10% of ATLFAST-II simulation time and 60–70% of ATLFAST-IIF simulation time.ATLFAST-I uses a relatively negligible amount of CPU time even for hard-scattering events.
  • Processing requirements: CPU comparisons require accounting for downstream processing: full and fast G4 require digitization and reconstruction, whereas ATLFAST-IIF requires only muon-system digitization before reconstruction.ATLFAST-II still requires inner-detector and muon-system digitization, while its calorimeter requires only reconstruction.

7.5 Physics Performance

Fast simulations are evaluated against full simulation using low-level single-particle studies and high-level jet, hard-scattering, and muon observables. Agreement is generally good, but deviations remain for shower-sensitive calorimeter properties, some jet resolutions, and punch-through.

  • Comparisons with full simulation: Fast G4 agrees with full simulation to about 1–2% in jet energy scale and within 5% in electron-identification efficiency.FastCaloSim differs from full simulation at the 5% level after reconstruction, especially for properties sensitive to hadronic-shower shape.
  • Calorimeter limitations: FastCaloSim does not describe visible electromagnetic subshowers in charged-pion showers because all particles use an average lateral shape function.Object-dependent correction functions can reduce these differences after reconstruction.
  • Calorimeter limitations: The fast simulations do not model fakes and calorimeter punch-through well in ATLFAST-II and ATLFAST-IIF.These effects are identified as limitations of the fast configurations.
  • Event-level observables: ATLFAST-II and Fast G4 agree well with full simulation in missing-transverse-energy spectra, including the distribution tails.ATLFAST-I underpopulates the tails, while ATLFAST-IIF produces a distribution that is too wide.
  • Jet performance: ATLFAST-I, ATLFAST-IIF, and ATLFAST-II show 10–20% deviations from full simulation in jet transverse-momentum resolution.Fast G4 remains consistent with full simulation across the full pseudorapidity range.
  • Muon performance: Muon resolution is generally in good agreement across the fast simulations, although ATLFAST-IIF is 10% better than full simulation in some standalone-muon pT bins.The ATLFAST-IIF muon-system simulation was still under development, and physics groups were expected to determine acceptability for their analyses.

8 Validation

ATLAS validates simulation in two phases: software performance and physics performance, using automated tests, resource benchmarks, and comparisons with detector data. The validation program also identifies rare release problems before production.

  • Validation first assesses software robustness, performance, and functionality, then compares physics performance with test-beam, cosmic-ray, and previous simulation data.
  • Software performance validation: Nightly ATN tests, subset-of-build RTT tests, and full-chain FCT tests provide progressively broader checks from basic functionality to Grid-production readiness.FCT exercises generation, fast and full simulation, digitization, bytestream conversion, and reconstruction across multiple physics processes.
  • Software performance validation: 1000-event long tests probe reconstruction stability and preliminary object quality, while the typical 50-event chains are limited by full-simulation CPU requirements.The long tests reconstruct events from an old validated release; other tests mainly check job success, output counts, and log errors.
  • Computing performance benchmarking: Full-detector simulation typically requires ∼750 MB of memory, with approximately 100 MB from GeoModel, 300 MB from G4Atlas, and 300 MB from loaded modules.Memory usage is largely independent of event count and is monitored for increases during the event loop.
  • Computing performance benchmarking: Full simulation takes typically several minutes per hard-scattering event; writing files increases t¯t time by ∼0.5%, while 10 TeV operation reduces it by 17%.The reported timings suppress logfile and output-file creation unless otherwise noted.
  • Computing performance benchmarking: Digitization can become memory-limited with many overlaid events, and at 10^34 cm−2s−1 swapping significantly increases CPU time.The testing machine reached its memory limit at that luminosity.
  • Physics validation: Grid validation usually exposes rare release problems, although bugs occurring much less often than 1/1000 events are unlikely to be caught automatically.Developers use the resulting feedback to produce fixes before the next production cycle.
  • Physics validation: Geant4 physics validation uses available detector data, including combined and standalone test-beam studies and cosmic-ray data collected with multiple subdetectors in 2008.These studies inform subsystem-performance understanding, simulation optimization, and parameter choices.

9 Summary and Conclusions

The ATLAS simulation project integrates event generation through digitization in a flexible framework designed for complex detector descriptions and physics models. By late 2008 it was ready for data, with continual Grid production and a validation program producing a high-quality simulation sample.

  • The project presents an integrated simulation chain covering event generation, detector simulation, and digitization.
  • The software project had been prepared for data since late 2008 and was ready for data.
  • Runtime configurability covers event generators, detector descriptions, detector conditions, simulation parameters, and digitization settings.These controls address uncertainty in physics models, machine performance, detector conditions, and cavern conditions.
  • Three fast-simulation varieties complement full simulation and reduce difficulties caused by full-detector simulation time.
  • Generation, simulation, and digitization run continually on the Grid, while validation produces a high-quality simulation sample for ATLAS data.
Loading 1005.4568v1…