| 1 | <HTML>
|
|---|
| 2 | <HEAD>
|
|---|
| 3 | <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
|
|---|
| 4 | <META NAME="GENERATOR" CONTENT="Mozilla/4.04 [en] (X11; I; AIX 4.1) [Netscape]">
|
|---|
| 5 | <!-- Changed by: Katsuya Amako, 4-Aug-1998 -->
|
|---|
| 6 | <!-- Changed by: Michel MAIRE, 3-Aug-1998 -->
|
|---|
| 7 | <!-- Changed by: Katsuya Amako, 30-Nov-1998 -->
|
|---|
| 8 | <!-- Changed by: Dennis Wright, 20-Nov-2001 -->
|
|---|
| 9 | <!-- Proof read by: Joe Chuma, 28-Jun-1999 -->
|
|---|
| 10 | </HEAD>
|
|---|
| 11 |
|
|---|
| 12 | <BODY>
|
|---|
| 13 | <BR>
|
|---|
| 14 |
|
|---|
| 15 | <TABLE WIDTH="100%" >
|
|---|
| 16 | <TR>
|
|---|
| 17 | <TD>
|
|---|
| 18 |
|
|---|
| 19 | </A>
|
|---|
| 20 | <A HREF="index.html">
|
|---|
| 21 | <IMG SRC="../../../../resources/html/IconsGIF/Contents.gif" ALT="Contents" HEIGHT=16 WIDTH=59></A>
|
|---|
| 22 | <A>
|
|---|
| 23 | <IMG SRC="../../../../resources/html/IconsGIF/PreviousGR.gif" ALT="Previous" HEIGHT=16 WIDTH=59></A>
|
|---|
| 24 | <A HREF="global.html">
|
|---|
| 25 | <IMG SRC="../../../../resources/html/IconsGIF/Next.gif" ALT="Next" HEIGHT=16 WIDTH=59></A>
|
|---|
| 26 | </TD>
|
|---|
| 27 |
|
|---|
| 28 | <TD ALIGN=RIGHT>
|
|---|
| 29 | <FONT COLOR="#238E23"><FONT SIZE=-1>
|
|---|
| 30 | <B>Geant4 User's Guide</B></FONT></FONT>
|
|---|
| 31 | <BR><FONT COLOR="#238E23"><FONT SIZE=-1>
|
|---|
| 32 | <B>For Application Developers</B> </FONT></FONT>
|
|---|
| 33 | <BR><FONT COLOR="#238E23"><FONT SIZE=-1>
|
|---|
| 34 | <B>Toolkit Fundamentals</B> </FONT></FONT></TD>
|
|---|
| 35 | </TR>
|
|---|
| 36 | </TABLE>
|
|---|
| 37 | <P><BR>
|
|---|
| 38 |
|
|---|
| 39 | <CENTER>
|
|---|
| 40 | <FONT COLOR="#238E23"><FONT SIZE=+3>
|
|---|
| 41 | <B>3.1 Class Categories and Domains</B></FONT></FONT>
|
|---|
| 42 | </CENTER>
|
|---|
| 43 | <P><BR>
|
|---|
| 44 |
|
|---|
| 45 | <HR ALIGN="Center" SIZE="7%">
|
|---|
| 46 |
|
|---|
| 47 | <P>
|
|---|
| 48 | <a name="3.1.1">
|
|---|
| 49 | <H2>3.1.1 What is a class category?</H2></a>
|
|---|
| 50 |
|
|---|
| 51 | In the design of a large software system such as Geant4, it is essential to
|
|---|
| 52 | partition it into smaller logical units. This makes the design well organized
|
|---|
| 53 | and easier to develop. Once the logical units are defined independent to
|
|---|
| 54 | each other as much as possible, they can be developed in parallel without
|
|---|
| 55 | serious interference.
|
|---|
| 56 | <P>
|
|---|
| 57 | In object-oriented analysis and design methodology by Grady Booch <a href="#GBooch">[1]</a>,
|
|---|
| 58 | class categories are used to create logical units. They are defined as
|
|---|
| 59 | "clusters of classes that are themselves cohesive, but are loosely coupled
|
|---|
| 60 | relative to other clusters." This means that a class category contains
|
|---|
| 61 | classes which have a close relationship (for example, the "has-a" relation).
|
|---|
| 62 | However, relationships between classes which belong to different class
|
|---|
| 63 | categories are weak, i.e., only limitted classes of these have "uses"
|
|---|
| 64 | relations. The class categories and their relations are presented by
|
|---|
| 65 | a class category diagram. The class category diagram designed for
|
|---|
| 66 | Geant4 is shown in the figure below. Each box in the figure represents
|
|---|
| 67 | a class category, and a "uses" relation by a straight line. The circle
|
|---|
| 68 | at an end of a straight line means the class category which has this
|
|---|
| 69 | circle uses the other category.
|
|---|
| 70 | <P>
|
|---|
| 71 | <center>
|
|---|
| 72 | <IMG SRC="../../../../Welcome/IntroductionToGeant4/html/introductionToGeant4.src/classCategory.gif">
|
|---|
| 73 | </center>
|
|---|
| 74 | <P>
|
|---|
| 75 | The file organization of the Geant4 codes follows basically the structure
|
|---|
| 76 | of this class cateogory. This <i>User's Manual</i> is also organized according
|
|---|
| 77 | to class categories.
|
|---|
| 78 | <P>
|
|---|
| 79 | In the development and maintenance of Geant4, one software team will
|
|---|
| 80 | be assigned to a class category. This team will have a responsibility to
|
|---|
| 81 | develop and maintain all classes belonging to the class category.
|
|---|
| 82 | <BR>
|
|---|
| 83 | <P>
|
|---|
| 84 |
|
|---|
| 85 | <HR>
|
|---|
| 86 | <a name="3.1.2">
|
|---|
| 87 | <H2>3.1.2 Class categories in Geant4</H2></a>
|
|---|
| 88 |
|
|---|
| 89 | The following is a brief summary of the role of each class category in Geant4.
|
|---|
| 90 | <P>
|
|---|
| 91 | <ol>
|
|---|
| 92 | <li><b>Run and Event</b>
|
|---|
| 93 | <p>
|
|---|
| 94 | These are categories related to the generation of events, interfaces
|
|---|
| 95 | to event generators, and any secondary particles produced. Their roles
|
|---|
| 96 | are principally to provide particles to be tracked to the Tracking Management.
|
|---|
| 97 | <p>
|
|---|
| 98 | <li><b>Tracking and Track</b>
|
|---|
| 99 | <p>
|
|---|
| 100 | These are categories related to propagating a particle by analyzing the factors
|
|---|
| 101 | limiting the step and applying the relevant physics processes. The important
|
|---|
| 102 | aspect of the design was that a generalized Geant4 physics process (or
|
|---|
| 103 | interaction) could perform actions, along a tracking step, either localized
|
|---|
| 104 | in space, or in time, or distributed in space and time (and all the possible
|
|---|
| 105 | combinations that could be built from these cases).
|
|---|
| 106 | <p>
|
|---|
| 107 | <li><b>Geometry and Magnetic Field</b>
|
|---|
| 108 | <p>
|
|---|
| 109 | These categories manage the geometrical definition of a detector
|
|---|
| 110 | (solid modeling) and the computation of distances to solids
|
|---|
| 111 | (also in a magnetic field). The Geant4 geometry
|
|---|
| 112 | solid modeler is based on the ISO STEP standard and it is fully compliant
|
|---|
| 113 | with it, in order to allow in future the exchange of geometrical information with CAD
|
|---|
| 114 | systems. A key feature of the Geant4 geometry is that the volume definitions
|
|---|
| 115 | are independent of the solid representation. By this abstract interface
|
|---|
| 116 | for the G4 solids, the tracking component works identically for various
|
|---|
| 117 | representations. The treatment of the propagation in the presence of fields
|
|---|
| 118 | has been provided within specified accuracy. An OO design allows us to
|
|---|
| 119 | exchange different numerical algorithms and/or different fields (not only
|
|---|
| 120 | B-field), without affecting any other component of the toolkit.
|
|---|
| 121 | <p>
|
|---|
| 122 | <li><b>Particle Definition and Matter</b>
|
|---|
| 123 | <p>
|
|---|
| 124 | These two categories manage the the definition of materials and particles.
|
|---|
| 125 | <p>
|
|---|
| 126 | <li><b>Physics</b>
|
|---|
| 127 | <p>
|
|---|
| 128 | This category manages all physics processes participating in the interactions
|
|---|
| 129 | of particles in matter. The abstract interface of physics processes allows
|
|---|
| 130 | multiple implementations of physics models per interaction or per channel.
|
|---|
| 131 | Models can be selected by energy range, particle type, material, etc. Data
|
|---|
| 132 | encapsulation and polymorphism make it possible to give transparent access
|
|---|
| 133 | to the cross sections (independently of the choice of reading from an ascii
|
|---|
| 134 | file, or of interpolating from a tabulated set, or of computing analytically
|
|---|
| 135 | from a formula). Electromagnetic and hadronic physics were handled in a
|
|---|
| 136 | uniform way in such a design, opening up the physics to the users.
|
|---|
| 137 | <p>
|
|---|
| 138 | <li><b>Hits and Digitization</b>
|
|---|
| 139 | <p>
|
|---|
| 140 | These two categories manage the creation of hits and their use for
|
|---|
| 141 | the digitization phase. The basic design and implementation of the Hits
|
|---|
| 142 | and Digi had been realized, and also several prototypes, test cases and
|
|---|
| 143 | scenarios had been developed before the alpha-release. Volumes (not necessarily
|
|---|
| 144 | the ones used by the tracking) are aggregated in sensitive detectors, while
|
|---|
| 145 | hits collections represent the logical read out of the detector. Different
|
|---|
| 146 | ways of creating and managing hits collections had been delivered and tested,
|
|---|
| 147 | notably for both single hits and calorimetry hits types. In all cases,
|
|---|
| 148 | hits collections had been successfully stored into and retrieved from an
|
|---|
| 149 | Object Data Base Management System.
|
|---|
| 150 | <p>
|
|---|
| 151 | <li><b>Visualization</b>
|
|---|
| 152 | <p>
|
|---|
| 153 | This manages the visualization of solids, trajectories and hits, and
|
|---|
| 154 | interacts with underlying graphical libraries (the Visualization class
|
|---|
| 155 | category). The basic and most frequently used graphics functionality had
|
|---|
| 156 | been implemented already by the alpha-release. The OO design of the visualization
|
|---|
| 157 | component allowed us to develop several drivers independently, such as
|
|---|
| 158 | for OpenGL and OpenInventor (for X11 and Windows), DAWN, Postscript (via
|
|---|
| 159 | DAWN) and VRML.
|
|---|
| 160 | <p>
|
|---|
| 161 | <li><b>Interfaces</b>
|
|---|
| 162 | <p>
|
|---|
| 163 | This category handles the production of the graphical user interface
|
|---|
| 164 | (GUI) and the interactions with external software (OODBMS, reconstruction
|
|---|
| 165 | etc.).
|
|---|
| 166 | <p>
|
|---|
| 167 | </ol>
|
|---|
| 168 | <P>
|
|---|
| 169 | <hr>
|
|---|
| 170 | <p>
|
|---|
| 171 | <table>
|
|---|
| 172 | <tr><td valign=top><a name="GBooch">[1]</a>
|
|---|
| 173 | <td>Grady Booch, Object-Oriented Analysis and Design with Applications
|
|---|
| 174 | The Benjamin/Cummings Publishing Co. Inc, 1994, ISBN 0-8053-5340-2
|
|---|
| 175 | </table>
|
|---|
| 176 | <P>
|
|---|
| 177 | <HR><A HREF="../../../../Authors/html/subjectsToAuthors.html">
|
|---|
| 178 | <I>About the authors</A></I>
|
|---|
| 179 | </BODY>
|
|---|
| 180 | </HTML>
|
|---|