source: trunk/documents/UserDoc/DocBookUsersGuides/ForToolkitDeveloper/xml/OOAnalysisDesign/Geometry/geometry.xml @ 904

Last change on this file since 904 was 904, checked in by garnier, 16 years ago

ajout de la doc

File size: 14.8 KB
Line 
1<!-- ******************************************************** -->
2<!--  Docbook Version:  For Toolkit Developers Guide          -->
3<!-- ******************************************************** -->
4
5<!-- ******************* Section (Level#1) ****************** -->
6<sect1 id="sect.DsgnFuncGeom">
7<title>
8Geometry
9</title>
10
11
12<!-- ******************* Section (Level#2) ****************** -->
13<sect2 id="sect.DsgnFuncGeom.DsgPhlsp">
14<title>
15Design Philosopy
16</title>
17
18<para>
19The geometry category provides the ability to describe a geometrical structure
20and propagate particles efficiently through it.  This is done in part with
21the aid of two central concepts, the <emphasis role="italic">logical</emphasis> 
22and <emphasis role="italic">physical</emphasis> volumes.
23A logical volume represents a detector element of a given shape which may
24contain other volumes, and which may have other attributes.  It has access to
25other information which is independent of its phyisical location in the
26detector, such as material and sensitive detector behavior.  A physical volume
27represents the spatial positioning or placement of the logical volume with
28respect to an enclosing mother (logical) volume.  Thus a hierarchical tree
29structure of volumes can be built with each volume containing smaller volumes
30(which may not overlap).  Repetitive structures can be represented by
31specialized physical volumes, such as replicas and parameterized placements,
32sometimes resulting in a large savings in memory.
33</para>
34
35<para>
36In Geant4 the logical volume has been refined by defining the shape as
37a separate entity, called a <emphasis role="italic">solid</emphasis>
38Solids with simple shapes, like
39rectilinear boxes, trapezoids, spherical or cylindrical sections or shells,
40each have their properties coded separately, in accord with the concept of
41<emphasis role="italic">Constructed Solid Geometry (CSG)</emphasis>
42More complex solids are defined by
43their bounding surfaces, which can be planes, second-order surfaces or
44higher-order B-spline surfaces, and belong to the
45<emphasis role="italic">Boundary Representations (BREP)</emphasis> sub-category.
46</para>
47
48<para>
49Another way to build solids is by boolean combination - union, intersection
50and subtraction.  The elemental solids should be CSGs. 
51</para>
52
53<para>
54Although a detector is naturally and best described as by a hierarchy of
55volumes, efficiency is not critically dependent on this.  An optimization
56technique, called voxelization, allows efficient navigation even in ``flat''
57geometries, typical of those produced by CAD systems.
58</para>
59
60</sect2>
61
62
63<!-- ******************* Section (Level#2) ****************** -->
64<sect2 id="sect.DsgnFuncGeom.ClassDsg">
65<title>
66Class Design
67</title>
68
69<para>
70
71<itemizedlist spacing="compact">
72<listitem><para>
73   <emphasis role="bold">G4GeometryManager</emphasis> -
74   responsible for managing ``high level'' objects in the geometry subdomain,
75   notably including opening and closing (``locking'') the geometry, and
76   creating/deleting optimization information for G4Navigator. The class is
77   a "singleton".
78</para></listitem> 
79<listitem><para>
80   <emphasis role="bold">G4LogicalVolumeStore</emphasis> -
81   a container for optionally storing created logical volumes. It enables
82   traversal of all logical volumes by the UI/user/etc.
83</para></listitem> 
84<listitem><para>
85   <emphasis role="bold">G4LogicalVolume</emphasis> -
86   represents a leaf node or unpositioned subtree in the geometry hierarchy.
87   It may have daughters ascribed to it, and is also responsible for
88   retrieval of the physical and tracking attributes of the physical volume
89   that it represents.  These attributes include solid, material, magnetic
90   field, and optionally user limits, sensitive detectors, etc.  Logical
91   volumes are optionally entered into the G4LogicalVolumeStore.
92</para></listitem>
93<listitem><para>
94   <emphasis role="bold">G4MagneticField</emphasis> -
95   a class responsible for the magnetic field in each volume, including the
96   calculation of particle trajectories along curved paths. In cases where
97   the geometry step limits the particle's step, the distance calculated
98   is guaranteed to be the distance to a volume boundary.
99</para></listitem>
100<listitem><para>
101   <emphasis role="bold">G4Navigator</emphasis> -
102   a class used by the tracking management, able to obtain/calculate
103   tracking-time geometrical information such as distance to the next volume,
104   or to find the physical volume containing a given point in the world
105   reference system.  The navigator maintains a transformation history and
106   other information used to optimize the tracking time performance.
107</para></listitem>
108<listitem><para>
109   <emphasis role="bold">G4NavigationHistory</emphasis> -
110   responsible for maintenance of the history of the path taken through the
111   geometrical hierarchy.  It is principally a utility class for use by
112   G4Navigator.
113</para></listitem>
114<listitem><para>
115   <emphasis role="bold">G4NormalNavigation</emphasis> -
116   a utility class for navigation in volumes containing only G4PVPlacement
117   daughter volumes.
118</para></listitem>
119<listitem><para>
120   <emphasis role="bold">G4ParameterisedNavigation</emphasis> -
121   a utility class for navigation in volumes containing a single
122   G4PVParameterised volume for which voxels for the replicated volumes have
123   been constructed.
124</para></listitem>
125<listitem><para>
126   <emphasis role="bold">G4VoxelNavigation</emphasis> -
127   a utility class for navigation in volumes containing only G4PVPlacement
128   daughter volumes for which voxels have been constructed.
129</para></listitem>
130<listitem><para>
131   <emphasis role="bold">G4ReplicaNavigation</emphasis> -
132   a utility class for navigation in volumes containing a single
133   G4PVParameterised volume for which voxels for the replicated volumes
134   have been constructed.
135</para></listitem>
136<listitem><para>
137   <emphasis role="bold">G4PhysicalVolumeStore</emphasis> -
138   a container for optionally storing created physical volumes. It enables
139   traversal of all physical volumes by the UI/user/etc.  All solids should
140   be registered with G4PhysicalVolumeStore, and removed on their destruction.
141   It is intended principally for the UI browser.
142</para></listitem>
143<listitem><para>
144   <emphasis role="bold">G4VPhysicalVolume</emphasis> -
145   a volume positioned within and relative to a given mother volume, and also
146   represented by a given logical volume.  They are optionally entered into
147   the G4PhysicalVolumeStore.
148</para></listitem>
149<listitem><para>
150   <emphasis role="bold">G4PVPlacement</emphasis> -
151   a physical volume corresponding to a single touchable detector element,
152   positioned within and relative to a mother volume.
153</para></listitem>
154<listitem><para>
155   <emphasis role="bold">G4PVIndexed</emphasis> -
156   a volume able to perform simple changes to its shape (corresponds to
157   GSPOSP), and representing a single touchable detector element.
158</para></listitem>
159<listitem><para>
160   <emphasis role="bold">G4PVReplica</emphasis> -
161   a physical volume representing many identically formed touchable detector
162   elements, differing only in their positioning.  The elements' positions
163   are determined by means of a simple formula, and the elements completely
164   fill the containing mother volume.
165</para></listitem>
166<listitem><para>
167   <emphasis role="bold">G4PVParameterised</emphasis> -
168   a physical volume representing many touchable detector elements differing
169   in their positioning and dimensions.  Both are calculated by means of a
170   G4VParameterisation object.  Each element's position is calculated as per
171   G4PVReplica, and each element's shape can be modified by means of a user
172   supplied formula.
173</para></listitem>
174<listitem><para>
175   <emphasis role="bold">G4VPVParameterisation</emphasis> -
176   a parameterisation class able to compute the transformation and,
177   indirectly, the dimensions of parameterised volumes, given a replication
178   number.
179</para></listitem>
180<listitem><para>
181   <emphasis role="bold">G4SmartVoxelProxy</emphasis> -
182   a class for proxying smart voxels.  The class represents either a header
183   (in turn refering to more VoxelProxies) or a node.  If created as a node,
184   calls to GetHeader cause an exception, and likewise GetNode when a header.
185</para></listitem>
186<listitem><para>
187   <emphasis role="bold">G4SmartVoxelHeader</emphasis> -
188   represents a single axis of virtual division.  Contains the individual
189   divisions which are potentially further divided along different axes.
190</para></listitem>
191<listitem><para>
192   <emphasis role="bold">G4SmartVoxelNode</emphasis> -
193   a single virtual division, containing the physical volumes inside its
194   boundaries and those of its parents.
195</para></listitem>
196<listitem><para>
197   <emphasis role="bold">G4VoxelLimits</emphasis> -
198   represents limitation/restrictions of space, where restrictions are only
199   made perpendicular to the cartesian axes.
200</para></listitem>
201<listitem><para>
202   <emphasis role="bold">G4RotationMatrixStore</emphasis> -
203   a container for optionally storing created G4RotationMatrices.
204</para></listitem> 
205<listitem><para>
206   <emphasis role="bold">G4SolidStore</emphasis> -
207   a container for optionally storing created solids.  It enables traversal
208   of all/any solids by the UI/user/etc. The class is a "singleton".
209</para></listitem>
210<listitem><para>
211   <emphasis role="bold">G4VSolid</emphasis> -
212   position independent geometrical entities. They have only `shape', and
213   encompass both CSG and boundary representations.  They are optionally
214   entered into the G4SolidStore.  This class defines, but does not implement,
215   functions to compute distances to/from the shape.  Functions are also
216   defined to check whether a point is inside the shape, to return the
217   surface normal of the shape at a given point, and to compute the extent
218   of the shape.
219</para></listitem>
220<listitem><para>
221   <emphasis role="bold">G4VSweptSolid</emphasis> -
222   a solid created by performing a 3D transformation on a finite planar face.
223</para></listitem>
224<listitem><para>
225   <emphasis role="bold">G4HalfSpaceSolid</emphasis> -
226   a solid created by the boolean AND of one or more half space surfaces.
227</para></listitem>
228<listitem><para>
229   <emphasis role="bold">G4BREPSolid</emphasis> -
230   a solid created by an abitrary set of finite surfaces.
231</para></listitem>
232<listitem><para>
233   <emphasis role="bold">G4VTouchable</emphasis> -
234   a class that maintains a ``reference'' on a given touchable element of
235   the detector - a kind of bookmark.  It enables a given detector element
236   to be saved during tracking (in case of booleans/user code/etc.) and the
237   corresponding G4PhysicalVolume retrieved later, with its ``state''
238   information (path through the tree) optionally restored so that
239   navigation can be restarted.  G4Touchables provide fast access to the
240   transformation from the global reference system to that of the saved
241   detector element.
242</para></listitem>
243<listitem><para>
244   <emphasis role="bold">G4TouchableHistory</emphasis> -
245   object representing a touchable detector element, and its history in the
246   geomtrical hierarchy, including its net resultant local->global transform.
247</para></listitem>
248<listitem><para>
249   <emphasis role="bold">G4GRSSolid</emphasis>} -
250   object representing a touchable solid.  It maintains
251   the association between a solid and its net resultant local-to-global
252   transform.
253</para></listitem>
254<listitem><para>
255   <emphasis role="bold">G4GRSVolume</emphasis> -
256   object representing a touchable detector element. 
257   It maintains associations between a physical volume and its net resultant
258   local-to-global transform.
259</para></listitem>
260<listitem><para>
261   <emphasis role="bold">G4TransformStore</emphasis> -
262   a container for optionally storing created G4AffineTransform objects.
263   It is responsible for storing and providing access to transformations
264   that are constant at tracking time.
265</para></listitem>
266<listitem><para>
267   <emphasis role="bold">G4AffineTransform</emphasis> -
268   a class for geometric affine transformations.
269   It supports efficient arbitrary rotation and transformation of vectors and
270   the computation of compound and inverse transformations.  A
271   ``rotation flag'' is maintained internally for greater computational
272   efficiency for transforms that do not involve rotation.
273</para></listitem>
274<listitem><para>
275   <emphasis role="bold">G4UserLimits</emphasis> -
276   responsible for user limits on step size, ascribable to individual volumes.
277</para></listitem>
278</itemizedlist>
279</para>
280
281<para>
282<xref linkend="fig.DsgnFuncGeom_1" /> shows a general overview, in UML notation, of
283the geometry design.  A detailed collection of class diagrams from the
284geometry category is found in the Appendix.
285
286<figure id="fig.DsgnFuncGeom_1">
287<title>
288Overview of the geometry
289</title>
290<mediaobject>
291  <imageobject role="fo">
292    <imagedata fileref="./AllResources/OOAnalysisDesign/Geometry/overall.gif" format="GIF" contentwidth="10.0cm" align="center" />
293  </imageobject>
294  <imageobject role="html">
295    <imagedata fileref="./AllResources/OOAnalysisDesign/Geometry/overall.gif" format="GIF" align="center" />
296  </imageobject>
297</mediaobject>
298</figure>
299</para>
300
301</sect2>
302
303<!-- ******************* Section (Level#2) ****************** -->
304<sect2 id="sect.DsgnFuncGeom.AddDgrm">
305<title>
306Additional Geometry Diagrams
307</title>
308
309<para>
310Additional diagrams for the object-oriented design of the 'geometry' related
311classes are included here.
312</para>
313<para>
314<xref linkend="fig.DsgnFuncGeom_2" /> shows the class diagram for smart voxels.
315<xref linkend="fig.DsgnFuncGeom_3" /> shows the class diagram for the navigator.
316
317<figure id="fig.DsgnFuncGeom_2">
318<title>
319Class diagram for smart voxels
320</title>
321<mediaobject>
322  <imageobject role="fo">
323    <imagedata fileref="./AllResources/OOAnalysisDesign/Geometry/smart_voxels.gif" format="GIF" contentwidth="10.0cm" align="center" />
324  </imageobject>
325  <imageobject role="html">
326    <imagedata fileref="./AllResources/OOAnalysisDesign/Geometry/smart_voxels.gif" format="GIF" align="center" />
327  </imageobject>
328</mediaobject>
329</figure>
330
331
332<figure id="fig.DsgnFuncGeom_3">
333<title>
334Class diagram for the navigator
335</title>
336<mediaobject>
337  <imageobject role="fo">
338    <imagedata fileref="./AllResources/OOAnalysisDesign/Geometry/navigator.gif" format="GIF" contentwidth="10.0cm" align="center" />
339  </imageobject>
340  <imageobject role="html">
341    <imagedata fileref="./AllResources/OOAnalysisDesign/Geometry/navigator.gif" format="GIF" align="center" />
342  </imageobject>
343</mediaobject>
344</figure>
345</para>
346
347
348<!-- ******* Bridgehead ******* -->
349<bridgehead role="revisionHistory" renderas="sect4">
350[Status of this chapter]
351</bridgehead>
352<para>
353<simplelist type="var">
354  <member>
355    27.06.05 subsection on design philosphy (from Geant4 general paper)
356    added by D.H. Wright
357  </member>
358    Dec. 2006 Conversion from latex to Docbook verson by K. Amako
359  <member>
360  </member>
361</simplelist>
362</para>
363   
364
365</sect2>
366</sect1>
Note: See TracBrowser for help on using the repository browser.