# How to initialize / bootstrap the Boris algorithm?

The Boris algorithm requires interleaved positions and velocities, i.e. position measured at $t_i$ and velocity at $t_{i-1/2}$ for example. I want to employ the Boris pusher in my application however I'm given position and velocity both at some time $t_0$ (as an input; not shifted by half a time-step). If I input this to the algorithm it obviously yields wrong results (as one can see from a case for which the analytical solution is known).

Question: How can I initialize the algorithm in order to obtain position and velocity shifted by $\Delta t/2$ ?

Aside (1): Boris algorithm first performs a velocity update and then uses the new velocity to compute the position update. However the velocity update uses both position (to compute the fields) and velocity so I cannot simply use a velocity update for $\Delta t \rightarrow \Delta t/2$.

Aside (2): The Leapfrog algorithm also (originally) uses interleaved positions and velocities however it can be reformulated so they are computed "in lockstep" (i.e. both defined at $t_i$). As far as I know such a reformulation doesn't exist for the Boris algorithm.

This is generally known as a "starting" problem and occurs with a number of schemes. Higher order implicit schemes for example need the values at multiple previous time levels.

The trick is to start out the simulation using one or more simpler schemes to get it going. For instance, you could use a 2nd order Runge-Kutta method for one step so you have values at $t_0$ and $t_1$, and then interpolate to $t_{0.5}$ and start your algorithm with that dataset. Any method would work, but a simple explicit scheme is going to be your best choice to get things moving.

If you want to ensure consistency when restarting from checkpoints vs running until the finish without checkpoints, you'll want to save your previous half-time step values when you save your checkpoints. That way, when you restart things, you don't need to take another starting step.

Just make sure you obey whatever stability and/or accuracy constraints you may have at the start of the simulation. For many systems, this is a highly non-linear moment and robustness can be a problem if the schemes are chosen poorly.

I had one asked a colleague how he dealt with the offset velocity for his particle in cell code, and his was response differed from what tpg2114 said in his answer.

Rather than computing the next time-step using a lower-order method, my colleague's PIC code would actually solve the next velocity backwards in time (i.e., at $t=-\Delta t/2$) and the force at $t=-\Delta t$ using their typical 2nd-order algorithms before moving forwards in time.1 It does seem to me that there is still the issue of your data containing $\mathbf v(t=0)$ and $\mathbf x(t=0)$, which may require tpg2114's solution.

I don't know that they did it, but it would seem reasonable that after stepping forward to $t=0$ one would check the positions of the particles to ensure that the positions match to some level (hopefully machine precision, but I could understand using some larger tolerance).

1. It might be the case that $v(t=-3\Delta t/2)$ is needed as well, but I'm not 100% sure as this was about 5 years ago that I had asked & I don't/didn't do PIC simulations.

• Worth pointing out (very belatedly) that this approach is okay so long as the discrete equations are stable with time reversal. Diffusive terms become sharpening terms when reversed and can lead to really nasty numerical instabilities. Aug 7 '18 at 15:57