\chapter*{Preface}\label{chapter:preface}
% c.f. https://tex.stackexchange.com/a/222961/152544
\addcontentsline{toc}{chapter}{\protect\numberline{}Preface}

The following is a summary of useful concepts in high energy particle physics.

\section{Units}\label{section:units}

\subsection{Natural Units}\label{subsection:natural_units}

The nature of high energy physics is to give descriptions of the phenomena and interactions that occur at energies that result in speeds that are close to the speed of light over very short time and distance scales.
Given this, it becomes readily apparent that the International System of Units (SI) of measurement is somewhat cumbersome to use in calculations, and a much more useful system of units would be consistent with the scale of the phenomena.
When measuring the speed of a relativistic particle it is more convenient to compare to the speed of light $\left(\text{such that }c=1\right)$ than to the number of meters per second.
Similarly, when measuring the momentum of a particle it is generally more useful to know the amount of its energy in the form of momentum compared to the amount in the form of its mass, resulting in expressing momentum in terms of energy.
This system of units is called ``Natural Units,'' and builds its measurements in terms of speed, angular momentum, and energy.
It is used extensively (if not almost exclusively) throughout high energy physics.
Quantities encountered routinely in high energy physics are given in Natural Units in \Cref{table:natural_units}.
\clearpage

\begin{table}[htpb]
 \centering
 \caption{Common quantities in particle physics given in both natural units and SI units.}
 \begin{tabular}{@{}llll@{}} \toprule
  Quantity         & Natural Units                 & Natural Units (dimensionful)            & SI Units                                              \\ \midrule
  Speed            & $1$                           & $c$                                     & $3.0\times 10^{8}~\mathrm{m}/\mathrm{s}$              \\
  Angular Momentum & $1$                           & $\hbar$                                 & $10^{34}~\mathrm{m}^2 \,\mathrm{kg}/\mathrm{s}$       \\
  Energy           & $\mathrm{GeV}$                & $\mathrm{GeV}$                          & $1.6\times 10^{-10}~\mathrm{J}$                       \\
  Momentum         & $\mathrm{GeV}$                & $\mathrm{GeV}/c$                        & $1\times 10^{-19}~\mathrm{kg}\,\mathrm{m}/\mathrm{s}$ \\
  Mass             & $\mathrm{GeV}$                & $\mathrm{GeV}/c^{2}$                    & $1.8\times 10^{-27}~\mathrm{kg}$                      \\
  Time             & $1/\mathrm{GeV}$              & $\hbar/\mathrm{GeV}$                    & $6.6\time 10^{-25}~\mathrm{s}$                        \\
  Length           & $1/\mathrm{GeV}$              & $\hbar c/\mathrm{GeV}$                  & $2\times 10^{-16}~\mathrm{m}$                         \\
  Electric Charge  & $1$                           & $e/\sqrt{4\pi \alpha_{\mathrm{em}}}$    & $5.3\times 10^{-19}~\mathrm{C}$                       \\
  Magnetic Field   & $\left(\mathrm{GeV}\right)^2$ & $\left(\mathrm{GeV}\right)^2/\hbar c^2$ & $5\times 10^{16}~\mathrm{T}$                          \\
  \bottomrule
 \end{tabular}\label{table:natural_units}%
\end{table}

\subsection{Units of Cross Section}\label{subsection:cross_section}

The ``cross section'' is the effective cross-sectional area of the event space for an given interaction to occur, and so has units of area.
It is commonly used though in the context of the fraction of the total event space that a particular process contributes (the dimensionful event space solid angle), and so is not a reflection of the physical size of an interaction.
For example, in high energy physics cross section can describe the production of a particle through a particular process, such as Higgs production through gluon-gluon fusion.
A particularly clear analogy for cross section\footnote{Made known to me by Stephen Sekula.} comes from theoretical physicist Rudolf Peierls~\cite{rhodes2012making}:
\begin{quote}
 For example, if I throw a ball at a glass window one square foot in area, there may be one chance in ten that the window will break, and nine chances in ten that the ball will just bounce.
 In the physicists' language, this particular window, for a ball thrown in this particular way, has a ``disintegration [inelastic] cross-section'' of $1/10$ square foot and an ``elastic cross-section'' of $9/10$ square foot.
\end{quote}
For the cross sections that are common in particle physics the units of ``barns'' is generally more convenient to work in, as further discussed in \Cref{subsection:luminosity_units}.
A barn is defined as
\begin{equation}
 1~\textrm{barn} = 10^{-28}~\textrm{m}^2 = 10^{-24}~\textrm{cm}^2,
 \label{eq:barn_to_area}
\end{equation}
which is roughly the cross sectional area of a uranium nucleus~\cite{web:history_physics_purdue,history:etymology_barn}.

\subsection{Units of Luminosity}\label{subsection:luminosity_units}

Tightly related to cross section is a crucial quantity of interest in high energy physics: the luminosity (both instantaneous and integrated) delivered by the particle accelerator.
The instantaneous luminosity, $\mathscr{L}$, can be defined as the number of particles incident per unit area per unit time (generally taken to be seconds),
\begin{equation}
 \mathscr{L} = \frac{\text{number of particles}}{\text{unit area} \cdot \text{second}}.
 \label{eq:instantaneous_luminosity}
\end{equation}
In accelerator physics, the unit area is generally chosen to be $\textrm{cm}^2$, giving instantaneous luminosities units of $\textrm{cm}^{-2} \cdot \textrm{s}^{-1}$,
\[
 \left[\mathscr{L}\right] = \textrm{cm}^{-2} \cdot \textrm{s}^{-1}.
\]
However, experimental particle physicists prefer to use units of inverse barns (per second) for (instantaneous) luminosities.

The context in which luminosity appears as being useful is in the form of an equation like
\begin{equation}
 N_{\textrm{events}} = \sigma_{\textrm{process}} \cdot \int \mathscr{L}\,dt
 \label{eq:events_from_luminosity}
\end{equation}
where:
\begin{itemize}
 \item $N_{\text{events}}$ is the number of events of a particular process that will be produced at the collider.
       This is what ends up exiting the collision process.
 \item $\sigma_{\textrm{process}}$ is the cross section of the particular process to occur per interaction of colliding particles.
       At the \gls{LHC} this would be the cross section per proton-proton interaction.
       This is a function of the fundamental physics that is available at the energy ranges being probed, and so is also a function of the collider's center of mass energy, $\sqrt{s}$.
       When written in an equation as such it is assumed that the cross section is also including the relevant branching ratios for the final state particles.
       That is, ${\sigma\left(pp \to H \to b\bar{b}\,\right) = \sigma\left(pp \to H\right) \cdot \mathcal{BR}\left(H \to b\bar{b}\,\right)}$.
 \item $L \equiv \int \mathscr{L}\,dt$ is the total luminosity integrated over time (the integrated luminosity)~\cite{Herr:941318}.
       This is what is delivered by the particle accelerator.
\end{itemize}

\begin{table}[htpb]
 \centering
 \caption{Instantaneous luminosities at the LHC.}
 \begin{tabular}{@{}ll@{}} \toprule
  Description                                                    & Units of $\textrm{cm}^{-2}\cdot\textrm{s}^{-1}$ \\ \midrule
  LHC Design Luminosity~\cite{Bruning:782076}                    & $10^{34}$                                       \\
  2017 ATLAS Trigger Menu Maximum~\cite{TWiki:MenuEvolution2017} & $2.0 \times 10^{34}$                            \\
  2017 Plan~\cite{Indico:MenuCoordination_2017Lumi}              & $1.7 \times 10^{34}$                            \\
  2017 Peak~\cite{TWiki:2017ATLASPeakLumi}                       & $2.09 \times 10^{34}$                           \\
  2018 Peak~\cite{TWiki:2018ATLASPeakLumi}                       & $2.1 \times 10^{34}$                            \\
  \bottomrule
 \end{tabular}\label{table:LHC_Luminosity_Goals}%
\end{table}

\begin{table}[htpb]
 \centering
 \caption{Integrated luminosity measurements in $\text{barns}^{-1}$.}
 \begin{adjustbox}{width=0.4\textwidth}
  \begin{tabular}{@{}lll@{}} \toprule
   Units                & Units of $\textrm{cm}^{-2}$ & Units of $\textrm{fb}^{-1}$ \\ \midrule
   $\textrm{barn}^{-1}$ & $10^{24}$                   & $10^{-15}$                  \\
   $\textrm{mb}^{-1}$   & $10^{27}$                   & $10^{-12}$                  \\
   $\mu\textrm{b}^{-1}$ & $10^{30}$                   & $10^{-9}$                   \\
   $\textrm{nb}^{-1}$   & $10^{33}$                   & $10^{-6}$                   \\
   $\textrm{pb}^{-1}$   & $10^{36}$                   & $10^{-3}$                   \\
   $\textrm{fb}^{-1}$   & $10^{39}$                   & $10^{0}$                    \\
   $\textrm{ab}^{-1}$   & $10^{42}$                   & $10^{3}$                    \\
   \bottomrule
  \end{tabular}\label{table:Luminosity}%
 \end{adjustbox}
\end{table}

\section{Coordinates}\label{section:coordinates}

The LHC coordinate system, seen in \Cref{fig:LHC_coordinate_system}, is a rectangular coordinate system defined relative to the LHC ring and the LHC beamline.
At any point, the positive $x$ direction is defined as the direction that points radially inward to the center of the LHC ring.
The positive $y$ direction is then defined as pointing upwards --- radially outward from the center of the Earth --- leaving the positive $z$ direction pointing along the beamline.

\begin{figure}[htbp]
 \centering
 \includegraphics[width=0.8\linewidth]{preface/LHC_coordinate_system.pdf}
 \caption{The LHC coordinate system as seen from the ATLAS detector.}
 \label{fig:LHC_coordinate_system}
\end{figure}

While the LHC coordinate system is Cartesian, the preferred coordinate system for describing LHC events is not.
As the ATLAS detector is arranged cylindrically around the beamline of the LHC --- such that most of its detector components are transverse to the beamline --- the coordinate system that is used to describe events in ATLAS is characterized by a particle's transverse momentum, pseudorapidity, and azimuthal angle: $\left(p_T, \eta, \phi\right)$.
The polar angle, $\theta$, is defined as the angle relative to the beam axis, and the azimuthal angle, $\phi$, is measured around the beam axis.

\Gls{Pseudorapidity} is then defined as
\begin{equation}
 \eta = - \ln \left(\tan \frac{\theta}{2}\right)
 \label{eq:pseudorapidity}
