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
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:
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.
- 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)
Milestones and Action Items
- 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.
- 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
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:
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.
- 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.
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
Detector Geometry Description
- Detector Description Services for STAR
Technical Requirements for STAR DSS
- Documentation for the CMS DDD Project, which is an intersting case study, even though the
packaging of their software basically precludes re-using it in STAR.
- Other references:
The latter item can potentially be of interest as there exist GDML to native GEANT4 converters,
which already is a useful functionality, that we can take advantage of. There has been preliminary
discussion with the ROOT team indicating the possibility of developing a parser/writer of GDML
for the TGeo classes.
- A reference page for the Geant 3 to Geant 4 conversion facility