8/8/2019 jpconf8_119_042014

1/8

An interface for GEANT4 simulation using ROOT geometry

navigation

A Gheata1,2

and M Gheata1,2

for ALICE offline Collaboration

1CERN, CH 1211 Geneva 23

2 Institute for Space Sciences, Bucharest

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

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

1.IntroductionDetector geometry is an important component of a HEP simulation application. In the context of theMonte Carlo (MC) simulation of particle transport through a detector setup, geometry is essentiallyused to answer navigation queries like: locating in which detector element is the particle, how far fromthe next volume boundary or crossing a given surface at which angle. No matter the transport MCtoolkit or application used (discussed here only FLUKA [1], GEANT3 [2] and GEANT4 [3]) thegeometry modeller is embedded within the framework and accessible to user code via API orconfiguration files. Due to incompatibilities between the geometry features of different transportengines a simulation application is hardly portable outside a given setup, making people generallyspeak of the GEANT4 simulation application or GEANT3 or FLUKA setups. Besides simulation,geometry is used by several other components of an experiments framework, whenever geometryinformation is required. This is the case for the reconstruction, alignment or event display frameworkswhich are not always using the same geometry information source and even less transient geometrymodel.The general approach is to import the same geometry description into the desired application, notalways possible and error prone due to the need of hardcoded parameters, database synchronization orformat conversions. A different approach was used by ALICEoffline framework that uses ROOT[4]geometry modeller TGeo [5] as single source of geometry information and navigation tool. For this towork 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

1

8/8/2019 jpconf8_119_042014

2/8

work describes the integration ofROOTgeometry as navigator for GEANT4 particle transportationmodule.

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

Figure 1: Virtual Monte Carlo idea

VMCprovides 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 theinterface. This had several limitations due to incompatibilities of different geometry features and notimplemented for FLUKA which has a quite different geometry model. ROOT geometry could beprogressively used directly via navigation interfaces so that it can be now created using VMCAPI. Thepossibility to create GEANT3 or GEANT4 native geometries is still preserved for validation andcomparison purposes, but now for new VMC users it is recommended to create directly TGeogeometry.Geometry converters can also be used for existing geometries in a different format. Conversionbetween 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

8/8/2019 jpconf8_119_042014

3/8

3.Navigation interfacesA 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 toa physics process manager and a navigation module. The physics step proposed is actually made onlyif it is within the geometry limits of the current geometrical object the particle is traversing. Thisapproach is taken for all transport MCs and all the corresponding geometry access methods makewhat we may call the navigation interface. For using a different geometry package providing the samenavigation functionality as the native MCgeometry one needs to replace the existing interface withone adapted to the new package.

3.1.Navigation interfaces for GEANT3 and FLUKABoth transport engines being written in FORTRAN, the navigation is natively performed via calls tospecific subroutines while communication is done through common blocks. This allowed thereplacement 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 thatseveral tests were done for validating their implementation. A very important issue when the nativegeometry interface is replaced is the consistency of results. In case ofFLUKA we were able even toreproduce the random seed sequence for some simple examples treated with the two geometryformats, showing that the usage of the new interface does not bias in any way the physics results.

3.2.Navigation interface for GEANT4GEANT4 navigation interface is using a base class G4Navigator. While the navigation using ROOTgeometry was implemented by inheriting from this class, several native GEANT4 geometry objectsneed 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 acompromise in order to minimize the memory penalties. The interface implementation, its usage andvalidation will be described in more detail in the following section.

4.Implementation of the G4ROOTinterfaceThe interface can operate once the ROOT geometry is loaded in memory, no matter the importmethod. It is composed of three main classes that are provided and transparent to users together with aplug-in base class for extra configuration options.

4.1.Additional data structures built at initializationThe normal procedure to make GEANT4 able to operate with certain geometry is to register a classderived from G4VUserDetectorConstruction to its run manager. In g4rootinterface the correspondingclass is called TG4RootDetectorConstruction and implements the mandatory Construct() methodcreating a native GEANT4 geometry structure. The Construct() method in fact just mirrors the TGeohierarchical 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 nativeGEANT4 volumes composing a path in the geometry hierarchy, as well as valid GEANT4 materialsand matrices. These are also mirrored from TGeo corresponding objects. The GEANT4 geometrystructure created in this way does not contain any optimization structures for navigation navigationis always performed using TGeo geometry.At tracking time, once the geometry state corresponding to a query is found using TGeo geometry, thecorresponding G4 geometry state has to be composed using a direct mapping between TGeo and G4corresponding objects. This procedure is extremely fast compared to the time to answer the queryitself, so the only penalty of the interface compared to using G4 native is the extra memory occupiedby the parallel structure. In figure 3 is presented how the mapping described above is done and thememory penalty in case ofALICEgeometry which looks quite acceptable.

3

8/8/2019 jpconf8_119_042014

4/8

Figure 3: Parallel GEANT4 geometry structure created during initialization. For ALICETGeo

geometry size is about 17MB (optimizations included). The new structures (no optimizationsneeded) add only 9MB including the loaded GEANT4 libraries.

4.2.Navigator class and work flowThe GEANT4 toolkit provides the base class G4Navigator for handling all G4 native geometryqueries. The solution in g4rootinterface was to provide a class TG4RootNavigatorto implement thesame functionality using the TGeo geometry. Besides the navigation query methods, the class providesmapping between TGeo objects and the corresponding GEANT4 ones crated at initialization. Theworkflow of a g4rootsession is presented in figure 4.

