Trends in simulation software development for a LC Experiment

1. Trends in simulation software development for a LC Experiment Frank Gaede, DESY, IT Hamburg Zeuthen Linear Collider Meeting July 8, 2003

2. Outline • Overview on simulation software • The long term goal: a unified framework • LCIO (persistency framework) • data model • software • status • Future Plans • Summary Frank Gaede, DESY IT

3. (Some)existing simulation frameworks • hep.lcd • LCDRoot • LCDG4 • Mokka • BRAHMS • SIMDET • SGV • many others … Frank Gaede, DESY IT

4. hep.lcd • NLC group (SLAC) : SD development • based on JAS (Java Analysis Studio) • simple geometry description • input from Gismo (moving to Geant4) and FastMC (.sio) • (simple) reconstruction modules • integrated event display (WIRED) Frank Gaede, DESY IT

5. Wired event display in JAS (hep.lcd) Frank Gaede, DESY IT

6. LCDRoot / LCDG4 • Geant4 based detailed simulation frameworks • LCDRoot – fully integrated into root • LCDG4 – plain vanilla C++ • XML description of geometry • LCDG4 produces .sio output • can make use of reconstruction code from hep.lcd Frank Gaede, DESY IT

7. Mokka • developed at LLR/IN2P3 for Tesla Detector • detailed Geant4 based simulation framework • uses MySQL database for geometry parameterization • very flexible approach (good for R&D) • no reconstruction  • current output format: ASCII  Frank Gaede, DESY IT

8. Mokka example 30GeV pi+ Frank Gaede, DESY IT

9. BRAHMS • Geant3 based detailed simulation of Tesla detector • geometry hard coded (TDR) • complete and fairly advanced reconstruction • track reconstruction + snark => pflow (eflow) algorithm • has been split up into simulation and reconstruction part (binary files) • geant3 and f77: not state of the art for an experiment that will start to take data ~201x Frank Gaede, DESY IT

10. Towards a unified framework • there will only be one Linear Collider • Ties Behnke: • where to start -> persistency -> LCIO • joined project DESY/SLAC The “holy grail” : develop a common simulation framework that is shared between the different regions ! Frank Gaede, DESY IT

11. LCIO Persistency Framework Generator Analysis Recon- struction Simulation Motivation for LCIO Java, C++, Fortran Java, C++, Fortran Geant3, Geant4 Java, C++, Fortran geometry Frank Gaede, DESY IT

12. data format persistency data access API implementation The Persistency Framework LCIO data model contents Frank Gaede, DESY IT

13. LCIO Data Model - Overview RunHeader Event SimHeader MCParticle ReconstructedParticle RecoHeader Reco SIM TrackerHit Track CalorimeterHit Cluster for details see transparencies after summary Frank Gaede, DESY IT

14. LCIO sw-requirements • need Java, C++ and f77 (!) implementation • extendable data model for current and future simulation studies • user code separated from concrete data format • -> need to be flexible for future decisions on persistency • three general use cases • writing data (simulation) • reading and updating data (reconstruction) • read only access to data (analysis) • needed a.s.a.p. -> keep it simple ! Frank Gaede, DESY IT

15. Common API definition for Java and C++ • use AID Abstract Interface Definition • tool from freehep.org (M. Dönzelsmann) • used successfully in the AIDA project • define interfaces in Java-like language with C++ extensions • -> generates files with Java interfaces • -> generates C++ header files with pure abstract base classes • use javadoc/doxygen for documentation • independent implementations in Java and C++ • -> keep Java “pure” i.e. machine independent Frank Gaede, DESY IT

16. User documentation (Java) • LCReader: • “direct access” via fast skip • read next event/run • callbacks for modules Frank Gaede, DESY IT

17. Example: reading data LCReader* lcReader = LCFactory::getInstance()->createLCReader() ; lcReader->open( "myFile" ) ; LCEvent *myEvt ; while( ( myEvt = lcReader->readNextEvent() ) != 0 ){ cout << " Evt : " << myEvt->getEventNumber() << " - " << myEvt->getRunNumber() << ": " << myEvt->getDetectorName() << endl ; } cout << endl ; lcReader->close() ; independent of persistency implementation ! Frank Gaede, DESY IT

18. C++ developer documentation documentation created from C++ implementation with doxygen Frank Gaede, DESY IT

19. LCIO Fortran interface • Fortran support for • legacy software (e.g. BRAHMS reconstruction) • non OO-analyses code (“old guys”) • not a third implementation of the library – use C++-wrapper functions and cfortran.h instead: • one function for every class member function • use integers to store pointers ! • have factory and delete functions • -> OO-like code in fortran Frank Gaede, DESY IT

20. LCIO f77 example: Frank Gaede, DESY IT

21. Persistency Implementation • use SIO: Simple Input Output • developed at SLAC for NLC simulation • already used in hep.lcd and LCDG4 frameworks • features: • on the fly data compression • some OO capabilities, e.g. pointers • C++ and Java implementation available Frank Gaede, DESY IT

