Global ILC Simulation Status Report (Personal summary from TILC08) Norman Graf (SLAC) ALCPG Physics and Detector R&D Seminar April 3,2008

Software Development Overview Physics analyses. Refine and strengthen the arguments for the ILC. Detector design. Integrated system design for an optimal detector. Event reconstruction. Demonstrate that proposed detector systems can conduct the physics program, and allows cost-benefit optimization to be done. Testbeam and prototype infrastructure. Support subsystem design, readout and analysis.

Simulation Mission Statement Provide full simulation capabilities for Linear Collider physics program: Physics simulations Detector designs Reconstruction and analysis Need flexibility for: New detector geometries/technologies Different reconstruction algorithms Limited resources demand efficient solutions, focused effort. Strong connections between university groups, national labs, international colleagues.

Goals Facilitate contribution from physicists in different locations with various amounts of available time. Use standard data formats, collaborate & cooperate. Provide a general-purpose framework for physics software development. Develop a suite of reconstruction and analysis algorithms and sample codes. Simulate benchmark physics processes on different full detector designs. Software should be easy to install, learn, use. Support via web based forums, tutorials, meetings.

From Physics Studies to Benchmarking We believe that the physics case for a TeV-scale linear e+ e- collider has been made. The emphasis of analyses now shifts towards Optimization, evaluation and comparison of detector choices Realities required by engineering: e.g. amount and distribution of readout and support material, … Realities required by realistic detector response simulations: e.g. electronics digitization, noise, … Realities required by reconstruction algorithms: e.g. track finding & fitting, PFA, jetfinding, …

Motivation for Common Benchmarks Detector concepts will naturally seek to optimize their designs using physics processes. The wider community would like to see demonstrated physics capabilities from mature detectors, e.g. with a reasonable level of engineering, costing, etc. Natural, then, especially with limited resources, to agree upon a common set of analyses to be used by all the concepts in the LOI process.

Common LOI Benchmarks …The evaluation of the detector performance should be based on physics benchmarks, some of which will be the same for all LOIs based upon an agreed upon list and some which may be chosen to emphasize the particular strengths of the proposed detector… “Guideline for the definition of a Letter of Intent …”, 3 October ‘07

Benchmark Selection Process WWS Software panel (Akiya Miyamoto, KEK, Ties Behnke, DESY, Norman Graf, SLAC,) in consultation with the detector concepts and the WWS Roadmap Panel and starting from the Benchmark Panel Report has drafted a short list of processes which are: consistent with the ILC baseline sensitive to detector performance not overly dependent on sophisticated analysis techniques. i.e. emphasis is on demonstrating detector performance Expect, and welcome, input from IDAG

Benchmark Processes e+e-→ZH, H→e+e-X, m+m-X (MH=120 GeV, Ecms=250 GeV) tracking efficiency and momentum resolution material distribution in the tracking detectors EM shower ID, kink reconstruction (bremsstrahlung) Higgs Mass and cross section e+e-→ZH, H→cc, m+m- Z→νν(MH=120 GeV, Ecms=250 GeV) heavy flavour tagging, secondary vertex reconstruction multi jet final state, c-tagging in jets, uds anti-tagging test anti-tagging by studying the H→gg BR(H  cc), BR (H  +-)

Benchmark Processes e+e-→ZH, H→cc , m+m-, Z→qq (MH=120GeV, Ecms=250GeV) in addition to the charm tagging, this final state tests the confusion resolution capability BR(H  cc) , BR (H  +-) e+e-→Z→τ+τ- (Ecms=500 GeV) tau reconstruction, aspects of particle flow π0 reconstruction tracking of very close-by tracks , AFB, and  decay mode efficiency and purity.

Benchmark Processes e+e-→tt, t→bW, W→qq’ (Mtop=175GeV, Ecms=500 GeV) multi jet final states, dense jet environment particle flow b-tagging inside a jet maybe lepton tagging in hadronic events (b-ID) tracking in a high multiplicity environment , AFB, and mtop e+e-→χ+χ- /χ20χ20 (Ecms=500 GeV) particle flow (WW, ZZ separation) multi-jet final states SUSY parameter is point 5 of Table 1 of hep-ex/0603010 , and masses

Standard Model Backgrounds All analyses used in the context of the detector optimization and LOI process will need an inclusive sample of the Standard Model Background. Will provide the SM sample centrally in stdhep format, for all concepts to use. Provide all information and tools necessary to produce specific signal samples individually with exactly the same setup as this SM sample.

