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