International Conference on Computing in High Energy and Nuclear Physics (CHEP’07) IOP Publishing

Journal of Physics: Conference Series 119 (2008) 042014 doi:10.1088/1742-6596/119/4/042014

An interface for GEANT4 simulation using ROOT geometry

navigation

1,2 1,2
A Gheata and M Gheata for ALICE offline Collaboration
1
CERN, CH 1211 Geneva 23
2
Institute for Space Sciences, Bucharest

E-mail: Andrei.Gheata@cern.ch, Mihaela.Gheata@cern.ch

Abstract. The ROOT geometry modeller (TGeo) offers powerful tools for detector geometry
description. The package provides several functionalities like: navigation, geometry checking,
enhanced visualization, geometry editing GUI and many others, using ROOT I/O. A new
interface module g4root was recently developed to take advantage of ROOT geometry
navigation optimizations in the context of GEANT4 simulation. The interface can be used
either by native GEANT4-based simulation applications or in the more general context of the
Virtual Monte Carlo (VMC) framework developed by ALICE offline and ROOT teams. The
latter allows running GEANT3, GEANT4 and FLUKA simulations without changing either the
geometry description or the user code. The interface was tested and stressed in the context of
ALICE simulation framework. A description of the interface, its usage as well as recent results
in terms of reliability and performance will be presented. Some benchmarks will be compared
for ROOT-TGeo or GEANT4 based navigation.

1. Introduction
Detector geometry is an important component of a HEP simulation application. In the context of the
Monte Carlo (MC) simulation of particle transport through a detector setup, geometry is essentially
used to answer navigation queries like: locating in which detector element is the particle, how far from
the next volume boundary or crossing a given surface at which angle. No matter the transport MC
toolkit or application used (discussed here only FLUKA [1], GEANT3 [2] and GEANT4 [3]) the
geometry modeller is embedded within the framework and accessible to user code via API or
configuration files. Due to incompatibilities between the geometry features of different transport
engines a simulation application is hardly portable outside a given setup, making people generally
speak of ‘the GEANT4 simulation application’ or ‘GEANT3 or FLUKA setups’. Besides simulation,
geometry is used by several other components of an experiment’s framework, whenever geometry
information is required. This is the case for the reconstruction, alignment or event display frameworks
which are not always using the same geometry information source and even less transient geometry
model.
The general approach is to import the same geometry description into the desired application, not
always possible and error prone due to the need of hardcoded parameters, database synchronization or
format conversions. A different approach was used by ALICE offline framework that uses ROOT [4]
geometry modeller TGeo [5] as single source of geometry information and navigation tool. For this to
work in a coherent way TGeo modeller was integrated in the Virtual Monte Carlo [6] framework that
allows running transparently simulation based on the three transport engines mentioned above. This


c 2008 IOP Publishing Ltd 1
International Conference on Computing in High Energy and Nuclear Physics (CHEP’07) IOP Publishing
Journal of Physics: Conference Series 119 (2008) 042014 doi:10.1088/1742-6596/119/4/042014

work describes the integration of ROOT geometry as navigator for GEANT4 particle transportation
module.

2. Virtual Monte Carlo and geometry

The Virtual Monte Carlo framework was created for providing users a unique API for configuring,
running and getting results from different MC particle transport engines. In this framework the user
application and the specific transport package are separated via one level of virtual layers as shown in
figure 1. Communication between the user application and the specific MC interface (provided by the
framework) is made only via base virtual classes.

Figure 1: Virtual Monte Carlo idea

VMC provides API for creating geometry. This is very close to GEANT3 geometry definition style and
in the first versions was actually creating the native geometry structures of the MC used via the
interface. This had several limitations due to incompatibilities of different geometry features and not
implemented for FLUKA which has a quite different geometry model. ROOT geometry could be
progressively used directly via navigation interfaces so that it can be now created using VMC API. The
possibility to create GEANT3 or GEANT4 native geometries is still preserved for validation and
comparison purposes, but now for new VMC users it is recommended to create directly TGeo
geometry.
Geometry converters can also be used for existing geometries in a different format. Conversion
between ROOT, GEANT4, and some XML formats (AGDD, GDML) is supported by VGM [7]
framework. These options are summarized in the workflow from figure 2.