Event Generators No single MC generator is optimal for everything. However, Whizard is a multi-purpose Matrix Element generator. Signals and backgrounds of all types (SM + MSSM) can be produced with the same settings It contains all interferences, hence it is more accurate than generators like Pythia, especially for complex final states (6f and more) Some inaccuracies remain, but benefits outweigh these minor issues.

Whizard SM Sample Generate an inclusive set of MC events with all SM processes WHIZARD Monte Carlo used to generate all 0,2,4,6-fermion and t quark dominated 8-fermion processes. 100% e- and e+ polarization used in generation. Arbitrary electron, positron polarization simulated by properly combining data sets. Fully fragmented MC data sets are produced. PYTHIA is used for final state QED & QCD parton showering, fragmentation, particle decay. Events are weighted!

Standard Model Sample Full 2ab-1 SM sample available via ftp from SLAC. Each file corresponds to a particular initial e-/e+ polarization and final state ftp://ftp-lcd.slac.stanford.edu/ilc/whizdata/ILC500/ cumbersome to work with for end user Have to mix polarizations by hand Each file contains only processes of one type, so need to run over complete data set (thousands of files) to get faithful subset. 500 fb-1 sample of these events generated with 80% e-, 30% e+ polarizations, randomly mixed events from all processes ftp://ftp-lcd.slac.stanford.edu/ilc/ILC500/StandardModel/

Next Steps for SM Data Sample Remove 120 Higgs from n fermion final states at 500 GeV, and add explicit ffH, ffHH, etc. final states. Regenerate states with  in final state using TAUOLA. Coding done at DESY, generation in progress. Produce full SM data set at 250 GeV Machine parameters have been obtained from the GDE, GuineaPig events being generated to provide pair background events and beam spectra to be used for event generation.

Additional Signal Processes Detector concepts are free (and encouraged) to add additional processes to this list in order to optimize their designs or demonstrate the capabilities of the detectors. These should, however, be generated using conditions as close as possible to those used for the canonical samples. It is more important for this process that we use a common, well-understood set of events than it is to pick the “best” generator for each final state. We are comparing detector response, not making physics case for the machine.

Additional Backgrounds GuineaPig pairs and photons (Cain too?) Added crossing angle, converted to stdhep, available here. Muons and other backgrounds from upstream collimators & converted to stdhep. Need to validate and understand normalizations.  hadrons generated as part of the “2ab-1 SM sample.” All events then capable of being processed through full detector simulation. Additive at the detector hit level, with time offsets, using LCIO utilities. i.e. simulate response separately for signals and backgrounds, then add at digitization/reconstruction level.

Additional Event Generation Issues Crossing Angle Agree that events will be generated with 0° and the 14mr crossing angle will be accounted for at the time of simulation. Tuning of pythia parton fragmentation has come up. Will most likely proceed with default due to large number of events already generated. Essential to fully document and maintain a provenance for all files (and analyses?)

Detector Modeling & Simulation ACFA-ILC Jupiter and Satellites ALCPG slic and org.lcsim packages ECFA-ILC Mokka and MarlinReco

Jupiter and Satellites Akiya Miyamoto 4 March 2008 TILC08

ROOT objects : Event Tree & Configuration Jupiter and friends Beamtest Analysis Event Reconstruction Digitizer Finder Fitter Detector Simulator QuickSim FullSim Generator Pythia CAIN StdHep Physics Jet finder ROOT objects : Event Tree & Configuration JUPITER Satellites Link to various tools at http://acfahep.kek.jp/subg/sim/soft GLD Software at http://ilcphys.kek.jp/soft All packages are kept in the CVS. Accessible from http://jlccvs.kek.jp/ Akiya Miyamoto TILC08, 4-Mar-2008 23 23

JSF Framework: JSF = Root based application All functions based on C++, compiled or through CINT Provides common framework for event generations, detector simulations, analysis, and beam test data analysis Unified framework for interactive and batch job: GUI, event display Data are stored as root objects; root trees, ntuples, detector configuration in Jupiter run. Release includes other tools QuickSim, Event generators, beamstrahlung spectrum generator, etc. Akiya Miyamoto TILC08, 4-Mar-2008 24

Jupiter feature - 1 Currently using Geant4 9.1p1 Physics List: LCPysicsList(Default) Modular structure  easy installation of sub-detectors Geometry Simple geometries are implemented ( enough for the detector optimization ) parameters ( size, material, etc ) can be modified by an input ASCII file at run time  Parameters are saved as a ROOT object for use in Satellites later

