[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.PhysVol"> |
---|
| 12 | <title> |
---|
| 13 | Physical Volumes |
---|
| 14 | </title> |
---|
| 15 | |
---|
| 16 | <para> |
---|
| 17 | Physical volumes represent the spatial positioning of the |
---|
| 18 | volumes describing the detector elements. Several techniques can be |
---|
| 19 | used. They range from the simple placement of a single copy to the |
---|
| 20 | repeated positioning using either a simple linear formula or a user |
---|
| 21 | specified function. |
---|
| 22 | </para> |
---|
| 23 | |
---|
| 24 | <para> |
---|
| 25 | The simple placement involves the definition of a transformation |
---|
| 26 | matrix for the volume to be positioned. Repeated positioning is |
---|
| 27 | defined using the number of times a volume should be replicated at |
---|
| 28 | a given distance along a given direction. Finally it is possible to |
---|
| 29 | define a parameterised formula to specify the position of multiple |
---|
| 30 | copies of a volume. Details about these methods are given |
---|
| 31 | below. |
---|
| 32 | </para> |
---|
| 33 | |
---|
| 34 | <para> |
---|
| 35 | <emphasis role="bold">Note</emphasis> - For geometries which vary between runs and for |
---|
| 36 | which components of the old geometry setup are explicitely |
---|
| 37 | -deleted-, it is required to consider the proper order of deletion |
---|
| 38 | (which is the exact inverse of the actual construction, i.e., first |
---|
| 39 | delete physical volumes and then logical volumes). Deleting a |
---|
| 40 | logical volume does NOT delete its daughter volumes. |
---|
| 41 | </para> |
---|
| 42 | |
---|
| 43 | <para> |
---|
| 44 | It is not necessary to delete the geometry setup at the end of a |
---|
| 45 | job, the system will take care to free the volume and solid stores |
---|
| 46 | at the end of the job. The user has to take care of the deletion of |
---|
| 47 | any additional transformation or rotation matrices allocated |
---|
| 48 | dinamically in his/her own application. |
---|
| 49 | </para> |
---|
| 50 | |
---|
| 51 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 52 | <sect3 id="sect.Geom.PhysVol.PlaceSingle"> |
---|
| 53 | <title> |
---|
| 54 | Placements: single positioned copy |
---|
| 55 | </title> |
---|
| 56 | |
---|
| 57 | <para> |
---|
| 58 | In this case, the Physical Volume is created by associating a |
---|
| 59 | Logical Volume with a Rotation Matrix and a Translation vector. The |
---|
| 60 | Rotation Matrix represents the rotation of the reference frame of |
---|
| 61 | the considered volume relatively to its mother volume's reference |
---|
| 62 | frame. The Translation Vector represents the translation of the |
---|
| 63 | current volume in the reference frame of its mother volume. |
---|
| 64 | </para> |
---|
| 65 | |
---|
| 66 | <para> |
---|
| 67 | Transformations including reflections are not allowed. |
---|
| 68 | </para> |
---|
| 69 | |
---|
| 70 | <para> |
---|
| 71 | To create a Placement one must construct it using: |
---|
| 72 | |
---|
| 73 | <informalexample> |
---|
| 74 | <programlisting> |
---|
| 75 | G4PVPlacement( G4RotationMatrix* pRot, |
---|
| 76 | const G4ThreeVector& tlate, |
---|
| 77 | G4LogicalVolume* pCurrentLogical, |
---|
| 78 | const G4String& pName, |
---|
| 79 | G4LogicalVolume* pMotherLogical, |
---|
| 80 | G4bool pMany, |
---|
| 81 | G4int pCopyNo, |
---|
| 82 | G4bool pSurfChk=false ) |
---|
| 83 | </programlisting> |
---|
| 84 | </informalexample> |
---|
| 85 | |
---|
| 86 | where: |
---|
| 87 | |
---|
| 88 | <informaltable> |
---|
| 89 | <tgroup cols="2"> |
---|
| 90 | <tbody> |
---|
| 91 | <row> |
---|
| 92 | <entry> |
---|
| 93 | <literal>pRot</literal> |
---|
| 94 | </entry> |
---|
| 95 | <entry> |
---|
| 96 | Rotation with respect to its mother volume |
---|
| 97 | </entry> |
---|
| 98 | </row> |
---|
| 99 | <row> |
---|
| 100 | <entry> |
---|
| 101 | <literal>tlate</literal> |
---|
| 102 | </entry> |
---|
| 103 | <entry> |
---|
| 104 | Translation with respect to its mother volume |
---|
| 105 | </entry> |
---|
| 106 | </row> |
---|
| 107 | <row> |
---|
| 108 | <entry> |
---|
| 109 | <literal>pCurrentLogical</literal> |
---|
| 110 | </entry> |
---|
| 111 | <entry> |
---|
| 112 | The associated Logical Volume |
---|
| 113 | </entry> |
---|
| 114 | </row> |
---|
| 115 | <row> |
---|
| 116 | <entry> |
---|
| 117 | <literal>pName</literal> |
---|
| 118 | </entry> |
---|
| 119 | <entry> |
---|
| 120 | String identifier for this placement |
---|
| 121 | </entry> |
---|
| 122 | </row> |
---|
| 123 | <row> |
---|
| 124 | <entry> |
---|
| 125 | <literal>pMotherLogical</literal> |
---|
| 126 | </entry> |
---|
| 127 | <entry> |
---|
| 128 | The associated mother volume |
---|
| 129 | </entry> |
---|
| 130 | </row> |
---|
| 131 | <row> |
---|
| 132 | <entry> |
---|
| 133 | <literal>pMany</literal> |
---|
| 134 | </entry> |
---|
| 135 | <entry> |
---|
| 136 | For future use. Can be set to false |
---|
| 137 | </entry> |
---|
| 138 | </row> |
---|
| 139 | <row> |
---|
| 140 | <entry> |
---|
| 141 | <literal>pCopyNo</literal> |
---|
| 142 | </entry> |
---|
| 143 | <entry> |
---|
| 144 | Integer which identifies this placement |
---|
| 145 | </entry> |
---|
| 146 | </row> |
---|
| 147 | <row> |
---|
| 148 | <entry> |
---|
| 149 | <literal>pSurfChk</literal> |
---|
| 150 | </entry> |
---|
| 151 | <entry> |
---|
| 152 | if true activates check for overlaps with existing volumes |
---|
| 153 | </entry> |
---|
| 154 | </row> |
---|
| 155 | </tbody> |
---|
| 156 | </tgroup> |
---|
| 157 | </informaltable> |
---|
| 158 | </para> |
---|
| 159 | |
---|
| 160 | <para> |
---|
| 161 | Care must be taken because the rotation matrix is not copied by |
---|
| 162 | a <literal>G4PVPlacement</literal>. So the user must not modify it after |
---|
| 163 | creating a Placement that uses it. However the same rotation matrix |
---|
| 164 | can be re-used for many volumes. |
---|
| 165 | </para> |
---|
| 166 | |
---|
| 167 | <para> |
---|
[1211] | 168 | Currently Boolean operations are not implemented at the level of |
---|
[904] | 169 | physical volume. So <literal>pMany</literal> must be false. However, an |
---|
[1211] | 170 | alternative implementation of Boolean operations exists. In this |
---|
[904] | 171 | approach a solid can be created from the union, intersection or |
---|
| 172 | subtraction of two solids. See <xref linkend="sect.Geom.Solids.BoolOp" /> |
---|
[1211] | 173 | above for an explanation of this. |
---|
[904] | 174 | </para> |
---|
| 175 | |
---|
| 176 | <para> |
---|
| 177 | The mother volume must be specified for all volumes |
---|
| 178 | <emphasis>except</emphasis> the world volume. |
---|
| 179 | </para> |
---|
| 180 | |
---|
| 181 | <para> |
---|
| 182 | An alternative way to specify a Placement utilizes a different |
---|
| 183 | method to place the volume. The solid itself is moved by rotating |
---|
| 184 | and translating it to bring it into the system of coordinates of |
---|
| 185 | the mother volume. This <emphasis>active</emphasis> method can be utilized using |
---|
| 186 | the following constructor: |
---|
| 187 | |
---|
| 188 | <informalexample> |
---|
| 189 | <programlisting> |
---|
| 190 | G4PVPlacement( G4Transform3D solidTransform, |
---|
| 191 | G4LogicalVolume* pCurrentLogical, |
---|
| 192 | const G4String& pName, |
---|
| 193 | G4LogicalVolume* pMotherLogical, |
---|
| 194 | G4bool pMany, |
---|
| 195 | G4int pCopyNo, |
---|
| 196 | G4bool pSurfChk=false ) |
---|
| 197 | </programlisting> |
---|
| 198 | </informalexample> |
---|
| 199 | </para> |
---|
| 200 | |
---|
| 201 | <para> |
---|
| 202 | An alternative method to specify the mother volume is to specify |
---|
| 203 | its placed physical volume. It can be used in either of the above |
---|
| 204 | methods of specifying the placement's position and rotation. The |
---|
| 205 | effect will be exactly the same as for using the mother logical |
---|
| 206 | volume. |
---|
| 207 | </para> |
---|
| 208 | |
---|
| 209 | <para> |
---|
| 210 | Note that a Placement Volume can still represent multiple |
---|
| 211 | detector elements. This can happen if several copies exist of the |
---|
| 212 | mother logical volume. Then different detector elements will belong |
---|
| 213 | to different branches of the tree of the hierarchy of geometrical |
---|
| 214 | volumes. |
---|
| 215 | </para> |
---|
| 216 | |
---|
| 217 | </sect3> |
---|
| 218 | |
---|
| 219 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 220 | <sect3 id="sect.Geom.PhysVol.RepeatVol"> |
---|
| 221 | <title> |
---|
| 222 | Repeated volumes |
---|
| 223 | </title> |
---|
| 224 | |
---|
| 225 | <para> |
---|
| 226 | In this case, a single Physical Volume represents multiple copies |
---|
| 227 | of a volume within its mother volume, allowing to save memory. This |
---|
| 228 | is normally done when the volumes to be positioned follow a well |
---|
| 229 | defined rotational or translational symmetry along a Cartesian or |
---|
| 230 | cylindrical coordinate. The Repeated Volumes technique is available |
---|
| 231 | for volumes described by CSG solids. |
---|
| 232 | </para> |
---|
| 233 | |
---|
| 234 | <!-- ******* Bridgehead ******* --> |
---|
| 235 | <bridgehead renderas='sect4'> |
---|
| 236 | Replicas: |
---|
| 237 | </bridgehead> |
---|
| 238 | |
---|
| 239 | <para> |
---|
| 240 | Replicas are <emphasis>repeated volumes</emphasis> in the case when the |
---|
| 241 | multiple copies of the volume are all identical. The coordinate |
---|
| 242 | axis and the number of replicas need to be specified for the |
---|
| 243 | program to compute at run time the transformation matrix |
---|
| 244 | corresponding to each copy. |
---|
| 245 | |
---|
| 246 | <informalexample> |
---|
| 247 | <programlisting> |
---|
| 248 | G4PVReplica( const G4String& pName, |
---|
| 249 | G4LogicalVolume* pCurrentLogical, |
---|
| 250 | G4LogicalVolume* pMotherLogical, // OR G4VPhysicalVolume* |
---|
| 251 | const EAxis pAxis, |
---|
| 252 | const G4int nReplicas, |
---|
| 253 | const G4double width, |
---|
| 254 | const G4double offset=0 ) |
---|
| 255 | </programlisting> |
---|
| 256 | </informalexample> |
---|
| 257 | |
---|
| 258 | where: |
---|
| 259 | |
---|
| 260 | <informaltable> |
---|
| 261 | <tgroup cols="2"> |
---|
| 262 | <tbody> |
---|
| 263 | <row> |
---|
| 264 | <entry> |
---|
| 265 | <literal>pName</literal> |
---|
| 266 | </entry> |
---|
| 267 | <entry> |
---|
| 268 | String identifier for the replicated volume |
---|
| 269 | </entry> |
---|
| 270 | </row> |
---|
| 271 | <row> |
---|
| 272 | <entry> |
---|
| 273 | <literal>pCurrentLogical</literal> |
---|
| 274 | </entry> |
---|
| 275 | <entry> |
---|
| 276 | The associated Logical Volume |
---|
| 277 | </entry> |
---|
| 278 | </row> |
---|
| 279 | <row> |
---|
| 280 | <entry> |
---|
| 281 | <literal>pMotherLogical</literal> |
---|
| 282 | </entry> |
---|
| 283 | <entry> |
---|
| 284 | The associated mother volume |
---|
| 285 | </entry> |
---|
| 286 | </row> |
---|
| 287 | <row> |
---|
| 288 | <entry> |
---|
| 289 | <literal>pAxis</literal> |
---|
| 290 | </entry> |
---|
| 291 | <entry> |
---|
| 292 | The axis along with the replication is applied |
---|
| 293 | </entry> |
---|
| 294 | </row> |
---|
| 295 | <row> |
---|
| 296 | <entry> |
---|
| 297 | <literal>nReplicas</literal> |
---|
| 298 | </entry> |
---|
| 299 | <entry> |
---|
| 300 | The number of replicated volumes |
---|
| 301 | </entry> |
---|
| 302 | </row> |
---|
| 303 | <row> |
---|
| 304 | <entry> |
---|
| 305 | <literal>width</literal> |
---|
| 306 | </entry> |
---|
| 307 | <entry> |
---|
| 308 | The width of a single replica along the axis of replication |
---|
| 309 | </entry> |
---|
| 310 | </row> |
---|
| 311 | <row> |
---|
| 312 | <entry> |
---|
| 313 | <literal>offset</literal> |
---|
| 314 | </entry> |
---|
| 315 | <entry> |
---|
| 316 | Possible offset associated to mother offset along the axis of |
---|
| 317 | replication |
---|
| 318 | </entry> |
---|
| 319 | </row> |
---|
| 320 | </tbody> |
---|
| 321 | </tgroup> |
---|
| 322 | </informaltable> |
---|
| 323 | </para> |
---|
| 324 | |
---|
| 325 | <para> |
---|
| 326 | <literal>G4PVReplica</literal> represents <literal>nReplicas</literal> volumes |
---|
| 327 | differing only in their positioning, and completely <emphasis role="bold">filling</emphasis> |
---|
| 328 | the containing mother volume. Consequently if a |
---|
| 329 | <literal>G4PVReplica</literal> is 'positioned' inside a given mother it |
---|
| 330 | <emphasis role="bold">MUST</emphasis> be the mother's only daughter volume. Replica's |
---|
| 331 | correspond to divisions or slices that completely fill the mother |
---|
| 332 | volume and have no offsets. For Cartesian axes, slices are |
---|
| 333 | considered perpendicular to the axis of replication. |
---|
| 334 | </para> |
---|
| 335 | |
---|
| 336 | <para> |
---|
| 337 | The replica's positions are calculated by means of a linear |
---|
| 338 | formula. Replication may occur along: |
---|
| 339 | |
---|
| 340 | <itemizedlist spacing="compact"> |
---|
| 341 | <listitem><para> |
---|
| 342 | <emphasis>Cartesian axes <literal>(kXAxis,kYAxis,kZAxis)</literal></emphasis> |
---|
| 343 | <para> |
---|
| 344 | The replications, of specified width have coordinates of form |
---|
| 345 | <literal>(-width*(nReplicas-1)*0.5+n*width,0,0)</literal> |
---|
| 346 | </para> |
---|
| 347 | <para> |
---|
| 348 | where <literal>n=0.. nReplicas-1</literal> for the case of <literal>kXAxis</literal>, |
---|
| 349 | and are unrotated. |
---|
| 350 | </para> |
---|
| 351 | </para></listitem> |
---|
| 352 | <listitem><para> |
---|
| 353 | <emphasis>Radial axis (cylindrical polar) <literal>(kRho)</literal></emphasis> |
---|
| 354 | <para> |
---|
| 355 | The replications are cons/tubs sections, centred on the origin and |
---|
| 356 | are unrotated. |
---|
| 357 | </para> |
---|
| 358 | <para> |
---|
| 359 | They have radii of <literal>width*n+offset</literal> to |
---|
| 360 | <literal>width*(n+1)+offset</literal> where |
---|
| 361 | <literal>n=0..nReplicas-1</literal> |
---|
| 362 | </para> |
---|
| 363 | </para></listitem> |
---|
| 364 | <listitem><para> |
---|
| 365 | <emphasis>Phi axis (cylindrical polar) <literal>(kPhi)</literal></emphasis> |
---|
| 366 | <para> |
---|
| 367 | The replications are <emphasis>phi sections</emphasis> or |
---|
| 368 | <emphasis>wedges</emphasis>, and of cons/tubs form. |
---|
| 369 | </para> |
---|
| 370 | <para> |
---|
| 371 | They have <literal>phi</literal> of <literal>offset+n*width</literal> to |
---|
| 372 | <literal>offset+(n+1)*width</literal> where |
---|
| 373 | <literal>n=0..nReplicas-1</literal> |
---|
| 374 | </para> |
---|
| 375 | </para></listitem> |
---|
| 376 | </itemizedlist> |
---|
| 377 | </para> |
---|
| 378 | |
---|
| 379 | <para> |
---|
| 380 | The coordinate system of the replicas is at the centre of each |
---|
| 381 | replica for the cartesian axis. For the radial case, the coordinate |
---|
| 382 | system is unchanged from the mother. For the <literal>phi</literal> axis, the |
---|
| 383 | new coordinate system is rotated such that the X axis bisects the |
---|
| 384 | angle made by each wedge, and Z remains parallel to the mother's Z |
---|
| 385 | axis. |
---|
| 386 | </para> |
---|
| 387 | |
---|
| 388 | <para> |
---|
| 389 | The solid associated via the replicas' logical volume should |
---|
| 390 | have the dimensions of the first volume created and must be of the |
---|
| 391 | correct symmetry/type, in order to assist in good |
---|
| 392 | visualisation. |
---|
| 393 | </para> |
---|
| 394 | |
---|
| 395 | <para> |
---|
| 396 | ex. For X axis replicas in a box, the solid should be another box |
---|
| 397 | with the dimensions of the replications. (same Y & Z dimensions |
---|
| 398 | as mother box, X dimension = mother's X dimension/nReplicas). |
---|
| 399 | </para> |
---|
| 400 | |
---|
| 401 | <para> |
---|
| 402 | Replicas may be placed inside other replicas, provided the above |
---|
| 403 | rule is observed. Normal placement volumes may be placed inside |
---|
| 404 | replicas, provided that they do not intersect the mother's or any |
---|
| 405 | previous replica's boundaries. Parameterised volumes may not be |
---|
| 406 | placed inside. |
---|
| 407 | </para> |
---|
| 408 | |
---|
| 409 | <para> |
---|
| 410 | Because of these rules, it is not possible to place any other |
---|
| 411 | volume inside a replication in <literal>radius</literal>. |
---|
| 412 | </para> |
---|
| 413 | |
---|
| 414 | <para> |
---|
| 415 | The world volume <emphasis>cannot</emphasis> act as a replica, therefore it |
---|
| 416 | cannot be sliced. |
---|
| 417 | </para> |
---|
| 418 | |
---|
| 419 | <para> |
---|
| 420 | During tracking, the translation + rotation associated with each |
---|
| 421 | <literal>G4PVReplica</literal> object is modified according to the currently |
---|
| 422 | 'active' replication. The solid is not modified and consequently |
---|
| 423 | has the wrong parameters for the cases of <literal>phi</literal> and |
---|
| 424 | <literal>r</literal> replication and for when the cross-section of the mother |
---|
| 425 | is not constant along the replication. |
---|
| 426 | </para> |
---|
| 427 | |
---|
| 428 | <para> |
---|
| 429 | Example: |
---|
| 430 | |
---|
| 431 | <example id="programlist_Geom.PhysVol_1"> |
---|
| 432 | <title> |
---|
| 433 | An example of simple replicated volumes with <literal>G4PVReplica</literal>. |
---|
| 434 | </title> |
---|
| 435 | <programlisting> |
---|
| 436 | G4PVReplica repX("Linear Array", |
---|
| 437 | pRepLogical, |
---|
| 438 | pContainingMother, |
---|
| 439 | kXAxis, 5, 10*mm); |
---|
| 440 | |
---|
| 441 | G4PVReplica repR("RSlices", |
---|
| 442 | pRepRLogical, |
---|
| 443 | pContainingMother, |
---|
| 444 | kRho, 5, 10*mm, 0); |
---|
| 445 | |
---|
| 446 | G4PVReplica repRZ("RZSlices", |
---|
| 447 | pRepRZLogical, |
---|
| 448 | &repR, |
---|
| 449 | kZAxis, 5, 10*mm); |
---|
| 450 | |
---|
| 451 | G4PVReplica repRZPhi("RZPhiSlices", |
---|
| 452 | pRepRZPhiLogical, |
---|
| 453 | &repRZ, |
---|
| 454 | kPhi, 4, M_PI*0.5*rad, 0); |
---|
| 455 | </programlisting> |
---|
| 456 | </example> |
---|
| 457 | </para> |
---|
| 458 | |
---|
| 459 | <para> |
---|
| 460 | <literal>RepX</literal> is an array of 5 replicas of width 10*mm, |
---|
| 461 | positioned inside and completely filling the volume pointed by |
---|
| 462 | <literal>pContainingMother</literal>. The mother's X length must be |
---|
| 463 | 5*10*mm=50*mm (for example, if the mother's solid were a Box of |
---|
| 464 | half lengths [25,25,25] then the replica's solid must be a box of |
---|
| 465 | half lengths [25,25,5]). |
---|
| 466 | </para> |
---|
| 467 | |
---|
| 468 | <para> |
---|
| 469 | If the containing mother's solid is a tube of radius 50*mm and |
---|
| 470 | half Z length of 25*mm, <literal>RepR</literal> divides the mother tube into |
---|
| 471 | 5 cylinders (hence the solid associated with <literal>pRepRLogical</literal> |
---|
| 472 | must be a tube of radius 10*mm, and half Z length 25*mm); |
---|
| 473 | <literal>repRZ</literal> divides it into 5 shorter cylinders (the solid |
---|
| 474 | associated with <literal>pRepRZLogical</literal> must be a tube of radius |
---|
| 475 | 10*mm, and half Z length 5*mm); finally, <literal>repRZPhi</literal> divides |
---|
| 476 | it into 4 tube segments with full angle of 90 degrees (the solid |
---|
| 477 | associated with <literal>pRepRZPhiLogical</literal> must be a tube segment of |
---|
| 478 | radius 10*mm, half Z length 5*mm and delta phi of |
---|
| 479 | M_PI*0.5*rad). |
---|
| 480 | </para> |
---|
| 481 | |
---|
| 482 | <para> |
---|
| 483 | No further volumes may be placed inside these replicas. To do so |
---|
| 484 | would result in intersecting boundaries due to the <literal>r</literal> |
---|
| 485 | replications. |
---|
| 486 | </para> |
---|
| 487 | |
---|
| 488 | <!-- ******* Bridgehead ******* --> |
---|
| 489 | <bridgehead renderas='sect4'> |
---|
| 490 | Parameterised Volumes: |
---|
| 491 | </bridgehead> |
---|
| 492 | |
---|
| 493 | <para> |
---|
| 494 | Parameterised Volumes are <emphasis>repeated volumes</emphasis> in the case in |
---|
| 495 | which the multiple copies of a volume can be different in size, |
---|
| 496 | solid type, or material. The solid's type, its dimensions, the |
---|
| 497 | material and the transformation matrix can all be parameterised in |
---|
| 498 | function of the copy number, both when a strong symmetry exist and |
---|
| 499 | when it does not. The user implements the desired parameterisation |
---|
| 500 | function and the program computes and updates automatically at run |
---|
| 501 | time the information associated to the Physical Volume. |
---|
| 502 | </para> |
---|
| 503 | |
---|
| 504 | <para> |
---|
| 505 | An example of creating a parameterised volume (by dimension and |
---|
| 506 | position) exists in novice example N02. The implementation is |
---|
| 507 | provided in the two classes <literal>ExN02DetectorConstruction</literal> and |
---|
| 508 | <literal>ExN02ChamberParameterisation</literal>. |
---|
| 509 | </para> |
---|
| 510 | |
---|
| 511 | <para> |
---|
| 512 | To create a parameterised volume, one must first create its |
---|
| 513 | logical volume like <literal>trackerChamberLV</literal> below. Then one must |
---|
| 514 | create his own parameterisation class |
---|
| 515 | (<emphasis>ExN02ChamberParameterisation</emphasis>) and instantiate an object of |
---|
| 516 | this class (<literal>chamberParam</literal>). We will see how to create the |
---|
| 517 | parameterisation below. |
---|
| 518 | |
---|
| 519 | <example id="programlist_Geom.PhysVol_2"> |
---|
| 520 | <title> |
---|
| 521 | An example of Parameterised volumes. |
---|
| 522 | </title> |
---|
| 523 | <programlisting> |
---|
| 524 | //------------------------------ |
---|
| 525 | // Tracker segments |
---|
| 526 | //------------------------------ |
---|
| 527 | // An example of Parameterised volumes |
---|
| 528 | // dummy values for G4Box -- modified by parameterised volume |
---|
| 529 | G4VSolid * solidChamber = |
---|
| 530 | new G4Box("chamberBox", 10.*cm, 10.*cm, 10.*cm); |
---|
| 531 | |
---|
| 532 | G4LogicalVolume * trackerChamberLV |
---|
| 533 | = new G4LogicalVolume(solidChamber, Aluminum, "trackerChamberLV"); |
---|
| 534 | G4VPVParameterisation * chamberParam |
---|
| 535 | = new ExN02ChamberParameterisation( |
---|
| 536 | 6, // NoChambers, |
---|
| 537 | -240.*cm, // Z of centre of first |
---|
| 538 | 80*cm, // Z spacing of centres |
---|
| 539 | 20*cm, // Width Chamber, |
---|
| 540 | 50*cm, // lengthInitial, |
---|
| 541 | trackerSize*2.); // lengthFinal |
---|
| 542 | |
---|
| 543 | G4VPhysicalVolume *trackerChamber_phys |
---|
| 544 | = new G4PVParameterised("TrackerChamber_parameterisedPV", |
---|
| 545 | trackerChamberLV, // Its logical volume |
---|
| 546 | logicTracker, // Mother logical volume |
---|
| 547 | kUndefined, // Allow default voxelising -- no axis |
---|
| 548 | 6, // Number of chambers |
---|
| 549 | chamberParam); // The parameterisation |
---|
| 550 | // "kUndefined" is the suggested choice, giving 3D voxelisation (i.e. along the three |
---|
| 551 | // cartesian axes, as is applied for placements. |
---|
| 552 | // |
---|
| 553 | // Note: In some cases where volume have clear separation along a single axis, |
---|
| 554 | // this axis (eg kZAxis) can be used to choose (force) optimisation only along |
---|
| 555 | // this axis in geometrical calculations. |
---|
| 556 | // When an axis is given it forces the use of one-dimensional voxelisation. |
---|
| 557 | </programlisting> |
---|
| 558 | </example> |
---|
| 559 | </para> |
---|
| 560 | |
---|
| 561 | <para> |
---|
| 562 | The general constructor is: |
---|
| 563 | |
---|
| 564 | <informalexample> |
---|
| 565 | <programlisting> |
---|
| 566 | G4PVParameterised( const G4String& pName, |
---|
| 567 | G4LogicalVolume* pCurrentLogical, |
---|
| 568 | G4LogicalVolume* pMotherLogical, // OR G4VPhysicalVolume* |
---|
| 569 | const EAxis pAxis, |
---|
| 570 | const G4int nReplicas, |
---|
| 571 | G4VPVParameterisation* pParam, |
---|
| 572 | G4bool pSurfChk=false ) |
---|
| 573 | |
---|
| 574 | </programlisting> |
---|
| 575 | </informalexample> |
---|
| 576 | </para> |
---|
| 577 | |
---|
| 578 | <para> |
---|
| 579 | Note that for a parameterised volume the user must always |
---|
| 580 | specify a mother volume. So the world volume can <emphasis>never</emphasis> be a |
---|
| 581 | parameterised volume, nor it can be sliced. The mother volume can |
---|
| 582 | be specified either as a physical or a logical volume. |
---|
| 583 | </para> |
---|
| 584 | |
---|
| 585 | <para> |
---|
| 586 | <literal>pAxis</literal> specifies the tracking optimisation algorithm to |
---|
| 587 | apply: if a valid axis (the axis along which the parameterisation |
---|
| 588 | is performed) is specified, a simple one-dimensional voxelisation |
---|
| 589 | algorithm is applied; if "kUndefined" is specified instead, the |
---|
| 590 | default three-dimensional voxelisation algorithm applied for normal |
---|
| 591 | placements will be activated. In the latter case, more voxels will |
---|
| 592 | be generated, therefore a greater amount of memory will be consumed |
---|
| 593 | by the optimisation algorithm. |
---|
| 594 | </para> |
---|
| 595 | |
---|
| 596 | <para> |
---|
| 597 | <literal>pSurfChk</literal> if <literal>true</literal> activates a check for |
---|
| 598 | overlaps with existing volumes or paramaterised instances. |
---|
| 599 | </para> |
---|
| 600 | |
---|
| 601 | <para> |
---|
| 602 | The parameterisation mechanism associated to a parameterised |
---|
| 603 | volume is defined in the parameterisation class and its methods. |
---|
| 604 | Every parameterisation must create two methods: |
---|
| 605 | |
---|
| 606 | <itemizedlist spacing="compact"> |
---|
| 607 | <listitem><para> |
---|
| 608 | <literal>ComputeTransformation</literal> defines where one of the copies |
---|
| 609 | is placed, |
---|
| 610 | </para></listitem> |
---|
| 611 | <listitem><para> |
---|
| 612 | <literal>ComputeDimensions</literal> defines the size of one copy, and |
---|
| 613 | </para></listitem> |
---|
| 614 | <listitem><para> |
---|
| 615 | a constructor that initializes any member variables that are |
---|
| 616 | required. |
---|
| 617 | </para></listitem> |
---|
| 618 | </itemizedlist> |
---|
| 619 | |
---|
| 620 | <para> |
---|
| 621 | An example is <literal>ExN02ChamberParameterisation</literal> that |
---|
| 622 | parameterises a series of boxes of different sizes |
---|
| 623 | |
---|
| 624 | <example id="programlist_Geom.PhysVol_3"> |
---|
| 625 | <title> |
---|
| 626 | An example of Parameterised boxes of different sizes. |
---|
| 627 | </title> |
---|
| 628 | <programlisting> |
---|
| 629 | class ExN02ChamberParameterisation : public G4VPVParameterisation |
---|
| 630 | { |
---|
| 631 | ... |
---|
| 632 | void ComputeTransformation(const G4int copyNo, |
---|
| 633 | G4VPhysicalVolume *physVol) const; |
---|
| 634 | |
---|
| 635 | void ComputeDimensions(G4Box& trackerLayer, |
---|
| 636 | const G4int copyNo, |
---|
| 637 | const G4VPhysicalVolume *physVol) const; |
---|
| 638 | ... |
---|
| 639 | } |
---|
| 640 | </programlisting> |
---|
| 641 | </example> |
---|
| 642 | </para> |
---|
| 643 | |
---|
| 644 | <para> |
---|
| 645 | These methods works as follows: |
---|
| 646 | </para> |
---|
| 647 | |
---|
| 648 | <para> |
---|
| 649 | The <literal>ComputeTransformation</literal> method is called with a copy |
---|
| 650 | number for the instance of the parameterisation under |
---|
| 651 | consideration. It must compute the transformation for this copy, |
---|
| 652 | and set the physical volume to utilize this transformation: |
---|
| 653 | |
---|
| 654 | <informalexample> |
---|
| 655 | <programlisting> |
---|
| 656 | void ExN02ChamberParameterisation::ComputeTransformation |
---|
| 657 | (const G4int copyNo,G4VPhysicalVolume *physVol) const |
---|
| 658 | { |
---|
| 659 | G4double Zposition= fStartZ + copyNo * fSpacing; |
---|
| 660 | G4ThreeVector origin(0,0,Zposition); |
---|
| 661 | physVol->SetTranslation(origin); |
---|
| 662 | physVol->SetRotation(0); |
---|
| 663 | } |
---|
| 664 | </programlisting> |
---|
| 665 | </informalexample> |
---|
| 666 | </para> |
---|
| 667 | |
---|
| 668 | <para> |
---|
| 669 | Note that the translation and rotation given in this scheme are |
---|
| 670 | those for the frame of coordinates (the <emphasis>passive</emphasis> method). |
---|
| 671 | They are <emphasis role="bold">not</emphasis> for the |
---|
| 672 | <emphasis>active</emphasis> method, in which the |
---|
| 673 | solid is rotated into the mother frame of coordinates. |
---|
| 674 | </para> |
---|
| 675 | |
---|
| 676 | <para> |
---|
| 677 | Similarly the <literal>ComputeDimensions</literal> method is used to set |
---|
| 678 | the size of that copy. |
---|
| 679 | |
---|
| 680 | <informalexample> |
---|
| 681 | <programlisting> |
---|
| 682 | void ExN02ChamberParameterisation::ComputeDimensions |
---|
| 683 | (G4Box & trackerChamber, const G4int copyNo, |
---|
| 684 | const G4VPhysicalVolume * physVol) const |
---|
| 685 | { |
---|
| 686 | G4double halfLength= fHalfLengthFirst + (copyNo-1) * fHalfLengthIncr; |
---|
| 687 | trackerChamber.SetXHalfLength(halfLength); |
---|
| 688 | trackerChamber.SetYHalfLength(halfLength); |
---|
| 689 | trackerChamber.SetZHalfLength(fHalfWidth); |
---|
| 690 | } |
---|
| 691 | </programlisting> |
---|
| 692 | </informalexample> |
---|
| 693 | </para> |
---|
| 694 | |
---|
| 695 | <para> |
---|
| 696 | The user must ensure that the type of the first argument of this |
---|
| 697 | method (in this example <literal>G4Box &</literal>) corresponds to the |
---|
| 698 | type of object the user give to the logical volume of parameterised |
---|
| 699 | physical volume. |
---|
| 700 | </para> |
---|
| 701 | |
---|
| 702 | <para> |
---|
| 703 | More advanced usage allows the user: |
---|
| 704 | |
---|
| 705 | <itemizedlist spacing="compact"> |
---|
| 706 | <listitem><para> |
---|
| 707 | to change the type of solid by creating a <literal>ComputeSolid</literal> |
---|
| 708 | method, or |
---|
| 709 | </para></listitem> |
---|
| 710 | <listitem><para> |
---|
| 711 | to change the material of the volume by creating a |
---|
| 712 | <literal>ComputeMaterial</literal> method. This method can also utilise |
---|
| 713 | information from a parent or other ancestor volume (see the Nested |
---|
| 714 | Parameterisation below.) |
---|
| 715 | </para></listitem> |
---|
| 716 | </itemizedlist> |
---|
| 717 | |
---|
| 718 | for the parameterisation. |
---|
| 719 | </para> |
---|
| 720 | |
---|
| 721 | <para> |
---|
| 722 | Example N07 shows a simple parameterisation by material. A more |
---|
| 723 | complex example is provided in |
---|
| 724 | <literal>examples/extended/medical/DICOM</literal>, where a phantom grid of |
---|
| 725 | cells is built using a parameterisation by material defined through |
---|
| 726 | a map. |
---|
| 727 | </para> |
---|
| 728 | |
---|
| 729 | <note> |
---|
| 730 | <title>Note</title> |
---|
| 731 | <para> |
---|
| 732 | Currently for many cases it is not possible to add |
---|
| 733 | daughter volumes to a parameterised volume. Only parameterised |
---|
| 734 | volumes all of whose solids have the same size are allowed to |
---|
| 735 | contain daughter volumes. When the size or type of solid varies, |
---|
| 736 | adding daughters is not supported. |
---|
| 737 | So the full power of parameterised volumes can be used only for |
---|
| 738 | "leaf" volumes, which contain no other volumes. |
---|
| 739 | </para> |
---|
[1211] | 740 | <para> |
---|
| 741 | A hierarchy of volumes included in a parameterised volume cannot |
---|
| 742 | vary. Therefore, it is not possible to implement a parameterisation |
---|
| 743 | which can modify the hierachy of volumes included inside a specific |
---|
| 744 | parameterised copy. |
---|
| 745 | </para> |
---|
[904] | 746 | </note> |
---|
| 747 | |
---|
| 748 | |
---|
| 749 | <!-- ******* Bridgehead ******* --> |
---|
| 750 | <bridgehead renderas='sect4'> |
---|
| 751 | Advanced parameterisations for 'nested' parameterised volumes |
---|
| 752 | </bridgehead> |
---|
| 753 | |
---|
| 754 | <para> |
---|
| 755 | A new type of parameterisation enables a user to have the |
---|
| 756 | daughter's material also depend on the copy number of the parent |
---|
| 757 | when a parameterised volume (daughter) is located inside another |
---|
| 758 | (parent) repeated volume. The parent volume can be a replica, a |
---|
| 759 | parameterised volume, or a division if the key feature of modifying |
---|
| 760 | its contents is utilised. (Note: a 'nested' parameterisation inside |
---|
| 761 | a placement volume is not supported, because all copies of a |
---|
| 762 | placement volume must be identical at all levels.) |
---|
| 763 | </para> |
---|
| 764 | |
---|
| 765 | <para> |
---|
| 766 | In such a " nested" parameterisation , the user must provide a |
---|
| 767 | <literal>ComputeMaterial</literal> method that utilises the new argument that |
---|
| 768 | represents the touchable history of the parent volume: |
---|
| 769 | |
---|
| 770 | <informalexample> |
---|
| 771 | <programlisting> |
---|
| 772 | // Sample Parameterisation |
---|
| 773 | class SampleNestedParameterisation : public G4VNestedParameterisation |
---|
| 774 | { |
---|
| 775 | public: |
---|
| 776 | // .. other methods ... |
---|
| 777 | // Mandatory method, required and reason for this class |
---|
| 778 | virtual G4Material* ComputeMaterial(G4VPhysicalVolume *currentVol, |
---|
| 779 | const G4int no_lev, |
---|
| 780 | const G4VTouchable *parentTouch); |
---|
| 781 | private: |
---|
| 782 | G4Material *material1, *material2; |
---|
| 783 | }; |
---|
| 784 | </programlisting> |
---|
| 785 | </informalexample> |
---|
| 786 | </para> |
---|
| 787 | |
---|
| 788 | <para> |
---|
| 789 | The implementation of the method can utilise any information |
---|
| 790 | from a parent or other ancestor volume of its parameterised |
---|
| 791 | physical volume, but typically it will use only the copy |
---|
| 792 | number: |
---|
| 793 | |
---|
| 794 | <informalexample> |
---|
| 795 | <programlisting> |
---|
| 796 | G4Material* |
---|
| 797 | SampleNestedParameterisation::ComputeMaterial(G4VPhysicalVolume *currentVol, |
---|
| 798 | const G4int no_lev, |
---|
| 799 | const G4VTouchable *parentTouchable) |
---|
| 800 | { |
---|
| 801 | G4Material *material=0; |
---|
| 802 | |
---|
| 803 | // Get the information about the parent volume |
---|
| 804 | G4int no_parent= parentTouchable->GetReplicaNumber(); |
---|
| 805 | G4int no_total= no_parent + no_lev; |
---|
| 806 | // A simple 'checkerboard' pattern of two materials |
---|
| 807 | if( no_total / 2 == 1 ) material= material1; |
---|
| 808 | else material= material2; |
---|
| 809 | // Set the material to the current logical volume |
---|
| 810 | G4LogicalVolume* currentLogVol= currentVol->GetLogicalVolume(); |
---|
| 811 | currentLogVol->SetMaterial( material ); |
---|
| 812 | return material; |
---|
| 813 | } |
---|
| 814 | </programlisting> |
---|
| 815 | </informalexample> |
---|
| 816 | </para> |
---|
| 817 | |
---|
| 818 | <para> |
---|
| 819 | Nested parameterisations are suitable for the case of regular, |
---|
| 820 | 'voxel' geometries in which a large number of 'equal' volumes are |
---|
| 821 | required, and their only difference is in their material. By |
---|
| 822 | creating two (or more) levels of parameterised physical volumes it |
---|
| 823 | is possible to divide space, while requiring only limited |
---|
| 824 | additional memory for very fine-level optimisation. This provides |
---|
| 825 | fast navigation. Alternative implementations, taking into account |
---|
| 826 | the regular structure of such geometries in navigation are under |
---|
| 827 | study. |
---|
| 828 | </para> |
---|
| 829 | |
---|
| 830 | <!-- ******* Bridgehead ******* --> |
---|
| 831 | <bridgehead renderas='sect4'> |
---|
| 832 | Divisions of Volumes |
---|
| 833 | </bridgehead> |
---|
| 834 | |
---|
| 835 | <para> |
---|
| 836 | Divisions in Geant4 are implemented as a specialized type of |
---|
| 837 | parameterised volumes. |
---|
| 838 | </para> |
---|
| 839 | |
---|
| 840 | <para> |
---|
| 841 | They serve to divide a volume into identical copies along one of |
---|
| 842 | its axes, providing the possibility to define an <emphasis>offset</emphasis>, and |
---|
| 843 | without the limitation that the daugthers have to fill the mother |
---|
| 844 | volume as it is the case for the replicas. In the case, for |
---|
| 845 | example, of a tube divided along its radial axis, the copies are |
---|
| 846 | not strictly identical, but have increasing radii, although their |
---|
| 847 | widths are constant. |
---|
| 848 | </para> |
---|
| 849 | |
---|
| 850 | <para> |
---|
| 851 | To divide a volume it will be necessary to provide: |
---|
| 852 | |
---|
| 853 | <orderedlist spacing="compact"> |
---|
| 854 | <listitem><para> |
---|
| 855 | the axis of division, and |
---|
| 856 | </para></listitem> |
---|
| 857 | <listitem><para> |
---|
| 858 | either |
---|
| 859 | <itemizedlist spacing="compact"> |
---|
| 860 | <listitem><para> |
---|
| 861 | the number of divisions (so that the width of each division |
---|
| 862 | will be automatically calculated), or |
---|
| 863 | </para></listitem> |
---|
| 864 | <listitem><para> |
---|
| 865 | the division width (so that the number of divisions will be |
---|
| 866 | automatically calculated to fill as much of the mother as |
---|
| 867 | possible), or |
---|
| 868 | </para></listitem> |
---|
| 869 | <listitem><para> |
---|
| 870 | both the number of divisions and the division width (this is |
---|
| 871 | especially designed for the case where the copies do not fully fill |
---|
| 872 | the mother). |
---|
| 873 | </para></listitem> |
---|
| 874 | </itemizedlist> |
---|
| 875 | </para></listitem> |
---|
| 876 | </orderedlist> |
---|
| 877 | </para> |
---|
| 878 | |
---|
| 879 | <para> |
---|
| 880 | An <emphasis>offset</emphasis> can be defined so that the first copy will |
---|
| 881 | start at some distance from the mother wall. The dividing copies |
---|
| 882 | will be then distributed to occupy the rest of the volume. |
---|
| 883 | </para> |
---|
| 884 | |
---|
| 885 | <para> |
---|
| 886 | There are three constructors, corresponding to the three input |
---|
| 887 | possibilities described above: |
---|
| 888 | |
---|
| 889 | <itemizedlist spacing="compact"> |
---|
| 890 | <listitem><para> |
---|
| 891 | Giving only the number of divisions: |
---|
| 892 | |
---|
| 893 | <informalexample> |
---|
| 894 | <programlisting> |
---|
| 895 | G4PVDivision( const G4String& pName, |
---|
| 896 | G4LogicalVolume* pCurrentLogical, |
---|
| 897 | G4LogicalVolume* pMotherLogical, |
---|
| 898 | const EAxis pAxis, |
---|
| 899 | const G4int nDivisions, |
---|
| 900 | const G4double offset ) |
---|
| 901 | </programlisting> |
---|
| 902 | </informalexample> |
---|
| 903 | </para></listitem> |
---|
| 904 | <listitem><para> |
---|
| 905 | Giving only the division width: |
---|
| 906 | |
---|
| 907 | <informalexample> |
---|
| 908 | <programlisting> |
---|
| 909 | G4PVDivision( const G4String& pName, |
---|
| 910 | G4LogicalVolume* pCurrentLogical, |
---|
| 911 | G4LogicalVolume* pMotherLogical, |
---|
| 912 | const EAxis pAxis, |
---|
| 913 | const G4double width, |
---|
| 914 | const G4double offset ) |
---|
| 915 | </programlisting> |
---|
| 916 | </informalexample> |
---|
| 917 | </para></listitem> |
---|
| 918 | <listitem><para> |
---|
| 919 | Giving the number of divisions and the division width: |
---|
| 920 | |
---|
| 921 | <informalexample> |
---|
| 922 | <programlisting> |
---|
| 923 | G4PVDivision( const G4String& pName, |
---|
| 924 | G4LogicalVolume* pCurrentLogical, |
---|
| 925 | G4LogicalVolume* pMotherLogical, |
---|
| 926 | const EAxis pAxis, |
---|
| 927 | const G4int nDivisions, |
---|
| 928 | const G4double width, |
---|
| 929 | const G4double offset ) |
---|
| 930 | </programlisting> |
---|
| 931 | </informalexample> |
---|
| 932 | </para></listitem> |
---|
| 933 | </itemizedlist> |
---|
| 934 | |
---|
| 935 | where: |
---|
| 936 | |
---|
| 937 | <informaltable> |
---|
| 938 | <tgroup cols="2"> |
---|
| 939 | <tbody> |
---|
| 940 | <row> |
---|
| 941 | <entry> |
---|
| 942 | <literal>pName</literal> |
---|
| 943 | </entry> |
---|
| 944 | <entry> |
---|
| 945 | String identifier for the replicated volume |
---|
| 946 | </entry> |
---|
| 947 | </row> |
---|
| 948 | <row> |
---|
| 949 | <entry> |
---|
| 950 | <literal>pCurrentLogical</literal> |
---|
| 951 | </entry> |
---|
| 952 | <entry> |
---|
| 953 | The associated Logical Volume |
---|
| 954 | </entry> |
---|
| 955 | </row> |
---|
| 956 | <row> |
---|
| 957 | <entry> |
---|
| 958 | <literal>pMotherLogical</literal> |
---|
| 959 | </entry> |
---|
| 960 | <entry> |
---|
| 961 | The associated mother Logical Volume |
---|
| 962 | </entry> |
---|
| 963 | </row> |
---|
| 964 | <row> |
---|
| 965 | <entry> |
---|
| 966 | <literal>pAxis</literal> |
---|
| 967 | </entry> |
---|
| 968 | <entry> |
---|
| 969 | The axis along which the division is applied |
---|
| 970 | </entry> |
---|
| 971 | </row> |
---|
| 972 | <row> |
---|
| 973 | <entry> |
---|
| 974 | <literal>nDivisions</literal> |
---|
| 975 | </entry> |
---|
| 976 | <entry> |
---|
| 977 | The number of divisions |
---|
| 978 | </entry> |
---|
| 979 | </row> |
---|
| 980 | <row> |
---|
| 981 | <entry> |
---|
| 982 | <literal>width</literal> |
---|
| 983 | </entry> |
---|
| 984 | <entry> |
---|
| 985 | The width of a single division along the axis |
---|
| 986 | </entry> |
---|
| 987 | </row> |
---|
| 988 | <row> |
---|
| 989 | <entry> |
---|
| 990 | <literal>offset</literal> |
---|
| 991 | </entry> |
---|
| 992 | <entry> |
---|
| 993 | Possible offset associated to the mother along the axis of division |
---|
| 994 | </entry> |
---|
| 995 | </row> |
---|
| 996 | </tbody> |
---|
| 997 | </tgroup> |
---|
| 998 | </informaltable> |
---|
| 999 | </para> |
---|
| 1000 | |
---|
| 1001 | <para> |
---|
| 1002 | The parameterisation is calculated automatically using the |
---|
| 1003 | values provided in input. Therefore the dimensions of the solid |
---|
| 1004 | associated with <literal>pCurrentLogical</literal> will not be used, but |
---|
| 1005 | recomputed through the |
---|
| 1006 | <literal>G4VParameterisation::ComputeDimension()</literal> method. |
---|
| 1007 | </para> |
---|
| 1008 | |
---|
| 1009 | <para> |
---|
| 1010 | Since <literal>G4VPVParameterisation</literal> may have different |
---|
| 1011 | <literal>ComputeDimension()</literal> methods for each solid type, the user |
---|
| 1012 | must provide a solid that is of the same type as of the one |
---|
| 1013 | associated to the mother volume. |
---|
| 1014 | </para> |
---|
| 1015 | |
---|
| 1016 | <para> |
---|
| 1017 | As for any replica, the coordinate system of the divisions is |
---|
| 1018 | related to the centre of each division for the cartesian axis. For |
---|
| 1019 | the radial axis, the coordinate system is the same of the mother |
---|
| 1020 | volume. For the phi axis, the new coordinate system is rotated such |
---|
| 1021 | that the X axis bisects the angle made by each wedge, and Z remains |
---|
| 1022 | parallel to the mother's Z axis. |
---|
| 1023 | </para> |
---|
| 1024 | |
---|
| 1025 | <para> |
---|
| 1026 | As divisions are parameterised volumes with constant dimensions, |
---|
| 1027 | they may be placed inside other divisions, except in the case of |
---|
| 1028 | divisions along the radial axis. |
---|
| 1029 | </para> |
---|
| 1030 | |
---|
| 1031 | <para> |
---|
| 1032 | It is also possible to place other volumes inside a volume where a |
---|
| 1033 | division is placed. |
---|
| 1034 | </para> |
---|
| 1035 | |
---|
| 1036 | <para> |
---|
| 1037 | The list of volumes that currently support divisioning and the |
---|
| 1038 | possible division axis are summarised below: |
---|
| 1039 | |
---|
| 1040 | <informaltable> |
---|
| 1041 | <tgroup cols="2"> |
---|
| 1042 | <tbody> |
---|
| 1043 | <row> |
---|
| 1044 | <entry> |
---|
| 1045 | <literal>G4Box</literal> |
---|
| 1046 | </entry> |
---|
| 1047 | <entry> |
---|
| 1048 | <literal>kXAxis</literal>, <literal>kYAxis</literal>, <literal>kZAxis</literal> |
---|
| 1049 | </entry> |
---|
| 1050 | </row> |
---|
| 1051 | <row> |
---|
| 1052 | <entry> |
---|
| 1053 | <literal>G4Tubs</literal> |
---|
| 1054 | </entry> |
---|
| 1055 | <entry> |
---|
| 1056 | <literal>kRho</literal>, <literal>kPhi</literal>, <literal>kZAxis</literal> |
---|
| 1057 | </entry> |
---|
| 1058 | </row> |
---|
| 1059 | <row> |
---|
| 1060 | <entry> |
---|
| 1061 | <literal>G4Cons</literal> |
---|
| 1062 | </entry> |
---|
| 1063 | <entry> |
---|
| 1064 | <literal>kRho</literal>, <literal>kPhi</literal>, <literal>kZAxis</literal> |
---|
| 1065 | </entry> |
---|
| 1066 | </row> |
---|
| 1067 | <row> |
---|
| 1068 | <entry> |
---|
| 1069 | <literal>G4Trd</literal> |
---|
| 1070 | </entry> |
---|
| 1071 | <entry> |
---|
| 1072 | <literal>kXAxis</literal>, <literal>kYAxis</literal>, <literal>kZAxis</literal> |
---|
| 1073 | </entry> |
---|
| 1074 | </row> |
---|
| 1075 | <row> |
---|
| 1076 | <entry> |
---|
| 1077 | <literal>G4Para</literal> |
---|
| 1078 | </entry> |
---|
| 1079 | <entry> |
---|
| 1080 | <literal>kXAxis</literal>, <literal>kYAxis</literal>, <literal>kZAxis</literal> |
---|
| 1081 | </entry> |
---|
| 1082 | </row> |
---|
| 1083 | <row> |
---|
| 1084 | <entry> |
---|
| 1085 | <literal>G4Polycone</literal> |
---|
| 1086 | </entry> |
---|
| 1087 | <entry> |
---|
[1211] | 1088 | <literal>kRho</literal>, <literal>kPhi</literal>, <literal>kZAxis</literal> |
---|
[904] | 1089 | </entry> |
---|
| 1090 | </row> |
---|
| 1091 | <row> |
---|
| 1092 | <entry> |
---|
| 1093 | <literal>G4Polyhedra</literal> |
---|
| 1094 | </entry> |
---|
| 1095 | <entry> |
---|
[1211] | 1096 | <literal>kRho</literal>, <literal>kPhi</literal>, <literal>kZAxis</literal> (*) |
---|
[904] | 1097 | </entry> |
---|
| 1098 | </row> |
---|
| 1099 | </tbody> |
---|
| 1100 | </tgroup> |
---|
| 1101 | </informaltable> |
---|
| 1102 | </para> |
---|
| 1103 | |
---|
| 1104 | |
---|
| 1105 | <para> |
---|
[1211] | 1106 | (*) - <literal>G4Polyhedra</literal>: |
---|
[904] | 1107 | |
---|
| 1108 | <itemizedlist spacing="compact"> |
---|
| 1109 | <listitem><para> |
---|
| 1110 | <literal>kPhi</literal> - the number of divisions has to be the same as |
---|
| 1111 | solid sides, (i.e. <literal>numSides</literal>), the width will |
---|
| 1112 | <emphasis>not</emphasis> be taken into account. |
---|
| 1113 | </para></listitem> |
---|
| 1114 | </itemizedlist> |
---|
| 1115 | </para> |
---|
| 1116 | |
---|
| 1117 | <para> |
---|
| 1118 | In the case of division along <literal>kRho</literal> of <literal>G4Cons</literal>, |
---|
| 1119 | <literal>G4Polycone</literal>, <literal>G4Polyhedra</literal>, if width is provided, it |
---|
| 1120 | is taken as the width at the <literal>-Z</literal> radius; the width at other |
---|
| 1121 | radii will be scaled to this one. |
---|
| 1122 | </para> |
---|
| 1123 | |
---|
| 1124 | <para> |
---|
| 1125 | Examples are given below in listings |
---|
| 1126 | <xref linkend="programlist_Geom.PhysVol_3" /> and |
---|
| 1127 | <xref linkend="programlist_Geom.PhysVol_4" />. |
---|
| 1128 | |
---|
| 1129 | <example id="programlist_Geom.PhysVol_4"> |
---|
| 1130 | <title> |
---|
| 1131 | An example of a box division along different axes, with or without offset. |
---|
| 1132 | </title> |
---|
| 1133 | <programlisting> |
---|
| 1134 | G4Box* motherSolid = new G4Box("motherSolid", 0.5*m, 0.5*m, 0.5*m); |
---|
| 1135 | G4LogicalVolume* motherLog = new G4LogicalVolume(motherSolid, material, "mother",0,0,0); |
---|
| 1136 | G4Para* divSolid = new G4Para("divSolid", 0.512*m, 1.21*m, 1.43*m); |
---|
| 1137 | G4LogicalVolume* childLog = new G4LogicalVolume(divSolid, material, "child",0,0,0); |
---|
| 1138 | |
---|
| 1139 | G4PVDivision divBox1("division along X giving nDiv", |
---|
| 1140 | childLog, motherLog, kXAxis, 5, 0.); |
---|
| 1141 | |
---|
| 1142 | G4PVDivision divBox2("division along X giving width and offset", |
---|
| 1143 | childLog, motherLog, kXAxis, 0.1*m, 0.45*m); |
---|
| 1144 | |
---|
| 1145 | G4PVDivision divBox3("division along X giving nDiv, width and offset", |
---|
| 1146 | childLog, motherLog, kXAxis, 3, 0.1*m, 0.5*m); |
---|
| 1147 | </programlisting> |
---|
| 1148 | </example> |
---|
| 1149 | |
---|
| 1150 | <itemizedlist spacing="compact"> |
---|
| 1151 | <listitem><para> |
---|
| 1152 | <literal>divBox1</literal> is a division of a box along its <literal>X</literal> |
---|
| 1153 | axis in 5 equal copies. Each copy will have a dimension in meters |
---|
| 1154 | of <literal>[0.2, 1., 1.]</literal>. |
---|
| 1155 | </para></listitem> |
---|
| 1156 | <listitem><para> |
---|
| 1157 | <literal>divBox2</literal> is a division of the same box along its |
---|
| 1158 | <literal>X</literal> axis with a width of <literal>0.1</literal> meters and |
---|
| 1159 | an offset of <literal>0.5</literal> meters. As the mother dimension along |
---|
| 1160 | <literal>X</literal> of |
---|
| 1161 | <literal>1</literal> meter (<literal>0.5*m</literal> of halflength), |
---|
| 1162 | the division will |
---|
| 1163 | be sized in total <literal>1 - 0.45 = 0.55</literal> meters. Therefore, |
---|
| 1164 | there's space for 5 copies, the first extending from <literal>-0.05</literal> |
---|
| 1165 | to <literal>0.05</literal> meters in the mother's frame and the last from |
---|
| 1166 | <literal>0.35</literal> to <literal>0.45</literal> meters. |
---|
| 1167 | </para></listitem> |
---|
| 1168 | <listitem><para> |
---|
| 1169 | <literal>divBox3</literal> is a division of the same box along its |
---|
| 1170 | <literal>X</literal> axis in 3 equal copies of width <literal>0.1</literal> |
---|
| 1171 | meters and an offset of <literal>0.5</literal> meters. |
---|
| 1172 | The first copy will extend from |
---|
| 1173 | <literal>0.</literal> to <literal>0.1</literal> meters in the mother's frame |
---|
| 1174 | and the last from <literal>0.2</literal> to <literal>0.3</literal> |
---|
| 1175 | meters. |
---|
| 1176 | </para></listitem> |
---|
| 1177 | </itemizedlist> |
---|
| 1178 | </para> |
---|
| 1179 | |
---|
| 1180 | <example id="programlist_Geom.PhysVol_5"> |
---|
| 1181 | <title> |
---|
| 1182 | An example of division of a polycone. |
---|
| 1183 | </title> |
---|
| 1184 | <programlisting> |
---|
| 1185 | G4double* zPlanem = new G4double[3]; |
---|
| 1186 | zPlanem[0]= -1.*m; |
---|
| 1187 | zPlanem[1]= -0.25*m; |
---|
| 1188 | zPlanem[2]= 1.*m; |
---|
| 1189 | G4double* rInnerm = new G4double[3]; |
---|
| 1190 | rInnerm[0]=0.; |
---|
| 1191 | rInnerm[1]=0.1*m; |
---|
| 1192 | rInnerm[2]=0.5*m; |
---|
| 1193 | G4double* rOuterm = new G4double[3]; |
---|
| 1194 | rOuterm[0]=0.2*m; |
---|
| 1195 | rOuterm[1]=0.4*m; |
---|
| 1196 | rOuterm[2]=1.*m; |
---|
| 1197 | G4Polycone* motherSolid = new G4Polycone("motherSolid", 20.*deg, 180.*deg, |
---|
| 1198 | 3, zPlanem, rInnerm, rOuterm); |
---|
| 1199 | G4LogicalVolume* motherLog = new G4LogicalVolume(motherSolid, material, "mother",0,0,0); |
---|
| 1200 | |
---|
| 1201 | G4double* zPlaned = new G4double[3]; |
---|
| 1202 | zPlaned[0]= -3.*m; |
---|
| 1203 | zPlaned[1]= -0.*m; |
---|
| 1204 | zPlaned[2]= 1.*m; |
---|
| 1205 | G4double* rInnerd = new G4double[3]; |
---|
| 1206 | rInnerd[0]=0.2; |
---|
| 1207 | rInnerd[1]=0.4*m; |
---|
| 1208 | rInnerd[2]=0.5*m; |
---|
| 1209 | G4double* rOuterd = new G4double[3]; |
---|
| 1210 | rOuterd[0]=0.5*m; |
---|
| 1211 | rOuterd[1]=0.8*m; |
---|
| 1212 | rOuterd[2]=2.*m; |
---|
| 1213 | G4Polycone* divSolid = new G4Polycone("divSolid", 0.*deg, 10.*deg, |
---|
| 1214 | 3, zPlaned, rInnerd, rOuterd); |
---|
| 1215 | G4LogicalVolume* childLog = new G4LogicalVolume(divSolid, material, "child",0,0,0); |
---|
| 1216 | |
---|
| 1217 | G4PVDivision divPconePhiW("division along phi giving width and offset", |
---|
| 1218 | childLog, motherLog, kPhi, 30.*deg, 60.*deg); |
---|
| 1219 | |
---|
| 1220 | G4PVDivision divPconeZN("division along Z giving nDiv and offset", |
---|
| 1221 | childLog, motherLog, kZAxis, 2, 0.1*m); |
---|
| 1222 | </programlisting> |
---|
| 1223 | </example> |
---|
| 1224 | |
---|
| 1225 | <itemizedlist spacing="compact"> |
---|
| 1226 | <listitem><para> |
---|
| 1227 | <literal>divPconePhiW</literal> is a division of a polycone along its |
---|
| 1228 | <literal>phi</literal> axis in equal copies of width 30 degrees with an |
---|
| 1229 | offset of 60 degrees. As the mother extends from 0 to 180 degrees, |
---|
| 1230 | there's space for 4 copies. All the copies have a starting angle of |
---|
| 1231 | 20 degrees (as for the mother) and a <literal>phi</literal> extension of 30 |
---|
| 1232 | degrees. They are rotated around the <literal>Z</literal> axis by 60 and 30 |
---|
| 1233 | degrees, so that the first copy will extend from 80 to 110 and the |
---|
| 1234 | last from 170 to 200 degrees. |
---|
| 1235 | </para></listitem> |
---|
| 1236 | <listitem><para> |
---|
| 1237 | <literal>divPconeZN</literal> is a division of the same polycone along |
---|
| 1238 | its <literal>Z</literal> axis. As the mother polycone has two sections, it |
---|
| 1239 | will be divided in two one-section polycones, the first one |
---|
| 1240 | extending from -1 to -0.25 meters, the second from -0.25 to 1 |
---|
| 1241 | meters. Although specified, the offset will not be used. |
---|
| 1242 | </para></listitem> |
---|
| 1243 | </itemizedlist> |
---|
| 1244 | </para> |
---|
| 1245 | |
---|
| 1246 | |
---|
| 1247 | </sect3> |
---|
| 1248 | </sect2> |
---|