Field Precision title

Setting a time step for electrons in a strong magnetic field

The determinants of accuracy in orbit calculations with Trak and OmniTrak are 1) the quality of the field solution(s) and 2) the choice of time step. In this note, I will discuss how to pick a time step and check the accuracy with emphasis on the case where an electron moves in a strong magnetic field.

There are several methods available for numerical solutions of differential equations with automatic adjustment of the integration step in references such as Numerical Recipes. There are two reasons why these are not employed in Trak and OmniTrak:

  • The implementation involves significant computational overhead for estimates and adjustments at each step. This would lead to unacceptable run times for calculations like circular accelerators where each orbit may require over 1,000,000 steps.
  • The step size affects not only the orbit integral, but also the independent process of space-charge and current assignment on the computational mesh.

Therefore, the programs use a fixed time step and there are circumstances where you may need to compute it.

The simplest situation is when there is only an electric field. In this case, the programs compute a time step based on the following criterion:

  • Find the minimum element width
  • Estimate the maximum kinetic energy based on starting energies and the maximum difference in potential.
  • Divide the the minimum distance by the maximum velocity.

You can perform the steps manually with the Time Step Calculator in the Tools menu of Trak and OmniTrak and enter the resulting value. One way to check the accuracy of orbit integrations in electric fields is to propagate a particle between electrodes and to compare the potential difference to the change in kinetic energy (in eV). Remember that there may be differences if the particle starts a small distance from the electrode surface. You can compute the exact potential at the starting point with the EPOINT command.

You must take some care when magnetic fields are present. You should ensure that the time step is short compared to the period of gyration in the field:

τ = 2πγ m0/q*B0

In the equation, q is the particle charge, B is the maximum field encountered,γ is the average relativistic mass factor and m0 is the rest mass. The orbits will be highly inaccurate or nonphysical if the time step Δt is comparable to or larger than τ.

The main issue is how small Δt should be for accuracy. The answer depends on the application. For a precise simulation of trajectories in the circular accelerator you might require 1000 steps per gyration. For an gun design with matching to a focusing solenoid, 50 steps per revolution may be sufficient. To check the accuracy, turn off the electric fields in the solution (by either commenting out the EFIELD command or including a multiplication factor of 0.0) and propagate a particle in the magnetic field. The kinetic energy should remain constant.

As an illustration, I created a simple OmniTrak run where a 5 MeV electron propagates in a uniform field B0z = 0.10 tesla. Use these links to download the example input files:

baccuracy.min
baccuracy.hin
baccuracy.oin

The data below show the percentage change in kinetic energy per turn as a function of the number of integration steps per turn:

Steps/Rev    DeltaTe/Te
=======================
10          8.984E-2
20          1.297E-2
50          8.560E-4
100         1.072E-4
200         1.340E-5
500         8.600E-7
1000        2.200E-8

As a final topic, what if the magnetic field is extremely high, leading to an unrealistically-small time step? In this case, you should consider a scaled solution rather than a literal approach. In a strong field, electrons are tied to the field lines. If the system volume has dimensions of several cm, would it make a difference whether an electron was tied to within 0.1 mm of the field line versus 0.01 mm? Probably not. Try some test orbits, comparing those in the original field to those with the field reduced by a factor of 10. You can probably arrive at almost the same solution with a significant reduction in run time.

LINKS