1 | <html> |
---|
2 | <head> |
---|
3 | <title>ADG: Geometry</title> |
---|
4 | </head> |
---|
5 | |
---|
6 | <!-- Changed by: Gabriele Cosmo, 18-Apr-2005 --> |
---|
7 | <!-- $Id: geomNav.html,v 1.5 2006/11/24 20:18:30 asaim Exp $ --> |
---|
8 | <!-- $Name: $ --> |
---|
9 | <body> |
---|
10 | <table WIDTH="100%"><TR> |
---|
11 | <td> |
---|
12 | <a href="../../../../Overview/html/index.html"> |
---|
13 | <IMG SRC="../../../../resources/html/IconsGIF/Overview.gif" ALT="Overview"></a> |
---|
14 | <a href="geometry.html"> |
---|
15 | <IMG SRC="../../../../resources/html/IconsGIF/Contents.gif" ALT="Contents"></a> |
---|
16 | <a href="geomReflection.html"> |
---|
17 | <IMG SRC="../../../../resources/html/IconsGIF/Previous.gif" ALT="Previous"></a> |
---|
18 | <a href="geomEditor.html"> |
---|
19 | <IMG SRC="../../../../resources/html/IconsGIF/Next.gif" ALT="Next"></a> |
---|
20 | </td> |
---|
21 | <td ALIGN="Right"> |
---|
22 | <font SIZE="-1" COLOR="#238E23"> |
---|
23 | <b>Geant4 User's Guide</b> |
---|
24 | <br> |
---|
25 | <b>For Application Developers</b> |
---|
26 | <br> |
---|
27 | <b>Geometry</b> |
---|
28 | </font> |
---|
29 | </td> |
---|
30 | </tr></table> |
---|
31 | <br><br> |
---|
32 | |
---|
33 | <a name="4.1.8"> |
---|
34 | <h2>4.1.8 The Geometry Navigator</h2></a> |
---|
35 | |
---|
36 | <p> |
---|
37 | Navigation through the geometry at tracking time is implemented by the class |
---|
38 | <tt>G4Navigator</tt>. The navigator is used to locate points in the geometry |
---|
39 | and compute distances to geometry boundaries. At tracking time, the navigator |
---|
40 | is intended to be the only point of interaction with tracking.<br> |
---|
41 | |
---|
42 | Internally, the G4Navigator has several private helper/utility classes: |
---|
43 | <ul> |
---|
44 | <li><b>G4NavigationHistory</b> - stores the compounded transformations, |
---|
45 | replication/parameterisation information, and volume pointers at each |
---|
46 | level of the hierarchy to the current location. The volume types |
---|
47 | at each level are also stored - whether normal (placement), |
---|
48 | replicated or parameterised.</li> |
---|
49 | <li><b>G4NormalNavigation</b> - provides location & distance computation |
---|
50 | functions for geometries containing 'placement' volumes, with no voxels. |
---|
51 | </li> |
---|
52 | <li><b>G4VoxelNavigation</b> - provides location and distance computation |
---|
53 | functions for geometries containing 'placement' physical volumes with |
---|
54 | voxels. Internally a stack of voxel information is maintained. Private |
---|
55 | functions allow for isotropic distance computation to voxel boundaries |
---|
56 | and for computation of the 'next voxel' in a specified direction.</li> |
---|
57 | <li><b>G4ParameterisedNavigation</b> - provides location and distance |
---|
58 | computation functions for geometries containing parameterised volumes |
---|
59 | with voxels. Voxel information is maintained similarly to |
---|
60 | <tt>G4VoxelNavigation</tt>, but computation can also be simpler by |
---|
61 | adopting voxels to be one level deep only (<I>unrefined</I>, or 1D |
---|
62 | optimisation)</li> |
---|
63 | <li><b>G4ReplicaNavigation</b> - provides location and distance computation |
---|
64 | functions for replicated volumes.</li> |
---|
65 | </ul> |
---|
66 | In addition, the navigator maintains a set of flags for exiting/entry |
---|
67 | optimisation. A navigator is not a singleton class; this is mainly to |
---|
68 | allow a design extension in future (e.g geometrical event biasing). |
---|
69 | </p> |
---|
70 | |
---|
71 | <a name="4.1.8.1"> |
---|
72 | <h3>4.1.8.1 Navigation and Tracking</h3></a> |
---|
73 | |
---|
74 | <p> |
---|
75 | The main functions required for tracking in the geometry are described below. |
---|
76 | Additional functions are provided to return the net transformation of volumes |
---|
77 | and for the creation of touchables. None of the functions implicitly requires |
---|
78 | that the geometry be described hierarchically. |
---|
79 | <ul> |
---|
80 | <li><b>SetWorldVolume()</b><br> |
---|
81 | Sets the first volume in the hierarchy. It must be unrotated and |
---|
82 | untranslated from the origin.</li> |
---|
83 | <li><b>LocateGlobalPointAndSetup()</b><br> |
---|
84 | Locates the volume containing the specified global point. This |
---|
85 | involves a traverse of the hierarchy, requiring the computation of |
---|
86 | compound transformations, testing replicated and parameterised volumes |
---|
87 | (etc). To improve efficiency this search may be performed relative |
---|
88 | to the last, and this is the recommended way of calling the |
---|
89 | function. A 'relative' search may be used for the first call of the |
---|
90 | function which will result in the search defaulting to a search from |
---|
91 | the root node of the hierarchy. |
---|
92 | Searches may also be performed using a <tt>G4TouchableHistory</tt>.</li> |
---|
93 | <li><b>LocateGlobalPointAndUpdateTouchableHandle()</b><br> |
---|
94 | First, search the geometrical hierarchy like the above method |
---|
95 | <tt>LocateGlobalPointAndSetup()</tt>. Then use the volume found and its |
---|
96 | navigation history to update the touchable.</li> |
---|
97 | <li><B>ComputeStep()</B><BR> |
---|
98 | Computes the distance to the next boundary intersected along the |
---|
99 | specified unit direction from a specified point. The point must be |
---|
100 | have been located prior to calling <tt>ComputeStep()</tt>.<BR> |
---|
101 | When calling <tt>ComputeStep()</tt>, a proposed physics step is passed. |
---|
102 | If it can be determined that the first intersection lies at or beyond that |
---|
103 | distance then <tt>kInfinity</tt> is returned. In any case, if the returned |
---|
104 | step is greater than the physics step, the physics step must be taken.</li> |
---|
105 | <li><B>SetGeometricallyLimitedStep()</B><BR> |
---|
106 | Informs the navigator that the last computed step was taken in its |
---|
107 | entirety. This enables entering/exiting optimisation, and should be |
---|
108 | called prior to calling <tt>LocateGlobalPointAndSetup()</tt>.</li> |
---|
109 | <li><b>CreateTouchableHistory()</b><br> |
---|
110 | Creates a <tt>G4TouchableHistory</tt> object, for which the caller has |
---|
111 | deletion responsibility. The 'touchable' volume is the volume returned |
---|
112 | by the last Locate operation. The object includes a copy of the current |
---|
113 | NavigationHistory, enabling the efficient relocation of points |
---|
114 | in/close to the current volume in the hierarchy.</li> |
---|
115 | </ul> |
---|
116 | As stated previously, the navigator makes use of utility classes to |
---|
117 | perform location and step computation functions. The different navigation |
---|
118 | utilities manipulate the <tt>G4NavigationHistory</tt> object.<BR> |
---|
119 | In <tt>LocateGlobalPointAndSetup()</tt> the process of locating a |
---|
120 | point breaks down into three main stages - optimisation, |
---|
121 | determination that the point is contained with a subtree (mother and |
---|
122 | daughters), and determination of the actual containing daughter. The |
---|
123 | latter two can be thought of as scanning first 'up' the hierarchy |
---|
124 | until a volume that is guaranteed to contain the point is found, and |
---|
125 | then scanning 'down' until the actual volume that contains the point |
---|
126 | is found.<BR> |
---|
127 | In <tt>ComputeStep()</tt> three types of computation are treated |
---|
128 | depending on the current containing volume: |
---|
129 | <ul> |
---|
130 | <li>The volume contains normal (placement) daughters (or none)</li> |
---|
131 | <li>The volume contains a single parameterised volume object, |
---|
132 | representing many volumes</li> |
---|
133 | <li>The volume is a replica and contains normal (placement) daughters</li> |
---|
134 | </ul> |
---|
135 | </P> |
---|
136 | |
---|
137 | <a name="4.1.8.2"> |
---|
138 | <h3>4.1.8.2 Using the navigator to locate points</h3></a> |
---|
139 | |
---|
140 | <P> |
---|
141 | More than one navigator objects can be created inside an application; these |
---|
142 | navigators can act independently for different purposes. The main navigator |
---|
143 | which is <i>activated</i> automatically at the startup of a simulation program |
---|
144 | is the navigator used for the <i>tracking</i> and attached the world volume |
---|
145 | of the main tracking (or <i>mass</i>) geometry.<br> |
---|
146 | The navigator for tracking can be retrieved at any state of the application |
---|
147 | by messagging the <tt>G4TransportationManager</tt>: |
---|
148 | <pre> |
---|
149 | G4Navigator* tracking_navigator = |
---|
150 | G4TransportationManager::GetInstance()->GetNavigatorForTracking(); |
---|
151 | </pre> |
---|
152 | The navigator for tracking also retains all the information of the current |
---|
153 | history of volumes transversed at a precise moment of the tracking during a |
---|
154 | run. Therefore, if the navigator for tracking is used during tracking for |
---|
155 | locating a generic point in the tree of volumes, the actual particle gets |
---|
156 | also -relocated- in the specified position and tracking will be of course |
---|
157 | affected !<br> |
---|
158 | In order to avoid the problem above and provide information about location |
---|
159 | of a point without affecting the tracking, it is suggested to either use an |
---|
160 | alternative <tt>G4Navigator</tt> object (which can then be assigned to the |
---|
161 | world-volume), or access the information through the step. |
---|
162 | </P> |
---|
163 | |
---|
164 | <P> |
---|
165 | <b>Using the 'step' to retrieve geometrical information</b> |
---|
166 | </P> |
---|
167 | <P> |
---|
168 | During the tracking run, geometrical information can be retrieved through |
---|
169 | the touchable handle associated to the current step. For example, to identify |
---|
170 | the exact copy-number of a specific physical volume in the mass geometry, |
---|
171 | one should do the following: |
---|
172 | <pre> |
---|
173 | // Given the pointer to the step object ... |
---|
174 | // |
---|
175 | G4Step* aStep = ..; |
---|
176 | |
---|
177 | // ... retrieve the 'pre-step' point |
---|
178 | // |
---|
179 | G4StepPoint* preStepPoint = aStep->GetPreStepPoint(); |
---|
180 | |
---|
181 | // ... retrieve a touchable handle and access to the information |
---|
182 | // |
---|
183 | G4TouchableHandle theTouchable = preStepPoint->GetTouchableHandle(); |
---|
184 | G4int copyNo = theTouchable->GetCopyNumber(); |
---|
185 | G4int motherCopyNo = theTouchable->GetCopyNumber(1); |
---|
186 | </pre> |
---|
187 | To determine the exact position in global coordinates in the mass geometry |
---|
188 | and convert to local coordinates (local to the current volume): |
---|
189 | <pre> |
---|
190 | G4ThreeVector worldPosition = preStepPoint->GetPosition(); |
---|
191 | G4ThreeVector localPosition = theTouchable->GetHistory()-> |
---|
192 | GetTopTransform().TransformPoint(worldPosition); |
---|
193 | </pre> |
---|
194 | </P> |
---|
195 | |
---|
196 | <P> |
---|
197 | <b>Using an alternative navigator to locate points</b> |
---|
198 | </P> |
---|
199 | <P> |
---|
200 | In order to know (when in the <i>idle</i> state of the application) in which |
---|
201 | physical volume a given point is located in the detector geometry, it is |
---|
202 | necessary to create an alternative navigator object first and assign it to |
---|
203 | the world volume: |
---|
204 | <pre> |
---|
205 | G4Navigator* aNavigator = new G4Navigator(); |
---|
206 | aNavigator->SetWorldVolume(worldVolumePointer); |
---|
207 | </pre> |
---|
208 | Then, locate the point <tt>myPoint</tt> (defined in global coordinates), |
---|
209 | retrieve a <i>touchable handle</i> and do whatever you need with it: |
---|
210 | <pre> |
---|
211 | aNavigator->LocateGlobalPointAndSetup(myPoint); |
---|
212 | G4TouchableHistoryHandle aTouchable = |
---|
213 | aNavigator->CreateTouchableHistoryHandle(); |
---|
214 | |
---|
215 | // Do whatever you need with it ... |
---|
216 | // ... convert point in local coordinates (local to the current volume) |
---|
217 | // |
---|
218 | G4ThreeVector localPosition = aTouchable->GetHistory()-> |
---|
219 | GetTopTransform().TransformPoint(myPoint); |
---|
220 | |
---|
221 | // ... convert back to global coordinates system |
---|
222 | G4ThreeVector globalPosition = aTouchable->GetHistory()-> |
---|
223 | GetTopTransform().Inverse().TransformPoint(localPosition); |
---|
224 | </pre> |
---|
225 | If outside of the tracking run and given a generic local position (local to a |
---|
226 | given volume in the geometry tree), it is -not- possible to determine a priori |
---|
227 | its global position and convert it to the global coordinates system. |
---|
228 | The reason for this is rather simple, nobody can guarantee that the given |
---|
229 | (local) point is located in the right -copy- of the physical volume ! |
---|
230 | In order to retrieve this information, some extra knowledge related to the |
---|
231 | absolute position of the physical volume is required first, i.e. one should |
---|
232 | first determine a global point belonging to that volume, eventually making |
---|
233 | a dedicated scan of the geometry tree through a dedicated <tt>G4Navigator</tt> |
---|
234 | object and then apply the method above after having created the touchable for |
---|
235 | it. |
---|
236 | </P> |
---|
237 | |
---|
238 | <a name="4.1.8.3"> |
---|
239 | <h3>4.1.8.3 Navigation in parallel geometries</h3></a> |
---|
240 | |
---|
241 | <P> |
---|
242 | Since release 8.2 of Geant4, it is possible to define geometry trees which |
---|
243 | are <i>parallel</i> to the tracking geometry and having them assigned to |
---|
244 | navigator objects that transparently communicate in sync with the normal |
---|
245 | tracking geometry. |
---|
246 | </P> |
---|
247 | <P> |
---|
248 | Parallel geometries can be defined for several uses (fast shower |
---|
249 | parameterisation, geometrical biasing, particle scoring, readout |
---|
250 | geometries, etc ...) and can <i>overlap</i> with the mass geometry defined |
---|
251 | for the tracking. The <i>parallel</i> transportation will be activated only |
---|
252 | after the registration of the parallel geometry in the detector description |
---|
253 | setup; see Section <a href="parallelWorld.html">4.7</a> for how to define a parallel |
---|
254 | geometry and register it to the run-manager.<br> |
---|
255 | The <tt>G4TransportationManager</tt> provides all the utilities to verify, |
---|
256 | retrieve and activate the navigators associated to the various parallel |
---|
257 | geometries defined. |
---|
258 | </P> |
---|
259 | |
---|
260 | <a name="4.1.8.4"> |
---|
261 | <h3>4.1.8.4 Run-time commands</h3></a> |
---|
262 | |
---|
263 | <P> |
---|
264 | When running in <i>verbose</i> mode (i.e. the default, <TT>G4VERBOSE</TT> |
---|
265 | set while installing the Geant4 kernel libraries), the navigator provides |
---|
266 | a few commands to control its behavior. It is possible to select different |
---|
267 | verbosity levels (up to 5), with the command: |
---|
268 | <pre> |
---|
269 | geometry/navigator/verbose [verbose_level] |
---|
270 | </pre> |
---|
271 | or to force the navigator to run in <I>check</I> mode: |
---|
272 | <pre> |
---|
273 | geometry/navigator/check_mode [true/false] |
---|
274 | </pre> |
---|
275 | The latter will force more strict and less tolerant checks in step/safety |
---|
276 | computation to verify the correctness of the solids' response in the |
---|
277 | geometry.<br> |
---|
278 | |
---|
279 | By combining <i>check_mode</i> with verbosity level-1, additional verbosity |
---|
280 | checks on the response from the solids can be activated. |
---|
281 | <p></p> |
---|
282 | |
---|
283 | <hr> |
---|
284 | <a href="../../../../Authors/html/subjectsToAuthors.html"> |
---|
285 | <i>About the authors</a></i> </P> |
---|
286 | |
---|
287 | </body> |
---|
288 | </html> |
---|