[904] | 1 | <!-- ******************************************************** --> |
---|
| 2 | <!-- --> |
---|
| 3 | <!-- [History] --> |
---|
| 4 | <!-- Converted to DocBook: Katsuya Amako, Aug-2006 --> |
---|
| 5 | <!-- Changed by: Gabriele Cosmo, 18-Apr-2005 --> |
---|
| 6 | <!-- --> |
---|
| 7 | <!-- ******************************************************** --> |
---|
| 8 | |
---|
| 9 | |
---|
| 10 | <!-- ******************* Section (Level#2) ****************** --> |
---|
| 11 | <sect2 id="sect.Geom.Dyna"> |
---|
| 12 | <title> |
---|
| 13 | Dynamic Geometry Setups |
---|
| 14 | </title> |
---|
| 15 | |
---|
| 16 | <para> |
---|
| 17 | Geant4 can handle geometries which vary in time (e.g. a geometry |
---|
| 18 | varying between two runs in the same job). |
---|
| 19 | </para> |
---|
| 20 | |
---|
| 21 | <para> |
---|
| 22 | It is considered a change to the geometry setup, whenever: |
---|
| 23 | |
---|
| 24 | <itemizedlist spacing="compact"> |
---|
| 25 | <listitem><para> |
---|
| 26 | the shape or dimension of an existing solid is modified; |
---|
| 27 | </para></listitem> |
---|
| 28 | <listitem><para> |
---|
| 29 | the positioning (translation or rotation) of a volume is |
---|
| 30 | changed; |
---|
| 31 | </para></listitem> |
---|
| 32 | <listitem><para> |
---|
| 33 | a volume (or a set of volumes, tree) is removed/replaced or |
---|
| 34 | added. |
---|
| 35 | </para></listitem> |
---|
| 36 | </itemizedlist> |
---|
| 37 | </para> |
---|
| 38 | |
---|
| 39 | <para> |
---|
| 40 | Whenever such a change happens, the geometry setup needs to be |
---|
| 41 | first "opened" for the change to be applied and afterwards "closed" |
---|
| 42 | for the optimisation to be reorganised. |
---|
| 43 | </para> |
---|
| 44 | |
---|
| 45 | <para> |
---|
| 46 | In the general case, in order to notify the Geant4 system of the |
---|
| 47 | change in the geometry setup, the <literal>G4RunManager</literal> has to be |
---|
| 48 | messaged once the new geometry setup has been finalised: |
---|
| 49 | |
---|
| 50 | <informalexample> |
---|
| 51 | <programlisting> |
---|
| 52 | G4RunManager::GeometryHasBeenModified(); |
---|
| 53 | </programlisting> |
---|
| 54 | </informalexample> |
---|
| 55 | </para> |
---|
| 56 | |
---|
| 57 | <para> |
---|
| 58 | The above notification needs to be performed also if a material |
---|
| 59 | associated to a <emphasis>positioned</emphasis> volume is changed, in order to |
---|
| 60 | allow for the internal materials/cuts table to be updated. However, |
---|
| 61 | for relatively complex geometries the re-optimisation step may be |
---|
| 62 | extremely inefficient, since it has the effect that the whole |
---|
| 63 | geometry setup will be re-optimised and re-initialised. In cases |
---|
| 64 | where only a limited portion of the geometry has changed, it may be |
---|
| 65 | suitable to apply the re-optimisation only to the affected portion |
---|
| 66 | of the geometry (subtree). |
---|
| 67 | </para> |
---|
| 68 | |
---|
| 69 | <para> |
---|
| 70 | Since release 7.1 of the Geant4 toolkit, it is possible to apply |
---|
| 71 | re-optimisation local to the subtree of the geometry which has |
---|
| 72 | changed. The user will have to explicitly "open/close" the geometry |
---|
| 73 | providing a pointer to the top physical volume concerned: |
---|
| 74 | |
---|
| 75 | <example id="programlist_Geom.Dyna_1"> |
---|
| 76 | <title> |
---|
| 77 | Opening and closing a portion of the geometry without |
---|
| 78 | notifying the <literal>G4RunManager</literal>. |
---|
| 79 | </title> |
---|
| 80 | <programlisting> |
---|
| 81 | #include "G4GeometryManager.hh" |
---|
| 82 | |
---|
| 83 | // Open geometry for the physical volume to be modified ... |
---|
| 84 | // |
---|
| 85 | G4GeometryManager::OpenGeometry(physCalor); |
---|
| 86 | |
---|
| 87 | // Modify dimension of the solid ... |
---|
| 88 | // |
---|
| 89 | physCalor->GetLogicalVolume()->GetSolid()->SetXHalfLength(12.5*cm); |
---|
| 90 | |
---|
| 91 | // Close geometry for the portion modified ... |
---|
| 92 | // |
---|
| 93 | G4GeometryManager::CloseGeometry(physCalor); |
---|
| 94 | </programlisting> |
---|
| 95 | </example> |
---|
| 96 | </para> |
---|
| 97 | |
---|
| 98 | <para> |
---|
| 99 | If the existing geometry setup is modified locally in more than |
---|
| 100 | one place, it may be convenient to apply such a technique only |
---|
| 101 | once, by specifying a physical volume on top of the hierarchy |
---|
| 102 | (subtree) containing all changed portions of the setup. |
---|
| 103 | </para> |
---|
| 104 | |
---|
| 105 | <para> |
---|
| 106 | An alternative solution for dealing with dynamic geometries is |
---|
| 107 | to specify NOT to apply optimisation for the subtree affected by |
---|
| 108 | the change and apply the general solution of invoking the |
---|
| 109 | <literal>G4RunManager</literal>. In this case, a performance penalty at |
---|
| 110 | run-time may be observed (depending on the complexity of the |
---|
| 111 | not-optimised subtree), considering that, without optimisation, |
---|
| 112 | intersections to all volumes in the subtree will be explicitely |
---|
| 113 | computed each time. |
---|
| 114 | </para> |
---|
| 115 | |
---|
| 116 | </sect2> |
---|