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 for the same physical volume:

  • the shape or dimension of its related solid is modified;

  • the positioning (translation or rotation) of the volume is changed;

  • the volume (or a set of volumes, tree) is removed/replaced or added.

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:

Listing 43 Opening and closing a portion of the geometry without notifying the G4RunManager.
#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);

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 explicitly computed each time.

Note

in multi-threaded runs, dynamic geometries are only allowed for runs consisting only of one event.