# An Efficient Parallelization of Microscopic Traffic Simulation
## 1 Introduction
### State of the Art
The vehicle update basically includes three distinct processes: (1) the car following model (LPSim uses the IDM model [19]), where each vehicle adjusts its speed to a lead vehicle in front or accelerates to the maximum allowed speed if there is no vehicle ahead; (2) the lane-change model, where the vehicle changes lane if the vehicle gap on the target lane is sufficiently large; a vehicle would only change if the lane change is necessary to turn into the successive edge (mandatory lane-change); discretionary lane changes seem not to be modeled at the reported development state; and (3) intersection model, where vehicles change to the successive edge on their predetermined route; particular care is taken to prevent the simultaneous occupation of lane-cells by multiple vehicles trying to merge into the same edge; this is accomplished using atomic operations, which are also used in the present work and discussed in Section 2.3. The traffic light model is greatly simplified, where red lights at junctions flash at a regular pace and vehicles stop during red phases. The execution speed of LPSim/MANTA is three orders of magnitude faster than SUMO for comparable simulation tasks [16], which means that the advantage of parallel simulator implementation is quite evident. The validation results have shown that LPSim reproduces realistic speed profiles and trip distance distributions [18]. This means that microsimulations could already substitute for the previously mentioned mesoscopic simulations in the calibration, relaxation, and optimization loops used to generate activity-based demand models, as used in many studies of large-scale areas [20; 21]. It is worth mentioning that MANTA also includes an optimized routing algorithm that updates link travel times during routing. This algorithm runs in parallel on multiple CPU cores is able to route 3.2 million OD pairs in 62 min. Clearly, routing time has not been included in simulation time, as routing is considered a separate task. Compared with other microsimulators, one must state that LPSim is neither an event-driven cellular automata [22] nor a discrete-time, continuous state simulator, such as most single-core microsimulators. Instead, LPSim uses updates at discrete times and discrete state variables (e.g., position, speed), in contrast to most single-core microsimulators, which are discrete in time and continuous in vehicle states. The adopted space and speed discretization may provide a sufficient resolution in most cases, but low-speed vehicle movements (e.g., during congestion) could result in an artificial stopping of all involved vehicles, leading to backpropagating queues and gridlock. The use of one byte per cell to store speed information limits the speed of all vehicles to a maximum of 254 m/s, which does not restrict applications to urban or extra-urban environments. However, the GPU memory usage of LPSim seems to be an issue; the 24 h Bay Area scenario (for details, see Section 3.1) appears not to fit on a single GPU with 40 GB of memory. This is why LPSim adopted a mechanism that enables the simulation to run on multiple GPUs by subdividing the network and distributing vehicles accordingly. However, data communication between GPUs, necessary to synchronize and exchange vehicles, seems to be a bottleneck, depending on the network-load [18].