Figure 4: Workflow of a simulation session using G4ROOT interface

While theROOTTGeo geometry is read in memory (e.g. from the file MyGeometry.root) its pointercan be passed to the static method TG4RootNavMgr::GetInstance(TGeoManager *pGeom). The classTG4RootNavMgris just the entry point for creating the interface that in addition has to connect withGEANT4 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

8/8/2019 jpconf8_119_042014

5/8

manager. The next step after creating a G4RunManageris to register optional additional configurationclass (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 afterwhich will apply the post-build configuration specified in the user-defined method Initialize() of thepost detector construction class. The last step is to call TG4RootNavMgr::ConnectToG4() that willactually connect the TG4RootDetectorConstruction to the GEANT4 run manager.

4.3.User-defined configurationIn GEANT4 non-geometrical objects can or have to be connected to the logical volumes. This is thecase for sensitive detectors, user limits or optical properties. These cannot be linked directly intoROOT geometry so they have to be used with the GEANT4 structures built on the fly. The interfaceprovides 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 togetherwith the interface.

5.Interface validationThe validation of the interface was done in many steps with tests of increasing complexity. The firstset of tests was comparing results for some native GEANT4 examples. The procedure here was tocreate the ROOTgeometry identical with the ones used in G4 novice examples, reuse all GEANT4classes in the examples but replace the detector construction one with g4root interface. Thecomparison was mainly aiming at fixing interface bugs but finally gave either identical or compatibleresults in all cases. One of these tests corresponding to optical photon transport was implemented as anexample for interface usage.A second set of tests was performed using the VGM testbed. This allows importing any ROOTgeometry and performs geantinos transport using g4root or native GEANT4 after converting inmemory to the corresponding G4 geometry. These tests were most easy to debug and in fact proved tobe a quite powerful debugging tool. All differences in the boundary crossing sequence or positionwere investigated and fixed or understood, revealing a very good match and compatibility between thetwo geometry modellers.The third and last set of tests was performed using geant4-vmc framework. This allowed comparingresults for real experiment geometries with physics setup switched on or off, ALICEbeing the first

candidate. These tests were performed with GEANT4 9.0 and ROOT 5.17.02 and some additionalfeedback is expected from other VMCusers. The testing environment was AliRoot [8] (the off-lineframework of ALICE experiment) and we could also make realistic comparisons in terms ofperformance for the two different navigation options with GEANT4, but also against GEANT3 andFLUKA to a certain extent. These results are however preliminary and additional investigations areongoing.

5.1.Tests using geantinos (no physics)Some results of the tests with geantinos transport are presented in figure 5. These tests were performedonly for 2ALICEdetectors (TPCand the muon spectrometer) and show a very good consistency. Thetiming for performing the transport is comparable.

5.2.Tests with physics and magnetic field onMore extensive tests were done for transporting 5KparameterizedHIJING cocktail particles in a wideenergy range (2999 GeV) in different geometry setups of increasing complexity. Results are

compared between g4rootand native GEANT4 in figure 6 for TPC. Results are again quite similar aswell as timing.

5

8/8/2019 jpconf8_119_042014

6/8

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 inALICEHMPID detector

6

8/8/2019 jpconf8_119_042014

7/8

5.3.Optical photon transportAfter 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. Somepreliminary results are presented in figure 7. Some differences in the number of photons per ring haveto be investigated.

5.4.Timing comparisonsAnother interesting aspect of the VMC-based tests was the comparison between differentMCtransportcodes for identical (or very similar) input settings related to geometry definition and physics setup. Adetailed physics comparison was not done at this level yet since the main objective was the navigationinterface 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 barreldetectors ofALICE. The results are presented in figure 8 for GEANT3, FLUKA and geant4-vmcinterfaces. We expected and observed a sizeable difference between GEANT3 and GEANT4/FLUKAsimulations scaling with the increased detail of the simulation. One notices that timing when usingGEANT4 native geometry orROOTgeometry in a GEANT4 simulation is quasi-identical, meaning thatno noticeable performance penalty is introduced by usingROOTgeometry for GEANT4 simulation.

Figure 8: Timing comparison for GEANT4, FLUKA and GEANT3VMC-based simulations with differentdetector geometry setups. The number oftouchables is the total number of different geometry objects in

the setup.

6.ConclusionsA new navigation interface allowing running GEANT4 based simulations usingROOTTGeo 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

8/8/2019 jpconf8_119_042014

8/8

ROOTgeometry is available; however the maximum benefit is by using it via the VMCframeworkthat allows running also GEANT3 and FLUKA simulations with the same user code.

We performed several validation tests in different environments, showing consistency between nativeGEANT4 geometry navigation and TGeo-based one. The benchmarks show no penalty in usingROOTgeometry via the interface that opens a several possibilities of cross-checking and comparing differenttransport Monte Carlo results.

7.References[1] Fasso' A, Ferrari A, Ranft J, and Sala P R, 2005 FLUKA: a multi-particle transport code CERN2005-10INFN/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. 2003Nucl. 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 2003A geometrical modeller for HEPProc. Computing inHigh Energy and Nuclear Physics, THMT001, La Jolla

[6] I. Hivnov et al.2003 The Virtual Monte Carlo Proc. Computing inHigh Energy and NuclearPhysics THJT006, La Jolla

[7] I. Hivnov 2004 The Virtual Geometry ModelProc. Computing in High Energy and NuclearPhysics, 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 perspectivesProc. Computing in High Energy

and Nuclear Physics, THJT003, La Jolla

8