Figure 2: Geometry usage in the VMC framework

2
International Conference on Computing in High Energy and Nuclear Physics (CHEP’07) IOP Publishing
Journal of Physics: Conference Series 119 (2008) 042014 doi:10.1088/1742-6596/119/4/042014

3. Navigation interfaces
A simplistic view on how a single particle transport is performed would be the following: a
transportation manager module decides the next step to be made by the current particle after talking to
a physics process manager and a navigation module. The physics step proposed is actually made only
if it is within the geometry limits of the current geometrical object the particle is traversing. This
approach is taken for all transport MC’s and all the corresponding geometry access methods make
what we may call the navigation interface. For using a different geometry package providing the same
navigation functionality as the native MC geometry one needs to replace the existing interface with
one adapted to the new package.

3.1. Navigation interfaces for GEANT3 and FLUKA

Both transport engines being written in FORTRAN, the navigation is natively performed via calls to
specific subroutines while communication is done through common blocks. This allowed the
replacement of the default functions with wrappers calling the corresponding functionality in ROOT
geometry. We will not describe these interfaces in detail here but it is important to mention that
several tests were done for validating their implementation. A very important issue when the native
geometry interface is replaced is the consistency of results. In case of FLUKA we were able even to
reproduce the random seed sequence for some simple examples treated with the two geometry
formats, showing that the usage of the new interface does not bias in any way the physics results.

3.2. Navigation interface for GEANT4

GEANT4 navigation interface is using a base class G4Navigator. While the navigation using ROOT
geometry was implemented by inheriting from this class, several native GEANT4 geometry objects
need to be kept since they are used by G4 framework itself for other than navigation purposes.
Replacing completely the native geometry with a foreign one is not possible so we had to find a
compromise in order to minimize the memory penalties. The interface implementation, its usage and
validation will be described in more detail in the following section.

4. Implementation of the G4ROOT interface

The interface can operate once the ROOT geometry is loaded in memory, no matter the import
method. It is composed of three main classes that are provided and transparent to users together with a
plug-in base class for extra configuration options.

4.1. Additional data structures built at initialization

The normal procedure to make GEANT4 able to operate with certain geometry is to register a class
derived from G4VUserDetectorConstruction to its run manager. In g4root interface the corresponding
class is called TG4RootDetectorConstruction and implements the mandatory Construct() method
creating a native GEANT4 geometry structure. The Construct() method in fact just mirrors the TGeo
hierarchical objects based on GEANT4 native ones: there is a one-to-one correspondence between
TGeoVolume and G4LogicalVolume, TGeoNode and G4PhysicalVolume.
The navigation interface of GEANT4 needs in fact to provide to the transportation module native
GEANT4 volumes composing a path in the geometry hierarchy, as well as valid GEANT4 materials
and matrices. These are also mirrored from TGeo corresponding objects. The GEANT4 geometry
structure created in this way does not contain any optimization structures for navigation – navigation
is always performed using TGeo geometry.
At tracking time, once the geometry state corresponding to a query is found using TGeo geometry, the
corresponding G4 geometry state has to be composed using a direct mapping between TGeo and G4
corresponding objects. This procedure is extremely fast compared to the time to answer the query
itself, so the only penalty of the interface compared to using G4 native is the extra memory occupied
by the parallel structure. In figure 3 is presented how the mapping described above is done and the
memory penalty in case of ALICE geometry which looks quite acceptable.

3
International Conference on Computing in High Energy and Nuclear Physics (CHEP’07) IOP Publishing
Journal of Physics: Conference Series 119 (2008) 042014 doi:10.1088/1742-6596/119/4/042014

Figure 3: Parallel GEANT4 geometry structure created during initialization. For ALICE TGeo
geometry size is about 17MB (optimizations included). The new structures (no optimizations
needed) add only 9MB including the loaded GEANT4 libraries.

4.2. Navigator class and work flow

The GEANT4 toolkit provides the base class G4Navigator for handling all G4 native geometry
queries. The solution in g4root interface was to provide a class TG4RootNavigator to implement the
same functionality using the TGeo geometry. Besides the navigation query methods, the class provides
mapping between TGeo objects and the corresponding GEANT4 ones crated at initialization. The
workflow of a g4root session is presented in figure 4.

