| 1 | <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
|
|---|
| 2 | <!--Converted with LaTeX2HTML 96.1-g (July 19, 1996) by Nikos Drakos (nikos@cbl.leeds.ac.uk), CBLU, University of Leeds -->
|
|---|
| 3 | <HTML>
|
|---|
| 4 | <HEAD>
|
|---|
| 5 | <TITLE>Getting started with Geant4: the Field</TITLE>
|
|---|
| 6 | <!-- Changed by: Katsuya Amako, 30-Nov-1998 -->
|
|---|
| 7 | <!-- Changed by: John APOSTOLAKIS, 7-Dec-1998 -->
|
|---|
| 8 | <!-- Proof read by: Joe Chuma, 29-Jun-1999 -->
|
|---|
| 9 | <!-- Changed by: Dennis Wright, 12-Dec-2002 -->
|
|---|
| 10 | <!-- Corrections for field changes: John Apostolakis, 17-Jun-2005 -->
|
|---|
| 11 | <!-- Corrections, changes by: John APOSTOLAKIS, 7-Jul-2005 -->
|
|---|
| 12 | </HEAD>
|
|---|
| 13 |
|
|---|
| 14 | <BODY>
|
|---|
| 15 | <P>
|
|---|
| 16 |
|
|---|
| 17 | <TABLE WIDTH="100%" >
|
|---|
| 18 | <TR>
|
|---|
| 19 | <TD>
|
|---|
| 20 | </A>
|
|---|
| 21 | <A HREF="index.html">
|
|---|
| 22 | <IMG SRC="../../../../resources/html/IconsGIF/Contents.gif" ALT="Contents" HEIGHT=16 WIDTH=59></A>
|
|---|
| 23 | <A HREF="material.html">
|
|---|
| 24 | <IMG SRC="../../../../resources/html/IconsGIF/Previous.gif" ALT="Previous" HEIGHT=16 WIDTH=59></A>
|
|---|
| 25 | <A HREF="hit.html">
|
|---|
| 26 | <IMG SRC="../../../../resources/html/IconsGIF/Next.gif" ALT="Next" HEIGHT=16 WIDTH=59></A>
|
|---|
| 27 | </TD>
|
|---|
| 28 |
|
|---|
| 29 | <TD ALIGN="Right"><FONT COLOR="#238E23"><FONT SIZE=-1>
|
|---|
| 30 | <B>Geant4 User's Guide</B> <BR>
|
|---|
| 31 | <B>For Application Developers</B> <BR>
|
|---|
| 32 | <B>Detector Definition and Response</B> </FONT></FONT> </TD>
|
|---|
| 33 | </TR>
|
|---|
| 34 | </TABLE>
|
|---|
| 35 | <P><BR>
|
|---|
| 36 |
|
|---|
| 37 |
|
|---|
| 38 | <CENTER><FONT COLOR="#238E23"><FONT SIZE=+3>
|
|---|
| 39 | <B>4.3 Electromagnetic Field</B> </FONT></FONT>
|
|---|
| 40 | </CENTER>
|
|---|
| 41 | <BR>
|
|---|
| 42 | <BR>
|
|---|
| 43 |
|
|---|
| 44 | <HR ALIGN="Center" SIZE="7%">
|
|---|
| 45 | <p>
|
|---|
| 46 |
|
|---|
| 47 | <a name="4.3.1">
|
|---|
| 48 | <H2>4.3.1 An Overview of Propagation in a Field</H2></a>
|
|---|
| 49 |
|
|---|
| 50 | <P>
|
|---|
| 51 | Geant4 is capable of describing and propagating in a variety of
|
|---|
| 52 | fields. Magnetic fields, electric fields and electromagnetic, uniform
|
|---|
| 53 | or non-uniform, can specified for a Geant4 setup. The
|
|---|
| 54 | propagation of tracks inside them can be performed to a
|
|---|
| 55 | user-defined accuracy. </P>
|
|---|
| 56 |
|
|---|
| 57 | <P>
|
|---|
| 58 | In order to propagate a track inside a field, the equation of motion
|
|---|
| 59 | of the particle in the field is integrated. In general, this is done
|
|---|
| 60 | using a Runge-Kutta method for the integration of ordinary differential
|
|---|
| 61 | equations. However, for specific cases where an analytical solution is
|
|---|
| 62 | known, it is possible to utilize this instead. Several Runge-Kutta
|
|---|
| 63 | methods are available, suitable for different conditions. In specific
|
|---|
| 64 | cases (such as a uniform field where the analytical solution is known)
|
|---|
| 65 | different solvers can also be used. In addition, when an approximate
|
|---|
| 66 | analytical solution is known, it is possible to utilize it in an
|
|---|
| 67 | iterative manner in order to converge to the solution to the precision
|
|---|
| 68 | required. This latter method is currently implemented and can be used
|
|---|
| 69 | particularly well for magnetic fields that are almost uniform. </P>
|
|---|
| 70 |
|
|---|
| 71 | <P>
|
|---|
| 72 | Once a method is chosen that calculates the track's propagation in
|
|---|
| 73 | a specific field, the curved path is broken up into linear chord
|
|---|
| 74 | segments. These chord segments are determined so that they closely
|
|---|
| 75 | approximate the curved path. The chords are then used to interrogate
|
|---|
| 76 | the Navigator as to whether the track has crossed a volume boundary.
|
|---|
| 77 | Several parameters are available to adjust the accuracy of the
|
|---|
| 78 | integration and the subsequent interrogation of the model geometry. </P>
|
|---|
| 79 |
|
|---|
| 80 | <P>
|
|---|
| 81 | How closely the set of chords approximates a curved trajectory is governed
|
|---|
| 82 | by a parameter called the <I>miss distance</I> (also called the <I>chord
|
|---|
| 83 | distance</I> ).
|
|---|
| 84 | This is an upper bound for the value of the sagitta - the distance between the
|
|---|
| 85 | 'real' curved trajectory and the approximate linear trajectory of the chord.
|
|---|
| 86 | By setting this parameter, the user can
|
|---|
| 87 | control the precision of the volume interrogation. Every attempt has been made
|
|---|
| 88 | to ensure that all volume interrogations will be made to an accuracy within
|
|---|
| 89 | this <I>miss distance</I>. </P>
|
|---|
| 90 | <P>
|
|---|
| 91 | <img src="electroMagneticField.src/MissDistance.jpg" width="629" height="168">
|
|---|
| 92 | </P>
|
|---|
| 93 |
|
|---|
| 94 | <P>
|
|---|
| 95 | Figure A: The curved trajectory will be approximated by chords, so that the
|
|---|
| 96 | maximum estimated distance between curve and chord is less than the the
|
|---|
| 97 | <i>miss distance</i>. </P>
|
|---|
| 98 | <P>
|
|---|
| 99 | In addition to the <I>miss distance</I> there are two more parameters which
|
|---|
| 100 | the user can set in order to adjust the accuracy (and performance) of
|
|---|
| 101 | tracking in a field. In particular these parameters govern the accuracy of
|
|---|
| 102 | the intersection with a volume boundary and the accuracy of the integration
|
|---|
| 103 | of other steps. As such they play an important role for tracking. </P>
|
|---|
| 104 |
|
|---|
| 105 | <P>
|
|---|
| 106 | The <I>delta intersection</I> parameter is the accuracy to which an
|
|---|
| 107 | intersection with a volume boundary is calculated. If a candidate boundary
|
|---|
| 108 | intersection is estimated to have a precision better than this, it is
|
|---|
| 109 | accepted. This parameter is especially important because it is used to limit
|
|---|
| 110 | a bias that our algorithm (for boundary crossing in a field) exhibits. This
|
|---|
| 111 | algorithm calculates the intersection with a volume boundary using a chord
|
|---|
| 112 | between two points on the curved particle trajectory. As such, the
|
|---|
| 113 | intersection point is always on the 'inside' of the curve. By setting a
|
|---|
| 114 | value for this parameter that is much smaller than some acceptable error,
|
|---|
| 115 | the user can limit the effect of this bias on, for example, the future
|
|---|
| 116 | estimation of the reconstructed particle momentum. </P>
|
|---|
| 117 | <P>
|
|---|
| 118 | <img src="electroMagneticField.src/IntersectionError.jpg" width="237" height="498"></P>
|
|---|
| 119 |
|
|---|
| 120 | <P>
|
|---|
| 121 | Figure B: The distance between the calculated chord intersection point C and
|
|---|
| 122 | a computed curve point D is used to determine whether C is an accurate
|
|---|
| 123 | representation of the intersection of the curved path ADB with a volume
|
|---|
| 124 | boundary. Here CD is likely too large, and a new intersection on the chord AD
|
|---|
| 125 | will be calculated.</P>
|
|---|
| 126 | <P>
|
|---|
| 127 | The <I>delta one step</I> parameter is the accuracy for the endpoint of
|
|---|
| 128 | 'ordinary' integration steps, those which do not intersect a volume boundary.
|
|---|
| 129 | This parameter is a limit on the estimated error of the endpoint of each
|
|---|
| 130 | physics step. It can be seen as akin to a statistical uncertainty and is not
|
|---|
| 131 | expected to contribute any systematic behavior to physical quantities. In
|
|---|
| 132 | contrast, the bias addressed by <I>delta intersection</I> is clearly
|
|---|
| 133 | correlated with potential systematic errors in the momentum of reconstructed
|
|---|
| 134 | tracks. Thus very strict limits on the intersection parameter should be used
|
|---|
| 135 | in tracking detectors or wherever the intersections are used to reconstruct a
|
|---|
| 136 | track's momentum. </P>
|
|---|
| 137 |
|
|---|
| 138 | <P>
|
|---|
| 139 | <I>Delta intersection</I> and <I>delta one step</I> are parameters of
|
|---|
| 140 | the Field Manager; the user can set them according to the demands of
|
|---|
| 141 | his application. Because it is possible to use more than one field
|
|---|
| 142 | manager, different values can be set for different detector regions. </P>
|
|---|
| 143 |
|
|---|
| 144 | <P>
|
|---|
| 145 | Note that reasonable values for the two parameters are strongly
|
|---|
| 146 | coupled: it does not make sense to request an accuracy of 1 nm for
|
|---|
| 147 | <I>delta intersection</I> and accept 100 μm for the
|
|---|
| 148 | <I>delta one step</I> error value. Nevertheless
|
|---|
| 149 | <I>delta intersection</I> is the more important of the two. It is
|
|---|
| 150 | recommended that these parameters should not differ significantly -
|
|---|
| 151 | certainly not by more than an order of magnitude. </P>
|
|---|
| 152 |
|
|---|
| 153 | <hr>
|
|---|
| 154 | <a name="4.3.2">
|
|---|
| 155 | <H2>4.3.2 Practical Aspects</H2></a>
|
|---|
| 156 |
|
|---|
| 157 | <B>Creating a Magnetic Field for a Detector</B>
|
|---|
| 158 | <P>
|
|---|
| 159 | The simplest way to define a field for a detector involves the
|
|---|
| 160 | following steps:
|
|---|
| 161 | <P>
|
|---|
| 162 | <ol>
|
|---|
| 163 | <li>create a field:
|
|---|
| 164 | <PRE>
|
|---|
| 165 | G4UniformMagField* magField
|
|---|
| 166 | = new G4UniformMagField(G4ThreeVector(0.,0.,fieldValue));
|
|---|
| 167 | </PRE>
|
|---|
| 168 | <li>set it as the default field:
|
|---|
| 169 | <PRE>
|
|---|
| 170 | G4FieldManager* fieldMgr
|
|---|
| 171 | = G4TransportationManager::GetTransportationManager()
|
|---|
| 172 | ->GetFieldManager();
|
|---|
| 173 | fieldMgr->SetDetectorField(magField);
|
|---|
| 174 | </PRE>
|
|---|
| 175 | <li>create the objects which calculate the trajectory:
|
|---|
| 176 | <PRE>
|
|---|
| 177 | fieldMgr->CreateChordFinder(magField);
|
|---|
| 178 | </PRE>
|
|---|
| 179 | </ol>
|
|---|
| 180 | <P>
|
|---|
| 181 | To change the accuracy of volume intersection use the <tt>SetDeltaChord</tt>
|
|---|
| 182 | method:
|
|---|
| 183 | <PRE>
|
|---|
| 184 | fieldMgr->GetChordFinder()->SetDeltaChord( G4double newValue);
|
|---|
| 185 | </PRE>
|
|---|
| 186 |
|
|---|
| 187 | <P>
|
|---|
| 188 | <B>Creating a Field for a Part of the Volume Hierarchy</B>
|
|---|
| 189 | <P> It is possible to create a field for a part of the detector. In particular
|
|---|
| 190 | it can describe the field (with pointer fEmField, for example) inside a
|
|---|
| 191 | logical volume and all its daughters. This can be done by simply creating a
|
|---|
| 192 | <tt>G4FieldManager</tt> and attaching it to a logical volume (with pointer,
|
|---|
| 193 | logicVolumeWithField, for example) or set of logical volumes.
|
|---|
| 194 | <PRE>
|
|---|
| 195 | G4bool allLocal = true;
|
|---|
| 196 | logicVolumeWithField->SetFieldManager(fEmField->GetLocalFieldManager(),allLocal);
|
|---|
| 197 | </PRE>
|
|---|
| 198 | </P>
|
|---|
| 199 | <P> </P>
|
|---|
| 200 | <P>You can then choose whether the logical volume's daughter volumes
|
|---|
| 201 | will also be given this new field. If so, the field will be 'pushed' into
|
|---|
| 202 | its daughters, unless they already have a field manager.</P>
|
|---|
| 203 |
|
|---|
| 204 | <B>Creating an Electric or Electromagnetic Field</B>
|
|---|
| 205 | <P>
|
|---|
| 206 | The design and implementation of the <i>Field</i> category allows and enables
|
|---|
| 207 | the use of an electric or combined electromagnetic field.
|
|---|
| 208 | These fields can also vary with time, as can magnetic fields.
|
|---|
| 209 |
|
|---|
| 210 | <P>
|
|---|
| 211 | Source listing 4.3.1 shows how to define a uniform electric field for the
|
|---|
| 212 | whole of a detector.
|
|---|
| 213 | <p>
|
|---|
| 214 | <center>
|
|---|
| 215 | <table border=2 cellpadding=10>
|
|---|
| 216 | <tr>
|
|---|
| 217 | <td>
|
|---|
| 218 | <PRE>
|
|---|
| 219 | // in the header file (or first)
|
|---|
| 220 | #include "G4EqMagElectricField.hh"
|
|---|
| 221 | #include "G4UniformElectricField.hh"
|
|---|
| 222 |
|
|---|
| 223 | ...
|
|---|
| 224 | G4ElectricField* fEMfield;
|
|---|
| 225 | G4EqMagElectricField* fEquation;
|
|---|
| 226 | G4MagIntegratorStepper* fStepper;
|
|---|
| 227 | G4FieldManager* fFieldMgr;
|
|---|
| 228 | G4double fMinStep ;
|
|---|
| 229 | G4ChordFinder* fChordFinder ;
|
|---|
| 230 |
|
|---|
| 231 | // in the source file
|
|---|
| 232 |
|
|---|
| 233 | {
|
|---|
| 234 | fEMfield = new G4UniformElectricField(
|
|---|
| 235 | G4ThreeVector(0.0,100000.0*kilovolt/cm,0.0));
|
|---|
| 236 |
|
|---|
| 237 | // Create an equation of motion for this field
|
|---|
| 238 | fEquation = new G4EqMagElectricField(fEMfield);
|
|---|
| 239 |
|
|---|
| 240 | G4int nvar = 8;
|
|---|
| 241 | fStepper = new G4ClassicalRK4( fEquation, nvar );
|
|---|
| 242 |
|
|---|
| 243 | // Get the global field manager
|
|---|
| 244 | fFieldManager= G4TransportationManager::GetTransportationManager()->
|
|---|
| 245 | GetFieldManager();
|
|---|
| 246 | // Set this field to the global field manager
|
|---|
| 247 | fFieldManager->SetDetectorField(fEMfield );
|
|---|
| 248 |
|
|---|
| 249 | fMinStep = 0.010*mm ; // minimal step of 10 microns
|
|---|
| 250 |
|
|---|
| 251 | fIntgrDriver = new G4MagInt_Driver(fMinStep,
|
|---|
| 252 | fStepper,
|
|---|
| 253 | fStepper->GetNumberOfVariables() );
|
|---|
| 254 |
|
|---|
| 255 | fChordFinder = new G4ChordFinder(fIntgrDriver);
|
|---|
| 256 | fFieldManager->SetChordFinder( fChordFinder );
|
|---|
| 257 |
|
|---|
| 258 | }
|
|---|
| 259 | </PRE>
|
|---|
| 260 | </td>
|
|---|
| 261 | </tr>
|
|---|
| 262 | <tr>
|
|---|
| 263 | <td align=center>
|
|---|
| 264 | Source listing 4.3.1<BR>
|
|---|
| 265 | How to define a uniform electric field for the whole of a detector, extracted
|
|---|
| 266 | from example in examples/extended/field/field02 .
|
|---|
| 267 | </td>
|
|---|
| 268 | </tr>
|
|---|
| 269 | </table></center>
|
|---|
| 270 |
|
|---|
| 271 |
|
|---|
| 272 | <P> An example with an electric field is examples/extended/field/field02, where
|
|---|
| 273 | the class F02ElectricFieldSetup demonstrates how to set these and other
|
|---|
| 274 | parameters, and how to choose different Integration Steppers. </P>
|
|---|
| 275 |
|
|---|
| 276 | The user can also create their own type of field, inheriting from
|
|---|
| 277 | <tt>G4VField</tt>,
|
|---|
| 278 | and an associated Equation of Motion class (inheriting from <tt>G4EqRhs</tt>)
|
|---|
| 279 | to simulate other types of fields.
|
|---|
| 280 |
|
|---|
| 281 | <P>
|
|---|
| 282 | <B>Choosing a Stepper</B></P>
|
|---|
| 283 | <P>
|
|---|
| 284 | Runge-Kutta integration is used to compute the motion of a charged
|
|---|
| 285 | track in a general field. There are many general steppers from which
|
|---|
| 286 | to choose, of low and high order, and specialized steppers for pure
|
|---|
| 287 | magnetic fields. By default, Geant4 uses the classical fourth-order
|
|---|
| 288 | Runge-Kutta stepper, which is general purpose and robust. If the field
|
|---|
| 289 | is known to have specific properties, lower or higher order steppers
|
|---|
| 290 | can be used to obtain the same quality results using fewer computing
|
|---|
| 291 | cycles. </P>
|
|---|
| 292 |
|
|---|
| 293 | <P>
|
|---|
| 294 | In particular, if the field is calculated from a field map, a lower
|
|---|
| 295 | order stepper is recommended. The less smooth the field is, the lower
|
|---|
| 296 | the order of the stepper that should be used. The choice of lower
|
|---|
| 297 | order steppers includes the third order stepper <tt>G4SimpleHeum</tt>, the
|
|---|
| 298 | second order <tt>G4ImplicitEuler</tt> and <tt>G4SimpleRunge</tt>,
|
|---|
| 299 | and the first order
|
|---|
| 300 | <tt>G4ExplicitEuler</tt>. A first order stepper would be useful only for
|
|---|
| 301 | very rough fields. For somewhat smooth fields (intermediate), the
|
|---|
| 302 | choice between second and third order steppers should be made by
|
|---|
| 303 | trial and error. Trying a few different types of steppers for a particular
|
|---|
| 304 | field or application is suggested if maximum performance is a goal. </P>
|
|---|
| 305 |
|
|---|
| 306 | The choice of stepper depends on the type of field: magnetic or general.
|
|---|
| 307 | A general field can be an electric or electromagnetic field,
|
|---|
| 308 | it can be a magnetic field or a user-defined field (which requires
|
|---|
| 309 | a user-defined equation of motion.)
|
|---|
| 310 |
|
|---|
| 311 | For a general field several steppers are available as alternatives to the
|
|---|
| 312 | default (<tt>G4ClassicalRK4</tt>):
|
|---|
| 313 | <PRE>
|
|---|
| 314 | G4int nvar = 8; // To integrate time & energy
|
|---|
| 315 | // in addition to position, momentum
|
|---|
| 316 | G4EqMagElectricField* fEquation= new G4EqMagElectricField(fEMfield);
|
|---|
| 317 |
|
|---|
| 318 | fStepper = new G4SimpleHeum( fEquation, nvar );
|
|---|
| 319 | // 3rd order, a good alternative to ClassicalRK
|
|---|
| 320 | fStepper = new G4SimpleRunge( fEquation, nvar );
|
|---|
| 321 | // 2nd order, for less smooth fields
|
|---|
| 322 | fStepper = new G4CashKarpRKF45( fEquation );
|
|---|
| 323 | // 4/5th order for very smooth fields
|
|---|
| 324 | </PRE>
|
|---|
| 325 |
|
|---|
| 326 | <P>
|
|---|
| 327 | Specialized steppers for pure magnetic fields are also available.
|
|---|
| 328 | They take into account the fact that a local trajectory in a slowly varying
|
|---|
| 329 | field will not vary significantly from a helix. Combining this in
|
|---|
| 330 | with a variation the Runge-Kutta method can provide higher accuracy at lower
|
|---|
| 331 | computational cost when large steps are possible. </P>
|
|---|
| 332 |
|
|---|
| 333 | <PRE>
|
|---|
| 334 | G4Mag_UsualEqRhs*
|
|---|
| 335 | fEquation = new G4Mag_UsualEqRhs(fMagneticField);
|
|---|
| 336 | fStepper = new G4HelixImplicitEuler( fEquation );
|
|---|
| 337 | // Note that for magnetic field that do not vary with time,
|
|---|
| 338 | // the default number of variables suffices.
|
|---|
| 339 |
|
|---|
| 340 | // or ..
|
|---|
| 341 | fStepper = new G4HelixExplicitEuler( fEquation );
|
|---|
| 342 | fStepper = new G4HelixSimpleRunge( fEquation );
|
|---|
| 343 | </PRE>
|
|---|
| 344 |
|
|---|
| 345 | <P>
|
|---|
| 346 | You can choose an alternative stepper either when the field manager
|
|---|
| 347 | is constructed or later.
|
|---|
| 348 | At the construction of the ChordFinder it is an optional argument:
|
|---|
| 349 |
|
|---|
| 350 | <PRE>
|
|---|
| 351 | G4ChordFinder( G4MagneticField* itsMagField,
|
|---|
| 352 | G4double stepMinimum = 1.0e-2 * mm,
|
|---|
| 353 | G4MagIntegratorStepper* pItsStepper = 0 );
|
|---|
| 354 | </PRE>
|
|---|
| 355 |
|
|---|
| 356 | To change the stepper at a later time use
|
|---|
| 357 | <PRE>
|
|---|
| 358 | pChordFinder->GetIntegrationDriver()
|
|---|
| 359 | ->RenewStepperAndAdjust( newStepper );
|
|---|
| 360 | </PRE>
|
|---|
| 361 | <BR>
|
|---|
| 362 |
|
|---|
| 363 | <p>
|
|---|
| 364 | <B>How to Adjust the Accuracy of Propagation</B></p>
|
|---|
| 365 | <p>In order to obtain a particular accuracy in tracking particles through an
|
|---|
| 366 | electromagnetic field, it is necessary to adjust the parameters of the field
|
|---|
| 367 | propagation module. In the following section, some of these additional
|
|---|
| 368 | parameters are discussed.</p>
|
|---|
| 369 | <p>
|
|---|
| 370 | When integration is used to calculate the trajectory, it is necessary to
|
|---|
| 371 | determine an acceptable level of numerical imprecision in order to get
|
|---|
| 372 | performant simulation with acceptable errors. The parameters in Geant4 tell
|
|---|
| 373 | the field module what level of integration inaccuracy is acceptable.</p>
|
|---|
| 374 | <p> In all quantities which are integrated (position, momentum, energy) there
|
|---|
| 375 | will be errors. Here, however, we focus on the error in two key quantities:
|
|---|
| 376 | the position and the momentum. (The error in the energy will come from the
|
|---|
| 377 | momentum integration). </p>
|
|---|
| 378 | <p>
|
|---|
| 379 | Three parameters exist which are relevant to the integration accuracy.
|
|---|
| 380 | DeltaOneStep is a distance and is roughly the position error which is
|
|---|
| 381 | acceptable in an integration step. Since many integration steps may be
|
|---|
| 382 | required for a single physics step, DeltaOneStep should be a fraction of the
|
|---|
| 383 | average physics step size. The next two parameters impose a further limit on
|
|---|
| 384 | the relative error of the position/momentum inaccuracy. EpsilonMin and
|
|---|
| 385 | EpsilonMax impose a minimum and maximum on this relative error -
|
|---|
| 386 | and take precedence over DeltaOneStep. (Note: if you set
|
|---|
| 387 | EpsilonMin=EpsilonMax=your-value, then all steps will be made to this
|
|---|
| 388 | relative precision.</p>
|
|---|
| 389 |
|
|---|
| 390 | <center>
|
|---|
| 391 | <table border=2 cellpadding=10>
|
|---|
| 392 | <tr>
|
|---|
| 393 | <td>
|
|---|
| 394 | <PRE>
|
|---|
| 395 | G4FieldManager *globalFieldManager;
|
|---|
| 396 |
|
|---|
| 397 | G4TransportationManager *transportMgr=
|
|---|
| 398 | G4TransportationManager::GetTransportationManager();
|
|---|
| 399 |
|
|---|
| 400 | globalFieldManager = transportMgr->GetFieldManager();
|
|---|
| 401 | // Relative accuracy values:
|
|---|
| 402 | G4double minEps= 1.0e-5; // Minimum & value for smallest steps
|
|---|
| 403 | G4double maxEps= 1.0e-4; // Maximum & value for largest steps
|
|---|
| 404 |
|
|---|
| 405 | globalFieldManager->SetMinimumEpsilonStep( minEps );
|
|---|
| 406 | globalFieldManager->SetMaximumEpsilonStep( maxEps );
|
|---|
| 407 | globalFieldManager->SetDeltaOneStep( 0.5e-3 * mm ); // 0.5 micrometer
|
|---|
| 408 |
|
|---|
| 409 | G4cout << "EpsilonStep: set min= " << minEps << " max= " << maxEps << G4endl;
|
|---|
| 410 | </PRE>
|
|---|
| 411 | </td>
|
|---|
| 412 | </tr>
|
|---|
| 413 | <tr>
|
|---|
| 414 | <td align=center>
|
|---|
| 415 | Source listing 4.3.2<BR>
|
|---|
| 416 | How to set accuracy parameters for the 'global' field of the setup.
|
|---|
| 417 | </td>
|
|---|
| 418 | </tr>
|
|---|
| 419 | </table></center>
|
|---|
| 420 | <P>
|
|---|
| 421 |
|
|---|
| 422 | <p>
|
|---|
| 423 | We note that the relevant parameters above limit the inaccuracy in each step.
|
|---|
| 424 | The final inaccuracy due to the full trajectory will accumulate!</p>
|
|---|
| 425 | <p>
|
|---|
| 426 | The exact point at which a track crosses a boundary is also calculated with
|
|---|
| 427 | finite accuracy. To limit this inaccuracy, a parameter called
|
|---|
| 428 | DeltaIntersection is used. This is a maximum for the inaccuracy of a single
|
|---|
| 429 | boundary crossing. Thus the accuracy of the position of the track after a
|
|---|
| 430 | number of boundary crossings is directly proportional to the number of
|
|---|
| 431 | boundaries.</p>
|
|---|
| 432 |
|
|---|
| 433 | <p>
|
|---|
| 434 | <b>Choosing different accuracies for the same volume</b></p>
|
|---|
| 435 | <p>
|
|---|
| 436 | It is possible to create a FieldManager which has different properties for
|
|---|
| 437 | particles of different momenta (or depending on other parameters of a track).
|
|---|
| 438 | This is useful, for example, in obtaining high accuracy for 'important' tracks
|
|---|
| 439 | (e.g. muons) and accept less accuracy in tracking others (e.g. electrons). To
|
|---|
| 440 | use this, you must create your own field manager which uses the method</p>
|
|---|
| 441 | <p>
|
|---|
| 442 | void ConfigureForTrack( const G4Track * );</p>
|
|---|
| 443 | <p>
|
|---|
| 444 | to configure itself using the parameters of the current track. An example of
|
|---|
| 445 | this will be available in examples/extended/field05.</p>
|
|---|
| 446 | <p>
|
|---|
| 447 | <b>Parameters that must scale with problem size</b></p>
|
|---|
| 448 | <p>
|
|---|
| 449 | The default settings of this module are for problems with the physical size
|
|---|
| 450 | of a typical high energy physics setup, that is, distances smaller than about
|
|---|
| 451 | one kilometer. A few parameters are necessary to carry this information to
|
|---|
| 452 | the magnetic field module, and must typically be rescaled for problems of
|
|---|
| 453 | vastly different sizes in order to get reasonable performance and
|
|---|
| 454 | robustness. Two of these parameters are the maximum acceptable step and
|
|---|
| 455 | the minimum step size.</p>
|
|---|
| 456 |
|
|---|
| 457 | <p>
|
|---|
| 458 | The <b>maximum acceptable step</b> should be set to a distance larger than
|
|---|
| 459 | the biggest reasonable step. If the apparatus in a setup has a diameter of
|
|---|
| 460 | two meters, a likely maximum acceptable steplength would be 10 meters. A
|
|---|
| 461 | particle could then take large spiral steps, but would not attempt to take,
|
|---|
| 462 | for example, a 1000-meter-long step in the case of a very low-density
|
|---|
| 463 | material. Similarly, for problems of a planetary scale, such as the earth
|
|---|
| 464 | with its radius of roughly 6400 km, a maximum acceptabe steplength of a few
|
|---|
| 465 | times this value would be reasonable.</p>
|
|---|
| 466 | <p>
|
|---|
| 467 | An upper limit for the size of a step
|
|---|
| 468 | is a parameter of <tt>G4PropagatorInField</tt>, and can be
|
|---|
| 469 | set by calling its <tt>SetLargestAcceptableStep</tt> method.</p>
|
|---|
| 470 |
|
|---|
| 471 | <p>
|
|---|
| 472 | The <b>minimum step size</b> is used during integration to limit the
|
|---|
| 473 | amount of work in difficult cases. It is possible that strong fields or
|
|---|
| 474 | integration problems can force the integrator to try very small steps;
|
|---|
| 475 | this parameter stops them from becoming unnecessarily small.</p>
|
|---|
| 476 | <p>
|
|---|
| 477 | Trial steps smaller than this parameter will be treated with less accuracy,
|
|---|
| 478 | and may even be ignored, depending on the situation.</p>
|
|---|
| 479 | <p>
|
|---|
| 480 | The minimum step size is a parameter of the MagInt_Driver, but can be set in
|
|---|
| 481 | the contstructor of G4ChordFinder, as in the source listing above.</p>
|
|---|
| 482 |
|
|---|
| 483 |
|
|---|
| 484 | <p><B>Known Issues</B> </p>
|
|---|
| 485 | <P>
|
|---|
| 486 | Currently it is computationally expensive to change the <I>miss distance</I>
|
|---|
| 487 | to very small values, as it causes tracks to be limited to curved sections
|
|---|
| 488 | whose 'bend' is smaller than this value. (The bend is the distance of the
|
|---|
| 489 | mid-point from the chord between endpoints.) For tracks with small curvature
|
|---|
| 490 | (typically low momentum particles in strong fields) this can cause a large
|
|---|
| 491 | number of steps
|
|---|
| 492 | <ul>
|
|---|
| 493 | <li>even in areas where there are no volumes to intersect
|
|---|
| 494 | (something that is expected to be addressed in future development,
|
|---|
| 495 | in which the safety will be utilized to partially alleviate this
|
|---|
| 496 | limitation)
|
|---|
| 497 |
|
|---|
| 498 | <li>especially in a region near a volume boundary
|
|---|
| 499 | (in which case it is necessary in order to discover
|
|---|
| 500 | whether a track might intersect a volume for only a short distance.)
|
|---|
| 501 | </ul>
|
|---|
| 502 | Requiring such precision at the intersection is clearly expensive, and new
|
|---|
| 503 | development would be necessary to minimize the expense.
|
|---|
| 504 |
|
|---|
| 505 | <P>
|
|---|
| 506 | By contrast, changing the intersection parameter is less computationally
|
|---|
| 507 | expensive. It causes further calculation for only a fraction of the steps,
|
|---|
| 508 | in particular those that intersect a volume boundary. </P>
|
|---|
| 509 |
|
|---|
| 510 | <BR>
|
|---|
| 511 |
|
|---|
| 512 | <hr>
|
|---|
| 513 | <a name="4.3.3">
|
|---|
| 514 | <H2>4.3.3 Spin Tracking</H2></a>
|
|---|
| 515 |
|
|---|
| 516 | The effects of a particle's motion on the precession of its spin angular
|
|---|
| 517 | momentum in slowly varying external fields are simulated. The
|
|---|
| 518 | relativistic equation of motion for spin is known as the BMT equation.
|
|---|
| 519 | The equation demonstrates a
|
|---|
| 520 | remarkable property; in a purely magnetic field, in vacuum, and
|
|---|
| 521 | neglecting small anomalous magnetic moments, the particle's spin
|
|---|
| 522 | precesses in such a manner that the longitudinal polarization remains a
|
|---|
| 523 | constant, whatever the motion of the particle. But when the particle
|
|---|
| 524 | interacts with electric fields of the medium and multiple scatters, the
|
|---|
| 525 | spin, which is related to the particle's magnetic moment, does not
|
|---|
| 526 | participate, and the need thus arises to propagate it independent of the
|
|---|
| 527 | momentum vector. In the case of a polarized muon beam, for example, it
|
|---|
| 528 | is important to predict the muon's spin direction at decay-time in
|
|---|
| 529 | order to simulate the decay electron (Michel) distribution correctly.
|
|---|
| 530 | <P>
|
|---|
| 531 | In order to track the spin of a particle in a magnetic field, you need to code
|
|---|
| 532 | the following:
|
|---|
| 533 |
|
|---|
| 534 | <P>
|
|---|
| 535 | <ol>
|
|---|
| 536 | <li> in your DetectorConstruction
|
|---|
| 537 | <PRE>
|
|---|
| 538 | #include "G4Mag_SpinEqRhs.hh"
|
|---|
| 539 |
|
|---|
| 540 | G4Mag_EqRhs* fEquation = new G4Mag_SpinEqRhs(magField);
|
|---|
| 541 |
|
|---|
| 542 | G4MagIntegratorStepper* pStepper = new G4ClassicalRK4(fEquation,12);
|
|---|
| 543 | <B>notice the 12 </B>
|
|---|
| 544 | </PRE>
|
|---|
| 545 | <P>
|
|---|
| 546 | <li> in your PrimaryGenerator
|
|---|
| 547 | <PRE>
|
|---|
| 548 | particleGun->SetParticlePolarization(G4ThreeVector p)
|
|---|
| 549 | </PRE>
|
|---|
| 550 |
|
|---|
| 551 | for example:
|
|---|
| 552 |
|
|---|
| 553 | <PRE>
|
|---|
| 554 | particleGun->
|
|---|
| 555 | SetParticlePolarization(-(particleGun->GetParticleMomentumDirection()));
|
|---|
| 556 | </PRE>
|
|---|
| 557 |
|
|---|
| 558 | or
|
|---|
| 559 |
|
|---|
| 560 | <PRE>
|
|---|
| 561 | particleGun->
|
|---|
| 562 | SetParticlePolarization(particleGun->GetParticleMomentumDirection()
|
|---|
| 563 | .cross(G4ThreeVector(0.,1.,0.)));
|
|---|
| 564 | </PRE>
|
|---|
| 565 |
|
|---|
| 566 | where you set the initial spin direction.
|
|---|
| 567 |
|
|---|
| 568 | </ol>
|
|---|
| 569 | </P>
|
|---|
| 570 |
|
|---|
| 571 | While the G4Mag_SpinEqRhs class constructor
|
|---|
| 572 |
|
|---|
| 573 | <PRE>
|
|---|
| 574 | G4Mag_SpinEqRhs::G4Mag_SpinEqRhs( G4MagneticField* MagField )
|
|---|
| 575 | : G4Mag_EqRhs( MagField )
|
|---|
| 576 | {
|
|---|
| 577 | anomaly = 1.165923e-3;
|
|---|
| 578 | }
|
|---|
| 579 | </PRE>
|
|---|
| 580 |
|
|---|
| 581 | sets the muon anomaly by default, the class also comes with the public method:
|
|---|
| 582 |
|
|---|
| 583 | <PRE>
|
|---|
| 584 | inline void SetAnomaly(G4double a) { anomaly = a; }
|
|---|
| 585 | </PRE>
|
|---|
| 586 |
|
|---|
| 587 | with which you can set the magnetic anomaly to any value you require.
|
|---|
| 588 |
|
|---|
| 589 | <P>
|
|---|
| 590 | For the moment, the code is written such that field tracking of the spin is
|
|---|
| 591 | done only for particles with non-zero charge. Please, see the Forum posting:
|
|---|
| 592 |
|
|---|
| 593 | <PRE>
|
|---|
| 594 | http://geant4-hn.slac.stanford.edu:5090/HyperNews/public/get/emfields/88/3/1.html
|
|---|
| 595 | </PRE>
|
|---|
| 596 |
|
|---|
| 597 | for modifications the user is required to make to facilitate neutron spin
|
|---|
| 598 | tracking.
|
|---|
| 599 | </P>
|
|---|
| 600 |
|
|---|
| 601 | <BR>
|
|---|
| 602 |
|
|---|
| 603 | <HR><A HREF="../../../../Authors/html/subjectsToAuthors.html">
|
|---|
| 604 | <I>About the authors</i></A> <p></P>
|
|---|
| 605 | </BODY>
|
|---|
| 606 | </HTML>
|
|---|
| 607 |
|
|---|
| 608 |
|
|---|