[904] | 1 | <!-- ******************************************************** --> |
---|
| 2 | <!-- --> |
---|
| 3 | <!-- [History] --> |
---|
| 4 | <!-- Changed by: Katsuya Amako, 30-Nov-1998 --> |
---|
| 5 | <!-- Converted with LaTeX2HTML 96.1-g (July 19, 1996) by --> |
---|
| 6 | <!-- Nikos Drakos (nikos@cbl.leeds.ac.uk), --> |
---|
| 7 | <!-- CBLU, University of Leeds --> |
---|
| 8 | <!-- Changed by: John APOSTOLAKIS, 7-Dec-1998 --> |
---|
| 9 | <!-- Proof read by: Joe Chuma, 29-Jun-1999 --> |
---|
| 10 | <!-- Changed by: Dennis Wright, 12-Dec-2002 --> |
---|
| 11 | <!-- Corrections for field changes: John Apostolakis, --> |
---|
| 12 | <!-- 17-Jun-2005 --> |
---|
| 13 | <!-- Corrections, changes by: John APOSTOLAKIS, 7-Jul-2005 --> |
---|
| 14 | <!-- Converted to DocBook: Katsuya Amako, Aug-2006 --> |
---|
[1222] | 15 | <!-- Corrections, changes by: John APOSTOLAKIS,15-Dec-2009 --> |
---|
[904] | 16 | <!-- --> |
---|
| 17 | <!-- ******************************************************** --> |
---|
| 18 | |
---|
| 19 | |
---|
| 20 | <!-- ******************* Section (Level#1) ****************** --> |
---|
| 21 | <sect1 id="sect.EMField"> |
---|
| 22 | <title> |
---|
| 23 | Electromagnetic Field |
---|
| 24 | </title> |
---|
| 25 | |
---|
| 26 | |
---|
| 27 | <!-- ******************* Section (Level#2) ****************** --> |
---|
| 28 | <sect2 id="sect.EMField.Overview"> |
---|
| 29 | <title> |
---|
| 30 | An Overview of Propagation in a Field |
---|
| 31 | </title> |
---|
| 32 | |
---|
| 33 | <para> |
---|
| 34 | Geant4 is capable of describing and propagating in a variety of |
---|
| 35 | fields. Magnetic fields, electric fields and electromagnetic, |
---|
| 36 | uniform or non-uniform, can specified for a Geant4 setup. The |
---|
| 37 | propagation of tracks inside them can be performed to a |
---|
| 38 | user-defined accuracy. |
---|
| 39 | </para> |
---|
| 40 | |
---|
| 41 | <para> |
---|
| 42 | In order to propagate a track inside a field, the equation of |
---|
| 43 | motion of the particle in the field is integrated. In general, this |
---|
| 44 | is done using a Runge-Kutta method for the integration of ordinary |
---|
| 45 | differential equations. However, for specific cases where an |
---|
| 46 | analytical solution is known, it is possible to utilize this |
---|
| 47 | instead. Several Runge-Kutta methods are available, suitable for |
---|
| 48 | different conditions. In specific cases (such as a uniform field |
---|
| 49 | where the analytical solution is known) different solvers can also |
---|
| 50 | be used. In addition, when an approximate analytical solution is |
---|
| 51 | known, it is possible to utilize it in an iterative manner in order |
---|
| 52 | to converge to the solution to the precision required. This latter |
---|
| 53 | method is currently implemented and can be used particularly well |
---|
| 54 | for magnetic fields that are almost uniform. |
---|
| 55 | </para> |
---|
| 56 | |
---|
| 57 | <para> |
---|
| 58 | Once a method is chosen that calculates the track's propagation |
---|
| 59 | in a specific field, the curved path is broken up into linear chord |
---|
| 60 | segments. These chord segments are determined so that they closely |
---|
| 61 | approximate the curved path. The chords are then used to |
---|
| 62 | interrogate the Navigator as to whether the track has crossed a |
---|
| 63 | volume boundary. Several parameters are available to adjust the |
---|
| 64 | accuracy of the integration and the subsequent interrogation of the |
---|
| 65 | model geometry. |
---|
| 66 | </para> |
---|
| 67 | |
---|
| 68 | <para> |
---|
| 69 | How closely the set of chords approximates a curved trajectory |
---|
| 70 | is governed by a parameter called the <emphasis>miss distance</emphasis> (also |
---|
| 71 | called the <emphasis>chord distance</emphasis> ). This is an upper bound for the |
---|
| 72 | value of the sagitta - the distance between the 'real' curved |
---|
| 73 | trajectory and the approximate linear trajectory of the chord. By |
---|
| 74 | setting this parameter, the user can control the precision of the |
---|
| 75 | volume interrogation. Every attempt has been made to ensure that |
---|
| 76 | all volume interrogations will be made to an accuracy within this |
---|
| 77 | <emphasis>miss distance</emphasis>. |
---|
| 78 | |
---|
| 79 | <figure id="fig.EMField_1"> |
---|
| 80 | <title> |
---|
| 81 | The curved trajectory will be approximated by chords, |
---|
| 82 | so that the maximum estimated distance between curve and chord is |
---|
| 83 | less than the the <emphasis>miss distance</emphasis>. |
---|
| 84 | </title> |
---|
| 85 | <mediaobject> |
---|
| 86 | <imageobject role="fo"> |
---|
| 87 | <imagedata fileref="./AllResources/Detector/electroMagneticField.src/MissDistance.jpg" |
---|
| 88 | format="JPG" contentwidth="12.0cm" align="center" /> |
---|
| 89 | </imageobject> |
---|
| 90 | <imageobject role="html"> |
---|
| 91 | <imagedata fileref="./AllResources/Detector/electroMagneticField.src/MissDistance.jpg" |
---|
| 92 | format="JPG" align="center" /> |
---|
| 93 | </imageobject> |
---|
| 94 | <textobject> |
---|
| 95 | <phrase>Miss Distance</phrase> |
---|
| 96 | </textobject> |
---|
| 97 | </mediaobject> |
---|
| 98 | </figure> |
---|
| 99 | </para> |
---|
| 100 | |
---|
| 101 | <para> |
---|
| 102 | In addition to the <emphasis>miss distance</emphasis> there are two more |
---|
| 103 | parameters which the user can set in order to adjust the accuracy |
---|
| 104 | (and performance) of tracking in a field. In particular these |
---|
| 105 | parameters govern the accuracy of the intersection with a volume |
---|
| 106 | boundary and the accuracy of the integration of other steps. As |
---|
| 107 | such they play an important role for tracking. |
---|
| 108 | </para> |
---|
| 109 | |
---|
| 110 | <para> |
---|
| 111 | The <emphasis>delta intersection</emphasis> parameter is the accuracy to which |
---|
| 112 | an intersection with a volume boundary is calculated. If a |
---|
| 113 | candidate boundary intersection is estimated to have a precision |
---|
| 114 | better than this, it is accepted. This parameter is especially |
---|
| 115 | important because it is used to limit a bias that our algorithm |
---|
| 116 | (for boundary crossing in a field) exhibits. This algorithm |
---|
| 117 | calculates the intersection with a volume boundary using a chord |
---|
| 118 | between two points on the curved particle trajectory. As such, the |
---|
| 119 | intersection point is always on the 'inside' of the curve. By |
---|
| 120 | setting a value for this parameter that is much smaller than some |
---|
| 121 | acceptable error, the user can limit the effect of this bias on, |
---|
| 122 | for example, the future estimation of the reconstructed particle |
---|
| 123 | momentum. |
---|
| 124 | |
---|
| 125 | <figure id="fig.EMField_2"> |
---|
| 126 | <title> |
---|
| 127 | The distance between the calculated chord intersection |
---|
| 128 | point C and a computed curve point D is used to determine whether C |
---|
| 129 | is an accurate representation of the intersection of the curved |
---|
| 130 | path ADB with a volume boundary. Here CD is likely too large, and a |
---|
| 131 | new intersection on the chord AD will be calculated. |
---|
| 132 | </title> |
---|
| 133 | <mediaobject> |
---|
| 134 | <imageobject role="fo"> |
---|
| 135 | <imagedata fileref="./AllResources/Detector/electroMagneticField.src/IntersectionError.jpg" |
---|
| 136 | format="JPG" contentdepth="5.0cm" align="center" /> |
---|
| 137 | </imageobject> |
---|
| 138 | <imageobject role="html"> |
---|
| 139 | <imagedata fileref="./AllResources/Detector/electroMagneticField.src/IntersectionError.jpg" |
---|
| 140 | format="JPG" align="center" /> |
---|
| 141 | </imageobject> |
---|
| 142 | <textobject> |
---|
| 143 | <phrase>Figure: The distance between the calculated chord intersection |
---|
| 144 | point and a computed curve point.</phrase> |
---|
| 145 | </textobject> |
---|
| 146 | </mediaobject> |
---|
| 147 | </figure> |
---|
| 148 | </para> |
---|
| 149 | |
---|
| 150 | <para> |
---|
| 151 | The <emphasis>delta one step</emphasis> parameter is the accuracy for the |
---|
| 152 | endpoint of 'ordinary' integration steps, those which do not |
---|
| 153 | intersect a volume boundary. This parameter is a limit on the |
---|
| 154 | estimated error of the endpoint of each physics step. It can be |
---|
| 155 | seen as akin to a statistical uncertainty and is not expected to |
---|
| 156 | contribute any systematic behavior to physical quantities. In |
---|
| 157 | contrast, the bias addressed by <emphasis>delta intersection</emphasis> is |
---|
| 158 | clearly correlated with potential systematic errors in the momentum |
---|
| 159 | of reconstructed tracks. Thus very strict limits on the |
---|
| 160 | intersection parameter should be used in tracking detectors or |
---|
| 161 | wherever the intersections are used to reconstruct a track's |
---|
| 162 | momentum. |
---|
| 163 | </para> |
---|
| 164 | |
---|
| 165 | <para> |
---|
| 166 | <emphasis>Delta intersection</emphasis> and <emphasis>delta one step</emphasis> are |
---|
| 167 | parameters of the Field Manager; the user can set them according to |
---|
| 168 | the demands of his application. Because it is possible to use more |
---|
| 169 | than one field manager, different values can be set for different |
---|
| 170 | detector regions. |
---|
| 171 | </para> |
---|
| 172 | |
---|
| 173 | <para> |
---|
| 174 | Note that reasonable values for the two parameters are strongly |
---|
| 175 | coupled: it does not make sense to request an accuracy of 1 nm for |
---|
| 176 | <emphasis>delta intersection</emphasis> and accept 100 &#956m for the |
---|
| 177 | <emphasis>delta one step</emphasis> error value. Nevertheless <emphasis>delta |
---|
| 178 | intersection</emphasis> is the more important of the two. It is |
---|
| 179 | recommended that these parameters should not differ significantly - |
---|
| 180 | certainly not by more than an order of magnitude. |
---|
| 181 | </para> |
---|
| 182 | |
---|
| 183 | </sect2> |
---|
| 184 | |
---|
| 185 | |
---|
| 186 | <!-- ******************* Section (Level#2) ****************** --> |
---|
| 187 | <sect2 id="sect.EMField.Pract"> |
---|
| 188 | <title> |
---|
| 189 | Practical Aspects |
---|
| 190 | </title> |
---|
| 191 | |
---|
| 192 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 193 | <sect3 id="sect.EMField.Pract.MagField"> |
---|
| 194 | <title> |
---|
| 195 | Creating a Magnetic Field for a Detector |
---|
| 196 | </title> |
---|
| 197 | |
---|
| 198 | <para> |
---|
| 199 | The simplest way to define a field for a detector involves the |
---|
| 200 | following steps: |
---|
| 201 | |
---|
| 202 | <orderedlist spacing="compact"> |
---|
| 203 | <listitem><para> |
---|
| 204 | create a field: |
---|
| 205 | <informalexample> |
---|
| 206 | <programlisting> |
---|
| 207 | G4UniformMagField* magField |
---|
| 208 | = new G4UniformMagField(G4ThreeVector(0.,0.,fieldValue)); |
---|
| 209 | </programlisting> |
---|
| 210 | </informalexample> |
---|
| 211 | </para></listitem> |
---|
| 212 | <listitem><para> |
---|
| 213 | set it as the default field: |
---|
| 214 | <informalexample> |
---|
| 215 | <programlisting> |
---|
| 216 | G4FieldManager* fieldMgr |
---|
| 217 | = G4TransportationManager::GetTransportationManager() |
---|
| 218 | ->GetFieldManager(); |
---|
| 219 | fieldMgr->SetDetectorField(magField); |
---|
| 220 | </programlisting> |
---|
| 221 | </informalexample> |
---|
| 222 | </para></listitem> |
---|
| 223 | <listitem><para> |
---|
| 224 | create the objects which calculate the trajectory: |
---|
| 225 | <informalexample> |
---|
| 226 | <programlisting> |
---|
| 227 | fieldMgr->CreateChordFinder(magField); |
---|
| 228 | </programlisting> |
---|
| 229 | </informalexample> |
---|
| 230 | </para></listitem> |
---|
| 231 | </orderedlist> |
---|
| 232 | </para> |
---|
| 233 | |
---|
| 234 | <para> |
---|
| 235 | To change the accuracy of volume intersection use the |
---|
| 236 | <literal>SetDeltaChord</literal> method: |
---|
| 237 | |
---|
| 238 | <informalexample> |
---|
| 239 | <programlisting> |
---|
| 240 | fieldMgr->GetChordFinder()->SetDeltaChord( G4double newValue); |
---|
| 241 | </programlisting> |
---|
| 242 | </informalexample> |
---|
| 243 | </para> |
---|
| 244 | |
---|
| 245 | </sect3> |
---|
| 246 | |
---|
| 247 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 248 | <sect3 id="sect.EMField.Pract.PartVol"> |
---|
| 249 | <title> |
---|
| 250 | Creating a Field for a Part of the Volume Hierarchy |
---|
| 251 | </title> |
---|
| 252 | |
---|
| 253 | <para> |
---|
| 254 | It is possible to create a field for a part of the detector. In |
---|
| 255 | particular it can describe the field (with pointer fEmField, for |
---|
| 256 | example) inside a logical volume and all its daughters. This can be |
---|
| 257 | done by simply creating a <literal>G4FieldManager</literal> and attaching it |
---|
| 258 | to a logical volume (with pointer, logicVolumeWithField, for |
---|
| 259 | example) or set of logical volumes. |
---|
| 260 | |
---|
| 261 | <informalexample> |
---|
| 262 | <programlisting> |
---|
| 263 | G4bool allLocal = true; |
---|
| 264 | logicVolumeWithField->SetFieldManager(localFieldManager, allLocal); |
---|
| 265 | </programlisting> |
---|
| 266 | </informalexample> |
---|
| 267 | </para> |
---|
| 268 | |
---|
| 269 | <para> |
---|
| 270 | Using the second parameter to <literal>SetFieldManager</literal> you choose |
---|
| 271 | whether daughter volumes of this logical volume will also be given this new |
---|
| 272 | field. If it has the value <literal>true</literal>, the field will be |
---|
| 273 | assigned also to its daughters, and all their sub-volumes. |
---|
| 274 | Else, if it is <literal>false</literal>, it will be copied only to those |
---|
| 275 | daughter volumes which do not have a field manager already. |
---|
| 276 | </para> |
---|
| 277 | |
---|
| 278 | </sect3> |
---|
| 279 | |
---|
| 280 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 281 | <sect3 id="sect.EMField.Pract.Electric"> |
---|
| 282 | <title> |
---|
| 283 | Creating an Electric or Electromagnetic Field |
---|
| 284 | </title> |
---|
| 285 | |
---|
| 286 | <para> |
---|
| 287 | The design and implementation of the <emphasis>Field</emphasis> category |
---|
| 288 | allows and enables the use of an electric or combined |
---|
| 289 | electromagnetic field. These fields can also vary with time, as can |
---|
| 290 | magnetic fields. |
---|
| 291 | </para> |
---|
| 292 | |
---|
| 293 | <para> |
---|
| 294 | Source listing <xref linkend="programlist_EMField_1" /> shows how to |
---|
| 295 | define a uniform electric field for the whole of a detector. |
---|
| 296 | |
---|
| 297 | <example id="programlist_EMField_1"> |
---|
| 298 | <title> |
---|
| 299 | How to define a uniform electric field for the whole of a detector, |
---|
| 300 | extracted from example in examples/extended/field/field02 . |
---|
| 301 | </title> |
---|
| 302 | |
---|
| 303 | <programlisting> |
---|
| 304 | // in the header file (or first) |
---|
| 305 | #include "G4EqMagElectricField.hh" |
---|
| 306 | #include "G4UniformElectricField.hh" |
---|
| 307 | |
---|
| 308 | ... |
---|
| 309 | G4ElectricField* fEMfield; |
---|
| 310 | G4EqMagElectricField* fEquation; |
---|
| 311 | G4MagIntegratorStepper* fStepper; |
---|
| 312 | G4FieldManager* fFieldMgr; |
---|
| 313 | G4double fMinStep ; |
---|
| 314 | G4ChordFinder* fChordFinder ; |
---|
| 315 | |
---|
| 316 | // in the source file |
---|
| 317 | |
---|
| 318 | { |
---|
| 319 | fEMfield = new G4UniformElectricField( |
---|
| 320 | G4ThreeVector(0.0,100000.0*kilovolt/cm,0.0)); |
---|
| 321 | |
---|
| 322 | // Create an equation of motion for this field |
---|
| 323 | fEquation = new G4EqMagElectricField(fEMfield); |
---|
| 324 | |
---|
| 325 | G4int nvar = 8; |
---|
| 326 | fStepper = new G4ClassicalRK4( fEquation, nvar ); |
---|
| 327 | |
---|
| 328 | // Get the global field manager |
---|
| 329 | fFieldManager= G4TransportationManager::GetTransportationManager()-> |
---|
| 330 | GetFieldManager(); |
---|
| 331 | // Set this field to the global field manager |
---|
| 332 | fFieldManager->SetDetectorField(fEMfield ); |
---|
| 333 | |
---|
| 334 | fMinStep = 0.010*mm ; // minimal step of 10 microns |
---|
| 335 | |
---|
| 336 | fIntgrDriver = new G4MagInt_Driver(fMinStep, |
---|
| 337 | fStepper, |
---|
| 338 | fStepper->GetNumberOfVariables() ); |
---|
| 339 | |
---|
| 340 | fChordFinder = new G4ChordFinder(fIntgrDriver); |
---|
| 341 | fFieldManager->SetChordFinder( fChordFinder ); |
---|
| 342 | |
---|
| 343 | } |
---|
| 344 | </programlisting> |
---|
| 345 | </example> |
---|
| 346 | </para> |
---|
| 347 | |
---|
| 348 | <para> |
---|
| 349 | An example with an electric field is |
---|
| 350 | examples/extended/field/field02, where the class |
---|
| 351 | F02ElectricFieldSetup demonstrates how to set these and other |
---|
| 352 | parameters, and how to choose different Integration Steppers. |
---|
| 353 | </para> |
---|
| 354 | |
---|
| 355 | <para> |
---|
| 356 | The user can also create their own type of field, inheriting from |
---|
| 357 | <literal>G4VField</literal>, and an associated Equation of Motion class |
---|
| 358 | (inheriting from <literal>G4EqRhs</literal>) to simulate other types of |
---|
| 359 | fields. |
---|
| 360 | </para> |
---|
| 361 | |
---|
| 362 | </sect3> |
---|
| 363 | |
---|
| 364 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 365 | <sect3 id="sect.EMField.Pract.Stepper"> |
---|
| 366 | <title> |
---|
| 367 | Choosing a Stepper |
---|
| 368 | </title> |
---|
| 369 | |
---|
| 370 | <para> |
---|
| 371 | Runge-Kutta integration is used to compute the motion of a |
---|
| 372 | charged track in a general field. There are many general steppers |
---|
| 373 | from which to choose, of low and high order, and specialized |
---|
| 374 | steppers for pure magnetic fields. By default, Geant4 uses the |
---|
| 375 | classical fourth-order Runge-Kutta stepper, which is general |
---|
| 376 | purpose and robust. If the field is known to have specific |
---|
| 377 | properties, lower or higher order steppers can be used to obtain |
---|
| 378 | the same quality results using fewer computing cycles. |
---|
| 379 | </para> |
---|
| 380 | |
---|
| 381 | <para> |
---|
| 382 | In particular, if the field is calculated from a field map, a |
---|
| 383 | lower order stepper is recommended. The less smooth the field is, |
---|
| 384 | the lower the order of the stepper that should be used. The choice |
---|
| 385 | of lower order steppers includes the third order stepper |
---|
| 386 | <literal>G4SimpleHeum</literal>, the second order <literal>G4ImplicitEuler</literal> |
---|
| 387 | and <literal>G4SimpleRunge</literal>, and the first order |
---|
| 388 | <literal>G4ExplicitEuler</literal>. A first order stepper would be useful |
---|
| 389 | only for very rough fields. For somewhat smooth fields |
---|
| 390 | (intermediate), the choice between second and third order steppers |
---|
| 391 | should be made by trial and error. Trying a few different types of |
---|
| 392 | steppers for a particular field or application is suggested if |
---|
| 393 | maximum performance is a goal. |
---|
| 394 | </para> |
---|
| 395 | |
---|
| 396 | <para> |
---|
| 397 | The choice of stepper depends on the type of field: magnetic or |
---|
| 398 | general. A general field can be an electric or electromagnetic |
---|
| 399 | field, it can be a magnetic field or a user-defined field (which |
---|
| 400 | requires a user-defined equation of motion.) For a general field |
---|
| 401 | several steppers are available as alternatives to the default |
---|
| 402 | (<literal>G4ClassicalRK4</literal>): |
---|
| 403 | |
---|
| 404 | <informalexample> |
---|
| 405 | <programlisting> |
---|
| 406 | G4int nvar = 8; // To integrate time & energy |
---|
| 407 | // in addition to position, momentum |
---|
| 408 | G4EqMagElectricField* fEquation= new G4EqMagElectricField(fEMfield); |
---|
| 409 | |
---|
| 410 | fStepper = new G4SimpleHeum( fEquation, nvar ); |
---|
| 411 | // 3rd order, a good alternative to ClassicalRK |
---|
| 412 | fStepper = new G4SimpleRunge( fEquation, nvar ); |
---|
| 413 | // 2nd order, for less smooth fields |
---|
| 414 | fStepper = new G4CashKarpRKF45( fEquation ); |
---|
| 415 | // 4/5th order for very smooth fields |
---|
| 416 | </programlisting> |
---|
| 417 | </informalexample> |
---|
| 418 | </para> |
---|
| 419 | |
---|
| 420 | <para> |
---|
| 421 | Specialized steppers for pure magnetic fields are also |
---|
| 422 | available. They take into account the fact that a local trajectory |
---|
| 423 | in a slowly varying field will not vary significantly from a helix. |
---|
| 424 | Combining this in with a variation the Runge-Kutta method can |
---|
| 425 | provide higher accuracy at lower computational cost when large |
---|
| 426 | steps are possible. |
---|
| 427 | |
---|
| 428 | <informalexample> |
---|
| 429 | <programlisting> |
---|
| 430 | G4Mag_UsualEqRhs* |
---|
| 431 | fEquation = new G4Mag_UsualEqRhs(fMagneticField); |
---|
| 432 | fStepper = new G4HelixImplicitEuler( fEquation ); |
---|
| 433 | // Note that for magnetic field that do not vary with time, |
---|
| 434 | // the default number of variables suffices. |
---|
| 435 | |
---|
| 436 | // or .. |
---|
| 437 | fStepper = new G4HelixExplicitEuler( fEquation ); |
---|
| 438 | fStepper = new G4HelixSimpleRunge( fEquation ); |
---|
| 439 | </programlisting> |
---|
| 440 | </informalexample> |
---|
| 441 | </para> |
---|
| 442 | |
---|
| 443 | <para> |
---|
[1222] | 444 | A new stepper for propagation in magnetic field is available in |
---|
| 445 | release 9.3. Choosing the G4NystromRK4 stepper provides accuracy |
---|
| 446 | near that of G4ClassicalRK4 (4th order) with a significantly reduced |
---|
| 447 | cost in field evaluation. Using a novel analytical expression for |
---|
| 448 | estimating the error of a proposed step and the Nystrom reuse of the |
---|
| 449 | mid-point field value, it requires only 2 additional field |
---|
| 450 | evaluations per attempted step, in place of 10 field evaluations of |
---|
| 451 | ClassicalRK4 (which uses the general midpoint method for estimating |
---|
| 452 | the step error.) |
---|
| 453 | |
---|
| 454 | <informalexample> |
---|
| 455 | <programlisting> |
---|
| 456 | G4Mag_UsualEqRhs* |
---|
| 457 | pMagFldEquation = new G4Mag_UsualEqRhs(fMagneticField); |
---|
| 458 | fStepper = new G4NystromRK4( pMagFldEquation ); |
---|
| 459 | </programlisting> |
---|
| 460 | </informalexample> |
---|
| 461 | </para> |
---|
| 462 | |
---|
| 463 | <para> |
---|
| 464 | It is proposed as an alternative stepper in the case of a pure |
---|
| 465 | magnetic field. It is not applicable for the simulation of electric |
---|
| 466 | or full electromagnetic or other types of field. For a pure |
---|
| 467 | magnetic field, results should be fully compatible with the results |
---|
| 468 | of ClassicalRK4 in nearly all cases. ( The only potential exceptions |
---|
| 469 | are large steps for tracks with small momenta - which cannot be |
---|
| 470 | integrated well by any RK method except the Helical extended methods.) |
---|
| 471 | </para> |
---|
| 472 | |
---|
| 473 | <para> |
---|
[904] | 474 | You can choose an alternative stepper either when the field |
---|
| 475 | manager is constructed or later. At the construction of the |
---|
| 476 | ChordFinder it is an optional argument: |
---|
| 477 | |
---|
| 478 | <informalexample> |
---|
| 479 | <programlisting> |
---|
| 480 | G4ChordFinder( G4MagneticField* itsMagField, |
---|
| 481 | G4double stepMinimum = 1.0e-2 * mm, |
---|
| 482 | G4MagIntegratorStepper* pItsStepper = 0 ); |
---|
| 483 | </programlisting> |
---|
| 484 | </informalexample> |
---|
| 485 | </para> |
---|
| 486 | |
---|
| 487 | <para> |
---|
| 488 | To change the stepper at a later time use |
---|
| 489 | |
---|
| 490 | <informalexample> |
---|
| 491 | <programlisting> |
---|
| 492 | pChordFinder->GetIntegrationDriver() |
---|
| 493 | ->RenewStepperAndAdjust( newStepper ); |
---|
| 494 | </programlisting> |
---|
| 495 | </informalexample> |
---|
| 496 | </para> |
---|
| 497 | |
---|
| 498 | </sect3> |
---|
| 499 | |
---|
| 500 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 501 | <sect3 id="sect.EMField.Pract.Adjust"> |
---|
| 502 | <title> |
---|
| 503 | How to Adjust the Accuracy of Propagation |
---|
| 504 | </title> |
---|
| 505 | |
---|
| 506 | <para> |
---|
| 507 | In order to obtain a particular accuracy in tracking particles |
---|
| 508 | through an electromagnetic field, it is necessary to adjust the |
---|
| 509 | parameters of the field propagation module. In the following |
---|
| 510 | section, some of these additional parameters are discussed. |
---|
| 511 | </para> |
---|
| 512 | |
---|
| 513 | <para> |
---|
| 514 | When integration is used to calculate the trajectory, it is |
---|
| 515 | necessary to determine an acceptable level of numerical imprecision |
---|
| 516 | in order to get performant simulation with acceptable errors. The |
---|
| 517 | parameters in Geant4 tell the field module what level of |
---|
| 518 | integration inaccuracy is acceptable. |
---|
| 519 | </para> |
---|
| 520 | |
---|
| 521 | <para> |
---|
| 522 | In all quantities which are integrated (position, momentum, |
---|
| 523 | energy) there will be errors. Here, however, we focus on the error |
---|
| 524 | in two key quantities: the position and the momentum. (The error in |
---|
| 525 | the energy will come from the momentum integration). |
---|
| 526 | </para> |
---|
| 527 | |
---|
| 528 | <para> |
---|
| 529 | Three parameters exist which are relevant to the integration |
---|
| 530 | accuracy. DeltaOneStep is a distance and is roughly the position |
---|
| 531 | error which is acceptable in an integration step. Since many |
---|
| 532 | integration steps may be required for a single physics step, |
---|
| 533 | DeltaOneStep should be a fraction of the average physics step size. |
---|
| 534 | The next two parameters impose a further limit on the relative |
---|
| 535 | error of the position/momentum inaccuracy. EpsilonMin and |
---|
| 536 | EpsilonMax impose a minimum and maximum on this relative error - |
---|
| 537 | and take precedence over DeltaOneStep. (Note: if you set |
---|
| 538 | EpsilonMin=EpsilonMax=your-value, then all steps will be made to |
---|
| 539 | this relative precision. |
---|
| 540 | |
---|
| 541 | <example id="programlist_EMField_2"> |
---|
| 542 | <title> |
---|
| 543 | How to set accuracy parameters for the 'global' field of the setup. |
---|
| 544 | </title> |
---|
| 545 | |
---|
| 546 | <programlisting> |
---|
| 547 | G4FieldManager *globalFieldManager; |
---|
| 548 | |
---|
| 549 | G4TransportationManager *transportMgr= |
---|
| 550 | G4TransportationManager::GetTransportationManager(); |
---|
| 551 | |
---|
| 552 | globalFieldManager = transportMgr->GetFieldManager(); |
---|
| 553 | // Relative accuracy values: |
---|
| 554 | G4double minEps= 1.0e-5; // Minimum & value for smallest steps |
---|
| 555 | G4double maxEps= 1.0e-4; // Maximum & value for largest steps |
---|
| 556 | |
---|
| 557 | globalFieldManager->SetMinimumEpsilonStep( minEps ); |
---|
| 558 | globalFieldManager->SetMaximumEpsilonStep( maxEps ); |
---|
| 559 | globalFieldManager->SetDeltaOneStep( 0.5e-3 * mm ); // 0.5 micrometer |
---|
| 560 | |
---|
| 561 | G4cout << "EpsilonStep: set min= " << minEps << " max= " << maxEps << G4endl; |
---|
| 562 | </programlisting> |
---|
| 563 | </example> |
---|
| 564 | </para> |
---|
| 565 | |
---|
| 566 | <para> |
---|
| 567 | We note that the relevant parameters above limit the inaccuracy |
---|
| 568 | in each step. The final inaccuracy due to the full trajectory will |
---|
| 569 | accumulate! |
---|
| 570 | </para> |
---|
| 571 | |
---|
| 572 | <para> |
---|
| 573 | The exact point at which a track crosses a boundary is also |
---|
| 574 | calculated with finite accuracy. To limit this inaccuracy, a |
---|
| 575 | parameter called DeltaIntersection is used. This is a maximum for |
---|
| 576 | the inaccuracy of a single boundary crossing. Thus the accuracy of |
---|
| 577 | the position of the track after a number of boundary crossings is |
---|
| 578 | directly proportional to the number of boundaries. |
---|
| 579 | </para> |
---|
| 580 | |
---|
| 581 | </sect3> |
---|
| 582 | |
---|
[1222] | 583 | |
---|
[904] | 584 | <!-- ******************* Section (Level#3) ****************** --> |
---|
[1222] | 585 | <sect3 id="sect.EMField.Pract.RedNumCall"> |
---|
| 586 | <title> |
---|
| 587 | Reducing the number of field calls to speed-up simulation |
---|
| 588 | </title> |
---|
| 589 | |
---|
| 590 | <para> |
---|
| 591 | An additional method to reduce the number of field evaluations is |
---|
| 592 | to utilise the new class G4CachedMagneticField class. It is |
---|
| 593 | applicable only for pure magnetic fields which do not vary with time. |
---|
| 594 | |
---|
| 595 | |
---|
| 596 | <informalexample> |
---|
| 597 | <programlisting> |
---|
| 598 | G4MagneticField * pMagField; // Your field - Defined elsewhere |
---|
| 599 | |
---|
| 600 | G4double distanceConst = 2.5 * millimeter; |
---|
| 601 | G4MagneticField * pCachedMagField= new G4CachedMagneticField( pMagField, distanceConst); |
---|
| 602 | </programlisting> |
---|
| 603 | </informalexample> |
---|
| 604 | </para> |
---|
| 605 | |
---|
| 606 | </sect3> |
---|
| 607 | |
---|
| 608 | <!-- ******************* Section (Level#3) ****************** --> |
---|
[904] | 609 | <sect3 id="sect.EMField.Pract.DiffAcc"> |
---|
| 610 | <title> |
---|
| 611 | Choosing different accuracies for the same volume |
---|
| 612 | </title> |
---|
| 613 | |
---|
| 614 | <para> |
---|
| 615 | It is possible to create a FieldManager which has different |
---|
| 616 | properties for particles of different momenta (or depending on |
---|
| 617 | other parameters of a track). This is useful, for example, in |
---|
| 618 | obtaining high accuracy for 'important' tracks (e.g. muons) and |
---|
| 619 | accept less accuracy in tracking others (e.g. electrons). To use |
---|
| 620 | this, you must create your own field manager which uses the |
---|
| 621 | method |
---|
| 622 | |
---|
| 623 | <informalexample> |
---|
| 624 | <programlisting> |
---|
| 625 | void ConfigureForTrack( const G4Track * ); |
---|
| 626 | </programlisting> |
---|
| 627 | </informalexample> |
---|
| 628 | |
---|
| 629 | to configure itself using the parameters of the current track. |
---|
| 630 | An example of this will be available in |
---|
| 631 | examples/extended/field05. |
---|
| 632 | </para> |
---|
| 633 | |
---|
| 634 | </sect3> |
---|
| 635 | |
---|
| 636 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 637 | <sect3 id="sect.EMField.Pract.ParaScal"> |
---|
| 638 | <title> |
---|
| 639 | Parameters that must scale with problem size |
---|
| 640 | </title> |
---|
| 641 | |
---|
| 642 | <para> |
---|
| 643 | The default settings of this module are for problems with the |
---|
| 644 | physical size of a typical high energy physics setup, that is, |
---|
| 645 | distances smaller than about one kilometer. A few parameters are |
---|
| 646 | necessary to carry this information to the magnetic field module, |
---|
| 647 | and must typically be rescaled for problems of vastly different |
---|
| 648 | sizes in order to get reasonable performance and robustness. Two of |
---|
| 649 | these parameters are the maximum acceptable step and the minimum |
---|
| 650 | step size. |
---|
| 651 | </para> |
---|
| 652 | |
---|
| 653 | |
---|
| 654 | <para> |
---|
| 655 | The <emphasis role="bold">maximum acceptable step</emphasis> should be set |
---|
| 656 | to a distance larger than the biggest reasonable step. If the apparatus |
---|
| 657 | in a setup has a diameter of two meters, a likely maximum acceptable |
---|
| 658 | steplength would be 10 meters. A particle could then take large |
---|
| 659 | spiral steps, but would not attempt to take, for example, a |
---|
| 660 | 1000-meter-long step in the case of a very low-density material. |
---|
| 661 | Similarly, for problems of a planetary scale, such as the earth |
---|
| 662 | with its radius of roughly 6400 km, a maximum acceptabe steplength |
---|
| 663 | of a few times this value would be reasonable. |
---|
| 664 | </para> |
---|
| 665 | |
---|
| 666 | <para> |
---|
| 667 | An upper limit for the size of a step is a parameter of |
---|
| 668 | <literal>G4PropagatorInField</literal>, and can be set by calling its |
---|
| 669 | <literal>SetLargestAcceptableStep</literal> method. |
---|
| 670 | </para> |
---|
| 671 | |
---|
| 672 | <para> |
---|
| 673 | The <emphasis role="bold">minimum step size</emphasis> is used during |
---|
| 674 | integration to limit the amount of work in difficult cases. It is |
---|
| 675 | possible that strong fields or integration problems can force the |
---|
| 676 | integrator to try very small steps; this parameter stops them from |
---|
| 677 | becoming unnecessarily small. |
---|
| 678 | </para> |
---|
| 679 | |
---|
| 680 | <para> |
---|
| 681 | Trial steps smaller than this parameter will be treated with |
---|
| 682 | less accuracy, and may even be ignored, depending on the |
---|
| 683 | situation. |
---|
| 684 | </para> |
---|
| 685 | |
---|
| 686 | <para> |
---|
| 687 | The minimum step size is a parameter of the MagInt_Driver, but |
---|
| 688 | can be set in the contstructor of G4ChordFinder, as in the source |
---|
| 689 | listing above. |
---|
| 690 | </para> |
---|
| 691 | |
---|
| 692 | </sect3> |
---|
| 693 | |
---|
| 694 | <!-- ******************* Section (Level#3) ****************** --> |
---|
| 695 | <sect3 id="sect.EMField.Pract.Known"> |
---|
| 696 | <title> |
---|
| 697 | Known Issues |
---|
| 698 | </title> |
---|
| 699 | |
---|
| 700 | <para> |
---|
| 701 | Currently it is computationally expensive to change the <emphasis>miss |
---|
| 702 | distance</emphasis> to very small values, as it causes tracks to be |
---|
| 703 | limited to curved sections whose 'bend' is smaller than this value. |
---|
| 704 | (The bend is the distance of the mid-point from the chord between |
---|
| 705 | endpoints.) For tracks with small curvature (typically low momentum |
---|
| 706 | particles in strong fields) this can cause a large number of |
---|
| 707 | steps |
---|
| 708 | |
---|
| 709 | <itemizedlist spacing="compact"> |
---|
| 710 | <listitem><para> |
---|
| 711 | even in areas where there are no volumes to intersect |
---|
| 712 | (something that is expected to be addressed in future development, |
---|
| 713 | in which the safety will be utilized to partially alleviate this |
---|
| 714 | limitation) |
---|
| 715 | </para></listitem> |
---|
| 716 | <listitem><para> |
---|
| 717 | especially in a region near a volume boundary (in which case it |
---|
| 718 | is necessary in order to discover whether a track might intersect a |
---|
| 719 | volume for only a short distance.) |
---|
| 720 | </para></listitem> |
---|
| 721 | </itemizedlist> |
---|
| 722 | </para> |
---|
| 723 | |
---|
| 724 | <para> |
---|
| 725 | Requiring such precision at the intersection is clearly expensive, |
---|
| 726 | and new development would be necessary to minimize the expense. |
---|
| 727 | </para> |
---|
| 728 | |
---|
| 729 | <para> |
---|
| 730 | By contrast, changing the intersection parameter is less |
---|
| 731 | computationally expensive. It causes further calculation for only a |
---|
| 732 | fraction of the steps, in particular those that intersect a volume |
---|
| 733 | boundary. |
---|
| 734 | </para> |
---|
| 735 | |
---|
| 736 | </sect3> |
---|
| 737 | </sect2> |
---|
| 738 | |
---|
| 739 | |
---|
| 740 | <!-- ******************* Section (Level#2) ****************** --> |
---|
| 741 | <sect2 id="sect.EMField.Spin"> |
---|
| 742 | <title> |
---|
| 743 | Spin Tracking |
---|
| 744 | </title> |
---|
| 745 | |
---|
| 746 | <para> |
---|
| 747 | The effects of a particle's motion on the precession of its spin |
---|
| 748 | angular momentum in slowly varying external fields are simulated. |
---|
| 749 | The relativistic equation of motion for spin is known as the BMT |
---|
| 750 | equation. The equation demonstrates a remarkable property; in a |
---|
| 751 | purely magnetic field, in vacuum, and neglecting small anomalous |
---|
| 752 | magnetic moments, the particle's spin precesses in such a manner |
---|
| 753 | that the longitudinal polarization remains a constant, whatever the |
---|
| 754 | motion of the particle. But when the particle interacts with |
---|
| 755 | electric fields of the medium and multiple scatters, the spin, |
---|
| 756 | which is related to the particle's magnetic moment, does not |
---|
| 757 | participate, and the need thus arises to propagate it independent |
---|
| 758 | of the momentum vector. In the case of a polarized muon beam, for |
---|
| 759 | example, it is important to predict the muon's spin direction at |
---|
| 760 | decay-time in order to simulate the decay electron (Michel) |
---|
| 761 | distribution correctly. |
---|
| 762 | </para> |
---|
| 763 | |
---|
| 764 | <para> |
---|
| 765 | In order to track the spin of a particle in a magnetic field, |
---|
| 766 | you need to code the following: |
---|
| 767 | |
---|
| 768 | <orderedlist spacing="compact"> |
---|
| 769 | <listitem><para> |
---|
| 770 | in your DetectorConstruction |
---|
| 771 | |
---|
| 772 | <informalexample> |
---|
| 773 | <programlisting> |
---|
| 774 | #include "G4Mag_SpinEqRhs.hh" |
---|
| 775 | |
---|
| 776 | G4Mag_EqRhs* fEquation = new G4Mag_SpinEqRhs(magField); |
---|
| 777 | |
---|
| 778 | G4MagIntegratorStepper* pStepper = new G4ClassicalRK4(fEquation,12); |
---|
| 779 | <emphasis role="bold">notice the 12 </emphasis> |
---|
| 780 | </programlisting> |
---|
| 781 | </informalexample> |
---|
| 782 | </para></listitem> |
---|
| 783 | <listitem><para> |
---|
| 784 | in your PrimaryGenerator |
---|
| 785 | |
---|
| 786 | <informalexample> |
---|
| 787 | <programlisting> |
---|
| 788 | particleGun->SetParticlePolarization(G4ThreeVector p) |
---|
| 789 | </programlisting> |
---|
| 790 | </informalexample> |
---|
| 791 | |
---|
| 792 | for example: |
---|
| 793 | |
---|
| 794 | <informalexample> |
---|
| 795 | <programlisting> |
---|
| 796 | particleGun-> |
---|
| 797 | SetParticlePolarization(-(particleGun->GetParticleMomentumDirection())); |
---|
| 798 | |
---|
| 799 | // or |
---|
| 800 | particleGun-> |
---|
| 801 | SetParticlePolarization(particleGun->GetParticleMomentumDirection() |
---|
| 802 | .cross(G4ThreeVector(0.,1.,0.))); |
---|
| 803 | </programlisting> |
---|
| 804 | </informalexample> |
---|
| 805 | |
---|
| 806 | where you set the initial spin direction. |
---|
| 807 | </para></listitem> |
---|
| 808 | </orderedlist> |
---|
| 809 | </para> |
---|
| 810 | |
---|
| 811 | <para> |
---|
| 812 | While the G4Mag_SpinEqRhs class constructor |
---|
| 813 | |
---|
| 814 | <informalexample> |
---|
| 815 | <programlisting> |
---|
| 816 | G4Mag_SpinEqRhs::G4Mag_SpinEqRhs( G4MagneticField* MagField ) |
---|
| 817 | : G4Mag_EqRhs( MagField ) |
---|
| 818 | { |
---|
| 819 | anomaly = 1.165923e-3; |
---|
| 820 | } |
---|
| 821 | </programlisting> |
---|
| 822 | </informalexample> |
---|
| 823 | |
---|
| 824 | sets the muon anomaly by default, the class also comes with the |
---|
| 825 | public method: |
---|
| 826 | |
---|
| 827 | <informalexample> |
---|
| 828 | <programlisting> |
---|
| 829 | inline void SetAnomaly(G4double a) { anomaly = a; } |
---|
| 830 | </programlisting> |
---|
| 831 | </informalexample> |
---|
| 832 | |
---|
| 833 | with which you can set the magnetic anomaly to any value you |
---|
| 834 | require. |
---|
| 835 | </para> |
---|
| 836 | |
---|
| 837 | |
---|
| 838 | <para> |
---|
| 839 | For the moment, the code is written such that field tracking of |
---|
| 840 | the spin is done only for particles with non-zero charge. Please, |
---|
| 841 | see the Forum posting: |
---|
| 842 | |
---|
| 843 | <literal> |
---|
| 844 | http://geant4-hn.slac.stanford.edu:5090/HyperNews/public/get/emfields/88/3/1.html |
---|
| 845 | </literal> |
---|
| 846 | |
---|
| 847 | for modifications the user is required to make to facilitate |
---|
| 848 | neutron spin tracking. |
---|
| 849 | </para> |
---|
| 850 | |
---|
| 851 | </sect2> |
---|
[1222] | 852 | </sect1> |
---|