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:
the shape or dimension of an existing solid is modified;
the positioning (translation or rotation) of a volume is
changed;
a 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:
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 explicitely
computed each time.