Overview Contents Previous Next Geant4 User's Guide
For Application Developers
Geometry


4.1.12 Dynamic Geometry Setups

Geant4 can handle geometries which vary in time (e.g. a geometry varying between two runs in the same job).
It is considered a change to the geometry setup, whenever:

Whenever such a change happens, the geometry setup needs to be first "opened" for the change to be applied and afterwards "closed" for the optimisation to be reorganised.
In the general case, in order to notify the Geant4 system of the change in the geometry setup, the G4RunManager has to be messaged once the new geometry setup has been finalised: 
     G4RunManager::GeometryHasBeenModified();
The above notification needs to be performed also if a material associated to a positioned volume is changed, in order to allow for the internal materials/cuts table to be updated. However, for relatively complex geometries the re-optimisation step may be extremely inefficient, since it has the effect that the whole geometry setup will be re-optimised and re-initialised. In cases where only a limited portion of the geometry has changed, it may be suitable to apply the re-optimisation only to the affected portion of the geometry (subtree).
Since release 7.1 of the Geant4 toolkit, it is possible to apply re-optimisation local to the subtree of the geometry which has changed. The user will have to explicitly "open/close" the geometry providing a pointer to the top physical volume concerned: 

 #include "G4GeometryManager.hh"
 
 // Open geometry for the physical volume to be modified ...
 //
 G4GeometryManager::OpenGeometry(physCalor);
 
 // Modify dimension of the solid ...
 //
 physCalor->GetLogicalVolume()->GetSolid()->SetXHalfLength(12.5*cm);
 
 // Close geometry for the portion modified ...
 //
 G4GeometryManager::CloseGeometry(physCalor);
Source listing 4.1.9
Opening and closing a portion of the geometry without notifying the G4RunManager.

If the existing geometry setup is modified locally in more than one place, it may be convenient to apply such a technique only once, by specifying a physical volume on top of the hierarchy (subtree) containing all changed portions of the setup.

An alternative solution for dealing with dynamic geometries is to specify NOT to apply optimisation for the subtree affected by the change and apply the general solution of invoking the G4RunManager. In this case, a performance penalty at run-time may be observed (depending on the complexity of the not-optimised subtree), considering that, without optimisation, intersections to all volumes in the subtree will be explicitely computed each time.

About the authors