From Geant 3 to Virtual Monte Carlo: Approach and Experience

1. From Geant 3 to Virtual Monte Carlo: Approach and Experience M. Potekhin, J.Lauret, Y.Fisyak, V. Perevoztchikov for the STAR Collaboration September 29, 2004

2. Overview • The current STAR MC simulation software: features and platform [ • Why are we interested in moving towards VMC ? [ • Should we consider alternative geometry models? [ • Infrastructure components that need to be built [ • Current status of the Star VMC and Detector Description project [

3. Features of the Existing STAR Simulation Software • The current STAR simulation software provides the following tools for the user/developer: • Detector (geometry) description language • Hit structure declaration (part of the above) • User-prescribed volume enumeration (important for analysis) • Comprehensive I/O system • Logic for treatment of secondary particles (and the mechanism of saving “interesting” particles for analysis) • Persistent documentation system (self-documenting Zebra banks)

4. Why is STAR interested in a new simulation platform? • Software Maintenance • Software Integration • Geant 3 to 4 to *?* Migration More specifically, we’ll talk about VMC

5. Our interest the VMC • Maintenance of the existing software is not trivial and requires product-specific expertise. The VMC is a hedge against our simulation framework becoming obsolete in terms of user expertise and platform change. • We want to increase the transparency to the users, in part due to benefits of OO programming and the more familiar language platform (C++ vs Fortran). • The VMC can be seen as a bridge between Geant 3 and 4, and future MC platforms • It has the potential to become a long term MC solution for STAR, with a stable API, and a geometry description system that facilitates the ongoing detector development and upgrades • It is a step to make the STAR software more robust by implementing a unified geometry description, i.e. establishing a CONSISTENT geometry model in simulation and reconstruction • There are other aspects of integration of the simulation and reconstruction, e.g. data formats etc

6. The Root Geometry component and its possible role in VMC • the Root Geometry (“TGeo”) is a broad term used to describe a set of geometry related ROOT classes • feature-rich and allows one to build complex geometries • suitable for building a Geant-like application such as VMC • can be used in event displays and potentially offers sophisticated graphic functionality (confer recent Qt work by V.Fine) • can be considered “platform neutral” as it is not really tied to any particular application such as Geant, and can be productively used to navigate geometry in STAR reconstruction • can provide a consistent geometry interface with reconstruction • more flexible, and portable, geometry description: geometry persistent in ROOT files, XML (future development), possible CAD systems interface, various TGeo based interfaces, and event displays • an attractive component to have in any future simulation framework • Offers a performance gain?

7. Infrastructure Issues • We want to preserve the following functionality of the existing software • Tools for the Detector Description • Hit structure declaration (part of the above) • User-prescribed volume enumeration (important for analysis) • Comprehensive I/O system • Logic for treatment of secondary particles (and the mechanism of saving “interesting” particles for analysis)

8. Infrastructure Issues • Hit structure declaration • Example from the existing STAR system: HITS ESCI Birk:0:(0,10) HITS CSDA type=4:2: eta:0.1:(0,1) etsp:h_phi2:(0,sh_phi2) Eloss:0:(0,1) HITS FSEC X:.0003:S Y:.0003: Z:.0003: cx:10: cy:10: cz:10:, Ptot:18:(0,100) Sleng:.1:(0,500), ToF:16:(0,1.e-6) LGAM:16:(-2,2), Step:11:(0,10) Elos:21:(0,.01) • A choice of pre-defined variables to be included in the hit structure, suitable for a lot of tasks • Advantage: reusability of software created for various detector subsystems, added user transparency

9. Infrastructure Issues • Volume navigation and enumeration: In analysis, it is often necessary to follow a convention in assigning IDs to volumes. Difference subsystems may have different rules attached to them. This is “engineer’s numbering vs GEANT numbering”. • This is not standardized and needs to be developed in a VMC implementation.

10. Detector Description • Detector Description is the method by which the detector geometry model, and properties of it constituents, are defined by the user. It can be a piece of Fortran code, a CAD system file, a piece C++ code, a XML file etc. • Now the Detector Description component should be viewed in a broader context of the VMC, as one of its components

11. Detector Description • Detector Description is an important component of the simulation software infrastructure, for the following reasons: • a robust DD system helps the detector development and upgrade process. • having tools that facilitate the geometry development and testing is requisite in a running experiment like STAR, where there are few resources immediately available • having it in place early during the transition process allows one to have the geometry ready by the time of the proposed transition • Future Detector Description in STAR - we could use one (or all) of the following… What is best? • C++ code with a proper API to interface the database • XML-based solution • We will try of course to find a uniform solution (XML -based detector description being of particular interest) • There are reasons why automated Zebra-to-Root conversion isn’t suited for the task (parameters are numbers, hit definitions not translated etc)

12. Detector Description • Why XML versus algorithmic languages? • experience in the STAR experiment shows that having a structured, declaration-based description of geometry helps a great deal in creation and maintenance of the geometry code. Extending this approach to a new platform, supported by the industry, seems to be a logical step forward. • always a possibility to use XML as an exchange format • Functionality of a XML-based solution should include • constants • arithmetic expressions • iterators (expressing symmetry in the system) • arrays of parameters • export of pure XML for visualization • database interface

13. Detector Description Open issues in Detector Description: • Have to make a choice of a particular language (schema), such as GDML • None of the existing parsers is useable right away in the TGeo context, so effectively this needs to be implemented almost from scratch • Separation of geometrical structure and the data component: current lack of a standard database interface in the existing implementations (will probably have to do it ourselves and/or establish a joint project with interested parties) • Geant 3 and 4 geometry implementation differences

14. Current status of the STAR VMC project • Parameters of the STAR VMC effort: • as lightweight application as possible, due to limited resources • experiment-independent, to better design and leave the door open for collaboration with other groups • focus on the end result, thus necessitating the development of the infrastructure as detailed above • Accomplished steps: • Developed core classes for the VMC implementation in STAR • Test application created • validation of the ROOT geometry manager in the VMC context (V.Perevoztchikov) • the TGeant3 library restructured (V.Perevoztchikov)

15. Current status of the STAR VMC project • Core classes: • StarConfiguration • StarDetectorConstruction • StarGenerator • StarHit • StarMaterial • StarMCApplication • StarMCDisplay • StarMCEvent • StarMedium • StarModule • StarParticle • StarRndm • StarRotation • StarStack • StarVertex • StarVolume • Additional classes: detector specific

16. Current status of the STAR VMC project • Example of VMC event class design:

17. Current status of the STAR VMC project • Saving tracks of interest: • done in StarStack::PushTrack method. • mechanisms of interest defined by the user, can include decays, particle types, or even volumes (work in progress) • Geometry: • a portion of the detector used, and currently coded in C++ (Root TGeo classes), as a stop-gap measure until we find a better solution • Interface with other components of the STAR software • pending implementation of the infrastructure elements such as volume numbering and hit declaration

18. driven from a CINT macro in the ROOT environment at the current stage, geometry of the detector coded in C++, pending the development of the Detector Description StarMCApplication* appl = new StarMCApplication("StarMCApplication", "STAR VMC"); StarTpc* tpc = new StarTpc(); StarEcal* ecal = new StarEcal(); appl->AddModule(tpc); appl->AddModule(ecal); TGeant3* geant3 = new TGeant3("TGeant3"); geant3->SetDRAY(1); geant3->SetHADR(1); geant3->SetLOSS(1); geant3->SetMULS(1); appl->InitMC(); appl->InitDisplay(); appl->SetFinishEventCB(StMcEventInterface::FinishEventCB); appl->SetInterest("Decay"); appl->SetInterest("Compton scattering"); appl->SetInterest("Positron annihilation"); appl->SetInterest("Photoelectric effect"); appl->SetInterest("Bremstrahlung"); appl->trig(); The STAR VMCTest application

19. Current status of the STAR VMC project • validation of the ROOT geometry manager in the VMC context (V.Perevoztchikov) • the g2root utility was used to generate a Root (TGeo) representation of the a realistic STAR geometry, based on the actual Geant model. • same geometry was studied using the standard STAR simulation tool • an identical set of tracks was used in both applications • observables: • distributions of track lengths in different volumes • integrated track lengths • results: • a few bugs found in the original STAR geometry description • minor differences (identified and understood) in the operation of respective geometry managers • No “show stopper” problem with the TGeo geometry manager found so far • performance: TGeo somewhat slower (caveat: non-optimized code)

20. Current status of the STAR VMC project • Restructuring of the TGeant3 library: • the “official” TGeant3 library comes with a particular (modified) version of Geant 3.21 code and is linked to it. This adversely affects interoperability with other software components that may have dependency on Geant 3.21 • same applies to a few other components • we have successfully separated the TGeant3 and other components that can now be loaded as dynamic libraries • Does it make sense to make that official?

21. Current status of the STAR VMC project • Areas of interest and collaboration with other groups and experiments: • the XML (GDML?) parser • enhancements to TGeant3 • elements of infrastructure useful in any context: hits, enumeration, etc