source: trunk/documents/UserDoc/UsersGuides/ForApplicationDeveloper/html/Detector/geomPhysical.html @ 1287

Last change on this file since 1287 was 1208, checked in by garnier, 15 years ago

CVS update
File size: 34.4 KB
Line 
1<html>
2<head>
3<title>ADG: Geometry</title>
4</head>
5
6<!-- Changed by: Gabriele Cosmo, 18-Apr-2005 -->
7<!-- $Id: geomPhysical.html,v 1.6 2006/06/09 13:58:03 gcosmo 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="geomLogical.html">
17<IMG SRC="../../../../resources/html/IconsGIF/Previous.gif" ALT="Previous"></a>
18<a href="geomTouch.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.4">
34<h2>4.1.4 Physical Volumes</h2></a>
35
36<p>
37Physical volumes represent the spatial positioning of the volumes describing
38the detector elements.  Several techniques can be used.  They range from
39the simple placement of a single copy to the repeated positioning using
40either a simple linear formula or a user specified function.
41</p>
42<p>
43The simple placement involves the definition of a transformation matrix for
44the volume to be positioned.  Repeated positioning is defined using the
45number of times a volume should be replicated at a given distance along a given
46direction.  Finally it is possible to define a parameterised formula to specify
47the position of multiple copies of a volume. Details about these methods are
48given below.
49</p>
50<p>
51<b>Note</b> - For geometries which vary between runs and for which components
52of the old geometry setup are explicitely -deleted-, it is required to
53consider the proper order of deletion (which is the exact inverse of the
54actual construction, i.e., first delete physical volumes and then logical
55volumes). Deleting a logical volume does NOT delete its daughter volumes.<BR>
56It is not necessary to delete the geometry setup at the end of a job, the
57system will take care to free the volume and solid stores at the end of
58the job. The user has to take care of the deletion of any additional
59transformation or rotation matrices allocated dinamically in his/her own
60application.
61</p>
62<P> </P>
63
64<a name="4.1.4.1">
65<H4>4.1.4.1 Placements: single positioned copy</H4></a>
66
67 In this case, the Physical Volume is created by associating a Logical Volume
68 with a Rotation Matrix and a Translation vector.
69 The Rotation Matrix represents the rotation of the reference frame of the
70 considered volume relatively to its mother volume's reference frame.
71 The Translation Vector represents the translation of the current volume in the
72 reference frame of its mother volume.<BR>
73 Transformations including reflections are not allowed.
74<P>
75 To create a Placement one must construct it using:
76 <PRE>
77    G4PVPlacement(       G4RotationMatrix*  pRot,
78                   const G4ThreeVector&amp;     tlate,
79                         G4LogicalVolume*   pCurrentLogical,
80                   const G4String&amp;          pName,
81                         G4LogicalVolume*   pMotherLogical,
82                         G4bool             pMany,
83                         G4int              pCopyNo,
84                         G4bool             pSurfChk=false )</PRE>
85 where:
86<p>
87 <table border=1 cellpadding=8>
88 <tr>
89  <td><tt>pRot</tt> <td>Rotation with respect to its mother volume
90 <tr>
91  <td><tt>tlate</tt> <td>Translation with respect to its mother volume
92 <tr>
93  <td><tt>pCurrentLogical</tt> <td>The associated Logical Volume
94 <tr>
95  <td><tt>pName</tt> <td>String identifier for this placement
96 <tr>
97  <td><tt>pMotherLogical</tt> <td>The associated mother volume
98 <tr>
99  <td><tt>pMany</tt> <td>For future use. Can be set to false
100 <tr>
101  <td><tt>pCopyNo</tt> <td>Integer which identifies this placement
102 <tr>
103  <td><tt>pSurfChk</tt> <td>if true activates check for overlaps with existing volumes
104 </table></P>
105<P>
106 Care must be taken because the rotation matrix is not copied by a
107 <tt>G4PVPlacement</tt>. So the user must not modify it after creating a
108 Placement that uses it.
109 However the same rotation matrix can be re-used for many volumes.
110</p>
111<p>
112Currently boolean operations are not implemented at the level of
113physical volume.  So <tt>pMany</tt> must be false.
114However, an alternative implementation of boolean operations exists.
115In this approach a solid can be created from the union, intersection
116or subtraction of two solids. See <a href="geomSolids.html#4.1.2.2">Section 4.1.2.2</a>
117above for an explanation of this.
118</p>
119<P>
120 The mother volume must be specified for all volumes <I>except</I> the world volume.</P>
121<P>
122 An alternative way to specify a Placement utilizes a different
123 method to place the volume.  The solid itself is moved by rotating and
124 translating it to bring it into the system of coordinates of the
125 mother volume.  This <I>active</I> method can be utilized using the
126 following constructor:
127
128 <PRE>
129    G4PVPlacement(       G4Transform3D      solidTransform,
130                         G4LogicalVolume*   pCurrentLogical,
131                   const G4String&amp;          pName,
132                         G4LogicalVolume*   pMotherLogical,
133                         G4bool             pMany,
134                         G4int              pCopyNo,
135                         G4bool             pSurfChk=false )</PRE></P>
136<P>
137 An alternative method to specify the mother volume is to specify its
138 placed physical volume. It can be used in either of the above methods
139 of specifying the placement's position and rotation. The effect will be
140 exactly the same as for using the mother logical volume.</P>
141<P>
142 Note that a Placement Volume can still represent multiple detector elements.
143 This can happen if several copies exist of the mother logical volume.
144 Then different detector elements will belong to different branches of
145 the tree of the hierarchy of geometrical volumes.</P>
146<P> </P>
147
148<a name="4.1.4.2">
149<H4>4.1.4.2 Repeated volumes</H4></a>
150
151 In this case, a single Physical Volume represents multiple copies of a volume
152 within its mother volume, allowing to save memory.  This is normally done when
153 the volumes to be positioned follow a well defined rotational or translational
154 symmetry along a Cartesian or cylindrical coordinate.  The Repeated Volumes
155 technique is available for volumes described by CSG solids.
156
157<P> </P>
158
159<b>Replicas</b>
160<P>
161 Replicas are <i>repeated volumes</i> in the case when the multiple copies of
162 the volume are all identical.  The coordinate axis and the number of replicas
163 need to be specified for the program to compute at run time the transformation
164 matrix corresponding to each copy.</P>
165<P>
166 <PRE>
167    G4PVReplica( const G4String&amp;          pName,
168                       G4LogicalVolume*   pCurrentLogical,
169                       G4LogicalVolume*   pMotherLogical, // OR G4VPhysicalVolume*
170                 const EAxis              pAxis,
171                 const G4int              nReplicas,
172                 const G4double           width,
173                 const G4double           offset=0 )</PRE>
174where:</P>
175<P>
176 <table border=1 cellpadding=8>
177 <tr>
178  <td><tt>pName</tt> <td>String identifier for the replicated volume
179 <tr>
180  <td><tt>pCurrentLogical</tt> <td>The associated Logical Volume
181 <tr>
182  <td><tt>pMotherLogical</tt> <td>The associated mother volume
183 <tr>
184  <td><tt>pAxis</tt> <td>The axis along with the replication is applied
185 <tr>
186  <td><tt>nReplicas</tt> <td>The number of replicated volumes
187 <tr>
188  <td><tt>width</tt> <td>The width of a single replica along the axis of
189                         replication
190 <tr>
191  <td><tt>offset</tt> <td>Possible offset associated to mother offset along
192                          the axis of replication
193 </table></P>
194<P>
195 <tt>G4PVReplica</tt> represents <tt>nReplicas</tt> volumes differing only in
196 their positioning, and completely <b>filling</b> the containing mother volume.
197 Consequently if a <tt>G4PVReplica</tt> is 'positioned' inside a given mother it
198 <b>MUST</b> be the mother's only daughter volume. Replica's correspond
199 to divisions or slices that completely fill the mother volume and have no
200 offsets. For Cartesian axes, slices are considered perpendicular to the axis
201 of replication.</P>
202<P>
203 The replica's positions are calculated by means of a linear formula.
204 Replication may occur along:
205<UL>
206<LI><i>Cartesian axes <tt>(kXAxis,kYAxis,kZAxis)</tt></i>
207  <BR>
208  The replications, of specified width have coordinates of
209  form <tt>(-width*(nReplicas-1)*0.5+n*width,0,0)</tt><BR>
210  where <tt>n=0.. nReplicas-1</tt> for the case of <tt>kXAxis</tt>,
211  and are unrotated.
212</LI>
213<LI><i>Radial axis (cylindrical polar) <tt>(kRho)</tt></i>
214  <BR>
215  The replications are cons/tubs sections, centred on the origin
216  and are unrotated.<BR>
217  They have radii of <tt>width*n+offset</tt> to <tt>width*(n+1)+offset</tt>
218  where <tt>n=0..nReplicas-1</tt>
219</LI>
220<LI><i>Phi axis (cylindrical polar) <tt>(kPhi)</tt></i>
221  <BR>
222  The replications are <i>phi sections</i> or <i>wedges</i>, and of cons/tubs
223  form.<BR>
224  They have <tt>phi</tt> of <tt>offset+n*width</tt>
225  to <tt>offset+(n+1)*width</tt> where <tt>n=0..nReplicas-1</tt>
226</LI>
227</UL>
228
229 The coordinate system of the replicas is at the centre of each replica
230 for the cartesian axis. For the radial case, the coordinate system is
231 unchanged from the mother. For the <tt>phi</tt> axis, the new coordinate system
232 is rotated such that the X axis bisects the angle made by each wedge,
233 and Z remains parallel to the mother's Z axis.</P>
234<P>
235 The solid associated via the replicas' logical volume should have the
236 dimensions of the first volume created and must be of the correct
237 symmetry/type, in order to assist in good visualisation.<BR>
238 ex. For X axis replicas in a box, the solid should be
239 another box with the dimensions of the replications. (same Y & Z
240 dimensions as mother box, X dimension = mother's X dimension/nReplicas).</P>
241<P>
242 Replicas may be placed inside other replicas, provided the above rule
243 is observed. Normal placement volumes may be placed inside replicas,
244 provided that they do not intersect the mother's or any previous replica's
245 boundaries. Parameterised volumes may not be placed inside.<BR>
246 Because of these rules, it is not possible to place any other volume inside
247 a replication in <tt>radius</tt>.<BR>
248 The world volume <I>cannot</I> act as a replica, therefore it cannot be sliced.</P>
249<P>
250 During tracking, the translation + rotation associated with each
251 <tt>G4PVReplica</tt> object is modified according to the currently 'active'
252 replication. The solid is not modified and consequently has the
253 wrong parameters for the cases of <tt>phi</tt> and <tt>r</tt> replication
254 and for when the cross-section of the mother is not constant along the
255 replication.</P>
256<P>
257 Example:
258 <center><table border=1 cellpadding=8>
259 <tr><td>
260 <PRE>
261           G4PVReplica repX("Linear Array",
262                            pRepLogical,
263                            pContainingMother,
264                            kXAxis, 5, 10*mm);
265
266           G4PVReplica repR("RSlices",
267                            pRepRLogical,
268                            pContainingMother,
269                            kRho, 5, 10*mm, 0);
270
271           G4PVReplica repRZ("RZSlices",
272                             pRepRZLogical,
273                             &repR,
274                             kZAxis, 5, 10*mm);
275
276           G4PVReplica repRZPhi("RZPhiSlices",
277                                pRepRZPhiLogical,
278                                &repRZ,
279                                kPhi, 4, M_PI*0.5*rad, 0);
280 </PRE>
281 <tr>
282 <td align=center>
283 Source listing 4.1.2<BR>
284 An example of simple replicated volumes with <tt>G4PVReplica</tt>.
285 </table></center></P>
286<P>
287 <tt>RepX</tt> is an array of 5 replicas of width 10*mm, positioned inside and
288 completely filling the volume pointed by <tt>pContainingMother</tt>.
289 The mother's X length must be 5*10*mm=50*mm (for example, if the mother's
290 solid were a Box of half lengths [25,25,25] then the replica's solid must
291 be a box of half lengths [25,25,5]).</P>
292<P>
293 If the containing mother's solid is a tube of radius 50*mm and half Z length
294 of 25*mm, <tt>RepR</tt> divides the mother tube into 5 cylinders (hence the
295 solid associated with <tt>pRepRLogical</tt> must be a tube of radius 10*mm, and
296 half Z length 25*mm); <tt>repRZ</tt> divides it into 5 shorter cylinders
297 (the solid associated with <tt>pRepRZLogical</tt> must be a tube of radius
298 10*mm, and half Z length 5*mm); finally, <tt>repRZPhi</tt> divides it into 4
299 tube segments with full angle of 90 degrees (the solid associated with
300 <tt>pRepRZPhiLogical</tt> must be a tube segment of
301 radius 10*mm, half Z length 5*mm and delta phi of M_PI*0.5*rad).<BR>
302 No further volumes may be placed inside these replicas. To do so would
303 result in intersecting boundaries due to the <tt>r</tt> replications.</P>
304
305<P> </P>
306
307<b>Parameterised Volumes</b>
308<P>
309 Parameterised Volumes are <i>repeated volumes</i> in the case in which the
310 multiple copies of a volume can be different in size, solid type, or material.
311 The solid's type, its dimensions, the material and the transformation matrix
312 can all be parameterised in function of the copy number, both when a strong
313 symmetry exist and when it does not.  The user implements the desired
314 parameterisation function and the program computes and updates automatically
315 at run time the information associated to the Physical Volume.</P>
316<P>
317 An example of creating a parameterised volume (by dimension and position) exists in novice
318 example N02. The implementation is provided in the two classes <tt>ExN02DetectorConstruction</tt>
319 and <tt>ExN02ChamberParameterisation</tt>.</P>
320<P>
321 To create a parameterised volume, one must first create its logical volume
322 like <tt>trackerChamberLV</tt> below.
323 Then one must create his own parameterisation class
324 (<i>ExN02ChamberParameterisation</i>) and instantiate an object of this class
325 (<tt>chamberParam</tt>).  We will see how to create the parameterisation below.</P>
326<P>
327 <center><table border=1 cellpadding=8>
328 <tr><td>
329 <PRE>
330  //------------------------------
331  // Tracker segments
332  //------------------------------
333  // An example of Parameterised volumes
334  // dummy values for G4Box -- modified by parameterised volume
335  G4VSolid * solidChamber =
336                new G4Box("chamberBox", 10.*cm, 10.*cm, 10.*cm);
337
338  G4LogicalVolume * trackerChamberLV
339    = new G4LogicalVolume(solidChamber, Aluminum, "trackerChamberLV");
340  G4VPVParameterisation * chamberParam
341    = new ExN02ChamberParameterisation(
342                         6,           //  NoChambers,
343                        -240.*cm,     //  Z of centre of first
344                        80*cm,        //  Z spacing of centres
345                        20*cm,        //  Width Chamber,
346                        50*cm,        //  lengthInitial,
347                        trackerSize*2.); //  lengthFinal
348
349  G4VPhysicalVolume *trackerChamber_phys
350    = new G4PVParameterised("TrackerChamber_parameterisedPV",
351                       trackerChamberLV, // Its logical volume
352                       logicTracker,     // Mother logical volume
353                       kUndefined,       // Allow default voxelising -- no axis
354                       6,                // Number of chambers
355                       chamberParam);    // The parameterisation
356  // "kUndefined" is the suggested choice, giving 3D voxelisation (i.e. along the three
357  // cartesian axes, as is applied for placements.
358  //
359  // Note:  In some cases where volume have clear separation along a single axis,
360  // this axis (eg kZAxis) can be used to choose (force) optimisation only along
361  // this axis in geometrical calculations.
362  // When an axis is given it forces the use of one-dimensional voxelisation.</PRE>
363 <tr>
364 <td align=center>
365 Source listing 4.1.3<BR>
366 An example of Parameterised volumes.
367 </table></center>
368
369 The general constructor is:
370 <PRE>
371    G4PVParameterised( const G4String&amp;              pName,
372                             G4LogicalVolume*       pCurrentLogical,
373                             G4LogicalVolume*       pMotherLogical, // OR G4VPhysicalVolume*
374                       const EAxis                  pAxis,
375                       const G4int                  nReplicas,
376                             G4VPVParameterisation* pParam,
377                             G4bool                 pSurfChk=false )
378 </PRE></P>
379<P>
380 Note that for a parameterised volume the user must always specify a mother
381 volume.  So the world volume can <I>never</I> be a parameterised volume, nor it can be sliced.
382 The mother volume can be specified either as a physical or a logical volume.</P>
383<P>
384 <tt>pAxis</tt> specifies the tracking optimisation algorithm to apply: if a valid axis
385 (the axis along which the parameterisation is performed) is specified, a simple
386 one-dimensional voxelisation algorithm is applied; if "kUndefined" is specified instead,
387 the default three-dimensional voxelisation algorithm applied for normal placements
388 will be activated. In the latter case, more voxels will be generated, therefore a
389 greater amount of memory will be consumed by the optimisation algorithm.</P>
390<P>
391 <tt>pSurfChk</tt> if <tt>true</tt> activates a check for overlaps with
392 existing volumes or paramaterised instances.</P>
393<P>
394 The parameterisation mechanism associated to a parameterised volume is defined
395 in the parameterisation class and its methods.  Every parameterisation must
396 create two methods:
397
398 <UL>
399  <LI><tt>ComputeTransformation</tt> defines where one of the copies is placed,
400  <LI><tt>ComputeDimensions</tt>     defines the size of one copy, and
401  <LI>a constructor that initializes any member variables that are required.
402 </UL></P>
403<P>
404 An example is <tt>ExN02ChamberParameterisation</tt> that parameterises a
405 series of boxes of different sizes
406
407 <center><table border=1 cellpadding=8>
408 <tr><td>
409 <PRE>
410 class ExN02ChamberParameterisation : public G4VPVParameterisation
411 {
412   ...
413   void ComputeTransformation(const G4int       copyNo,
414                              G4VPhysicalVolume *physVol) const;
415
416   void ComputeDimensions(G4Box&amp;              trackerLayer,
417                          const G4int             copyNo,
418                          const G4VPhysicalVolume *physVol) const;
419   ...
420 }
421 </PRE>
422 <tr>
423 <td align=center>
424 Source listing 4.1.4<BR>
425 An example of Parameterised boxes of different sizes.
426 </table></center></P>
427<P>
428 These methods works as follows:</P>
429<P>
430 The <tt>ComputeTransformation</tt> method is called with a copy number for
431 the instance of the parameterisation under consideration.  It must
432 compute the transformation for this copy, and set the physical volume to
433 utilize this transformation:
434
435 <PRE>
436 void ExN02ChamberParameterisation::ComputeTransformation
437 (const G4int copyNo,G4VPhysicalVolume *physVol) const
438 {
439   G4double      Zposition= fStartZ + copyNo * fSpacing;
440   G4ThreeVector origin(0,0,Zposition);
441   physVol-&gt;SetTranslation(origin);
442   physVol-&gt;SetRotation(0);
443 }
444 </PRE>
445 Note that the translation and rotation given in this scheme are those for
446 the frame of coordinates (the <I>passive</I> method).  They are <b>not</b>
447 for the <I>active</I> method, in which the solid is rotated into the mother
448 frame of coordinates.</P>
449<P>
450 Similarly the <tt>ComputeDimensions</tt> method is used to set the size of that copy.
451 <PRE>
452 void ExN02ChamberParameterisation::ComputeDimensions
453 (G4Box &amp; trackerChamber, const G4int copyNo,
454  const G4VPhysicalVolume * physVol) const
455 {
456   G4double  halfLength= fHalfLengthFirst + (copyNo-1) * fHalfLengthIncr;
457   trackerChamber.SetXHalfLength(halfLength);
458   trackerChamber.SetYHalfLength(halfLength);
459   trackerChamber.SetZHalfLength(fHalfWidth);
460 }
461 </PRE>
462 The user must ensure that the type of the first argument of this method (in this
463 example <tt>G4Box &amp;</tt>) corresponds to the type of object the user give to
464 the logical volume of parameterised physical volume.</P>
465<P>
466 More advanced usage allows the user:
467 <UL>
468  <LI>to change the type of solid by creating a <tt>ComputeSolid</tt> method, or
469  <LI>to change the material of the volume by creating a <tt>ComputeMaterial</tt> method.
470    This method can also utilise information from a parent or other ancestor
471    volume (see the Nested Parameterisation below.)
472</UL>
473 for the parameterisation.<BR>
474 Example N07 shows a simple parameterisation by material. A more complex example
475 is provided in <TT>examples/extended/medical/DICOM</TT>, where a phantom grid
476 of cells is built using a parameterisation by material defined through a map.</P>
477<P>
478 <B>Note</B> - Currently for many cases it is not possible to add daughter
479 volumes to a parameterised volume.  Only parameterised volumes
480 all of whose solids have the same size are allowed
481 to contain daughter volumes.   When the size or type of solid varies, adding
482 daughters is not supported. <BR>
483 So the full power of parameterised volumes can be used only for "leaf"
484 volumes,  which contain no other volumes.</P>
485
486<P> </P>
487<b>Advanced parameterisations for 'nested' parameterised volumes </b>
488<p>
489A new type of parameterisation enables a user to have the daughter's material
490also depend on the copy number of the parent when a parameterised volume (daughter)
491is located inside another (parent) repeated volume. The parent volume can be a
492replica, a parameterised volume, or a division if the key feature of modifying
493its contents is utilised. (Note: a 'nested' parameterisation inside a placement
494volume is not supported, because all copies of a placement volume must be identical
495at all levels.)
496</p>
497<p>
498In such a &quot; nested&quot; parameterisation , the user must provide a
499<tt>ComputeMaterial</tt> method that utilises the new argument that represents
500the touchable history of the parent volume:
501</p>
502  <pre>
503// Sample Parameterisation
504class SampleNestedParameterisation : public G4VNestedParameterisation
505{
506 public:
507   // .. other methods ...
508    // Mandatory method, required and reason for this class
509    virtual G4Material* ComputeMaterial(G4VPhysicalVolume *currentVol,
510                                                         const G4int no_lev,
511                                                         const G4VTouchable *parentTouch);
512 private:
513    G4Material *material1, *material2; 
514};
515  </pre>
516<p>
517The implementation of the method can utilise any information
518from a parent or other ancestor volume of its parameterised physical volume,
519but typically it will use only the copy number:
520</p>
521  <pre>
522 G4Material*
523 SampleNestedParameterisation::ComputeMaterial(G4VPhysicalVolume *currentVol,
524                                                    const G4int no_lev,
525                                                                    const G4VTouchable *parentTouchable)
526 {
527    G4Material *material=0;
528       
529    // Get the information about the parent volume
530    G4int no_parent= parentTouchable->GetReplicaNumber();
531    G4int no_total= no_parent + no_lev;
532    // A simple 'checkerboard' pattern of two materials
533    if( no_total / 2 == 1 ) material= material1;
534    else  material= material2;
535    // Set the material to the current logical volume
536    G4LogicalVolume* currentLogVol= currentVol->GetLogicalVolume();
537    currentLogVol->SetMaterial( material );
538    return material;
539 }
540</pre>
541<p>
542Nested parameterisations are suitable for the case of regular, 'voxel'
543geometries in which a large number of 'equal' volumes are required,
544and their only difference is in their material. By creating two (or more)
545levels of parameterised physical volumes it is possible to divide space,
546while requiring only limited additional memory for very fine-level
547optimisation.  This provides fast navigation. Alternative implementations,
548taking into account the regular structure of such geometries in
549navigation are under study.
550</p>
551
552<P></P>
553<b>Divisions of Volumes</b>
554<P>
555 Divisions in Geant4 are implemented as a specialized type of parameterised volumes.
556<br>
557They serve to divide a volume into identical copies along one of its axes,
558providing the possibility to define an <i>offset</i>, and without the
559limitation that the daugthers have to fill the mother volume as it is the
560case for the replicas.
561In the case, for example, of a tube divided along its radial axis,
562the copies are not strictly identical, but have increasing radii, although
563their widths are constant.
564</p>
565<p>
566 To divide a volume it will be necessary to provide:
567 <OL>
568  <LI>the axis of division, and</LI>
569  <LI>either
570      <UL>
571      <LI>the number of divisions (so that the width of each division will be automatically
572          calculated), or</LI>
573      <LI>the division width (so that the number of divisions will be automatically calculated
574          to fill as much of the mother as possible), or</LI>
575      <LI>both the number of divisions and the division width (this is especially designed for
576          the case where the copies do not fully fill the mother).</LI>
577      </UL></LI>
578 </OL></P>
579<P>
580 An <i>offset</i> can be defined so that the first copy will start at some
581 distance from the mother wall. The dividing copies will be then distributed to occupy the rest
582 of the volume.</P>
583<P>
584There are three constructors, corresponding to the three input possibilities described above:
585<UL>
586 <LI>Giving only the number of divisions:
587 <PRE>
588     G4PVDivision( const G4String&amp; pName,
589                         G4LogicalVolume* pCurrentLogical,
590                         G4LogicalVolume* pMotherLogical,
591                   const EAxis pAxis,
592                   const G4int nDivisions,
593                   const G4double offset )
594 </PRE></LI>
595 <LI>Giving only the division width:
596 <PRE>
597     G4PVDivision( const G4String&amp; pName,
598                         G4LogicalVolume* pCurrentLogical,
599                         G4LogicalVolume* pMotherLogical,
600                   const EAxis pAxis,
601                   const G4double width,
602                   const G4double offset )
603 </PRE></LI>
604 <LI>Giving the number of divisions and the division width:
605 <PRE>
606     G4PVDivision( const G4String&amp; pName,
607                         G4LogicalVolume* pCurrentLogical,
608                         G4LogicalVolume* pMotherLogical,
609                   const EAxis pAxis,
610                   const G4int nDivisions,
611                   const G4double width,
612                   const G4double offset )
613 </PRE></LI>
614</UL></P>
615<P>
616where:</P>
617<P>
618 <table border=1 cellpadding=8>
619 <tr>
620  <td><tt>pName</tt> <td>String identifier for the replicated volume
621 <tr>
622  <td><tt>pCurrentLogical</tt> <td>The associated Logical Volume
623 <tr>
624  <td><tt>pMotherLogical</tt> <td>The associated mother Logical Volume
625 <tr>
626  <td><tt>pAxis</tt> <td>The axis along which the division is applied
627 <tr>
628  <td><tt>nDivisions</tt> <td>The number of divisions
629 <tr>
630  <td><tt>width</tt> <td>The width of a single division along the axis
631 <tr>
632  <td><tt>offset</tt> <td>Possible offset associated to the mother along
633                          the axis of division
634 </table></P>
635<P>
636The parameterisation is calculated automatically using the values provided in input.
637Therefore the dimensions of the solid associated with <tt>pCurrentLogical</tt> will not be used,
638but recomputed through the <tt>G4VParameterisation::ComputeDimension()</tt> method.</P>
639<P>
640Since <tt>G4VPVParameterisation</tt> may have different <tt>ComputeDimension()</tt> methods for
641each solid type, the user must provide a solid that is of the same type as of the one
642associated to the mother volume.</P>
643<P>
644As for any replica, the coordinate system of the divisions is related to the centre of each division
645for the cartesian axis. For the radial axis, the coordinate system is the same of the mother volume.
646For the phi axis, the new coordinate system is rotated such that the X axis bisects the angle
647made by each wedge, and Z remains parallel to the mother's Z axis.</P>
648<P>
649As divisions are parameterised volumes with constant dimensions, they may be placed inside
650other divisions, except in the case of divisions along the radial axis.<BR>
651It is also possible to place other volumes inside a volume where a division is placed.</P>
652<p>
653The list of volumes that currently support divisioning and the possible division axis
654are summarised below:</P>
655<P>
656 <table border=1 cellpadding=8>
657 <tr>
658  <td><tt>G4Box</tt> <td><tt>kXAxis</tt>, <tt>kYAxis</tt>, <tt>kZAxis</tt>
659 <tr>
660  <td><tt>G4Tubs</tt> <td><tt>kRho</tt>, <tt>kPhi</tt>, <tt>kZAxis</tt>
661 <tr>
662  <td><tt>G4Cons</tt> <td><tt>kRho</tt>, <tt>kPhi</tt>, <tt>kZAxis</tt>
663 <tr>
664  <td><tt>G4Trd</tt> <td><tt>kXAxis</tt>, <tt>kYAxis</tt>, <tt>kZAxis</tt>
665 <tr>
666  <td><tt>G4Para</tt> <td><tt>kXAxis</tt>, <tt>kYAxis</tt>, <tt>kZAxis</tt>
667 <tr>
668  <td><tt>G4Polycone</tt> <td><tt>kRho</tt>, <tt>kPhi</tt>, <tt>kZAxis</tt> (*)
669 <tr>
670  <td><tt>G4Polyhedra</tt> <td><tt>kRho</tt>, <tt>kPhi</tt>, <tt>kZAxis</tt> (**)
671 </table></P>
672<P>
673(*) - <tt>G4Polycone</tt>:
674 <UL>
675  <LI><tt>kZAxis</tt> - the number of divisions has to be the same as solid sections,
676     (i.e. <tt>numZPlanes-1</tt>), the width will <i>not</i> be taken into account.</LI>
677 </UL>
678(**) - <tt>G4Polyhedra</tt>:
679 <UL>
680  <LI><tt>kPhi</tt> - the number of divisions has to be the same as solid sides,
681     (i.e. <tt>numSides</tt>), the width will <i>not</i> be taken into account.</LI>
682  <LI><tt>kZAxis</tt> - the number of divisions has to be the same as solid sections,
683     (i.e. <tt>numZPlanes-1</tt>), the width will <i>not</i> be taken into account.</LI>
684 </UL></P>
685
686<P>
687In the case of division along <tt>kRho</tt> of <tt>G4Cons</tt>, <tt>G4Polycone</tt>,
688<tt>G4Polyhedra</tt>, if width is provided, it is taken as the width at the <tt>-Z</tt>
689radius; the width at other radii will be scaled to this one.<BR>
690
691Examples are given below in listings 4.1.4 and 4.1.5.</P>
692<P>
693 <center><table border=1 cellpadding=8>
694 <tr><td>
695 <PRE>
696 G4Box* motherSolid = new G4Box("motherSolid", 0.5*m, 0.5*m, 0.5*m);
697 G4LogicalVolume* motherLog = new G4LogicalVolume(motherSolid, material, "mother",0,0,0);
698 G4Para* divSolid = new G4Para("divSolid", 0.512*m, 1.21*m, 1.43*m);
699 G4LogicalVolume* childLog = new G4LogicalVolume(divSolid, material, "child",0,0,0);
700
701 G4PVDivision divBox1("division along X giving nDiv",
702                      childLog, motherLog, kXAxis, 5, 0.);
703
704 G4PVDivision divBox2("division along X giving width and offset",
705                      childLog, motherLog, kXAxis, 0.1*m, 0.45*m);
706
707 G4PVDivision divBox3("division along X giving nDiv, width and offset",
708                      childLog, motherLog, kXAxis, 3, 0.1*m, 0.5*m);
709 </PRE>
710 <tr>
711 <td align=center>
712 Source listing 4.1.5<BR>
713 An example of a box division along different axes, with or without offset.
714 </table></center></P>
715<P>
716<ul>
717<li><tt>divBox1</tt> is a division of a box along its <tt>X</tt> axis in 5 equal copies.
718    Each copy will have a dimension in meters of <tt>[0.2, 1., 1.]</tt>.</li>
719<li><tt>divBox2</tt> is a division of the same box along its <tt>X</tt> axis with a width of
720    <tt>0.1</tt> meters and an offset of <tt>0.5</tt> meters. As the mother dimension along
721    <tt>X</tt> of <tt>1</tt> meter (<tt>0.5*m</tt> of halflength), the division will be sized
722    in total <tt>1 - 0.45 = 0.55</tt> meters. Therefore, there's space for 5 copies,
723    the first extending from <tt>-0.05</tt> to <tt>0.05</tt> meters in the mother's frame and
724    the last from <tt>0.35</tt> to <tt>0.45</tt> meters.</li>
725<li><tt>divBox3</tt> is a division of the same box along its <tt>X</tt> axis in 3 equal copies of width
726    <tt>0.1</tt> meters and an offset of <tt>0.5</tt> meters. The first copy will extend from
727    <tt>0.</tt> to <tt>0.1</tt> meters in the mother's frame and the last from <tt>0.2</tt>
728    to <tt>0.3</tt> meters.</li>
729</ul></P>
730<P>
731 <center><table border=1 cellpadding=8>
732 <tr><td>
733 <PRE>
734  G4double* zPlanem = new G4double[3];
735            zPlanem[0]= -1.*m;
736            zPlanem[1]= -0.25*m;
737            zPlanem[2]=  1.*m;
738  G4double* rInnerm = new G4double[3];
739            rInnerm[0]=0.;
740            rInnerm[1]=0.1*m;
741            rInnerm[2]=0.5*m;
742  G4double* rOuterm  = new G4double[3];
743            rOuterm[0]=0.2*m;
744            rOuterm[1]=0.4*m;
745            rOuterm[2]=1.*m;
746  G4Polycone* motherSolid = new G4Polycone("motherSolid", 20.*deg, 180.*deg,
747                                           3, zPlanem, rInnerm, rOuterm);
748  G4LogicalVolume* motherLog = new G4LogicalVolume(motherSolid, material, "mother",0,0,0);
749
750  G4double* zPlaned = new G4double[3];
751            zPlaned[0]= -3.*m;
752            zPlaned[1]= -0.*m;
753            zPlaned[2]=  1.*m;
754  G4double* rInnerd = new G4double[3];
755            rInnerd[0]=0.2;
756            rInnerd[1]=0.4*m;
757            rInnerd[2]=0.5*m;
758  G4double* rOuterd  = new G4double[3];
759            rOuterd[0]=0.5*m;
760            rOuterd[1]=0.8*m;
761            rOuterd[2]=2.*m;
762  G4Polycone* divSolid = new G4Polycone("divSolid", 0.*deg, 10.*deg,
763                                        3, zPlaned, rInnerd, rOuterd);
764  G4LogicalVolume* childLog = new G4LogicalVolume(divSolid, material, "child",0,0,0);
765
766  G4PVDivision divPconePhiW("division along phi giving width and offset",
767                            childLog, motherLog, kPhi, 30.*deg, 60.*deg);
768
769  G4PVDivision divPconeZN("division along Z giving nDiv and offset",
770                          childLog, motherLog, kZAxis, 2, 0.1*m);
771 </PRE>
772 <tr>
773 <td align=center>
774 Source listing 4.1.6<BR>
775 An example of division of a polycone.
776 </table></center></P>
777<P>
778<ul>
779<li><tt>divPconePhiW</tt> is a division of a polycone along its <tt>phi</tt> axis in equal
780  copies of width 30 degrees with an offset of 60 degrees. As the mother extends from
781  0 to 180 degrees, there's space for 4 copies. All the copies have a starting angle
782  of 20 degrees (as for the mother) and a <tt>phi</tt> extension of 30 degrees.
783  They are rotated around the <tt>Z</tt> axis by 60 and 30 degrees,
784  so that the first copy will extend from 80 to 110 and the last from 170 to 200 degrees.</li>
785<li><tt>divPconeZN</tt> is a division of the same polycone along its <tt>Z</tt> axis. As the mother
786  polycone has two sections, it will be divided in two one-section polycones, the first
787  one extending from -1 to -0.25 meters, the second from -0.25 to 1 meters.
788  Although specified, the offset will not be used.</li>
789</ul></p>
790
791<hr><a href="../../../../Authors/html/subjectsToAuthors.html">
792<i>About the authors</a></i> </P>
793
794</body>
795</html>
Note: See TracBrowser for help on using the repository browser.