[1208] | 1 | \chapter{Geometry} |
---|
| 2 | |
---|
| 3 | \section{Design Philosopy} |
---|
| 4 | The geometry category provides the ability to describe a geometrical structure |
---|
| 5 | and propagate particles efficiently through it. This is done in part with |
---|
| 6 | the aid of two central concepts, the {\it logical} and {\it physical} volumes. |
---|
| 7 | A logical volume represents a detector element of a given shape which may |
---|
| 8 | contain other volumes, and which may have other attributes. It has access to |
---|
| 9 | other information which is independent of its phyisical location in the |
---|
| 10 | detector, such as material and sensitive detector behavior. A physical volume |
---|
| 11 | represents the spatial positioning or placement of the logical volume with |
---|
| 12 | respect to an enclosing mother (logical) volume. Thus a hierarchical tree |
---|
| 13 | structure of volumes can be built with each volume containing smaller volumes |
---|
| 14 | (which may not overlap). Repetitive structures can be represented by |
---|
| 15 | specialized physical volumes, such as replicas and parameterized placements, |
---|
| 16 | sometimes resulting in a large savings in memory. |
---|
| 17 | |
---|
| 18 | In {\sc Geant4} the logical volume has been refined by defining the shape as |
---|
| 19 | a separate entity, called a {\it solid}. Solids with simple shapes, like |
---|
| 20 | rectilinear boxes, trapezoids, spherical or cylindrical sections or shells, |
---|
| 21 | each have their properties coded separately, in accord with the concept of |
---|
| 22 | {\it Constructed Solid Geometry (CSG)}. More complex solids are defined by |
---|
| 23 | their bounding surfaces, which can be planes, second-order surfaces or |
---|
| 24 | higher-order B-spline surfaces, and belong to the {\it Boundary |
---|
| 25 | Representations (BREP)} sub-category. |
---|
| 26 | |
---|
| 27 | Another way to build solids is by boolean combination - union, intersection |
---|
| 28 | and subtraction. The elemental solids should be CSGs. |
---|
| 29 | |
---|
| 30 | Although a detector is naturally and best described as by a hierarchy of |
---|
| 31 | volumes, efficiency is not critically dependent on this. An optimization |
---|
| 32 | technique, called voxelization, allows efficient navigation even in ``flat'' |
---|
| 33 | geometries, 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 | |
---|
| 210 | Fig. \ref{figure:geom-1} shows a general overview, in UML notation, of |
---|
| 211 | the geometry design. A detailed collection of class diagrams from the |
---|
| 212 | geometry 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 | |
---|
| 225 | 27.06.05 subsection on design philosphy (from Geant4 general paper) |
---|
| 226 | added by D.H. Wright \\ |
---|