\end{equation}
to be a good approximation in the high energy regime of the \gls{rapidity} of a particle --- a measurement of the velocity of a particle longitudinal to the beam axis,
\begin{equation}
 y = \frac{1}{2} \ln \left(\frac{E + p_{z}}{E - p_{z}}\right).
 \label{eq:rapidity}
\end{equation}
As the beam axis is defined as $\hat{\vec{z}}$, such that $p_{z} = \abs{\vec{p}} \cos\theta$, then it is seen that in the relativistic limit, $\abs{\vec{p}} \gg m$, the rapidity reduces to the pseudorapidity
\[
 \begin{split}
  y\left(\abs{\vec{p}} \gg m\right)   &\approx \frac{1}{2} \ln \left(\frac{p + p\cos\theta}{p - p\cos\theta}\right)\\
  &\approx \frac{1}{2} \ln \left(\frac{2 \cos^{2} \frac{\theta}{2}}{2 \sin^{2} \frac{\theta}{2}}\right) \\
  &\approx - \ln \left(\tan \frac{\theta}{2}\right) = \eta.
 \end{split}
\]
It is clear that the rapidity and the pseudorapidity are not \Glspl{Lorentz invariant}.
However, for a Lorentz \gls{boost} --- a Lorentz transformation without any rotations --- of speed $\beta$ along the beam axis, $\hat{\vec{z}}$,
\[
 \begin{pmatrix}
  E' \\
  p_{z}'
 \end{pmatrix}
 =
 \begin{pmatrix}%
  \gamma       & -\gamma\beta \\%
  -\gamma\beta & \gamma
 \end{pmatrix}%
 \begin{pmatrix}
  E \\
  p_{z}
 \end{pmatrix}\,,
\]
it is seen\footnote{Glossing over some algebra and hyperbolic trigonometric identities.} that the rapidity for a particle under the boost is the sum of the original rapidity and a constant of the boost
\[
 \begin{split}
  y'  &= \frac{1}{2} \ln \left(\frac{E' + p_{z}'}{E' - p_{z}'}\right) \\
  &= \frac{1}{2} \ln \left(\frac{E - \beta p_{z} + p_{z} - \beta E}{E - \beta p_{z} - p_{z} + \beta E}\right) \\
  &= \frac{1}{2} \ln \left(\frac{E + p_{z}}{E - p_{z}}\right) + \frac{1}{2} \ln \left(\frac{1 - \beta}{1 + \beta}\right) \\
  &= y - \tanh^{-1}\beta\,.
 \end{split}
\]
Thus, the \emph{difference in rapidities} between two particles is seen to be independent of the boost and so is a \Gls{Lorentz invariant}.
Defining the distance metric\footnote{$\Delta R$ is an angular distance in $\left(\eta, \phi\right)$ space, and can be thought of as a solid angle.} for two particles in $\left(\eta, \phi\right)$ space as
\begin{equation}
 \Delta R = \sqrt{\left(\Delta\eta\right)^{2} + \left(\Delta\phi\right)^{2}}
 \label{eq:DeltaR}
\end{equation}
it is seen that $\Delta R$ is by construction invariant to boosts along the beam axis.
As a result, \emph{translations} in $\eta$ of particles correspond to \glspl{boost} of the particles along the beamline.

For experiments at high energy colliders, the pseudorapidity offers a distinct advantage in the high energy limit as it only requires angular information while giving an excellent approximation to the rapidity.
Measuring both the energy and the full momentum for highly relativistic particles can be quite difficult, and as the differences between the rapidity and the pseudorapidity can quickly become very small, pseudorapidity is the favored measurement for experimental results.
Values of the pseudorapidity for values of the polar angle are summarized in \Cref{table:pseudorapidity_angles} and are plotted along with the form of \Cref{eq:rapidity} in \Cref{fig:pseudorapidity_angles}.

\begin{table}[htpb]
 \centering
 \caption{Polar angles relative to the LHC beam axis, $\theta$, and their corresponding pseudorapiditities, $\eta$.}
 \begin{tabular}{@{}cr@{}} \toprule
  Polar angle $(\theta)$ & Pseudorapidity $(\eta)$ \\ \midrule
  $\frac{\pi}{2}$        & $0$                     \\
  $\frac{\pi}{4}$        & $0.88137$               \\
  $\frac{\pi}{8}$        & $1.61489$               \\
  $\frac{\pi}{16}$       & $2.31779$               \\
  $\frac{\pi}{32}$       & $3.01335$               \\
  \bottomrule
 \end{tabular}\label{table:pseudorapidity_angles}%
\end{table}

\begin{figure}[htbp]
 \centering
 \includegraphics[width=0.8\linewidth]{preface/pseudorapidity.pdf}
 \caption[Pseudorapidity as a function of the polar angle.]{%
  Pseudorapidity, $\eta = - \ln \left(\tan \frac{\theta}{2}\right)$, as a function of the polar angle, $\theta$.
  The example markers are the points given in \Cref{table:pseudorapidity_angles}.
  The blue shaded region indicates the polar angle coverage up to $\eta = 2.5$, which is the end of the fiducial region coverage by the ATLAS inner detector tracking.}
 \label{fig:pseudorapidity_angles}
\end{figure}

\clearpage
\input{src/statistics.tex}

\clearpage
\section{Open Source Tools}\label{section:open_source}

This thesis and the researched described in it were made possible only through use of open source software.
The analysis was written in the open source languages \texttt{C++} and \texttt{Python} and made extensive use of the \texttt{ROOT} data analysis framework~\cite{Brun:1997pa}.
Similarly, parts of the analysis were conducted in Python and leveraged the SciPy ecosystem~\cite{SciPy}, most notably the NumPy~\cite{oliphant_guide_2006,NumPy_array} and matplotlib~\cite{Matplotlib} libraries.
The thesis itself was written in \LaTeXe, built using \texttt{latexmk} and \texttt{Make}, and versioned with Git.
The Pandas~\cite{mckinney-proc-scipy-2010} library was also used and the code was formatted with Black~\cite{Black_formatter}.
Scientific research is built upon the open source community and tools, and this work would not have been made possible without it.


\subsection{Representing compact groups}


\section{Simulation of the system}
All the previous results have been used to simulate the system with SimuLink.

The SimuLink model consists of:
\begin{itemize}
\item The photovoltaic module (\emph{PV\_module}): it is composed by a grid of $WxH$ cells, each corresponding to the model we obtained previously. It receives a power request from its load (the DC-DC converter) and outputs a current and a voltage depending on the current irradiation.
\item The DC-DC converter model receives a $(I,V)$ request from its load (driven by the current controller) and generates a power request to the photovoltaic module based on its efficiency.
\item The battery model receives a current request from the load and gives it the requested current, changing its SoC and its $V$. The latter is the same voltage that the converter will be requested to provide to the load. In case that the photovoltaic module itself is capable of providing more current that the needed one, the remaining current can be fed to the battery to recharge it (i.e. the current controller can give a negative $I$ to the battery).
\item Finally, the current controller is responsible of requesting to the battery and the photovoltaic model the right quantity of current.
\end{itemize}

The first three modules have been fully characterized in the previous parts, and thus the behavioural equations have been put into the corresponding parts of the model.

However, for the latter module, a good policy needed to be implemented. A greedy strategy has been chosen, in which the photovoltaic model is given precedence over the battery, as this means simpler hardware and a good result. Also, by giving full precedence to the photovoltaic module, the self-recharge effect of the battery can be exploited at its maximum - although this effect is not modeled into the SimuLink model.

Regarding the battery model, it should be noticed how the first implementation, which simply integrated the input current over time, didn't use a saturating integrator, thus letting the battery recharge over the 100\% SoC. This has been fixed by saturating the integration down to the initial SoC and up to $1-SoC(0)$.

\subsection{Implementation of a as-most-as-possible current controller}
In order to drive current requests to the photovoltaic panel, a good implementation of a current controller has been needed. Its task is to compute the best current request for the PV module knowing only the current irradiation value and the load's current request.

The chosen strategy has been to try to ask always for the most available current from the PV module. This lets the panel exploit its full potential, and lets the battery recharge if it can be done. An analisys of the circuit structure can help to achieve this result.

As the PV is connected to a DC-DC converter \emph{before} entering the load, the output current available to the load does not rely of having the curresponding right voltage from the panel. This means that, in order to maximize the avilable current $I_{out}$, the PV module must be used as much as possible near to its \emph{Maximum power point} ($M$). It is important, although, not trying to pass this power limit, as the PV module will not be able to deliver it, making the SimuLink model not work (in the simulation case) or drastically decreasing the output power (in the real case).

Considering the equations modeling the DC-DC converter, we get the following relationships:

\begin{align*}
  \eta I_{pv}V_{pv} &= I_{out}V_{out} \\
                    &\Updownarrow \\
  \eta P_{pv} &= P_{out} \\
                    &\Updownarrow \\
  P_{pv}&=P_{out}+P_{loss}  \\
\end{align*}

By choosing the maximum power point $M(G)$ for as $P_{pv}$ (which has been implemented as a LUT and then suitably scaled by a security factor 0.95 - in order to be sure never to pass it because of approximation errors of the fitting functions and LUTs), we obtain:
\begin{align*}
  M(G)&=V_{out}I_{req}+P_{loss}(I_{req}) \\
\end{align*}

Here, $V_{out}$ is the voltage of the battery, which depends on its SoC. Not knowing it into the block, (as this would cause an algebraic loop and complicate a lot the computation) it has been chosen to be the worst-case one, corresponding to the voltage of the fully-charged battery, $V=4.2 [V]$. This conservative approach ensures that the computed maximum current will always be output by the panel without problems.

As the power loss has been previously modeled as $P_{loss}(I_{req})=c_1I_{req}^2+c_2I_{req}+c_3$, the output current corresponding to the maximum power point can be computed as follows:

\begin{align*}
  M(G)&=VI_{req}+c_1I_{req}^2+c_2I_{req}+c_3 \\
  c_1I_{req}^2+(c_2+V) I_{req} + (c_3)-M(G) &= 0 \\
  I_{req} &= \frac{ -(c_2+V) + \sqrt{ (c_2+V)^2-4c_1(c_3 -M(G) )} }{2 c_1} \\
\end{align*}

Using this expression as a function block for computing the requested current ensures that the maximum power is always extracted from the PV module, by taking also into account the non-idealities of the DC-DC module.


