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 --> |
---|
15 | <!-- Corrections, changes by: John APOSTOLAKIS,15-Dec-2009 --> |
---|
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> |
---|
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> |
---|
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 | |
---|
583 | |
---|
584 | <!-- ******************* Section (Level#3) ****************** --> |
---|
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) ****************** --> |
---|
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> |
---|
852 | </sect1> |
---|