Jupiter feature - 2 Input: Output: Run mode: StdHep file(ASCII), HepEvt, CAIN, or any generators implemented in JSF. Interface to StdHep: Prepared as a JSFModule, using StdHep 5.06.01 Output: Exact Hits of each detectors (Smearing in Satellites) Pre- and Post- Hits at before/after Calorimeter Used to record true track information which enter CAL/FCAL/BCAL. Break points in tracking volume Output in LCIO Format is through a JSFModule Break point Post-hits Run mode: A standalone Geant4 application JSF application to output a ROOT file.

GLDPrime_v03 in Jupiter Updates since since GLDPrime_v02 ( Jan 08) Parameters for VTX, TPC, CAL, Coil, MUD are updated. CAL module BCAL FCAL CH2mask IT Barrel-Endcap 10cm gap VTX Akiya Miyamoto TILC08, 4-Mar-2008 27

GLD/GLDPrim/J4LDC J4LDC GLD B=4 Tesla B= 3 Tesla Rmin(ECAL)=160cm Akiya Miyamoto TILC08, 4-Mar-2008 28

LCIO Interface Ejet JER (cosq < 0.7) 45 GeV 30.1 ± 0.3 175 GeV T.Yoshioka • An interface which converts Jupiter output to LCIO format has been implemented. • Jupiter data reconstructed by ilcsoft v01-03. (includes LDCFullTracking and PandoraPFA v02-01) Ejet JER (cosq < 0.7) 45 GeV 30.1 ± 0.3 175 GeV 45.9 ± 0.7

Mokka, Marlin and Friends

ALCPG Detector Software Development

LC Detector Full Simulation Items highlighted in yellow represent common standards MC Event (stdhep) slic Raw Event (lcio) Geometry (lcdd) Compact Geometry Description (compact.xml) GEANT4 Reconstruction, Visualization, … lcgo (?)

slic Number of internal optimizations and refactorings. Should not be noticed by end users. Upgrades to recent version of Geant4 (9.1p1) has essentially eliminated problem of event aborts when particle tracking became stuck. Output file autonaming option provides provenance. panpyZmumuh120-0-500_SLIC-v2r3p10_geant4-v9r0p1_LCPhys_sid01.slcio slic from scratch: cvs -d :pserver:anonymous@cvs.freehep.org:/cvs/lcd co SimDist cd SimDist ./configure make Binaries also available for Windows, Mac, Linuxes input stdhep file name generator & version geant version physics list det name

Detector Variants Runtime XML format allows variations in detector geometries to be easily set up and studied: Stainless Steel vs. Tungsten HCal sampling material RPC vs. GEM vs. Scintillator vs. dual readout Layering (radii, number, composition) Readout segmentation (size, projective vs. nonprojective) Tracking detector technologies & topologies TPC, Pixels, Silicon microstrip, SIT, SET “Wedding Cake” Nested Tracker vs. Barrel + Cap Field strength Far forward MDI variants

Improved Calorimeter Simulations II Have two types of polygonal barrel geometries currently defined in the compact description: Overlapping staves: Wedge staves: Can define ~arbitrary layerings (and boundary stay-clears) within these envelopes to simulate sampling calorimeters. Additional geometries (e.g. tilted polyhedra) will be developed on an as-needed basis. Support for dual readout, e.g. optical processes, included.

sid01_polyhedra Dodecagonal, overlapping stave EMCal Dodecagonal, wedge HCal Cylindrical Solenoid with substructure Octagonal, wedge Muon

Silicon Tracking Detectors For the purposes of quickly scanning the parameter space of number of tracking layers and their radial and z positioning, etc. have been simulating the trackers as cylindrical shells or planar disks. Are now moving beyond this to be able to realistically simulate buildable subdetectors. Have always been able to simulate arbitrarily complex shapes in slic using lcdd, but this is a very verbose format. Introduced Geometry and Detector Element trees to handle arbitrary hierarchies of detector elements. Have now introduced tilings of planar detectors (simulating silicon wafers) into the compact xml description.

The Barrel Vertex Detector

LCIO SimTracker Hits from Vertex CAD Drawing GEANT Volumes LCIO Hits

The Barrel Outer Tracker

Example Geometries (same exe) TPC Tracker Cal Barrel SiD01 MDI-BDS Test Beam Cal Endcap

