| 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 \\
|
|---|