source: trunk/documents/UserDoc/UsersGuides/ForToolkitDeveloper/latex/OOAnalysisDesign/Geometry/geometry.tex@ 1300

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

CVS update

File size: 10.2 KB
Line 
1\chapter{Geometry}
2
3\section{Design Philosopy}
4The geometry category provides the ability to describe a geometrical structure
5and propagate particles efficiently through it. This is done in part with
6the aid of two central concepts, the {\it logical} and {\it physical} volumes.
7A logical volume represents a detector element of a given shape which may
8contain other volumes, and which may have other attributes. It has access to
9other information which is independent of its phyisical location in the
10detector, such as material and sensitive detector behavior. A physical volume
11represents the spatial positioning or placement of the logical volume with
12respect to an enclosing mother (logical) volume. Thus a hierarchical tree
13structure of volumes can be built with each volume containing smaller volumes
14(which may not overlap). Repetitive structures can be represented by
15specialized physical volumes, such as replicas and parameterized placements,
16sometimes resulting in a large savings in memory.
17
18In {\sc Geant4} the logical volume has been refined by defining the shape as
19a separate entity, called a {\it solid}. Solids with simple shapes, like
20rectilinear boxes, trapezoids, spherical or cylindrical sections or shells,
21each have their properties coded separately, in accord with the concept of
22{\it Constructed Solid Geometry (CSG)}. More complex solids are defined by
23their bounding surfaces, which can be planes, second-order surfaces or
24higher-order B-spline surfaces, and belong to the {\it Boundary
25Representations (BREP)} sub-category.
26
27Another way to build solids is by boolean combination - union, intersection
28and subtraction. The elemental solids should be CSGs.
29
30Although a detector is naturally and best described as by a hierarchy of
31volumes, efficiency is not critically dependent on this. An optimization
32technique, called voxelization, allows efficient navigation even in ``flat''
33geometries, typical of those produced by CAD systems.
34
35\section{Class Design}
36
37\begin{itemize}
38
39\item {\bf G4GeometryManager} -
40 responsible for managing ``high level'' objects in the geometry subdomain,
41 notably including opening and closing (``locking'') the geometry, and
42 creating/deleting optimization information for G4Navigator. The class is
43 a "singleton".
44
45\item {\bf G4LogicalVolumeStore} -
46 a container for optionally storing created logical volumes. It enables
47 traversal of all logical volumes by the UI/user/etc.
48
49\item {\bf G4LogicalVolume} -
50 represents a leaf node or unpositioned subtree in the geometry hierarchy.
51 It may have daughters ascribed to it, and is also responsible for
52 retrieval of the physical and tracking attributes of the physical volume
53 that it represents. These attributes include solid, material, magnetic
54 field, and optionally user limits, sensitive detectors, etc. Logical
55 volumes are optionally entered into the G4LogicalVolumeStore.
56
57\item {\bf G4MagneticField} -
58 a class responsible for the magnetic field in each volume, including the
59 calculation of particle trajectories along curved paths. In cases where
60 the geometry step limits the particle's step, the distance calculated
61 is guaranteed to be the distance to a volume boundary.
62
63\item {\bf G4Navigator} -
64 a class used by the tracking management, able to obtain/calculate
65 tracking-time geometrical information such as distance to the next volume,
66 or to find the physical volume containing a given point in the world
67 reference system. The navigator maintains a transformation history and
68 other information used to optimize the tracking time performance.
69
70\item {\bf G4NavigationHistory} -
71 responsible for maintenance of the history of the path taken through the
72 geometrical hierarchy. It is principally a utility class for use by
73 G4Navigator.
74
75\item {\bf G4NormalNavigation} -
76 a utility class for navigation in volumes containing only G4PVPlacement
77 daughter volumes.
78
79\item {\bf G4ParameterisedNavigation} -
80 a utility class for navigation in volumes containing a single
81 G4PVParameterised volume for which voxels for the replicated volumes have
82 been constructed.
83
84\item {\bf G4VoxelNavigation} -
85 a utility class for navigation in volumes containing only G4PVPlacement
86 daughter volumes for which voxels have been constructed.
87
88\item {\bf G4ReplicaNavigation} -
89 a utility class for navigation in volumes containing a single
90 G4PVParameterised volume for which voxels for the replicated volumes
91 have been constructed.
92
93\item {\bf G4PhysicalVolumeStore} -
94 a container for optionally storing created physical volumes. It enables
95 traversal of all physical volumes by the UI/user/etc. All solids should
96 be registered with G4PhysicalVolumeStore, and removed on their destruction.
97 It is intended principally for the UI browser.
98
99\item {\bf G4VPhysicalVolume} -
100 a volume positioned within and relative to a given mother volume, and also
101 represented by a given logical volume. They are optionally entered into
102 the G4PhysicalVolumeStore.
103
104\item {\bf G4PVPlacement} -
105 a physical volume corresponding to a single touchable detector element,
106 positioned within and relative to a mother volume.
107
108\item {\bf G4PVIndexed} -
109 a volume able to perform simple changes to its shape (corresponds to
110 GSPOSP), and representing a single touchable detector element.
111
112\item {\bf G4PVReplica} -
113 a physical volume representing many identically formed touchable detector
114 elements, differing only in their positioning. The elements' positions
115 are determined by means of a simple formula, and the elements completely
116 fill the containing mother volume.
117
118\item {\bf G4PVParameterised} -
119 a physical volume representing many touchable detector elements differing
120 in their positioning and dimensions. Both are calculated by means of a
121 G4VParameterisation object. Each element's position is calculated as per
122 G4PVReplica, and each element's shape can be modified by means of a user
123 supplied formula.
124
125\item {\bf G4VPVParameterisation} -
126 a parameterisation class able to compute the transformation and,
127 indirectly, the dimensions of parameterised volumes, given a replication
128 number.
129
130\item {\bf G4SmartVoxelProxy} -
131 a class for proxying smart voxels. The class represents either a header
132 (in turn refering to more VoxelProxies) or a node. If created as a node,
133 calls to GetHeader cause an exception, and likewise GetNode when a header.
134
135\item {\bf G4SmartVoxelHeader} -
136 represents a single axis of virtual division. Contains the individual
137 divisions which are potentially further divided along different axes.
138
139\item {\bf G4SmartVoxelNode} -
140 a single virtual division, containing the physical volumes inside its
141 boundaries and those of its parents.
142
143\item {\bf G4VoxelLimits} -
144 represents limitation/restrictions of space, where restrictions are only
145 made perpendicular to the cartesian axes.
146
147\item {\bf G4RotationMatrixStore} -
148 a container for optionally storing created G4RotationMatrices.
149
150\item {\bf G4SolidStore} -
151 a container for optionally storing created solids. It enables traversal
152 of all/any solids by the UI/user/etc. The class is a "singleton".
153
154\item {\bf G4VSolid} -
155 position independent geometrical entities. They have only `shape', and
156 encompass both CSG and boundary representations. They are optionally
157 entered into the G4SolidStore. This class defines, but does not implement,
158 functions to compute distances to/from the shape. Functions are also
159 defined to check whether a point is inside the shape, to return the
160 surface normal of the shape at a given point, and to compute the extent
161 of the shape.
162
163\item {\bf G4VSweptSolid} -
164 a solid created by performing a 3D transformation on a finite planar face.
165
166\item {\bf G4HalfSpaceSolid} -
167 a solid created by the boolean AND of one or more half space surfaces.
168
169\item {\bf G4BREPSolid} -
170 a solid created by an abitrary set of finite surfaces.
171
172\item {\bf G4VTouchable} -
173 a class that maintains a ``reference'' on a given touchable element of
174 the detector - a kind of bookmark. It enables a given detector element
175 to be saved during tracking (in case of booleans/user code/etc.) and the
176 corresponding G4PhysicalVolume retrieved later, with its ``state''
177 information (path through the tree) optionally restored so that
178 navigation can be restarted. G4Touchables provide fast access to the
179 transformation from the global reference system to that of the saved
180 detector element.
181
182\item {\bf G4TouchableHistory} -
183 object representing a touchable detector element, and its history in the
184 geomtrical hierarchy, including its net resultant local->global transform.
185
186\item {\bf G4GRSSolid} - object representing a touchable solid. It maintains
187 the association between a solid and its net resultant local-to-global
188 transform.
189
190\item {\bf G4GRSVolume} - object representing a touchable detector element.
191 It maintains associations between a physical volume and its net resultant
192 local-to-global transform.
193
194\item {\bf G4TransformStore} -
195 a container for optionally storing created G4AffineTransform objects.
196 It is responsible for storing and providing access to transformations
197 that are constant at tracking time.
198
199\item {\bf G4AffineTransform} - a class for geometric affine transformations.
200 It supports efficient arbitrary rotation and transformation of vectors and
201 the computation of compound and inverse transformations. A
202 ``rotation flag'' is maintained internally for greater computational
203 efficiency for transforms that do not involve rotation.
204
205\item {\bf G4UserLimits} -
206 responsible for user limits on step size, ascribable to individual volumes.
207
208\end{itemize}
209
210Fig. \ref{figure:geom-1} shows a general overview, in UML notation, of
211the geometry design. A detailed collection of class diagrams from the
212geometry category is found in the Appendix.
213
214\begin{figure}
215\begin{center}
216% \addtolength{\textwidth}{3cm}
217\includegraphics[angle=0,scale=0.6]{OOAnalysisDesign/Geometry/overall.eps}
218\caption{Overview of the geometry}
219\label{figure:geom-1}
220\end{center}
221\end{figure}
222
223\section{Status of this chapter}
224
22527.06.05 subsection on design philosphy (from Geant4 general paper)
226 added by D.H. Wright \\
Note: See TracBrowser for help on using the repository browser.