1 / 23

GEANT4 for Future Linear Colliders

GEANT4 for Future Linear Colliders. Geant4 Workshop @ DESY October 2, 2003. Linear Collider Environment. Exploit the physics discovery potential of e + e - collisions at s ~ 1TeV. Precision measurements of complex final states require detectors with:

gbowen
Download Presentation

GEANT4 for Future Linear Colliders

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GEANT4 for Future Linear Colliders Geant4 Workshop @ DESY October 2, 2003

  2. Linear Collider Environment • Exploit the physics discovery potential of e+e- collisions at s ~ 1TeV. • Precision measurements of complex final states require detectors with: • Exceptional momentum resolution & vertexing. • Imaging calorimetry for “Energy Flow” analysis. • Common simulation environment for all LC studies would allow sharing of detectors, algorithms, and code. • The system should be flexible, powerful, yet simple to install and maintain.

  3. MC Event Raw Event G4Application Geometry Geometry Database Reconstruction, Visualization, … LC Detector Full Simulation GEANT4

  4. Mokka • Geant4 full simulation for the Tesla detector. • Uses subdetector-specific geometry drivers. • Relevant parameters stored in MySQL database. • Tight coupling between Sensitive Detector and geometry volume definitions. • LCIO persistence for generic hits & MC chain.

  5. The Proto00 geometry driver P55 MOKKA Proto00 P55Ec

  6. LCD Full Simulation • Geometry defined in XML. • Flexible, but simplified volumes. • Projective readout of sensitive volumes. • Dynamic topology, not just parameters. • Have defined generic hit classes for sensitive tracker and calorimeter hits. • Root and LCIO bindings for I/O.

  7. TPC Tracker, Si Disks, CCD VTX

  8. All Si Tracker, CCD VTX

  9. Generic Hits Problem Statement • We wish to define a generic output hit format for full simulations of the response of detector elements to physics events. • Want to preserve the “true” Monte Carlo track information for later comparisons. • Want to defer digitization as much as possible to allow various resolutions, etc. to be efficiently studied.

  10. Types of Hits • “Tracker” Hits • Position sensitive. • Particle unperturbed by measurement. • Save “ideal” hit information. • “Calorimeter” Hits • Energy sensitive. • Enormous number of particles in shower precludes saving of each “ideal” hit. • Quantization necessary at simulation level.

  11. Hits Summary • Storing “ideal” hits gives detailed information about MC track trajectory. • Deferring digitization allows studies of detector resolution to be efficiently conducted. • Can approximate the same in calorimeter by defining small cells, then ganging later.

  12. LCIO • Persistency framework for LC simulations. • Currently uses SIO: Simple Input Output • on the fly data compression • some OO capabilities, e.g. pointers • C++ and Java implementation available • Changes in IO engine designed for. • Extensible event data model • Generic Tracker and Calorimeter Hits. • Monte Carlo particle heirarchy.

  13. LCIO (II) • Persistency framework for LC simulations. • Java, C++ and f77 user interface. • LCIO is currently implemented in simulation frameworks: • hep.lcd • Mokka/BRAHMS-reco -> other groups are invited to join

  14. Generator Analysis Recon- struction Simulation LCIO Motivation LCIO Persistency Framework Java, C++, Fortran Java, C++, Fortran Geant3, Geant4 Java, C++, Fortran geometry

  15. Towards Internationalization • Suggest that Tesla, NLC and JLC full simulation groups could run a single GEANT4 executable. • Geometry determined at run-time (XML). • Write out common “ideal” hits. • Digitize as appropriate with plug-ins. • Enormous savings in effort. • Makes comparisons easy.

  16. Common GEANT4 executable Runtime geometry Generic Hit output Full Simulations BRAHMS GEANT3 FORTRAN LCD Full Sim GISMO C++ JIM GEANT3 FORTRAN LCDROOT/LCDG4 MOKKA JUPITER

  17. LCD/Mokka • First version of mysql / xml interface exists • SD detector fully modelled including beamline elements. • Several TESLA detector versions modelled. • LCIO output implemented in beta version. • Interfaces to HEPEVT and STDHEP and background files implemented. • Interface to AIDA integrated.

  18. SD in Mokka

  19. MC Event (STDHEP) Raw Event (Generic Hits) (LCIO/Root) Geometry (XML) Geometry Database (MySQL) LC Detector Full Simulation Histograms (AIDA) G4Application GEANT4

  20. Main Simulation Issues • Need flexible method to describe geometry. • Prefer G4 supported geometry input (GDML?) • Beam Delivery System requires arbitrary magnetic fields, excellent tracking precision. • Tracking System: (1/pT)5x10-5 GeV/c • Multiple Scattering, tracking precision. • Jet Reconstruction: E/E~30%/√E • Excellent hadronic shower simulations.

  21. Highlights of LC Geant4 Effort • Common executable, with runtime geometry. • Detector designs compared on equal footing. • Generic hits for trackers and calorimeters. • Simplifies Sensitive Detector implementation. • Post-GEANT digitization  design flexibility. • Lightweight persistence format (LCIO). • Allows interchange of data between communities. • Common target for Java, C++ & Fortran analyses.

  22. Why XML? • Simplicity: Rigid set of rules, plain text • Extensibility: Add custom features, data types • Interoperability: between OS and languages • Self-describing data • Hierarchical structure  OOP • Open W3 standard, lingua franca for B2B • Many tools for validating, parsing, translating • Automatic code-generation for data-binding

  23. Why G4 XML? • XML Schema very useful for “compile-time” type safety and bounds checking. • Prefer a G4-supported XML-based solution. • Had hoped for common LHC solution. • Investigated GDML. • Looks promising. • Sensitive detector definitions needed. • Support?

More Related