1 / 21

From Geant 3 to Virtual Monte Carlo: Approach and Experience

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. Overview. The current STAR MC simulation software: features and platform [ Why are we interested in moving towards VMC ? [

rwilkins
Download Presentation

From Geant 3 to Virtual Monte Carlo: Approach and Experience

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. 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

More Related