\chapter{Background and Related Work}
In this chapter, the reader is introduced to physics simulations and the differences between real-time and non-real-time simulations along with important terms, workings, important and relevant aspects of physics simulations. Along with an introduction to physics simulations, the following points will also be discussed:
\begin{itemize}
	\item Scalable non-real-time physics
	\item Online gaming
	\item RakNet
	\item Consistency in real-time physics
	\item Distributed virtual environments
	\item Distributed real-time physics
	\item Cloud computing
	\item Real-time physics for scalable simulations
	\item Microservices for game engines
	\item Streamed gaming
\end{itemize}

\section{Real-time Physics Engines Overview}
%We introduce the reader to the topic of physics simulations and we compare real-time with non-real-time physics simulations. We define terms, workings, important and relevant aspects, e.g. body types, uses in games and simulations, typical scales and performance of real-time simulations and performance budget in real-time applications.

Real-time physics simulations (physics engines) are responsible for simulating the physical behaviour of objects and are based around Newtonian mechanics. The motion of the system is calculated given the forces acting on the system and this is known as the forward dynamics problem \cite{Boeing2007}.

The main three aspects of the functionality of a physics engine are the following:
\begin{itemize}
	\item Integration: Moving objects according to a set of physical rules and values i.e. velocity, drag, friction
	\item Collision Detection: Checking for collisions between two or more objects
	\item Collision Response: The reaction to collisions between objects
\end{itemize}

The term `object' is used here to describe any physical entity. Objects can be any entity that physically interacts, for example, a barrel, a bullet, a fire particle, a jointed robot arm, the wheel of a vehicle, a mountain etc. The terms `world' or `scene' are often used to describe the physical system.

The numerical integrator used to update the positions of objects in the system, uses a discrete time value. Each discrete time value is known as a time step. Each step simulates a set period of time. The shorter the time period simulated, the more physically accurate the simulation will be. However, each simulation step must take less time to execute than the time it is intending to simulate, otherwise the simulation would be unable to run in real-time. It is common for the time step to be a fixed value, though physics engines can support variable time steps.

\subsection{Linear Motion}
Linear motion will first be discussed and the following variables are used:
\begin{itemize}
	\item $F$ - Force
	\item $m$ - Mass
	\item $a$ - Acceleration
	\item $v$ - Velocity
	\item $s$ - Displacement
	\item $n$ - Current time step
	\item $n+1$ - Next time step
\end{itemize}

Acceleration is calculated from the sum of the forces acting on the body and with the use of the mass of the objects and Newton's Second Law:

\begin{equation}
F=ma
\end{equation}

The simplest numerical integrator is explicit Euler (or sometimes referred to simply as Euler) integration:

\begin{equation}
\begin{split}
	v_{n+1}=v_n+a_{n+1}{\Delta}t\\
	s_{n+1}=s_n+v_{n}{\Delta}t
\end{split}
\end{equation}

However, this is not often used by physics engines as it can lead to instability unless short time steps are used.

A symplectic Euler (semi-implicit Euler) integrator is often used in physics engines. Symplectic Euler is similar to explicit Euler, except that the updated velocity is used before calculating the new position:

\begin{equation}
\begin{split}
	v_{n+1}=v_n+a_n{\Delta}t\\
	s_{n+1}=s_n+v_{n+1}{\Delta}t
\end{split}
\end{equation}

Symplectic Euler is faster to compute and remains accurate over many iterations and is stable when longer time steps are used.

\subsection{Angular Motion}
In addition to solving linear motion, physics engines also solve angular motion. Angular motion will now be discussed and the following variables are used:
\begin{itemize}
	\item $T$ - Torque
	\item $I$ - Inertia Matrix or Inertia Tensor
	\item $\alpha$ - Angular acceleration
	\item $\omega$ - Angular velocity
	\item $\theta$ - Orientation
	\item $n$ - Current time step
	\item $n+1$ - Next time step
\end{itemize}

Orientation of objects are represented using Quaternions. Torque is calculated using the following equation:

\begin{equation}
T=I\alpha
\end{equation}

This equation is the rotational equivalent of $F=ma$.
%Inertia
Angular velocity $\omega$ can be integrated relative to angular acceleration $\alpha$ using the following equation:

\begin{equation}
\omega_{n+1}=\omega_n+\alpha_n\Delta t
\end{equation}

Orientation $\theta$ can then be calculated using $\omega$ and the following equation:

\begin{equation}
\theta_{n+1}=\theta_n+\theta_n\omega_n\frac{\Delta t}{2}
\end{equation}

This equation is a fast approximation of orientation.

\subsection{Integration comparison with non-real-time simulations}
The equations used in real-time physics engines use iterative processes and approximate a continuous process with discrete steps. As a result, errors due to inaccuracies in the discreteness accumulate over time due to the iterative nature of the integrators. Different real-time physics engines will often give different results for the same simulation, despite identical starting parameters \cite{Boeing2007}.

\subsection{Collision Detection}\label{collision_detection}
Objects are represented by geometry colliders. Collision detection works by detecting overlaps between geometry representations  (contact determination).
Typically objects have simple colliders, such as boxes, capsules, cylinders and spheres. More complex colliders are often supported, such as convex and concave hulls. Colliders can either be static or dynamic.

Optimisations for collision detection are used to avoid comparing every possible pair of objects. Phases of collision detection are used, known and the broadphase and the narrowphase.
%TODO: Give examples of these

In addition to informing the collision response phase, callbacks can also be generated, allowing any part of the software to be informed of collision events that have taken place. For example, the game logic may receive events of when a bullet hits an avatar in order to determine when a player has been shot in a shooting game.

%Collision detection
%Collision response
%Constraints
%Body describes any non-point-like physical entity

%Main physics loop (what goes on within a simulation step)
%Explanation of rigid bodies, actors, shapes, constraints
%Explanation of simulation and query shapes
%Explanation of trigger volumes
%Explanation of kinetic vs kinematic
%Explanation of sleeping

%It is possible for the main application to update more often than the simulation frequency
%It is also possible that the main application update is unable to be executed at the same frequency as the physics simulation frequency. Options are running the simulation at a bigger time-step or simulate multiple, smaller sub-steps. Trade-off between keeping consistent behaviour and performance.
%Diagrams for above
%Well of despair example and diagram
%Solutions to well of despair:
%Decouple physics from application update with use of sync and async scene, can make player interaction more difficult
%allow time dropping
%variable time-stepping
%simplifying the physics scene

%PhysX runs on a separate thread by default
%It is not possible to read/write directly to the scene during simulation, scene is buffered so changes can be made and will only affect the next simulation step.
%Image of time-slots
%Event callbacks for collisions/triggers

\subsection{Collision Response}

Collision response is the phase of the real-time physics loop which deals with integrating into the model the effect produced by contacts between entities within the system. Collision response will take into account mass, coefficient of restitution (loss of kinetic energy during a collisions) and the location and angle of the collision. Collision response can be very simple to calculate for simple geometric shapes, but becomes expensive when more complex mesh representations are used.
%\subsection{Constraints}

\subsection{Performance of Real-Time Physics Engines}
In this section the performance of real-time physics engines will be discussed. Examples of different scenarios under different performance conditions will be used and discussed using time-sequence diagrams.

Physics engines are kept as separate as possible from the rendering loop and other logic in the main loop. Fig. \ref{GoodPerf} shows a time sequence diagram of a game loop with good performance. The target physics time step is 16ms. Every 16ms that is passed, a physics update is triggered, simulating 16ms of the simulation. Multiple update loops can be completed between physics steps being performed.

\begin{figure}
	\centering
	\input{Figs/GoodPerfNoVSync.pdf_tex}
	\caption{Time sequence diagram of good performance.}
	\label{GoodPerf}
\end{figure}

Fig. \ref{SubStep} shows a time sequence diagram of sub-stepping. If an update loop takes longer than the target time-step (in this case 16ms), multiple physics steps will need to be performed to update the simulation to the present time. This is known as sub-stepping. Sub-stepping is supported by PhysX. Longer update times may occur in many situations, such as a read from the hard-drive, a background process performed by the OS or particularly expensive game logic or AI task.

\begin{figure}
	\centering
	\input{Figs/SubStepping.pdf_tex}
	\caption{Time sequence diagram of sub-stepping.}
	\label{SubStep}
\end{figure}

Fig. \ref{ExpensivePhysics} shows a time sequence diagram of a scenario in which the physics simulation is expensive to step. This could be the result of a large number of objects being simulated or complex collision detection. As a result of the expensive physics update the render frame rate is reduced to 60Hz, despite the main update only taking $~3ms$.
%TODO: Expand this?

\begin{figure}
	\centering
	\input{Figs/ExpensivePhysics.pdf_tex}
	\caption{Time sequence diagram of expensive physics.}
	\label{ExpensivePhysics}
\end{figure}

%Fig. \ref{WellOfDespair} shows a time sequence diagram of a scenario in which a long update frame has occurred. The main update has taken long enough that two sub-steps must be simulated, as each sub-step takes $~9ms$, it will take $~18ms$ to simulate. As a result, the time step also misses the target of $16ms$,
%
%\begin{figure}
%	\centering
%	\input{Figs/WellOfDespair.pdf_tex}
%	\caption{The well of despair.}
%	\label{WellOfDespair}
%\end{figure}

\section{Scalable Non-Real Time Physics}
Scalable non-real time physics simulations include fluid simulations, meteorological simulations and accurate physical simulations e.g. robotics, wheeled and tracked vehicle dynamics and mechatronics. An example of a scalable non-real time physic is Project Chrono \cite{Chrono}. Non-real time physics simulations work very differently from real-time, accuracy is highly favoured as opposed to the fast, plausible simulations in real-time physics. In addition high latency (10s of ms) is a small issue relative to large time-steps used in such simulations.

\section{Online Gaming}
%TODO: Change to include related work will be discussed
In this section an overview of online gaming challenges and architectures will be discussed.
The main challenges facing online gaming are consistency, latency, fault-tolerance, fairness, cheating, and scalability.
These will all be briefly explained, although they are not all the main focus of this study, this is intended to make the reader aware of the challenges different architectures address. Finally, important aspects of online gaming that are relevant to this study are also discussed. The purpose of this study is to demonstrate scalability and consistency of real-time physics through the use of a distributed server architecture. In later sections, consistency will be defined in greater detail with respect to real-time physics and online gaming and existing work addressing scalability and consistency will be discussed.
%Existing work into scalability in online gaming will discussed leading into discussion of online gaming architectures. Finally, important aspects of online gaming that are relevant to this study are discussed.

