STAR  Computing  Simulation  
Virtual Monte Carlo Application and Detector Description Services for STAR

This page is under heavy construction and will be continuously updated.


We see the Virtual Monte Carlo approach to simulation as a promising platform to move to, from the present legacy software which is likely approaching the limits of its useful lifecycle (as mentioned in various STAR meetings; also see the Detector Description Services section below).

An extremely simplified, abstract diagram of the Monte Carlo simulation can be pictured like this:

In most existing Monte Carlo applications (e.g. GEANT 3.21 and GEANT 4) there is close coupling of some of the elements pictured above: geometry, for example, is described in the same algorithmic language in which the Monte Carlo engine was written, which precludes interoperability with other applications. Likewise, the geometry manager (a loose term for the module responsible for tracing particles through volumes) uses a particular internal representation of the geometry which is impossible to change in favor of a more optimal one, or another format required for interoperability.

The Virtual Monte Carlo (VMC) is an attempt to solve this problem by creating a platform-neutral kernel of the application, to the highest degree possible. This kernel is then equipped with interfaces to the modules responsible for simulating the physics of particle propagation, and importantly, tracking.

Objectives of the project

The ultimate objective is to create a new infrastructure for the STAR simulation activity, which would take advantage of the VMC concept and importantly provide convenient interfaces to other application used in STAR. The latter concerns both external detector geometry description and internal representation which we aim to unify with that of the reconstruction software.

The immediate goal is to create a working mode of the VMC application, in order to benchmark and test it as applied to STAR. Additional considerations are listed below.

We consider the native geometry description classes in the ROOT system as a good choice for the internal (i.e. in-memory) geometry representation for the following reasons:

  • A high degree of interoperability with other components of the STAR software, as it is ROOT-based
  • Abstraction from particular features of any given simulator (platform neutrality)
  • Existence of claims of high performance of the ROOT-based tracking (which still needs to be verified)

The existing ROOT classes (often referred to as TGeo) do not provide facility for defining the geometry of the apparatus, other than native C++ code. This is a common disadvantage with the existing aplications and it is addressed in the section below on the Detector Description Services (DDS).

On the physics side, we intend to preserve the proven GEANT 3.21 implementation as a starting point, and keep the option of switching to GEANT 4 later, which should be possible if the potential of VMC is realized.

Milestones and Action Items

Achieved Milestones:
  • We do have a working albeit somewhat primitive application based on the code provided by the ROOT team, and have the capability to define the detector geometry either in C++ code or by importing an externally created ROOT file
  • The actual benchmarking of the existing STAR simulation system vs the VMC application, under comparable conditions, has started
  • We have created a facility for the conversion of the GEANT/ZEBRA based geometry representation into the TGeo/ROOT based classes. This is still being updated.

Action items:

  • Continuing benchmarking in order to better understand the implication of the new tracking
  • Design of the necessary data structures in which to persist all the data components: the input and output event data, configuration settings, and the detector geometry:
    • Format of the data fed into the simulation from the event generator. This is essentially designing classes, more than anything else, as the persistence feature is largely taken care of by using the right ROOT objects.
    • Same for the output.
    • Geometry description: a project in itself. More broadly, the Detector Description Services.
    • Configurations settings: anything that's not part of the detector geometry, materials and parameters. This may be, for example, the physics settings to be used in the simulation. As a comment, XML seems like a good candidate for this rask.

Virtual MC implementations

Currently there exist two tested implementations of the Virtual Monte Carlo based on the ROOT software, one based on GEANT 3 and another on GEANT4. In the following, we'll use G3 and G4 designations for the sake of brevity. Below we consider the classes used to incorporate these into the VMC framework.

The ROOT class TVirtualMC is an abstraction of the actual Monte Carlo engine (be it GEANT 3 or 4), and as such and abstracts a large number of crucial MC methods. To illustrate that, here is a small sample of its tracking methods:

    virtual Int_t       CurrentVolID(Int_t& copyNo) const =0;
    virtual Int_t       CurrentVolOffID(Int_t off, Int_t& copyNo) const =0;
    virtual const char* CurrentVolName() const =0;
    virtual const char* CurrentVolOffName(Int_t off) const =0;
    virtual Int_t       CurrentMaterial(Float_t &a, Float_t &z, 
                        Float_t &dens, Float_t &radl, Float_t &absl) const =0;  
and its run managmement methods:
    virtual void Init() = 0;
    virtual void BuildPhysics() = 0;
    virtual void ProcessEvent() = 0;
    virtual void ProcessRun(Int_t nevent) = 0;
When instantiated, the object that inherits from the TVirtualMC is singleton and assigns a pointer to itself to the global variable gMC, which is how it is accessed from outside.

The often significant differences between the GEANT 3 and GEANT 4 internals are encapsulated here and result in significant differences in the actual code between TGeant3 and TGeant4 classes, derived from TVirtualMC.

The the interaction between the TVirtualMC-based singleton and the class derived from TVirtualMCApplication is as follows:

  • TVirtualMCApplication calls TVirtualMC to do various initializations and then to run the actual MC event simulation
  • TVirtualMC makes callbacks to TVirtualMCApplication, allowing the user to take action pertaining to steps, hits etc.
The TVirtualMCApplication can therefore be characterized as steering and instrumentation part of the application exposed to the user. It is designed to carry little dependency on the implementation (whether it's G3 or G4), and to that extent the term "Virtual" is appropriate here (but see comments below).

The above can be sumarized in the following chart, which depicts both functional relationship between the most important classes, and the inheritance of the implementation classes.

Differences between GEANT 3 and 4 implementations

As mentioned above, the TVirtualMCApplication methods are identical in both cases, confer:
void MyMCApplication::RunMC(Int_t nofEvents)
However, the G4 implementation tends to forward more of the control to the native methods of G4. This is in contrast to the G3 implenetation, where most of the typical G3 program flow is re-implemented in side the TGeant3 class. Among other things, this leads to a vastly different amount of code in TGeant3 and TGeant4 (the latter is much more compact).

To reiterate, the different structure of the original G3 and 4 applications results in TGeant3 and TGeant4 being dramatically different, and subclassed from TVirtualMC as almost from a pure abstract class.

VMC implementation in Alice

Information can be found here

Detector Geometry Description

Last updated by Maxim Potekhin on 06/23/2004