More complex geometries Arbitrarily complex geometries can be accommodated in the lcdd detector description, but these will not be propagated to the reconstruction system. May be appropriate for supports, readouts, and far-forward BDS/MDI elements. CAD to GEANT functionality implemented, and tested for simple elements, so engineering drawings for some elements can be adopted ~as-is. Will, of course, have an impact on performance due to use of BREPS in Geant.

Physics Lists & Hadron Showers Number of issues still unresolved with choice (or not) of showering models. For many neutral hadrons LHEP (Gheisha-inspired) is only choice. Transition regions still very worrisome. LCPhys is still default, but all lists available. FTFP_BERT looks good. Transverse distance containing 90% of hits Scintillator RPC Energy (GeV)

Diagnostic Histograms Diagnostic plots of event data MCParticles, hits, clusters Runs on different detectors must have compact description also need sampling fractions Easy to use and setup on the web at http://lcsim.org/SlicDiagWeb/ SLAC CVS project cvs –d :pserver:anonymous @cvs.freehep.org:/cvs/lcd co SlicDiagnostics ./build.sh ./bin/SlicDiagnostics [...]

GeomConverter GeomConverter LCDD slic lcio Small Java program for converting from compact description to a variety of other formats GODL lelaps lcio GeomConverter Compact Description HEPREP wired org.lcsim Analysis & Reconstruction

Event Samples Have generated canonical data samples and have processed them through full detector simulations. simple single particles: , , e, +/- , n, … composite single particles: 0,, K0S ,, , Z, … Z Pole events: comparison to SLD/LEP WW, ZZ, tt, qq, tau pairs, mu pairs, Z, Zh beam pairs, muons,  hadrons, etc. backgrounds inclusive 1 ab-1 Standard Model sample Web accessible http://www.lcsim.org/datasets/ftp.html Additive at the detector hit level, with time offsets. Investigate effects of full backgrounds.

Beam Background Overlays Take output from full beam simulation (from IR/backgrounds group) Feed into full detector simulation Build library of simulated background bunches Overlay backgrounds on signal events at start of reconstruction Adjust timing of hits (for TPC e.g.) Add energy in calorimeter cells Allows to change #bunches/train, bunch timing

Additional Simulation Issues Detector Geometries All packages are capable of modeling very detailed detector geometries, including cracks, support structures and other “dead” material. In fullness of time, mature reconstruction will account for such issues. Question is, how much effort should be devoted to putting in effects in the simulation only to take them out again (or not) in the reconstruction? Detector Magnetic Fields Implementing full field maps in Geant is very CPU consuming. Accounting for non-homogeneous fields in the reconstruction is also extremely CPU intensive. Propose to generate signals using simplified fields, full fields for far-forward backgrounds.

“Validation” Process Transparency in the analysis comparisons would be ensured if input and output were strictly controlled. Generating and providing a canonical data sample ensures common input. As I understand the LOI process, this benchmarking is primarily a detector concept exercise. Can we more fully involve the physics working groups? Could we develop and release “canned” physics analyses to reduce systematic uncertainties in e.g. jet-finding, combinatorics, constrained fits, … Create library of analysis drivers which target LCIO lists of ReconstructedParticle. Write out standard set of histograms or analysis metrics. Strengthens the “horizontal” nature of the physics working groups, does not disenfranchise them from LOI.

ReconstructedParticles Analysis Flow Three regional efforts, ACFA-LC, ALCPG, ECFA-LC all support the LCIO event data model, making interoperability possible. sim reco Input Events (stdhep) Jupiter Marlin Mokka org.lcsim Output Events ReconstructedParticles (lcio) ? slic Uranus ? ? others? others? analysis Common Analysis Suite (Physics Groups?) Standard metrics

Benchmarking The WWS Software Panel has produced a short list of physics processes to be studied by each of the concepts for the LOI. Individual concepts will also analyze additional reactions in the process of optimizing their detector designs. A common set of Standard Model physics and machine backgrounds is being / has been generated. Events will be provided in stdhep format. Performance metrics have been identified. Details still to be resolved, and changes may still be made, but the benchmarking process is well underway.

Summary The three regional efforts (ACFA-ILC, ALCPG, and ECFA-ILC) all have mature, full-featured, detector simulation packages, capable of modeling very detailed geometries. How detailed should the simulations be for the LOI? LCIO event data model and file format allows exchange of simulated (& reconstructed) data. Number of analyses presented at TILC08 exploited this functionality, e.g. Jupiter GLD simulation input to MarlinReco PandoraPFA slic SiD simulation fed to LCFI flavor-tagging package