Figure 4: Workflow of a simulation session using G4ROOT interface

While the ROOT TGeo geometry is read in memory (e.g. from the file MyGeometry.root) its pointer
can be passed to the static method TG4RootNavMgr::GetInstance(TGeoManager *pGeom). The class
TG4RootNavMgr is just the entry point for creating the interface that in addition has to connect with
GEANT4 transportation and run managers. Getting the interface up as above will also create the
TG4RootDetectorConstruction object, create the navigator and register it to GEANT4 transportation

4
International Conference on Computing in High Energy and Nuclear Physics (CHEP’07) IOP Publishing
Journal of Physics: Conference Series 119 (2008) 042014 doi:10.1088/1742-6596/119/4/042014

manager. The next step after creating a G4RunManager is to register optional additional configuration
class (described later on) while initializing the interface:
TG4RootNavMgr::Initialize(TVirtualUserPostDetconstruction *pDC)
The initialization will create in fact all the GEANT4 structures mirroring TGeo geometry objects after
which will apply the post-build configuration specified in the user-defined method Initialize() of the
post detector construction class. The last step is to call TG4RootNavMgr::ConnectToG4() that will
actually connect the TG4RootDetectorConstruction to the GEANT4 run manager.

4.3. User-defined configuration

In GEANT4 non-geometrical objects can or have to be connected to the logical volumes. This is the
case for sensitive detectors, user limits or optical properties. These cannot be linked directly into
ROOT geometry so they have to be used with the GEANT4 structures built on the fly. The interface
provides a base class that users have to derive from and implement the Initialize() method.
G4LogicalVolume objects can be easily accessed using the existing mapping with TGeoVolume ones.
The access methods take the volume name as argument and an example of usage is provided together
with the interface.

5. Interface validation
The validation of the interface was done in many steps with tests of increasing complexity. The first
set of tests was comparing results for some native GEANT4 examples. The procedure here was to
create the ROOT geometry identical with the ones used in G4 novice examples, reuse all GEANT4
classes in the examples but replace the detector construction one with g4root interface. The
comparison was mainly aiming at fixing interface bugs but finally gave either identical or compatible
results in all cases. One of these tests corresponding to optical photon transport was implemented as an
example for interface usage.
A second set of tests was performed using the VGM testbed. This allows importing any ROOT
geometry and performs geantinos transport using g4root or native GEANT4 after converting in
memory to the corresponding G4 geometry. These tests were most easy to debug and in fact proved to
be a quite powerful debugging tool. All differences in the boundary crossing sequence or position
were investigated and fixed or understood, revealing a very good match and compatibility between the
two geometry modellers.
The third and last set of tests was performed using geant4-vmc framework. This allowed comparing
results for real experiment geometries with physics setup switched on or off, ALICE being the first
candidate. These tests were performed with GEANT4 9.0 and ROOT 5.17.02 and some additional
feedback is expected from other VMC users. The testing environment was AliRoot [8] (the off-line
framework of ALICE experiment) and we could also make realistic comparisons in terms of
performance for the two different navigation options with GEANT4, but also against GEANT3 and
FLUKA to a certain extent. These results are however preliminary and additional investigations are
ongoing.

5.1. Tests using geantinos (no physics)

Some results of the tests with geantinos transport are presented in figure 5. These tests were performed
only for 2 ALICE detectors (TPC and the muon spectrometer) and show a very good consistency. The
timing for performing the transport is comparable.

5.2. Tests with physics and magnetic field on

More extensive tests were done for transporting 5K parameterized HIJING cocktail particles in a wide
energy range (2–999 GeV) in different geometry setups of increasing complexity. Results are
compared between g4root and native GEANT4 in figure 6 for TPC. Results are again quite similar as
well as timing.

5
International Conference on Computing in High Energy and Nuclear Physics (CHEP’07) IOP Publishing
Journal of Physics: Conference Series 119 (2008) 042014 doi:10.1088/1742-6596/119/4/042014

Figure 5: Comparison of 100K geantinos tracking in ALICE TPC detector

