Geant4 review from the aspect of a GATE developer and user
Nicolas Karakatsanis
Contents
Tracking in parameterized volumes
Performance of Geant4 with large voxelized phantoms
Profiling of GATE-GEANT4 performance
Variance Reduction Techniques with GEANT4
GEANT4 implementation of the ion source
Radioactive Decay Module
Dosimetry in GEANT4
Further suggestions from the medical community
Tracking in parameterized volumes
In SPECT a detector is typically made of a scintillator capturing gammas emitted from a patient tracer.
In front of such a detector is a lead block with circa 150.000 air holes
In parallel beam applications all these holes have an identical form and are aligned along a rectangular grid.
We can model such a parallel beam collimator using arrays (repeaters) or using Geant4 replicas.
Both options are available in GATE but for distributed computing only replicas are used since building the geometry goes fast (almost no overhead on a cluster).
Tracking in parametrized volumes
However also applying
Fan collimators (oriented towards a focal line)
cone beam collimators (oriented towards a focal spot)
Hence, every individual hole has another form/orientation
which can be pre-calculated and described in a closed analytical expression
To model such collimators
GATE uses G4 parametrised volumes.
Building the geometry goes fast and flawless.
The tracking however is multiple orders slower
probably because every time a particle hits the collimator every form and distance is recalculated.
Tracking in parametrized volumes
Temporary solution
Design of a "flying hole array“
only takes the 20 neighbouring holes around the interaction site into account.
Limitation if the energy of the gammas increases
because then can travel through many of the lead lamella, crossing over multiple holes (not known before how many holes)
Question
How to increase calculation speed in an application with more than 10^4 parametrized inserts in one volume
Contact: Steven Staelens : steven.staelens@ugent.be
Performance of Geant4 with large voxelized phantoms
Problem:
The simulation time for a voxelized phantom in GATE is prohibitive (dependent on the number of total voxels).
This is a bottleneck in GATE when using voxelized phantom.
Question
Couldn't some implementation in Geant4 reduce this computing time?
Performance of Geant4 with large voxelized phantoms
Our analysis:
Geant4 forces one step in material region boundary
This feature could be one of most important (if not the most important) factors that affects simulation speed when using large voxelised phantoms
Because G4 is dealing with each voxel as a different material region
Possible solution
If the material in one voxel is the same as that in its neighboring voxel,
Treat those two voxels as one region (no region boundary between those two voxels)
Check that condition for all voxels
Performance of Geant4 with large voxelized phantoms
Possible solution (..continue)
Create an option in stepping function
to test if the material in next region is the same as current one.
If yes
no boundary is applied here and
a normal step is taken
A flag can turn on/off the previous option
Performance of Geant4 with large voxelized phantoms
Solution developed in GATE
A compressedMatrix phantom object can be used instead of the parameterizedBoxMatrix
generate a compressed phantom where voxel size is variable
All adjacent voxels of the same material are fused together to form the largest possible rectangular voxel.
A compressed phantom uses
less memory and also
less CPU
It is possible to exclude regions in the phantom from being compressed through the use of an "exclude list" of materials
Question
Using compressedMatrix phantom
reduce the CPU time but only by maybe 30%.
A more efficient way to track particles in a voxelized geometry is welcomed
Contact: Richard Taschereau: RTaschereau@mednet.ucla.edu
Profiling of GATE-Geant4 performance
Profiling tools
Grpof and Valgrind (GNU profiling tools)
Profiling results indicate
Use of voxelized maps
degrade Geant4 performance
Significant increase of the computation time consumed by the method
CLHEP :: Hep3vector G4ThreeVector
which is used by the Geant4 class
G4ParameterizedNavigation
Geant4 navigation follows a voxel-to-voxel approach
=>time-consuming approach
Possible Solutions
Need for optimization
Merging of neighboring voxels with similar attributes