\subsection{Consistency}
As online games are distributed (either between clients and a server, peers or multiple servers), inconsistent states can occur. Multiple peer/servers execute updates in parallel, however if these are executed out of order, such as due to messages being received out of order or messages lost entirely, inconsistent states can arise.  Different aspects of game state require different levels consistency and games often employ consistency resolution instead of inconsistency prevention \cite{P2PForMMOs}.

%Strong Consistency
%Weak Consistency
%2 of 3, availability, network partitioning, consistency
%An Enhanced Dead Reckoning Model for Physics-Aware Multiplayer Computer Games
%Peer-to-Peer Architectures for Massively Multiplayer Online Games: A Survey
%TODO: Talk about consistency in Proposed Solution

\subsection{Latency}
Latency can significantly affect the quality of experience of a game and can impact both a player's performance in a game \cite{EffectsofLossandLatency, claypool2010latency} and subjective perception of the game \cite{dick2005analysis}. However, this depends heavily on the game genre and actions taken by the player \cite{LatencyandPlayerActions, claypool2010latency}. Fig. \ref{fig_LatencyCompensation} shows an example of the effects of latency on a networked game. Where the target appears to the player and hitboxes on the server used to detect a player's shot are significantly different.

% Latency and scalability: a survey of issues and techniques for supporting networked games
% Synchronization Technique - Lock-step
% Optimistic Technique
%TODO: Talk about latency compensation in Proposed Solution

\begin{figure}
	\centering
	\includegraphics[width=\textwidth]{Figs/LagCompensation.jpg}
	\caption{ A screenshot taken when 200ms of latency was present on a client. The red hitboxes show the target position on the client (100ms + interpolated period). While the user command was travelling to the server, the target continued to move to the left. When the user command arrived at the server, the server reverted the target position (blue hitboxes) using the estimated time of the command execution. The server calculates whether or not the hist was successful and sends a confirmation message to the client \cite{Source}.}
	\label{fig_LatencyCompensation}
\end{figure}

\subsection{Fault-tolerance}
Fault-tolerance is a challenge for online gaming and can result from failures or unscheduled disconnections of server or peers which can lead to the loss of game state \cite{P2PForMMOs}.

\subsection{Fairness}
Fairness is the degree of difference among all players’ gaming environments, i.e. players should be treated equally and no game advantage/disadvantage should be given to players due to factors like latency \cite{P2PForMMOs}.

%MANAGING LATENCY AND FAIRNESS IN NETWORKED GAMES

\subsection{Cheating}
Cheating is when players maliciously gain an unfair advantage in a game. Cheating reduces the quality of experience for non-cheating players and is a main concern in the design of game architecture \cite{P2PForMMOs}.

\subsection{Scalability}
Scalability in online games is typically measured in terms of players that can be supported \cite{turchini2015scalability}. An online gaming system's ability to scale depends upon the architecture employed, discussed below. However, scalability in terms of supported players should not be confused with the scalability of real-time physics, which is the focus of this study. Scalability of real-time physics can be measured in terms of objects that can be simulated while maintaining real-time speeds.

%This screenshot was taken on a listen server with 200 milliseconds of lag (using net_fakelag), right after the server confirmed the hit. The red hitbox shows the target position on the client where it was 100ms + interp period ago. Since then, the target continued to move to the left while the user command was travelling to the server. After the user command arrived, the server restored the target position (blue hitbox) based on the estimated command execution time. The server traces the shot and confirms the hit (the client sees blood effects).

%Client and server hitboxes don't exactly match because of small precision errors in time measurement. Even a small difference of a few milliseconds can cause an error of several inches for fast-moving objects. Multiplayer hit detection is not pixel perfect and has known precision limitations based on the tickrate and the speed of moving objects.

\subsection{Architectures}
Online game architectures fall into the following main categories: client-server; peer-to-peer; hybrid peer-to-peer; and distributed server (also referred to as multiserver). Each type has advantages and disadvantages and suitability depends on a number of factors, including number of players and whether or not the game is short-session-based or persistent.
%We discuss the wider topic of online gaming (client-hosted, P2P, server), challenges of latency, security/cheating and computational limits. Also some details of online gaming servers are discussed, specifically, typical server frame-times and network tick updates.

Client-Server architecture is a type of architecture in which the game is executed and game state is managed entirely by the server. Clients connect to the server and receive the necessary information about the game world. All messages and interactions are sent through the game server and the server is responsible for disseminating messages to the appropriate clients. The main challenge with this approach is scalability, as a single server can only support a limited number of players \cite{Ferretti2018}. This is normally solved with the addition of more servers, i.e. switching to a distributed server architecture. As all communication goes through the server, clients do not directly communicate with each other, meaning latency can be increased for interactions with other players.
As there is only one central version of the game state, consistency resolution is simplified to solving inconsistencies between server and client and the server treated as the correct master copy. In addition, fault-tolerance is simplified to keeping a single backup of the sate of the central server, although this adds more complexity and cost, and can reduce scalability. Client-Server architectures are less prone to cheating than peer-to-peer based architectures, as the game provider has complete control over the game state \cite{P2PForMMOs}.

\begin{figure}
	\centering
	\input{Figs/ServerHosted.pdf_tex}
	\caption{Server hosted networked game.}
\end{figure}

%\subsection{Client-Hosted}
%
%\begin{figure}
%	\centering
%	\input{Figs/ClientHosted.pdf_tex}
%	\caption{Client hosted networked game.}
%\end{figure}

Peer-to-Peer, often referred to as`P2P', is a type of architecture in which the game is executed and game state is managed entirely by the peers, although peers are often only responsible for a subset of the game state, such as the entities they are currently interacting with. A peer-to-peer architecture is shown in Fig. \ref{fig_P2P}. Peers are all responsible for message forwarding to each other. In other words, peers act as both server and client. Peer-to-Peer reduces the cost for the game provider of maintaining expensive servers and can reduce latency between players, as communication is performed directly between peers, rather than communicating through a server. In addition, it provides scalability in terms of compute power, as the more peers that join, the more resources available to the system. However, as more peers join, the greater the communication overhead is between peers. In addition, peer-to-peer is prone to the problems of fault-tolerance, data consistency and cheating by players. A peer is more likely to fail or experience unscheduled disconnection than a dedicated server. As each peer is responsible for the game state, it is possible for communication errors to occur, resulting in two peers with different game states or a peer maliciously altering the game state or the messages being sent to other peers in order to cheat. The fault-tolerance requirements of short-session-based games are lower than persistent games, making peer-to-peer architectures better suited to short-session-based games \cite{P2PForMMOs}. Peer-to-Peer architectures have received much research attention in previous years, with many solutions that attempt to address the problems above, through the use of techniques discussed in \cite{P2PForMMOs}.

%VoroGame, work is distributed amongst clients.
%VoroGame uses Voronoi spatial partitioning to assign a region to a peer and an overlay based on a distributed hash table for data distribution.

\begin{figure}
	\centering
	\input{Figs/PeerToPeer.pdf_tex}
	\caption{Peer-to-peer hosted networked game.}
	\label{fig_P2P}
\end{figure}

Hybrid Peer-to-Peer architectures are a combination of client-server and peer-to-peer architectures. The peer-to-peer part of the system can be responsible for different aspects of the system, including Cooperative Message Dissemination, State Distribution, Basic Server Control and distributing software updates. \cite{P2PForMMOs}. Hybrid Peer-to-Peer enables trade-offs between consistency control and scalability, determined by how the system is divided between server and peer-to-peer. The more responsibility peers have, the greater the scalability but at a loss of consistency control.
%These can be broadly classified into two types: Homogeneous, in which all nodes have similar responsibilities and Heterogeneous, in which some peers be

% TODO: More references for this
Distributed server or Multi-Server architectures use multiple servers and the computational workload is divided between the servers. This can be achieved in one of two ways, either through `shards' or through division of the game world.

