source: trunk/documents/UserDoc/DocBookUsersGuides/ForApplicationDeveloper/xml/Detector/geomDynamic.xml @ 905

<!-- ******************************************************** -->
<!--                                                          -->
<!--  [History]                                               -->
<!--    Converted to DocBook: Katsuya Amako, Aug-2006         -->
<!--    Changed by: Gabriele Cosmo, 18-Apr-2005               -->
<!--                                                          -->
<!-- ******************************************************** -->


<!-- ******************* Section (Level#2) ****************** -->
<sect2 id="sect.Geom.Dyna">
<title>
Dynamic Geometry Setups
</title>

<para>
Geant4 can handle geometries which vary in time (e.g. a geometry
varying between two runs in the same job).
</para>

<para>
It is considered a change to the geometry setup, whenever:

<itemizedlist spacing="compact">
  <listitem><para>
    the shape or dimension of an existing solid is modified;
  </para></listitem>
  <listitem><para>
    the positioning (translation or rotation) of a volume is
    changed;
  </para></listitem>
  <listitem><para>
    a volume (or a set of volumes, tree) is removed/replaced or
    added.
  </para></listitem>
</itemizedlist>
</para>

<para>
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.
</para>

<para>
In the general case, in order to notify the Geant4 system of the
change in the geometry setup, the <literal>G4RunManager</literal> has to be
messaged once the new geometry setup has been finalised:

<informalexample>
<programlisting>
     G4RunManager::GeometryHasBeenModified();
</programlisting>
</informalexample> 
</para>

<para>
The above notification needs to be performed also if a material
associated to a <emphasis>positioned</emphasis> 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).
</para>

<para>
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:

<example id="programlist_Geom.Dyna_1">
<title>
Opening and closing a portion of the geometry without 
notifying the <literal>G4RunManager</literal>.
</title>
<programlisting>
 #include "G4GeometryManager.hh"
 
 // Open geometry for the physical volume to be modified ...
 //
 G4GeometryManager::OpenGeometry(physCalor);
 
 // Modify dimension of the solid ...
 //
 physCalor-&gt;GetLogicalVolume()-&gt;GetSolid()-&gt;SetXHalfLength(12.5*cm);
 
 // Close geometry for the portion modified ...
 //
 G4GeometryManager::CloseGeometry(physCalor);
</programlisting>
</example>
</para>

<para>
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.
</para>

<para>
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
<literal>G4RunManager</literal>. 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.
</para>

</sect2>