Figure 6: Step size distribution for TPC detector (physics and magnetic field on)

Figure 7: Optical photon transport comparison in ALICE HMPID detector

6
International Conference on Computing in High Energy and Nuclear Physics (CHEP’07) IOP Publishing
Journal of Physics: Conference Series 119 (2008) 042014 doi:10.1088/1742-6596/119/4/042014

5.3. Optical photon transport

After some minor changes in the user code setting-up optical parameters we were able to set-up and
compare results of optical photons transport simulation between GEANT3 and GEANT4. Some
preliminary results are presented in figure 7. Some differences in the number of photons per ring have
to be investigated.

5.4. Timing comparisons

Another interesting aspect of the VMC-based tests was the comparison between different MC transport
codes for identical (or very similar) input settings related to geometry definition and physics setup. A
detailed physics comparison was not done at this level yet since the main objective was the navigation
interface validation but it was interesting to do a first level check of the timing with different setups.
We have chosen few geometry setups with increasing number of geometry objects within the barrel
detectors of ALICE. The results are presented in figure 8 for GEANT3, FLUKA and geant4-vmc
interfaces. We expected and observed a sizeable difference between GEANT3 and GEANT4/FLUKA
simulations scaling with the increased detail of the simulation. One notices that timing when using
GEANT4 native geometry or ROOT geometry in a GEANT4 simulation is quasi-identical, meaning that
no noticeable performance penalty is introduced by using ROOT geometry for GEANT4 simulation.

Figure 8: Timing comparison for GEANT4, FLUKA and GEANT3 VMC-based simulations with different
detector geometry setups. The number of touchables is the total number of different geometry objects in
the setup.

6. Conclusions
A new navigation interface allowing running GEANT4 based simulations using ROOT TGeo geometry
was implemented. The interface is available in ROOT distribution and can be run starting with ROOT
v5.14 and GEANT4 8.2. The interface can be used within GEANT4 VMC framework starting with
version 2.0. The package can be used stand-alone by a native GEANT4 application provided that

7
International Conference on Computing in High Energy and Nuclear Physics (CHEP’07) IOP Publishing
Journal of Physics: Conference Series 119 (2008) 042014 doi:10.1088/1742-6596/119/4/042014

ROOT geometry is available; however the maximum benefit is by using it via the VMC framework
that allows running also GEANT3 and FLUKA simulations with the same user code.
We performed several validation tests in different environments, showing consistency between native
GEANT4 geometry navigation and TGeo-based one. The benchmarks show no penalty in using ROOT
geometry via the interface that opens a several possibilities of cross-checking and comparing different
transport Monte Carlo results.

7. References

[1] Fasso' A, Ferrari A, Ranft J, and Sala P R, 2005 FLUKA: a multi-particle transport code CERN
2005-10 INFN/TC_05/11, SLAC-R-773
[2] Brun R, Bruyant F, Maire M, McPherson A C, Zanarini P 1985 GEANT3 User Guide, CERN Data
Handling Division DD/EE/84-1
[3] Agostinelli S et al. 2003 Nucl. Instrum, and Methods A506 250-303
[4] Brun R and Rademakers F 1996 ROOT - An Object Oriented Data Analysis Framework, Proc.
AIHENP'96 Workshop, Lausanne, Sep. 1996, Nucl. Inst. & Meth. in Phys. Res. A 389 (1997) 81-86.
See also http://root.cern.ch/
[5] A. Gheata, M. Gheata, and R. Brun 2003 A geometrical modeller for HEP Proc. Computing in
High Energy and Nuclear Physics, THMT001, La Jolla
[6] I. Hřivnáčová et al.2003 The Virtual Monte Carlo Proc. Computing inHigh Energy and Nuclear
Physics THJT006, La Jolla
[7] I. Hřivnáčová 2004 The Virtual Geometry Model Proc. Computing in High Energy and Nuclear
Physics, Interlaken
[8] R. Brun, P. Buncic, F. Carminati, A. Morsch, F. Rademakers, K. Safarik on behalf of the ALICE
collaboration, 2003 The AliRoot framework, status and perspectives Proc. Computing in High Energy
and Nuclear Physics, THJT003, La Jolla