In the `shards' method, complete and separate instances of the game world exist, each maintained by one server. Each server is responsible for a different set of clients. The game can be scaled through the introduction of more servers, supporting more clients. However, as each instance of the game world is separate, there can be no interaction in the game world between players on different shards \cite{P2PForMMOs}.

In the game world division method, there is a single instance of the game world and the workload is distributed either through each server being responsible for a region or a set of players. Division methods are discussed further in Section \ref{distrubted_virtual_env}. Even with the workload distributed between servers, one server may be become overloaded if the workload is too high, for example, by a large number of players in a region being managed by a single server. Dynamic load-balancing schemes can be employed to improve distribution between servers and prevent servers being overloaded when resources are available on other servers. The disadvantage of distributed servers is the need for complex hand-offs when players migrate or interact between servers and can lead to consistency problems between servers as latency will always exist between servers \cite{P2PForMMOs}.

The distributed server approach enables scalability as more servers can be utilised, allowing support for more players. However, depending on workload distribution, more problems are introduced. Fault-tolerance is potentially higher than a single server solution, even if no backup system is employed, as only players connected to the failing server will be affected \cite{P2PForMMOs}.

%TODO: Mention cost? Persistent games?

\subsection{Update Rate and Network Tick Rate} \label{update-rate-test-values}

Two important aspects of online video game servers are the update rate and network tick rate, which will now both be defined. Update rate is the rate at which the server updates the game state, such as game logic updates and AI. Network tick rate is the rate at which the server communicates the game state to clients and clients communicate interactions with the server, such as movement input for a player character \cite{pisan2004challenges}. The two rates can be independent of each other and the network tick rate can be lower than the server update rate, reducing the network requirements through less frequent communication between server and client.

In many cases it is not possible for a server to communicate the entire game state to the each client due to bandwidth constraints. Instead, techniques are used to prioritise and filter the information that is most relevant to each client, in order to reduce the data that needs to be communicated with clients \cite{pisan2004challenges}. These techniques are known as Interest Management and discussed further in \ref{InterestManagement}.

The rates chosen for network tick rates depend on a variety of factors, including the required level of accuracy and bandwidth restrictions. Higher tick rates enable higher accuracy, but at the cost of more bandwidth being required. Different genres of games have different accuracy demands. For example, in first-person-shooters (FPS), higher tick rates result in a higher mean shooting accuracy for players \cite{lee2015evaluation}. Whereas, genres like real-time-strategy (RTS) games have more relaxed accuracy requirements. In the RTS Age of Empires, latency only becomes noticeable if it exceeds $500ms$, meaning network tick rates can be very low without being noticeable to the player \cite{pisan2004challenges}. Tick rates of popular network games range from 128Hz for CS:GO to 20Hz for Minecraft \cite{metzger2016comprehensive}.

\subsection{Delta-Encoding}
%TODO: Mention Delta-Encoding is used between servers for auras in implementation
A common optimisation used by networked games is delta-encoding. Typically in games entities and their state change little from one update to the next, i.e. it is expected that only a small number of entities change between updates. Delta-encoding reduces network traffic by the server only encoding the difference (delta) between updates, reducing the size of messages that need to be sent \cite{bharambe2006colyseus}. Additionally, if an object's state has not changed, no message is required to be sent, dramatically reducing network overhead in cases of a large number of objects which are not changing. The main drawback of this technique is a missed update message sent to a client would lead to a different entity state from that point for that client and can lead to missing entities or entities that have been deleted on the server, remaining on the client. As result of this, delta-encoding either requires reliable message transmission between server and client or a periodically transmitted full "key" frame, containing the state of all entities \cite{bharambe2004supporting}.

\subsection{Protocols}
Games use both TCP (Transmission Control Protocol) and UDP (User Datagram Protocol). Most games use the UDP network protocol for transmission of short and time-sensitive data and TCP for long and content-aware data, providing services such as matchmaking \cite{2018NetworkTraffic, 2012PacketLevelTraffic}. UDP offers best effort communication. Unlike TCP, UDP is a connection-less protocol and does not guarantee data delivery, but suffers from less latency. In many situations in online games, lost packets are not critical, for example in an online game in which  the server informs each client of the positions of each player, there are a large number of updates, meaning a missed update is not critical \cite{pisan2004challenges}.
%Network play in online games has to be constructed around latency and packet-loss

\section{RakNet}
RakNet is the gaming network library used in the development of the implementation of AP. Features of RakNet used by AP will now be described.

\subsection{Reliability and Ordering layer}
RakNet uses UDP but also provides a reliability and ordering layer. When messages have the reliable option enabled, RakNet guarantees that UDP packets will arrive at their destination eventually. When messages have the ordered option enabled, RakNet guarantees that the packets are ordered at the destination. Ordering has the advantage of removing the need to handle out of order packets \cite{RakNetReliability}.

\subsection{Replica Manager}
RakNet provides a replica manager plugin, which supports the use of replicas and delta-encoding for the updates of their states. Replicas are replicated entities, hosted by one node and replicated on connected nodes. For example, a server is responsible for the updates of a set of entities, the entities are then replicated on all connected clients. The replica manager handles the broadcast of: existing game entities to new connections, new game entities to existing connections; deleted game entities to existing entities and updates of states of replicated entities \cite{RakNetReplica}.

\section{Consistency in Real-Time Physics} \label{ConsistencyRealTimePhysics}
%(and the lack of, due to the challenges faced). Mostly limited to dead-reckoning
%https://books.google.co.uk/books?hl=en&lr=&id=ujfOBQAAQBAJ&oi=fnd&pg=PA307&dq=Physics+networked+games&ots=OC5YWxmd25&sig=vcxatd9Wl0_SdxCAUZvmP6BWl7I&redir_esc=y#v=onepage&q=Physics%20networked%20games&f=false

%Predictive schemes that run locally

Maintaining consistency in the physics aspect of games when distributed is great challenge. This is due to the time-sensitive nature of physics (millisecond differences can result in completely divergent results, discussed further in \ref{divergingResults}) \cite{2012EnhancedDeadReckoning}.

Consistency in physics can be divided into two categories:
\begin{itemize}
\item Consistency in simulation view, for example, differences between the physics simulation on the server and a client.
\item Consistency within the simulation itself (when the simulation is distributed between devices).
\end{itemize}

\begin{figure}
	\centering
	\includegraphics[width=\textwidth]{Figs/DeadReckoning}
	\caption{An example of dead-reckoning \cite{2012EnhancedDeadReckoning}.}
	\label{fig_DeadReckoning}
\end{figure}

The former is a very common issue in online gaming, particularly due to high latency and limited bandwidth between servers and client, necessitating the need for client-side correction techniques. The most common technique used is dead-reckoning, shown in Fig. \ref{fig_DeadReckoning}. The use of dead-reckoning in games is a well researched topic, including the suitability for different genres \cite{2002DeadReckoningSuitability}, the accuracy of dead-reckoning \cite{2004AccuracyDeadReckoning}, its effects on fairness \cite{2005FairnessDeadReckoning} and enhancements of the technique, such as \cite{2012EnhancedDeadReckoning} which takes into account environmental (static) objects when dead-reckoning is performed.

Although these correction techniques may be suitable for handling inconsistencies in simulation view between servers and clients, they are not suitable for maintaining consistency within a distributed simulation, which is the focus of this research. This is because in order to prevent diverging results, strong consistency of collisions must be maintained (discussed further in \ref{divergingResults}).

There are two approaches to handling the authority of physics in networked games:
%As a result of the inconsistencies in distributed real-time physics and importance of consistency in gameplay, this leaves game developers with two approaches:

\begin{enumerate}
	\item Server-authoritative physics - the server is responsible for simulating the physics aspect of the game.
	\item Client-authoritative physics - the physics is simulated on the clients in a distributed manner.
\end{enumerate}

Server-authoritative physics on a single server does not suffer from inconsistencies within the simulation, meaning there is no potential for the physics state to diverge as there is only one single simulation. Inconsistencies between the server and client will exist due to latency, but the state on the client can be corrected. However, server-authoritative physics uses up limited computational resources in single server systems.

Server-authoritative physics in distributed server systems creates complex problems at the boundaries between servers. These boundary problems include:
\begin{itemize}
\item The handing off (migration) of physical entities between servers, e.g. when an object traverses between server regions.
\item Maintaining consistent states of physical entities between servers, i.e. servers will need to be aware of the state of objects being simulated on a different server and this state needs to be kept consistent between the two servers.
\item The interaction of entities between servers, i.e. objects being simulated on different servers that should physically interact with each other.
\end{itemize}

Client-authoritative physics creates consistency problems within the simulation, as the physics states on different clients will quickly diverge (discussed further in \ref{divergingResults}). This is especially true with high latencies and limited bandwidth experienced between clients. Client-side resources, both computational and network must be sacrificed in order to attempt to reach consensus on the physics state, however, inconsistencies will always be present. Gameplay aspects of games, such as life/death and score decisions require a high-level of consistency in order to maintain fairness \cite{savery2014consistency}. Due to these consistency problems, physics is unable to influence gameplay without sacrifices to fairness being made.

This study aims to address the problems of consistency in distributing real-time physics between servers in multi-server networked games. Solving this problem would allow for physics to play a larger role in networked games, including having significant influences on gameplay.

\section{Distributed Virtual Environments} \label{distrubted_virtual_env}
%We look at existing ways of distributing game worlds and previous work carried out on these approaches. These fall into two categories, migratory (approach used by AP) and non-migratory. The studies found non-migratory to be the better solution when focusing on player-player interaction and we will discuss why migratory is the better solution for physics body-physics body interaction. Important concepts such as interest management are introduced to the reader.

Although there has been research utilising multiple servers to distribute the task of solving physics based problems (e.g., \cite{mashayekhi2018automatically}), there is no known literature describing real-time interactive physics exploiting the addition of servers to gain scalability. The closest work to this challenge is that carried out to seek scalability in terms of player numbers in online gaming in the field of Distributed Virtual Environments (DVEs).

There are primarily two ways in which server-side resources can provide scalability in online gaming (e.g., DVEs): (1) Migratory; (2) Non-migratory. In migratory approaches, a server will assume responsibility for handling in-simulation objects within a region. When objects traverse region boundaries into a region that is the responsibility of another server, they will be handed over to the other server. In a non-migratory approach, in-simulation objects are allocated to the responsibility of a particular server at instantiation time and stay with that server until they are deleted.

The benefit of a migratory approach is that tightly coupled objects (interacting frequently) can be co-located on the same server, reducing interaction latencies. However, the act of moving such objects may be costly in terms of time required to resolve the hosting requirements of an object. The benefit of a non-migratory approach is that servers are rarely exhausted but network traffic will result in higher latencies that will inhibit the fidelity of interaction between objects.

Migratory and non-migratory approaches are now described in greater detail.

In the migratory approach, a single game world exists, but is divided into geographical regions. Each region is maintained by a separate server (e.g. \cite{AnOverlappingArchitecture, ScalabilityIssues, LoadBalancingForDistributedVR, ALoadBalancingAlgorithm, SpatialOS}). The main drawback of this approach is the complexity of handling interactions between objects in different regions/servers while maintaining consistency \cite{P2PForMMOs}. A technique to minimise these issues is to use overlapping regions between spatial partitions. Servers share state information about objects in the overlapping region (examples include 'zoning' as described in \cite{AnOverlappingArchitecture} or 'sub-regions' as described in \cite{ScalabilityIssues}). Examples of games using this technology include \cite{Vanishin30:online} and \cite{WorldsAd48:online}, which use the SpatialOS platform \cite{SpatialOS}. %However, the techniques used by SpatialOS are not described in any literature. Their demonstration video exhibits unnatural object "jitter", which is possibly a result of network latency.

In the non-migratory approach, the game world is not divided into geographical regions and players are split between servers in one of two ways: (1) Several instances of the game world run with complete independence from one another (known as shards e.g.\cite{WOW}) and players have no interaction across shards \cite{P2PForMMOs}; (2) Players are distributed amongst servers by some other non-geographical method and interactions with players on other servers requiring servers to share messages \cite{LoadBalancingforMMOs}.

Although shards allow a degree of scalability in the number of players, it is not suitable for use in scaling real-time physics simulations as all entities within a real-time physics simulation, in the same geographical region, may interact with each other.

In the case of architectures not using shards, Interest Management is required to prevent message passing growing polynomially as players increase (e.g. \cite{Bezerra2008} and \cite{LoadBalancingforMMOs}).

Despite DVE being a popular area of research, the literature is restricted to modelling player interaction across servers and balancing their support on different servers. Clearly, the interaction patterns of players are significantly less demanding in terms of timeliness than that of interacting physical objects.

% Some introduction to interest management?
\subsection{Interest Management}\label{InterestManagement}
The technique presented in this paper, Aura Projection, makes use of the aura concept from Interest Management. Interest Management is a term used to describe any method of restricting message dissemination between objects within a virtual space, with the aim of reducing the network overhead when large numbers of participants or players are connected to a virtual world \cite{Morgan2005}.

Interest Management can be broadly classified into two categories: Regions and Auras \cite{Morgan2005, storey2004determining}.

``In the region based approach the virtual world is commonly, but not always, divided into well defined uniform sized regions that are static in nature (i.e. their boundaries are defined at virtual world creation time)."\cite{storey2004determining}\\

``In the aura based approach each object is associated to an aura that defines an area of the virtual world over which an object may exert influence. Ideally, an object may potentially communicate their actions to only objects that fall within their influence."\cite{storey2004determining}\\

Interest management is a well researched topic and enhancements to it exist, such as \cite{Bezerra2008} which proposes the A3 algorithm. A3 uses a combination of a circular area of interest and field of view combined with a relevance gradient. \cite{LoadBalancingforMMOs} proposes a Behavioural Interest Management Technique that allocates resources based on player interactions. Auras (an area of interest/influence) are used to determine player message exchanges, reducing message passing while promoting player number scalability.

In addition to reducing the network traffic between servers, interest management can also be utilised to reduce the required network traffic between client and servers. In terms of physics being simulated on server(s), clients will be most concerned with objects within close proximity to them and less concerned with objects beyond the range in which can be physically interacted with. In addition, clients will be more concerned with objects in their field of view than objects that can't currently be seen. An example of an interest management technique using distance and field of view is the A3 algorithm \cite{Bezerra2008}. Through the use of client interest management it would be possible to simulate a persistent world far larger than could be simulated or rendered on a single machine, yet allow a player unrestricted, seamless access to the entire world.

Interest Management is relevant to this study as it enables the minimisation of network overhead in distributed virtual environments. It is important to note that objects within a virtual space are only affected by other objects in their region and neighbouring regions or objects within their area of influence. AP uses the concept of auras to minimise message passing between servers while still allowing time-space consistency to be maintained.

\section{Distributed Real-Time Physics}
%We will discuss previous work looking specifically at distributing real-time physics and how AP differs from these approaches.

In this section research into existing methods for distributing real-time physics across a cluster of nodes in a network will be discussed.

Distributed Real-Time Physics has attracted a lot of commercial attention recently, for many applications including games, multi-agent AI, city planning and VR \cite{SpatialOS}. The commercial interest in Distributed Real-Time Physics is likely due to the recent availability of cloud computing, which allows for scaling of the required computing resources on-demand. On-demand scaling provides a more cost-efficient approach as opposed to the traditional use of private server clusters \cite{On-DemandResourceMMOGs}.

Using Distributed Real-Time Physics removes the limitation of the computational power of a single machine (such as the limitation in server-centric architectures \cite{ScalabilityforVirtualWorlds} and avoids the complexity and communication overhead of P2P architectures such as that described in \cite{VON}) thus allowing for greater scalability in both the number of users \cite{ScalabilityIssues} and complexity and size of the Virtual Environment.

Distributed Real-Time Physics techniques fall into two main categories, those that use multiple instances of the same physics engine (as used by AP) and those that distribute particular aspects of the computational workload of a physics engine. Both techniques will now be discussed.

Examples of previous attempts at scaling real-time physics engine through the use of distributing a particular aspect of the workload include \cite{Morgan2005} and \cite{allard2006distributed}.

\cite{Morgan2005} describes a way of scaling physics simulations through deploying a real-time collision detection service across a cluster of servers. The simulation is spatially divided into regions and each node is responsible for all narrow phase collision detections within one region. A dedicated node is responsible for determining which region an object is contained within and informing the region's node that the object should be considered for collision detection.
Objects intersecting region boundaries are discussed in \cite{Morgan2005}; objects intersecting a region boundary result in the same collision pair appearing in more than one region, these are dealt with by ensuring only one node will enact the narrow phase collision test for the pair. The process of identifying duplicate pairs is not described. The result of the response on a single object from collisions on two nodes is also not described.
%Two server can get different results from same collisions. What happens if there are a cluster of objects on the boundary?
% Surely this must require considerable message exchange and introduce latency as all messages must be exchanged before progressing to the next step? Result of responses added together?

% Peer to Peer networked games???

In \cite{allard2006distributed}, a modular approach to physics simulations is described. A dedicated module is used for each type of object (rigid body, spring-mass, fluid etc.). Interactions are then handled between object modules through interaction modules. Each module can be run on a node in a cluster, allowing the simulation to be scaled.

Techniques that distribute a particular aspect of the workload have not gained any commercial attention recently, unlike techniques that use multiple instances of the same physics engine, which will now be discussed.

Examples of Distributed Real-Time Physics that use multiple instances of a physics engine include SpatialOS \cite{SpatialOS} and Aether Engine \cite{AetherEngine}. SpatialOS spatially partitions the world into regions, each region is a separate instance of a physics engine. Where regions meet, there is an overlapping area, allowing objects hosted on different servers to interact. However, the specifics of the techniques used by SpatialOS and Aether Engine are not described in any literature. The demonstration video of SpatialOS exhibits unnatural object "jitter", which is possibly a result of network latency and collision inconsistencies.

This thesis proposes an alternative technique to SpatialOS and Aether Engine, AP, that does not use overlapping regions and reduces the effect of communication delays between servers regarding states of physical entities. If the instability problems e.g. "jitter" can be solved, this would enable the use of Distributed Real-Time Physics for games and simulations that rely on stable and consistent physics.

%In addition increases the available size and complexity of the world. Game developers design around the limitations of current technology; increasing the achievable size and complexity of virtual environments reduces this as a limitation.
%Why spatially partitioned and not other MSDVEs?

% We don't know how SpatialOS works, so maybe best to reword it as this paper describes an approach to achieve the same goal of having a distributed simulation with physics

%\subsection{Distributed Architectures}
%The complexity of the different simulations can be separated, which has advantages from a software-engineering perspective as it allows for separation of concerns. For example, one implementation of a fluid simulation could easily be replaced with another implementation without any changes to the master simulation being required.

%\subsection{Our Contribution}
%Prior research has not addressed the problem of tightly-coupled interactions of entities between servers.
%Tightly-coupled interactions present a challenge for MSDVEs as server communication is subject to delays and bandwidth restrictions.
%Physical interactions, such as those required by real-time physics, near region boundaries are an example of a tightly-coupled interaction between servers. For example, Real-time physics engines typically run with a step time of 16\si{ms}, a 100\si{ms} network delay would mean a 6 step discrepancy in the states of objects, which can lead to extremes in the simulations resulting in instabilities. In addition, we will demonstrate why a naive approach to real-time physics for Spatially Partitioned MSDVEs will also inevitably lead to time-space consistency issues.
%
%Techniques to deal with physical interactions at the boundary that work within the delay and bandwidth constraints of network communication, are therefore necessary in order to enable real-time physics to behave in a realistic manner across a Spatially Partitioned MSDVE.
%We propose a new technique, Aura Projection, to address this challenge.

\section{Cloud Computing}
In this section a brief overview of cloud computing is given, deployment and service models are discussed. This study's implementation is deployed on the chosen cloud provider, Amazon Web Services (AWS). The latency and packet-loss conditions that affect AP are presented and these values will used to inform the correctness experiments performed on AP.

%We discuss the wider context of cloud computing, how AP is deployed on the cloud and also specifically conditions that affect AP in the cloud, i.e. latency and packet-loss

Cloud computing is a large scale distributed computing paradigm \cite{2008CloudComputing}. Cloud providers offer flexible, real-time on-demand services, including servers, storage and applications. Cloud Computing allows compute resources to be rapidly and elasticity provisioned \cite{2012CloudComputing}.

Cloud deployment models are categorised into the following:
\begin{itemize}
\item Private cloud - Set up within an organisation's internal data centre. This is much more secure than the public cloud due to its internal only exposure and access is limited to designated users within an organisation \cite{2012CloudComputing}.
\item Public cloud - Resources are provided by a third-party provider. Users request resources in a self-service manner over the Internet. Users are typically charged on a pay-per-use model. Public cloud services are less secure than private cloud as users have more responsibility in ensuring the security of their applications and data from potential malicious attacks from other users in the cloud. Public cloud services offer far greater resources than a private cloud, allowing spikes in demand to be provided for  \cite{2012CloudComputing}.
\item Hybrid cloud - A private cloud linked to one or more public clouds. This provides solutions with more secure control over data and applications while still allowing public access over the internet \cite{2012CloudComputing}.
\end{itemize}

Cloud Computing Service Models are categorised into the following:
\begin{itemize}
	\item Infrastructure–as–a—Service (IaaS) - Provides basic hosting of resources, e.g. Virtual Machines (VM)s and storage \cite{2012CloudComputing}.
	\item Platform–as–a–Service (PaaS) - Provide the ability to build or deploy applications on top of IaaS \cite{2012CloudComputing}.
	\item Software–as–a–Service (SaaS) - Provides entire sets of applications running in the cloud. Users have no responsibility or management oversight for SaaS. Examples include Gmail from Google \cite{2012CloudComputing}.
\end{itemize}

%Previously scaling up software would require a single machine with more computing power or a dedicated cluster. Cloud computing allows for on demand allocation of resources, dramatically cutting the cost. There has been a big move to abstract architecture away from the applications running on it, containers such as docker and even further with things like Google's App Engine.

%https://aisel.aisnet.org/cgi/viewcontent.cgi?article=3672&context=cais

\subsection{Latency Values}
In order to validate the correctness of AP, experiments were conducted on AP in the cloud under differing conditions, including when subject to different levels of latency. Real world values of latency were used with values taken from a recent study that performed a series of exhaustive performance tests across all major cloud service providers, including our chosen provider, (AWS) \cite{ThousandEyesCloudPerf2019}. Benchmark categories included:
\begin{itemize}
	\item Global end-user network latency - measured between a variety of global ``end-user'' machines across the Internet and different geographical cloud availability zones (AZs)
	\item Inter-region latency - measured between cloud hosts located in different geographical regions within the same cloud provider
	\item Inter-AZ latency - measured between cloud hosts located within the same geographical region and within the same cloud provider.
\end{itemize}

This study is concerned with inter-region and inter-AZ latencies as these are the latencies that affect server-server communication and the correctness of the system. Lower latency is ideal for the deployment of a real-time distributed physics system, in the case of AP, lower latency means smaller auras leading to better partitioning and subsequent performance. However, inter-AZ deployment may not always be possible or desired (e.g. lack of availability of resources in one AZ or to reduce latency between users and some of the servers in the system in the case of geographically diverse users). Therefore the latency experiments used inter-AZ latency and low inter-region latency values. The lowest latency observed was from the inter-AZ category, i.e. servers hosted in the same geographical region at $<2ms$. Inter-region latency measured in the range of ($7-302ms$).

The chosen values for the latency experiment were as follows: $2ms$, $8ms$ and $16ms$. These values represent inter-AZ latency and low inter-region latencies within AWS, for regions that lie within same continent (eu-West-2 - eu-west-3) and (eu-West-1 - eu-west-2) \cite{ThousandEyesCloudPerf2019}.

%Dale's background starts here
\subsection{Packet-Loss Values}
Another factor that affects the performance of networked applications is packet-loss. An experiment was conducted in this study to determine the effects of packet-loss on the correctness of AP. The most common causes of packet-loss include network congestion \cite{1998PacketLoss} and bit errors in wireless transmission \cite{2005PacketLoss}. According to \cite{ThousandEyesCloudPerf2018}, carried out in 2018, cloud providers' networks have a very high level of reliability and exhibit only negligible packet-loss (measured at 0.01\% of packets lost, on average). This holds true even when traversing inter-region backbone links and between different cloud providers. The only significant measured level of packet-loss was between some geographical ``end-user'' locations outside of the cloud providers' networks, and were typically $<1\%$. However, this study is only concerned with packet-loss between servers in the cloud and not ``end-users''. The only notable exception to this and worst case for packet-loss was for traffic entering or exiting China, which experienced packet-loss as high as $8\%$.

The chosen values for the packet-loss correctness experiment range from $0\%-20\%$. These values cover the entire range of expected packet-loss values while running in the cloud, as well as beyond those values, in order to determine what impact severe packet-loss would have on the correctness of AP and establish any trend increasing packet-loss has.

\section{Real-time Physics for Scalable Simulations}
%Real-time simulations are being used more in scientific research, however these are limited to what can be achieved on a single machine. AP allows real-time physics simulations to be scaled, enabling large or complex simulations, that otherwise wouldn’t have been able, to run in real-time.

In the past, real-time physics engines have not always been suitable for use in simulations \cite{Boeing2007}. However, in recent years significant effort has been put towards realism of real-time physics engines and the mathematical error has reduced. Commercial game engines (using real-time physics) are finding their use in other industries, including their application in virtual simulations (e.g. \cite{Xu2017, Lu2017, Shah2018}, collaborative VR \cite{NVIDIAHolodeck} and in film production \cite{mehta2015animated}.

%TODO: The advantages of real-time physics for non-game applications?

However, real-time physics for use in other applications has been bounded by the computational power of a single machine. For large, detailed and/or dynamic simulations, this may be insufficient \cite{koszela2018distributed}. Prior to the proprietary commercial software SpatialOS \cite{SpatialOS} and Aether Engine \cite{AetherEngine}, real-time physics simulations have been limited to what can be achieved on a single machine. Scalability in simulations can be achieved by distributing a real-time physics engine across multiple machines, alleviating the computation limit of just one machine. This would allow many more applications to take advantage of real-time physics. This study aims to bring the methods for distributing real-time physics into an academic setting for the first time.

\section{Microservices for Game Engines}
Microservices have gained much recent attention in the software industry in the context of cloud computing. The reason for this, is the microservice architecture allows for greater leverage of the opportunities that cloud computing presents. Additional advantages include flexible horizontal scaling, as well as more efficient team structures during development \cite{2017ExtractionofMicroservices}.

Popular existing commercial game engines, such as Unity \cite{Unity} and Unreal Engine \cite{Unreal}, are based on the Monolith architecture. However, for game engines to take greater advantage of cloud deployment a move to a microservice architecture will be needed. This would allow for independent horizontal scaling and resource provision management of the different systems within a game engine, such as graphics, physics and AI. Despite the recent commercial interest in microservice architecture, there has been no academic research into the use of microservices for game engines. The only notable exception to this is \cite{vaha2017applying}, however, this has a limited focus to the application of microservices to the genre of Massively Multiplayer Online Role-Playing Games (MMORPG).

A microservice architecture for a game engine would create a more cost-efficient approach to cloud-hosted games and simulations, while also creating the potential for the scalability of individual systems on an on-demand basis. This study concentrates on separating out the physics system from the game engine and distributing it across multiple servers while maintaining the real-time streamed service to players. Through this distribution, this study aims to demonstrate that the physics aspect of a game engine can be horizontally scaled through the use of cloud computing.

\section{Streamed Gaming}
%The main foreseeable application of AP is Streamed Gaming, with the use of large multiplayer worlds, that are persistent and scalable with dedicated and elastic physics nodes. Physics is no longer limited to what can be simulated on a single machine

Streamed Gaming (also know as Gaming as a Service or Cloud Gaming) consists of cloud servers streaming to a player's device with player input being returned to the cloud server. The player's device acts as a thin client. The main benefit is that a player does not require expensive, powerful hardware, and games can be played on any operating system (e.g. Android, Linux and Mac) \cite{D_Angelo_2015}. However, these benefits come at the cost of bandwidth and latency requirements \cite{iCloudAccess}.

The first successful demonstration of game streaming was in 2001 by G-cluster, who publicly demonstrated game streaming over WiFi to a PDA in 2001 and launched a game-on-demand service in 2004 \cite{2016SurveyOnCloudGaming}. In the late 2000s, more companies introduced game streaming platforms such as OnLive \cite{OnLive}, Gaikai, and GameNow \cite{GameNow}. Due to financial difficulty in 2012, OnLive sold their patents to Sony and Gaikai and in 2012, Gaikai was bought by PSNOW \cite{PSNOW}.
Streamed Gaming services currently available include NVidia Geforce Now \cite{NVidiaGameStream}, PSNOW \cite{PSNOW}, Google Stadia\cite{Stadia} and Microsoft xCloud\cite{xCloud}. NVIDIA GRID hardware technology is targeted specifically at Streamed Gaming \cite{NVIDIACloud}.

A drawback to streamed gaming is the requirement for a significantly more powerful machine at the server-side than what would be required if the game was played solely at the client side. This is because the server not only has to run the game, but has to process the video and audio stream into a suitable format for streaming. In addition, real-time player interaction requires low latency and high bandwidth resulting in networking infrastructure more expensive than would be expected for regular streaming services.

In recent years, streamed gaming has become an active area of research, with many studies focusing on the effects of latency on the quality of service, e.g. \cite{CloudGamingArchPerf, chen2011measuring, jarschel2011evaluation, lee2012all, StormInCloudGaming, chen2013quality}. The challenges in streamed gaming that remain are both technical as well as economical \cite{2016SurveyOnCloudGaming}.

In streamed gaming, each game instance resides on a single server. There is no technology to balance the real-time requirements of the game across multiple servers. The core problem is that all gaming technology is built and designed for single console/PC install and the greatest bottleneck is the inability to share physics calculations across machines.

The technique presented in this study, AP, is intended for use in streamed gaming. This study aims to be preliminary research into the division of game engines into microservices, allowing streamed gaming to take better advantage of cloud infrastructure, such as through elastic scaling of resources as needed.
%As discussed in \ref{ConsistencyRealTimePhysics}, high latency between client and server
%
% Real-time physics as a microservice, combined with renderer microservices (using co-located render nodes) solves the issue of high latencies between client rendering and the physics simulation hosted on the server, the main problem with the use of physics in online gaming.
AP allows multiple servers to simulate physics, meaning physics simulations are no longer limited in size and complexity to that which can be achieved by only a single server. This allows for game streaming servers to make use of multiple physics servers, the numbers of which can grow and shrink as needed by the game and greatly increase the limit on size and complexity of physics within the game.

\section{Background Summary}
%In physics simulations, there must be an object present in the solving phase for it to be considered in the overall solution of the scenario. A non-migratory approach requires a "ghost" representation of the object in a remote server to enable interaction. Given the calculations and discretisation steps, a "ghost" object takes up just as many resources in deriving a solution as a real object. This rules out the non-migratory approach for our problem. This leaves migratory.
%
%Migratory approaches are concerned with managing the network traffic for those entities that could possibly exist on two servers but can only be solved on one. Such objects need to be placed with an owning server while minimising the effect of thrashing (where an algorithm frequently transfers objects between servers).

The reader has been provided with a brief overview of the working of real-time physics and introduced to important terms and concepts. The current state of online gaming has been discussed, including the main challenges faced. In addition, aspects of online gaming that are relevant to this study have been presented in greater detail. The challenges in physics in online gaming are those of latency and consistency i.e. maintaining consistent states while latency exists between servers. Techniques for handling consistency on longer time scales (100s of milliseconds), such as interactions between players, already exist and compensation techniques (based on dead-reckoning) exist to reduce the perceived differences in physics state due high latency between clients and servers. However, neither of these are appropriate for distributing the simulation across multiple machines. Therefore this study intends to address this challenge through the use of a novel technique called AP.

The applications of AP in both scalable games and simulations, as well as in cloud gaming, have been discussed. AP is a move towards real-time physics as a microservice for a microservice-based game engine, which can better take advantage of cloud infrastructure, ideal for cloud gaming. AP also provides a means of scaling real-time physics simulations beyond what can be achieved on a single machine.
For the remainder of this research, we describe our approach to solving this algorithmically, present how a working implementation was achieved, and present results evidencing our work. This is the first presentation of literature that can demonstrate real-time scalable server-side physics modelling and is a significant contribution to reducing the cost of commercialised streamed gaming.


\section*{One Game, Two Logics}
Consider a system that is described by the value of two different components:
Xolor (pronounced color) and Pattern. Each component has two values when
measured: red/blue for Xolor and solid/design for Pattern. A four-sided die
(tetrahedron) can represent each pair of component values on its faces for a
classical game (see following table).
\begin{tabular}{ccc}
  \toprule
  \multicolumn{1}{c}{\bfseries Xolor ($X$)} %
  &\multicolumn{2}{c}{\bfseries Pattern ($P$)} %
  \\%
  \cmidrule(lr){2-3}
  &\multicolumn{1}{c}{solid ($s$)} %
  &\multicolumn{1}{c}{design ($d$)} %
  \\%
  \midrule
  red ($r$)%
  &\raisebox{-0.5\height}{\includegraphics[scale=0.66]{Graphics/XrPs-scaled}} %
  &\raisebox{-0.5\height}{\includegraphics[scale=0.65]{Graphics/XrPd-scaled}} %
  \\%
  blue ($b$)%
  &\raisebox{-0.5\height}{\includegraphics[scale=0.75, trim={0.15cm 0.15cm
        0.15cm 0.15cm}, clip]{Graphics/XbPs-scaled}} %
  &\raisebox{-0.5\height}{\includegraphics[scale=0.6]{Graphics/XbPd-scaled}}
  %
  \\%
  \bottomrule
\end{tabular}

There are two players, the Classical (C) and Quantum Scientist (Q). Both
are honest and both have a firm grasp of classical reasoning. The only
difference is that C does not know quantum mechanical reasoning whereas Q
does.  Game play for a single round proceeds in four stages: Setup,
Guess, Verify, and Score.
\begin{enumerate}
\item Setup: Q \emph{prepares} the system and honestly records the results of
  \emph{measuring} the components in succession, $X$ then $P$. Note:
  Measuring with the tetrahedron described previously means observing the
  face of the die that is down, and \emph{only for that component being
    measured at the moment}; any other presumed information is not
  regarded.
\item Guess: C guesses the state of the system by recording the values
  that $X$ and $P$ hold simultaneously at this stage of play.
\item Verify: Q \emph{measures} the components of the system again in
  succession, $X$ then $P$.
\item Score: Together C and Q compare the verified values to the guessed
  values. If the results of $X$ {\bfseries and} $P$ match then C gains
  \$1. If the results do not \emph{both} match then C losses \$2.
\end{enumerate}
The Scientists agree to play ten rounds, five with a classical system and
five with a quantum system.

%\subsection*{The Classical System: Common Reasoning}
\begingroup
\setlength{\tabcolsep}{4 pt}
\begin{table}[H]
  \centering
  \caption{\emph{Classical} system play results (actual)}
\begin{tabular}{*{6}{>$l<$}}
  \toprule
  \multicolumn{2}{c}{\bfseries Setup}
  &\multicolumn{1}{c}{\bfseries Guess}
  &\multicolumn{2}{c}{\bfseries Verify}
  &\multicolumn{1}{c}{\bfseries Score}
  \\%
  \cmidrule(lr){1-2} %
  %\cmidrule(lr){3-3} %
  \cmidrule(lr){4-5} %
  %
  \multicolumn{1}{c}{$\Downarrow\!\! X$}
  &\multicolumn{1}{c}{$\Downarrow\!\! P$}
  &\multicolumn{1}{c}{$(X \text{ \bfseries and } P)$}
  &\multicolumn{1}{c}{$\Downarrow\!\! X$}
  &\multicolumn{1}{c}{$\Downarrow\!\! P$}
  %&\multicolumn{1}{c}{$\Downarrow\!\! X$}
  \\%
  \midrule
  b & d & (b,d) & b & d & +\$1\\%
  b & s & (b,s) & b & s & +\$1\\%
  b & s & (b,s) & b & s & +\$1\\%
  r & d & (r,d) & r & d & +\$1\\%
  r & s & (r,s) & r & s & +\$1\\%
  \bottomrule
\end{tabular}
\end{table}
\endgroup

\begingroup
\setlength{\tabcolsep}{4 pt}
\vspace*{-2\baselineskip}%
\begin{table}[H]
  \centering
  \caption{\emph{Quantum} system play results (actual)}
\begin{tabular}{*{6}{>$l<$}}
  \toprule
  \multicolumn{2}{c}{\bfseries Setup}
  &\multicolumn{1}{c}{\bfseries Guess}
  &\multicolumn{2}{c}{\bfseries Verify}
  &\multicolumn{1}{c}{\bfseries Score}
  \\%
  \cmidrule(lr){1-2} %
  %\cmidrule(lr){3-3} %
  \cmidrule(lr){4-5} %
  %
  \multicolumn{1}{c}{$\Downarrow\!\! X$}
  &\multicolumn{1}{c}{$\Downarrow\!\! P$}
  &\multicolumn{1}{c}{$(X \text{ \bfseries and } P)$}
  &\multicolumn{1}{c}{$\Downarrow\!\! X$}
  &\multicolumn{1}{c}{$\Downarrow\!\! P$}
  %&\multicolumn{1}{c}{$\Downarrow\!\! X$}
  \\%
  \midrule
  b & d & (b,d) & b & s & -\$2\\%
  b & d & (b,s) & r & s & -\$2\\%
  b & s & (b,s) & b & s & +\$1\\%
  r & s & (r,d) & b & s & -\$2\\%
  r & s & (r,s) & r & s & +\$1\\%
  \bottomrule
\end{tabular}
\end{table}
\endgroup

At the end of this particular game the C is up \$1, which seems good to C
especially since he has the classical half of the game down pat. Before
continuing with another game, the Classical Scientist would be wise to not
be beguiled and should consider the following, {\bfseries the Quantum house
  always wins!} Using classical reasoning with quantum systems is a losing
proposition\footnote{%
  Hint: {\bfseries Quantum measurement prepares the system} into a particular
  state. Component measurements are not necessarily simultaneously
  compatible, thereby randomizing the results of successive measurements. %
}.


%mainfile: ../master.tex
\section{Parallelism}\label{sec:parallelism}

In the continued effort of trying to squeeze as much power out of computers as possible, the computer scientific community is at a point where increasing the clock speed of processors is no longer as viable a solution as it used to be. This has spawned an increased interest in increasing computational power in other ways. One of these ways is parallelism.

Parallelism is the act of dividing calculations into independently solvable parts, and then solving them on multiple processors before finally gathering the individual results and combining them. The main benefit of parallelising anything is to gain \emph{speed up} in the computation time of problems. This will be described in \cref{sup}.

With parallelism you gain \emph{speed up} through combining multiple processing units. This is seen in newer CPU's as multiple cores, but on a larger scale this principle can be used to create supercomputers, capable of performing immense calculations.

But even without a supercomputer, a distributed network of multiple computers can provide large amounts of parallel computing power. With this being a foreseeable future, we predict an increase in the access to, and need for, parallel systems.

\subsection{Speed Up}\label{sup}

For parallel computing, Gene Amdahl, an american computer scientist, defined a law for describing the theoretical maximum speed up using multiple processors. The maximum speed up a system can achieve by parallelisation is limited to at most 20×.
The law can be used to describe the speed up achievable by a giving system, by the percentage of parallelisable code, in this equation \cite{wiki_amdahl}.

The time an algorithm takes to finish with $n \in \mathbb{N}$ execution units and $B \in [0, 1]$ the fraction of the algorithm that is strictly serial.

\begin{equation}
  T(n) = T(1)(B + \frac{1}{n} (1 - B))
\end{equation}

The theoretical speed up to be made can then be described by:

\begin{equation}
  S(n) = \frac{T(1)}{T(n)} = \frac{T(1)}{T(1)(B + \frac{1}{n} (1 - B))} = \frac{1}{B + \frac{1}{n} (1 - B)}
\end{equation}

By this law, maximising the percentage of parallelisable, the highest possible speed up achievable is increased, thereby improving the scaling of the solution on multiple processor.

\subsection{Types of Tasks}\label{top}

Tasks within a problem can be dependent on each other, in the sense that one task needs the output of a computation done by another task. This section will describe two types of problems relevant when doing parallel computations \cite{gribblelab,compLLNL}.

\subsubsection{Embarrassingly Parallel Problems}
A problem can be describe as being \emph{embarrassingly parallel} when the tasks within the problem are independent of each other, and can therefore be parallelised without any concern of the order in which the tasks can be executed. They are trivially parallel in nature because of the independency. An example of this type of problem is incrementation of a large matrix, the individual cells in the matrix are completely independent from each other and can therefore be incremented without regard of other cells in the matrix.

\subsubsection{Serial Problems with Dependencies}
Although multiple similar simulations can be observed as being independent of each other, as utilised by the Monte Carlo method, most simulations do not satify the condition of being independent. Instead these are inherently sequential. They form a class of problems that cannot be split into independent sub-problems. In some cases it is not possible to gain speed up at all, by trying to parallelise a problem, which is not parallelisable. The only thing that a simulation designer can achieve in this case, is to add overhead to the computations. An example is calculating the fibonacci series by f(n) = f(n-1)+f(n-2), where f(n) is dependent on first finding the previous values of f.

\subsection{Parallel Data Access}
When trying to solve problems that are not embarrasingly parallel, with a parallel approach, some problems arise when multiple processes try to access the same memory. Among these the most common are race conditions and deadlocks.

\subsubsection{Race Conditions}
This problem arises when multiple processes want to modify the same data in memory or a similar resource, and the outcome of the modification depends on the internal timing of processes. We call the resource "the shared resource" and the code which works with the shared resource "the critical region". An example of a race condition is two concurrent processes that want to raise the value of an integer by 1. In a normal modern day processor the process could be split into the three atomic operations\footnote{Atomic operations are operations which the hardware manufacturer ensures happen without disruptions and that cannot be split into smaller operations}:

\begin{itemize}
\item Copy the current value of the integer from main memory into register A
\item Calculate the value from register A, add 1 to it and place the result in register B
\item Take the new value from register B and override the integer in memory
\end{itemize}

Since we do not know when each process will try to access the memory, the value can either be raised by one, if both processes access it before the other overrides it, or raised by two, if one process finished before the other copy the value from memory. This is a well known problem and exists in many situations, where multiple processes work with non-atomic operations on the same memory. Some software solutions, that ensure only one instance of the critical region has permission to access the shared resource at the time, have been developed; especially Gary L. Peterson's algorithm, published in 1981, is used today. Other solutions have also been developed by creating atomic assembly instructions that can set a flag, thereby ensuring that only one critical region access the shared resource at the time.

\subsubsection{Deadlocks}

Deadlocks are a type of problem that occur when two or more processes are waiting for at least one of the others to finish, before it itself finishes, thereby never finishing. This is a common problem within concurrent programming. Edward G. Coffman described four conditions that must be present if a deadlock is to occur~\cite{Coffman:1971}:

\begin{description}
\item[Mutual Exclusion] Resources can not be shared simultaneously by two processes.
\item[Hold and Wait] A process is at some point holding one resource, while waiting for another.
\item[No Preemption] A resources can not be released externally from a process.
\item[Circular Wait] A process must be waiting for a resource which is held by another process, which is waiting for the first process to release a resource.
\end{description}

By knowing these four conditions, we can try prevent deadlocks by making sure at least one of the conditions is not present.