22. Status of LCIO • first Java and C++ implementation (simulation data!) • first public release soon (stable format and API) • f77 prototype (demonstrating the design) • complete integration into simulation software chains ongoing: • US: hep.lcd (Java) (+ WIRED event display !) • Europe: Mokka (C++) & BRAHMS-reco(f77) • hcalppt (Geant4 HCAL-prototype simulation) • Future: • LCDG4, SIMDET, others ? • further details: see LCIO webpage: http://www-it.desy.de/physics/projects/simsoft/lcio/index.html Frank Gaede, DESY IT

23. Future plans I • Mokka: “Open Source” like simulation tool • to be used by NLC and Tesla group (JLC?) • already started: Ties has an XML based geometry definition for the US SD in Mokka • Peter Wienemann: LAT/LCAL , new Mask • should replace/be joined with LCDG4 • writes LCIO output • BRAHMS reco • will read LCIO input (Harald Vogt) • and eventually produce LCIO output (pflow) • a first full simulation framework for Tesla detector • caveat: geometry has to be implemented (debugged) twice Frank Gaede, DESY IT

24. Future plans II • need common geometry definition: • for detailed simulation • for reconstruction • for event display • idea: use hierarchy in XML and Mokka like drivers • need common reconstruction framework • modular approach based on LCIO event data model • Java and C++ ? • would allow to compare/switch algorithms Frank Gaede, DESY IT

25. Summary • attempt to unify some existing simulation frameworks (towards the “holy grail”) • started with common persistency framework LCIO: • Java, C++ and f77 implementation • defines an event data model that can be used for reconstruction and analysis modules • user code independent of persistency format • common geometry description and reconstrucion framework needed • until then: Mokka/Brahms(reco) is going to be the working horse for detailed TESLA detector simulations Frank Gaede, DESY IT

26. Data model - LCRunHeader • block: RunHeader • int: runNumber • string: detectorName • string: description • string[]: activeSubdetectors => describes the run setup Frank Gaede, DESY IT

27. Data model - LCEventHeader • EventHeader • int: runNumber • int: evtNumber • string: detectorName • String[]: subdetectorName • blockNames: • string: blockName • string: blockType Frank Gaede, DESY IT

28. MCParticle pntr: parent pntr: secondparent pntr[]: daughters int : pdgid: int : hepevtStatus (0,1,2,3 HepEvt) (201, 202 sim. decay) MCParticle cont. double[3]: start (production vertex) float[3] : momentum (at vertex) float: energy float: charge Data model – LCEvent (sim) Frank Gaede, DESY IT

29. Data model - LCEvent (sim) • TrackerHit • string: subdetector • int: hitFlags (detector specific: Id, key, etc.) • double[3]: position • float: dEdx • float: time • pntr: MCParticle Frank Gaede, DESY IT

30. Data model - LCEvent (sim) • CalorimeterHit • string: subdetector • int: cellId0 • int: cellId1 • float: energy • float[3]: position – optional (file size!) • particle contributions: • pntr: MCParticle • float: energyContribution • float: time • int: PDG (of secondary) - optional Frank Gaede, DESY IT

31. Data model - LCEvent (reco) • OutputHeader • int: isrFlag • float: colliderEnergy • int: flag0 (to be defined) • int: flag1 (to be defined) • int: reconstructionProgramTag • float: Bfield -> could be combined with global header… Frank Gaede, DESY IT

32. Data model - LCEvent (reco) • Track • int: tracktype (full reconstr, TPC only, Muon only, etc.) • float: momentum • float: theta • float: phi • float: charge • float: d0 (Impact Parameter in r-phi) • float: z0 (Impact Parameter in r-z) • float[15]: cov.matrix • float: reference point (x, y, z) • float: chi**2 of fit • float[10]: dEdx (weights and probabilities) • TrackerHits: - optional • pntr: TrackerHit Frank Gaede, DESY IT

33. Data model - LCEvent (reco) • Cluster • int: detector (type of cluster: ECAL, HCAL, combined…) • int: clustertype (neutral, charged, undefined cluster) • float: energy • float[3]: position (center of cluster x, y, z) • float[6]: errpos (cov. matrix of position) • float: theta (intrinsic direction: theta at position) • float: phi (intrinsic direction: phi at position) • float[3]: errdir (cov. matrix of direction) • float[6]: shapeParameters (definition needed) • float[3]: weights (compatible with em., had., muon) • CalorimeterHits: - optional • pntr: CalorimeterHit • float: contribution Frank Gaede, DESY IT

34. ReconstructedParticle int: primaryFlag (0: secondary, 1: primary) int: ObjectType (charged/ neutral particle) float[3]: 3-Vec (px, py, pz) float: energy float[10]: covariance matrix float: charge float[3]: reference position for 4-vector float[5]: PID_type (hypotheses for e, g, pi, K, p, ...) Tracks: pntr: Track float:weight Clusters: pntr: Cluster float:weight MCParticles: pntr: MCParticle float:weight Data model - LCEvent (reco) self reference to build up compound objects Frank Gaede, DESY IT