% !TEX root = thesis.tex

\chapter{Implementing higher-dimensional representations and operations}
\label{ch:implementation}

The higher-dimensional representations described in \refpa{pa:representation} and the operations described in \refpa{pa:operations} can be difficult to implement, especially when we expect these implementations to be fast, robust, generic, compact and dimension-independent.
This is true even when the basic ideas and algorithms are provided, as has been done in this thesis.

For the sake of full reproducibility, this chapter shows some of the key implementation details that are used to efficiently implement the representations and operations described in this thesis.
\refse{se:libraries} lists the main libraries that were used and how they were used.
\refse{se:computerarithmetic} explains the main techniques that are used to perform arithmetic and geometric operations robustly.
Finally, \refse{se:traits} describes the traits programming technique and its use in CGAL and this thesis to produce dimension-independent efficient implementations.

\section{Main libraries used within this thesis}
\label{se:libraries}

\begin{description}

\item[CGAL\footnotemark]
\footnotetext{\url{http://www.cgal.org}}
(the Computational Geometry Algorithms Library) contains a wide variety of 2D/3D/$n$D data structures and computational geometry algorithms.
Some of its basic packages are directly used within this thesis to store and manipulate numbers and basic shapes, namely: Algebraic Foundations, Number Types, 2D and 3D Linear Geometry Kernel, and $d$D Geometry Kernel.
Most significantly, the packages Combinatorial Maps and Linear Cell Complex are used in most of the implementations described in the previous chapters.
Finally, other packages are used as temporary data structures and to process and clean input data: 3D Polyhedral Surface, Halfedge Data Structures, 3D Boolean Operations on Nef Polyhedra, 2D Triangulation, and Principal Component Analysis.
A few other packages are used as dependencies of the aforementioned packages.

\item[GDAL\footnotemark]
\footnotetext{\url{http://www.gdal.org}}
(the Geospatial Data Abstraction Library) reads and writes commonly used GIS file formats.
Within this thesis, its OGR vector module is mainly used to read and write polygons described as well-known text \citep{SimpleFeatures1}, or in Esri Shapefile \citep{Shapefile} and FileGDB files.

\item[IfcOpenShell\footnotemark]
\footnotetext{\url{http://www.ifcopenshell.org}}
is a library that is able to read and write IFC files \citep{ISO16739:2013}.
It internally uses the Open CASCADE geometry types, including to convert implicit geometries (\eg\ those built using constructive-solid geometry or sweeps as in \reffig{fig:ifc}) into explicit ones that can be stored using boundary representation, or to create meshes of a given degree of accuracy from curved surfaces.

\item[Open CASCADE\footnotemark]
\footnotetext{\url{http://www.opencascade.org}}
is a library that is able to manipulate geometric representations in CAD applications.
In theory, it supports complex geometric operations between implicit geometries, including Boolean set operations with 3D point sets.
However, in practice it performs poorly with GIS data, often failing due to numerical errors or imperfect data.

\end{description}

\section{Geometric operations using computer arithmetic}
\label{se:computerarithmetic}

Theoretical descriptions of geometric objects and geometric algorithms generally start from the notions of the Euclidean space $\mathbb{R}^n$, in which the coordinates of a point can be described precisely using real numbers ($\mathbb{R}$).
However, as real numbers cannot be represented on (digital) computers, implementations usually opt for a combination of \emph{integer numbers} to represent whole numbers of known precision that are known to fall within a given interval and \emph{floating-point numbers} in all other cases.
While integers can be precisely expressed as a sequence of binary digits of a given length, floating-point numbers often cannot.
The latter are therefore usually\footnote{This is only the most common representation among those provided by the much broader IEEE 754 standard \citep{IEEE754-2008}, which provides for decimal numbers as well as special values for $\pm \infty$ and NaN (not a number), among other features.} expressed using binary numbers with a predefined number of bits.
% as:

% \begin{equation*}
% {(-1)}^\mathrm{sign} \times 2^\mathrm{exponent} \times \mathrm{significand}
% \end{equation*}

% where the exponent is a positive integer and the significand is expressed as a normalised number.
% As a normalised binary number always begins with \texttt{1.}, the first binary digit is known and therefore not stored.
% The \emph{fraction} of the number (\ie\ the digits following the \texttt{1.}) is stored instead.
% Single precision (or 32-bit) floating-point numbers use 1 bit for the sign, 8 bits for the exponent and 23 bits for the significand.
% Double precision (or 64-bit) floating-point numbers use 1 bit for the sign, 11 bits for the exponent and 52 bits for the significand.

Floating-point numbers can represent a wide range of values and work well in many instances.
However, arithmetic performed using floating-point numbers needs special care, as it often leads to a loss of precision \citep{Goldberg91}.
While this is a problem for all kinds of algorithms \citep{Hoffmann88}, geometric operations are particularly vulnerable as they often rely on getting a correct result for a large number of predicates, which can fail when dealing with edge cases \citep{Kettner08}, such as almost collinear or coplanar points.

Many alternatives have been developed to deal with various limitations of integer and floating-point numbers.
Among these, the ones described below are those that have been used for the implementations related to this thesis.
\emph{Multiple precision arithmetic} is a generic solution that can achieve an arbitrary level of precision by using numbers with a user-definable number of digits.
It is widely implemented in libraries such as GMP\footnote{\url{https://gmplib.org/}} and MPFR\footnote{\url{http://www.mpfr.org}}.

Simple arithmetic operations can be computed precisely by using \emph{rational arithmetic}, where a number is stored as a ratio of two other numbers, most commonly integers.
In a geometric context, this type of representation is often used in the form of homogeneous coordinates, where a single number is used as a common denominator for all of the coordinates.
This common denominator can be used to represent special values, such as a point at infinity by setting it to zero.

In \emph{interval arithmetic} numbers are substituted with intervals.
When these are used to represent the error bounds of an operation\footnote{combined with correct rounding in the case of floating-point numbers}, it is possible to compute arithmetic operations with provably correct results \citep[Ch.~2]{Ratschek88}, such as those provided by the MPFI library\footnote{\url{https://perso.ens-lyon.fr/nathalie.revol/software.html}}.
Unfortunately, while this setup using multiple precision interval arithmetic can be applied to most problems with relative ease, it is also very slow.
For instance, \citet{Held11} reports a factor of 70 for the computation of Voronoi diagrams.

It is possible to go around this problem by fine-tuning a multiple-precision approach to a specific problem.
Notably, this is done with very good results for a few geometric predicates by \citet{Shewchuk97}, and the simulation of simplicity paradigm advocated by \citet{Edelsbrunner90}.
A more generic and easier to implement solution is provided by the lazy evaluation scheme used in CGAL \citep{Pion11}, which is based on interval arithmetic and is the one used in this thesis.
% , which is used in the implementations mentioned in this thesis.
In it, the computationally expensive multiple precision operations are only computed when floating-point precision is not sufficient.
As these cases are important to get correct results, but also relatively rare, it significantly improves the performance of most operations while maintaining their correctness.

\section{Efficient and flexible dimension-independent programming}
\label{se:traits}

Previously, \refse{ss:dimensions} discussed how higher-dimensional representations have large sizes and methods using them have high computational complexities, which often increase exponentially on the dimension.
However, there are also practical obstacles that make it difficult to implement dimension-independent structures and methods efficiently, especially when these have to be used in a generic setting such as in GIS, where varied objects of different dimensions need to be dynamically created and modified, as well as appended with possibly multiple attributes of various types.

One of these obstacles is the need to allocate and use structures that are dimension- and data-independent, and therefore flexible enough to cover all the aforementioned use cases, but at the same time remain compact and allow their contents to be accessed efficiently.
These structures can range from simple ones that can be handled by standard data types and containers, to more complex ones that need to be dynamically defined.
For instance, some simple types are directly dependent on the dimension, such as $n$-tuples storing the coordinates of a point in $\mathbb{R}^n$, and can thus be stored as arrays or vectors.

At the opposite end, consider the sets of extrusion intervals that were associated to each cell in \refch{ch:extrusion}, where an unknown number of cells need to be each associated with an unknown number of intervals.
As the number of intervals per cell is not known, it is not possible to store the intervals in a fixed-length structure that is integrated into the embedding structure of each cell.
Also, while it is possible to directly link a cell to its set of intervals from its embedding structure, these intervals are only temporarily needed, so allocating space for the intervals directly in the embedding structure is wasteful at all other times and thus difficult to justify.
The end result was that the intervals per cell were kept in an external structure, where a \texttt{map} linked a cell embedding to a \texttt{set} of intervals.
As \reftab{tab:complexitystd} shows, this means that accessing a given interval of a given cell---an operation that is performed a very large number of times---, takes logarithmic rather than constant time, significantly slowing the extrusion algorithm in practice.
\marginpar{
\captionsetup{type=table}
\centering
\caption[Computational complexity of accessing an element in C++ containers]{The typical computational complexity of accessing a given element in common C++ containers \citep{ISO14882:2015}}
\label{tab:complexitystd}
\small
\begin{tabular}{cc}
\toprule
structure & complexity \\
\midrule
hard-coded & $O(1)$ \\
array/vector & $O(1)$ \\
map/set & $O(\log n)$ \\
list & $O(n)$ \\
\bottomrule
\end{tabular}
}

A possible solution to the aforementioned problems is based on \emph{template meta-programming}.
Template meta-programming is a technique that uses templates to generate certain data structures or perform certain computations during the compilation of a program rather than during its execution.
Templates are normally used as a way to support generic programming, enabling the creation of functions that can deal with different data types indistinctly.
A template might thus be instantiated with the dimension of an object or a particular attribute type, thus generating a data structure of the appropriate size and disposition whose members can be accessed in constant time.
\reffig{fig:template-conversion} shows a slightly more complex example, where a template can be used to convert a string into any number type, which is used in this thesis to parse numbers from various types of files (\eg\ coordinates and identifiers).
\begin{figure}[tb]
\centering
\small
\lstinputlisting[language=C++]{figs/templateconversion.txt}
\caption[Using C++ templates to convert a \texttt{string} into any number type]{Using C++ templates to convert a \texttt{string} containing a number into any number type $T$, including scientific notation. Adapted from \url{http://www.cplusplus.com/forum/articles/9645/}.}
\label{fig:template-conversion}
\end{figure}

However, apart from their use in generic programming, templates can also be used to create complex dimension-dependent structures, such as through the use of the traits programming technique \citep{Myers95} used in CGAL, which exploits C++'s \texttt{typedef} declarations to create custom dependent types.\@
As an example, \reffig{fig:extrudedlcc} shows how the implementation of the extrusion algorithm defines a combinatorial map that is one dimension higher than the input, which is created during compilation.
\begin{figure*}[tb]
\centering
\small
\lstinputlisting[language=C++,numbers=left]{figs/extrudedlcc.txt}
\caption[Creating a dependent type using C++ templates]{Using C++ templates it is possible to create dependent types such as the \texttt{Higher\_dimensional\_cell\_complex} defined in line 5 and used in line 15.}
\label{fig:extrudedlcc}
\end{figure*}

This type of mechanism can be used to a much higher degree by defining \emph{recursive templates}, which are used extensively in the CGAL Combinatorial Maps package.
As an example, \reffig{fig:dimensionindependent} shows how this was applied in order to store the extrusion ranges maps for each dimension separately, which is necessary because the embedding structures of each cell are different depending on the dimension.
\begin{figure*}[tb]
\centering
\small
\lstinputlisting[language=C++,numbers=left]{figs/dimensionindependent.txt}
\caption[Using recursive C++ templates to produce dimension independent code]{Recursive C++ templates can be used to generate dimension independent code.
The first structure \texttt{Extrusion\_ranges\_map\_of\_dimension} (lines 1--8) contains the extrusion map for a single dimension.
The second structure \texttt{Extrusion\_ranges\_tuple\_per\_dimension\_up\_to} (lines 10--23) uses as a triplet of definitions to create copies of the first for every dimension up to a given one.
This is done using a template specialisation for dimension 0 which stops the recursion.
The last structure \texttt{Extrusion\_ranges\_tuple\_per\_dimension} (lines 25--32) creates all structures using the dimension of a passed combinatorial map \texttt{LCC}.
Note the non-ideal use of \texttt{std::map} in line 5.}
\label{fig:dimensionindependent}
\end{figure*}

The same technique can be used to create algorithms that are also fully dimension-independent.
In fact, C++ templates are known to be Turing-complete \citep{Veldhuizen03}, and thus can be used to compute general-purpose problems.
\reffig{fig:manifoldvalidation} shows one such example from the implementation of the incremental construction algorithm of \refch{ch:incremental-construction}, which shows the validation that a set of $(n-1)$-cells form a quasi-$n$-manifold.
\begin{figure*}[tb]
\centering
\small
\lstinputlisting[language=C++]{figs/manifoldvalidation.txt}
\caption[Dimension-independent algorithms using recursive C++ templates]{Recursive C++ templates can also be used to implement dimension-independent algorithms. In this case, the \texttt{dimension} that is passed to the templated function is passed on to other functions to obtain appropriate orbits for a given facet (\texttt{dimension-1}) or ridge (\texttt{dimension-2}), which are then compared dart by dart.}
\label{fig:manifoldvalidation}
\end{figure*}


\section{Longitudinal string excitation.}

\subsection{Hadron--nucleon inelastic collision.}

\hspace{1.0em}Let us consider collision of two hadrons with their c. m. momenta
$P_1 = \{E^{+}_1,m^2_1/E^{+}_1,{\bf 0}\}$ and $P_2 =
\{E^{-}_2,m^2_2/E^{-}_2,{\bf 0}\}$, where the light-cone variables
$E^{\pm}_{1,2} = E_{1,2} \pm P_{z1,2}$ are defined through hadron
energies $E_{1,2}=\sqrt{m^2_{1,2} + P^2_{z1,2}}$, hadron longitudinal
momenta $P_{z1,2}$ and hadron masses $m_{1,2}$, respectively. Two
hadrons collide by two partons with momenta $p_1 = \{x^{+}E^{+}_1,0,{\bf
0}\}$ and $p_2 = \{0, x^{-}E^{-}_2,{\bf 0}\}$, respectively.

\subsection{The diffractive string excitation.}

In the diffractive string excitation (the Fritiof approach \cite{FRITIOF87})
 only momentum can be transferred:
\begin{equation}
\label{LSE1}
\begin{array}{cc}
P^{\prime}_1 = P_1 + q\\
P^{\prime}_2 = P_2 -q,
\end{array}
\end{equation}
where
\begin{equation}
\label{LSE2}q=\{-q^2_t/(x^{-}E^{-}_2),q^2_t/(x^{+}E^{+}_1),\bf q_t \}
\end{equation}
 is parton
momentum transferred and ${\bf q_t}$ is its transverse component.
We use the Fritiof approach to simulate the diffractive excitation of
particles.

\subsection{The string excitation by parton exchange.}

\hspace{1.0em}For this case the parton exchange (rearrangement) and
the momentum exchange are allowed \cite{QGSM82},\cite{DPM94}:
\begin{equation}
\label{LSE3}
\begin{array}{cc}
P^{\prime}_1 = P_1 - p_1 + p_2 + q \\
P^{\prime}_2 = P_2 + p_1 - p_2 - q,
\end{array}
\end{equation}
where $q= \{0,0, {\bf q_t}\}$ is parton momentum transferred, i. e. only
its transverse components ${\bf q_t}$ is taken into account \cite{Am86}.

\subsection{Transverse momentum sampling.}

\hspace{1.0em}The transverse component of the parton momentum
transferred is generated according to probability
\begin{equation}
\label{LSE4}P({\bf q_t})d{\bf q_t} =
\sqrt{\frac{a}{\pi}} \exp{(-aq^2_t)}d{\bf q_t},
\end{equation}
where  parameter $a = 1.4$ GeV$^{-2}$.

{\bf $x^{+}$ and $x^{-}$ samplings.}

Light cone parton quantities $x^{+}$ and $x^{-}$ are generated
independently and according to distribution:
\begin{equation}
\label{LSE5} u(x) \sim x^{\alpha}(1 - x)^{\beta},
\end{equation}
where $x=x^{+}$ or $x=x^{-}$.
Parameters $\alpha =-1$ and $\beta = 0$ are chosen for the FRITIOF approach
\cite{FRITIOF87}. In the case of the QGSM approach \cite{Am86} $\alpha = -0.5$
and $\beta = 1.5$ or $\beta = 2.5$.  Masses of the excited strings
should satisfy the kinematical constraints:
\begin{equation}
\label{LSE6} P^{\prime +}_1 P^{\prime -}_1 \geq m^2_{h1} + q^2_t
\end{equation}
and
\begin{equation}
\label{LSE7} P^{\prime +}_2 P^{\prime -}_2 \geq m^2_{h2} + q^2_t,
\end{equation}
where hadronic masses $m_{h1}$ and $m_{h2}$ (model parameters) are
defined by string quark contents.  Thus, the random selection of the
values $x^{+}$ and $x^{-}$ is limited by above constraints.

\subsection{The string excitation by quark or diquark annihilation.}

\hspace{1.0em}
We consider also hadron-hadron inelastic processes when antiquark or
antidiquark from hadron projectile annihilate with corresponding quark
or diquark from hadron target.
In this case excitation of one baryonic (string with quark and diquark
ends) or mesonic (string with quark and antiquark ends) is created,
respectively. These processes in the Regge theory correspond to cut
reggeon exchange diagrams. Initial energy $\sqrt{s}$
dependences of these processes
cross sections are defined by  intercepts of reggeon exchange trajectories.
For example $\sigma_{\pi^{+}p\rightarrow S(s)} \sim s^{\alpha_{\rho}(0)-1}$,
$S$ notes string and $\alpha_{\rho}(0)$ is the intercept of $\rho$ reggeon
trajectory. Thus $\sigma_{\pi^{+}p\rightarrow S(s)}
$ decreases with energy
rise. Cross sections for other quark and diquark proccesses have simiar
as $\sigma_{\pi^{+}p\rightarrow S(s)}$ initial energy dependences.
Thus quark and diquark annihilation processes are important at
relative low initial energies. Another example of these processes is
$\bar{p}p \rightarrow S$, which is used in the kinetic model to describe
final state of $\bar{p}p$ annihilation.
Simulation of such kind process is rather simple. We should randomly
(according to weight calculated using hadron wave function)
choose quark (antiquark) or diquark (antidiquark) from projectile and
find suitable (with the same flavor content) partner for annihilation
from target. The created string four-momentum will be equal total reaction
four-momentum since annihilated system has small neglected momentum (only
low momenta quarks are able to annihilate).

To determine statistical weights for
 quark annihilation processes are leading to a string production
and separate them from processes, when two or more strings can be produced we
use the Regge motivated total cross section parametrization suggested by
Donnachie and Landshoff \cite{DL92}. Using their parametrization the
statistical weight for the one string production process is given by
\begin{equation}
\label{OSE1} W_{1} = \frac{Y_{hN}s^{-\eta}}{\sigma^{tot}_{hN}(s)}
\end{equation}
and statistical weight to produce two and more strings is given by
\begin{equation}
\label{OSE2} W_{2} = \frac{X_{hN}s^{\epsilon}}{\sigma^{tot}_{hN}(s)},
\end{equation}
where hadron-nucleon total cross sections  $\sigma^{tot}_{hN}(s)$ and its
fit parameters $Y_{hN}$, $X_{hN}$, which do not depend
from the total c.m. energy squared $s$ and depend on type of
projectile hadron $h$ and target nucleon $N$ can be found in \cite{PDG96}.
The reggeon intercept $\eta \approx
0.45$ and the pomeron intercept $\epsilon \approx 0.08$.

\subsection{Hadron--nucleus or nucleus--nucleus inelastic collisions.}

\hspace{1.0em}Hadron-nucleus or nucleus-nucleus collisions in the both
approaches (diffractive and parton exchange) are considered
as a set of the independent hadron-nucleon or
nucleon-nucleon collisions.  However, the string excitation procedures
in these approaches are rather different.

\subsection{The diffractive string excitation.}

\hspace{1.0em}In the diffractive string excitation (the
FRITIOF approach \cite{FRITIOF87}) for each
inelastic hadron--nucleon or nucleon--nucleon collision we have to select
randomly the transverse momentum transferred ${\bf q_t}$ (in accordance
with the probability given by Eq. ($\ref{LSE4}$)) and select randomly
the values of $x^{\pm}$ (in accordance with distribution defined by
Eq. ($\ref{LSE5}$)). Then we have to calculate the parton momentum
transferred $q$ using Eq. ($\ref{LSE2}$) and update scattered hadron
and nucleon or scatterred nucleon and nucleon momenta using
Eq. ($\ref{LSE3}$). For each collision we have to check the constraints
($\ref{LSE6}$) and ($\ref{LSE7}$), which can be written more
explicitly:
\begin{equation}
\label{LSE8} [E_1^{+} -\frac{q^2_t}{x^{-}E^{-}_2}][\frac{m_1^2}{E^{+}_1} +
\frac{q^2_t}{x^{+}E^{+}_1}]\geq m^2_{h1} + q^2_t
\end{equation}
and
\begin{equation}
\label{LSE9} [E_2^{-} +\frac{q^2_t}{x^{-}E^{-}_2}][\frac{m_2^2}{E^{-}_2} -
\frac{q^2_t}{x^{+}E^{+}_1}]\geq m^2_{h1} + q^2_t.
\end{equation}

\subsection{The string excitation by parton rearrangement.}

\hspace{1.0em}In this approach \cite{Am86} strings (as result of parton
rearrangement) should be spanned not only between valence quarks of
colliding hadrons, but also between valence and sea quarks and between
sea quarks.  The each participant hadron or nucleon should be splitted
into set of partons: valence quark and antiquark for meson or valence
quark (antiquark) and diquark (antidiquark) for baryon (antibaryon) and
additionaly the $(n-1)$ sea quark-antiquark pairs (their flavours are
selected according to probability ratios $ u:d:s = 1:1:0.35$), if hadron
or nucleon is participating in the $n$ inelastic collisions.  Thus for
each participant hadron or nucleon we have to generate a set of light
cone variables $x_{2n}$, where $x_{2n}=x^{+}_{2n}$ or
$x_{2n}=x^{-}_{2n}$ according to distribution:
\begin{equation}
\label{LS10} f^{h}(x_1,x_2,...,x_{2n})=f_{0}\prod_{i=1}^{2n}u^h_{q_i}(x_i)
\delta{(1-\sum_{i=1}^{2n}x_i)},
\end{equation}
where $f_0$ is the normalization constant.
Here, the quark structure functions $u_{q_i}^h(x_i)$ for valence quark
(antiquark) $q_v$,
sea quark and antiquark $q_s$ and valence diquark (antidiquark) $qq$ are:
\begin{equation}
\label{LS11}
u^h_{q_v}(x_v)=x_v^{\alpha_v},\ u^h_{q_s}(x_s)=x_s^{\alpha_s},\ u^h_{qq}(x_{qq})
=x_{qq}^{\beta_{qq}},
\end{equation}
where $\alpha_v = -0.5$ and $\alpha_s = -0.5$ \cite{QGSM82}
 for the non-strange quarks (antiquarks) and $\alpha_v =
0$ and $\alpha_s = 0$ for strange quarks (antiquarks), $\beta_{uu} =
1.5$ and $\beta_{ud} = 2.5$ for proton (antiproton) and $\beta_{dd} =
1.5$ and $\beta_{ud} = 2.5$ for neutron (antineutron).  Usualy $x_i$ are
selected between $x^{min}_i \leq x_i \leq 1$, where model parameter
$x^{min}$ is a function of initial energy, to prevent from production of
strings with low masses (less than hadron masses), when whole selection
procedure should be repeated.  Then the transverse momenta of partons
${\bf q_{it}}$ are generated according to the Gaussian probability
Eq. ($\ref{LSE4}$) and under the constraint: $\sum_{i=1}^{2n}{\bf
q_{it}}=0$. The partons are considered as the off-shell partons,
i. e. $m^2_i \neq 0$.

\subsection{Barion and meson splitting.}
\hspace{1.0em}To perform
 a simulation of the string excitation we need to split hadron and
choose valence quark (antiquark) and diquark (antidiquark). In the case
of a meson we split it into valence quark and antiquark (for neutral mixed
mesons this sampling is performed according to mixing probabilities.)
In the case of barion we determine probabilities of baryon (antbarion)
state (a quark (antiquark) and
diquark (antidiquark) with given spin and isospin)
 from $SU(6)$ symmetric wave barion functions. These probabilities are
 given in the Table 3.1.
\hspace{1.0em}
\begin{table}
\begin{center}
\begin{tabular}{|c|c|}
\hline
Baryon type & Quark content \\
\hline
$p$         &$1/3uu_{11}d+1/6(1/12)ud_{11}u+1/2(7/12)ud_{00}u$    \\
$n$         &$1/6(1/12)ud_{11}d+1/2(7/12)ud_{00}d+1/3dd_{11}u$    \\
$\Sigma^{+}$&$1/3uu_{11}s+1/6us_{11}u+1/2us_{00}u$    \\
$\Sigma^{0}$&$1/3ud_{11}s+1/12us_{11}d+1/4us_{00}d+1/12ds_{11}u+1/4ds_{00}u$\\
$\Sigma^{-}$&$1/3dd_{11}s+1/6ds_{11}d+1/2ds_{00}d$    \\
$\Xi^{-}$   &$1/6ds_{11}s+1/2ds_{00}s+1/3ss_{11}d$    \\
$\Xi^{0}$   &$1/6us_{11}s+1/2us_{00}s+1/3ss_{11}u$    \\
$\Lambda^{0}$&$1/3ud_{00}s+1/4us_{11}d+1/12us_{00}d+1/4ds_{11}u+1/12ds_{00}u$\\
$\Delta^{++}$&$uu_{11}u$    \\
$\Delta^{+}$ &$1/3uu_{11}d+2/3ud_{11}u$    \\
$\Delta^{0}$ &$2/3ud_{11}d+1/3dd_{11}u$    \\
$\Delta^{-}$ &$dd_{11}d$    \\
$\Sigma^{*+}$&$1/3uu_{11}s+2/3us_{11}u$    \\
$\Sigma^{*0}$&$1/3ud_{11}s+1/3us_{11}d+1/3ds_{11}u$\\
$\Sigma^{*-}$&$1/3dd_{11}s+2/3ds_{11}d$    \\
$\Xi^{*0}$   &$1/3us_{11}s+2/3ss_{11}u$    \\
$\Xi^{*-}$   &$2/3ds_{11}s+1/3ss_{11}d$    \\
$\Omega^{-}$   &$ss_{11}s$    \\
\hline
\end{tabular}
\end{center}
Table 3.1: Baryon quark contents. Diquark indices indicate spin-isospin states.
\end{table}
We also  use these probability to sample barion or barion resonance in
the string fragmentation, assuming that a valence diquark (antidiquark)
keeps its spin and isospin during whole reaction.


\subsection{Overview}\label{randomsampleExecutable_randomsampleOverview}
The {\bfseries randomsample} executable heuristically solves p-\/median formulations of the sensor placement problem.
\subsection{Usage}\label{randomsampleExecutable_randomsampleUsage}
\begin{verbatim}
   randomsample <sp-configuration-file> <num-sample> <random-seed>
            <impact-file-representation> <time-limit> [<solution-file>]
\end{verbatim}
\subsection{Arguments}\label{randomsampleExecutable_randomsampleArgs}
\begin{verbatim}
     <sp-configuration-file>
     The configuration file generated by the 'sp' script.

     <num-sample>
     The number of local searches performed by this heuristic.

     <random-seed>
     A random number seed.

     <impact-file-representation>
     An integer that indicates how the impact file is stored internally:
     0 - sparse and 1 - dense

     <time-limit>
     A time limit (in seconds) for how long the heuristic should run.

     <solution-file>
     The name of the output file that contains the solutions found
     by this heuristic.
\end{verbatim}
\subsection{Description}\label{randomsampleExecutable_randomsampleDescription}
The {\ttfamily sp} command runs {\ttfamily randomsample} to solve p-\/median sensor sensor placement problems with the GRASP heuristic. Currently, the following statistics are supported: mean, var (Value At Risk), tce (Tail-\/Conditional Expectation), and worst-\/case.

This command is intended to be only used by the {\bfseries sp} script, which drives both heuristic and exact solvers.
\subsection{Notes}\label{randomsampleExecutable_randomsampleNotes}

\begin{itemize}
\item The randomsample heuristic currently does not support side constraints other than on the number of sensors. Side-\/constraints are supported by the \doxyref{sideconstraints}{p.}{sideconstraintsExecutable} executable.
\end{itemize}


\chapter{Methodology}
\newtheorem{definition}{Definition}
% \label{ch:relatedwork}
As mentioned in the previous sections, the rapid increase in IoT devices as well as its use-cases has
significantly impacted and at times more often than not, improved our experiences. However, when these
personal, and usually hand-held or wearable devices like smart phones and smart watches, have a
plethora of added functionality, it also poses the problem of increased energy consumption. This results
on a less uptime for one charge of a battery which corresponds to the device not being utilized for proper
amounts of time. This is especially important in the healthcare sector where a device monitoring a patient's
vitals should be able to do so for prolonged lengths of time. \\
In this thesis, our study focused on optimizing energy consumption for communication. Most applications
on an edge device usually communicate with a remote server to exchange different data and it varies from
application to application. But within these applications, communication is a core aspect which is not
being investigated by researchers.
The best general practice used when designing these applications is to send data in sizes multiples of 2, which
generally means faster communication without unwanted packet drops but on the other hand, is no where near
optimal. This is due to the fact that each edge device may have different hardware and different software
versions, and the energy cost for communication for each possible variation of these is different \cite{6200281}. It has no
optimal trend, therefore, the best practice is to use general values of chunk sizes that the protocol
can easily handle. Our work focuses on communication cost because most of the times other hardware related
factors are not flexible or would otherwise compromise the integrity of the task. \\

This work is divided into two portions. First, we present a pretty straightforward way to estimate an
application's energy consumption over time. Next, we present an approach to compute optimal chunk sizes
for respective edge devices. We evaluate and confirm whether this optimal chunk size approach consumes less
energy or not with the help of our energy estimation approach, on two real-world applications. \\
\section{Estimating Energy Usage}
There have been other approaches in the past to estimate energy consumption of applications \cite{6606555} but we
adopt an approach that is similar to energest \cite{energest} which is an energy profiling approach for Contiki OS.
We combine runtime information from applications with static information from data sheets of specific
hardware components to estimate energy consumption. Before getting into the details, we will define some
terminologies. \\

\begin{definition}
    \textbf{Current }(I) is defined as the flow of electrical charge (q) over time (t). It is measured in Amperes (A).
\end{definition}

\begin{definition}
    \textbf{Power}(P) is defined as the amount of charge (q) moved through voltage (V) in a time interval (t). It is measured in Watts (W).
\end{definition}

For devices powered by a battery, both current and voltage is an important factor and is heavily dependent
on the components used on the device itself. Different electrical components operate on different voltages, thereby,
drawing different amounts of current, resulting in different power consumption. However, in order to calculate the
energy consumption, the dynamic factor is time. Power used or spent over a specific period of time equals the
energy used by the specific device or specific component of device.

\begin{definition}
    \textbf{Energy}(E) is defined as the amount of power (P) expended over a time interval (t). It is measured in Joules (J).
\end{definition}

We use these definitions to be able to express how we estimate the energy consumption of a specific edge IoT device.
Almost all hardware components when designed and brought to market have a corresponding data sheet publicly available,
with important information such as circuit diagrams, and current and voltage values for different modes (if possible). Current
and voltage are dynamic factors however by using information from said data sheets, we can estimate these values by
computing the mean average sum of values corresponding to different operating modes. The data sheet for BCM43455, the
wifi adapter used in Raspberry Pi 4 Model B \cite{cypress} contains valuable information regarding different technical
details such as frequency, circuit design, power management etc. However,
what is interesting to us is current and voltage values. Figure \ref{fig:bcm} provides a snapshot from one such table.
It outlines the different current values corresponding to different voltage values for different modes. In a
real world setting, the devices switch between these modes depending on various factors. A reasonable assumption
in this case would be to take the mean average sum of values for different modes. \\

\begin{figure}
    \begin{center}
        \includegraphics[scale=0.25]{Figs/datasheet.png}
    \end{center}
    \caption{Current and Voltage values for BCM43455}
    \label{fig:bcm}
\end{figure}

Given this information, we can estimate the power \texttt{P} that the wifi adapter would use in this case when it is
turned on. Consider an app \texttt{A} which finishes executing in about \texttt{t} seconds. The total energy
consumed (by the wifi adapter) by running \texttt{A} would then be calculated by \texttt{E = P * t}. \\
In order to calculate the estimated energy for specific block of code, such as ones which handle communication, all one
needs to do is instrument the app to log execution time for that specific block of code. And then we can
calculate the energy usage of that specific portion of program. The main idea behind this approach to
estimate energy is that software developers don't usually have the technical equipment required to
individually measure current and voltage values of actual devices. Given that setback, estimating energy
consumption off of publicly available data sheets and runtime information from the app itself is a
pretty reliable way to gather the required data. \\
\section{Calculating Optimal Chunk Size}
As mentioned before, our study focuses on optimizing communication cost of applications for IoT edge devices.
Even though the best practices involved in this case do perform well for average case, our hypothesis
is that after a communication pipe is established between the client and the server, having data sent or
received in different chunk sizes could have an impact on the energy consumption of the whole process.
The motivation behind this is that even though hardware optimizations such as power saving modes improve
energy consumption efficiency, there are still software related configurations that can be altered to reduce
the overall energy usage. We chose to focus on communication cost because it is an integral part of more or less
every app deployed on an edge device where it communicated with the server one way or another to transmit
some sort of data. \\
But why communication cost? Indeed, there are multiple code related factors that can help optimize energy
consumption but our work is done under the assumption that these factors, such as data collection, via the
sensor, the disk I/O operations etc. differ heavily from use-case to use-case and any alteration in code
functionality to them, may affect their usage in real world. For example, a device monitoring a patient's
heartbeat continuously is bound to use more energy than, let's say, monitoring every five minutes.
However, in these kinds of critical health monitoring applications, such types of optimizations severely undermine the actual
functionality of the app. Therefore, our approach addresses a factor that is independent of the sensor
usage in such a context and can potentially work on diverse examples. \\
To better explain how we calculate the optimal chunk size, we will first define energy-per-byte or EPB.
It is a metric we use to determine which chunk size consumes the least amount of energy. \\

\begin{definition}
    \textbf{EPB} or Energy-per-Byte is defined as the amount of energy consumed when a single byte of data is sent from one device to another.
\end{definition}

But why is EPB an important factor rather than the overall energy consumed for the corresponding chunk size?
We will explain this with the help of an example. Consider an app \texttt{C} on the edge device \texttt{EdgeD} that needs
to send 256 bytes to the server-side app \texttt{S}. Assume you calculated the energy to send data at a
chunk size of 64 bytes was the lowest at \texttt{E1} Joules. However, if you used 128 bytes at a time to
send this data, you consume \texttt{E2} Joules which is slightly more than \texttt{E1}. In this case,
we can not say the 64 bytes is the optimal chunk size for \texttt{EdgeD} because it would take \texttt{E1*4}
amounts of energy to send the complete data and \texttt{E2*2} on the other hand. For the sake of this
example, assume \texttt{E1} has the arbitrary value of 2 Joules (actual values are way way less and are usually
in microJoules) and \texttt{E2} has the arbitrary value of 3 Joules. 64 bytes would take 8 Joules in total
to send 256 bytes of data where as 128 bytes of chunk size would only use 6 Joules. That is why, EPB is an
important factor and metric in this case. So what we need to do is divide \texttt{E1} by 64 and \texttt{E2}
by 128 to get the EPB for their respective chunk sizes. Now, the lower energy consumption value of the
two would be the optimal one as it would consume the lowest amount of energy among different chunk sizes. \\
To calculate the optimal chunk size on an edge device, we deploy a Python script which comprises of a
list of different chunk sizes of order \texttt{$2^{n}$} where \texttt{n} by default can be anything between
1 and 30 (included). The upper limit can be adjusted depending on the use case of the program. It then
proceeds to send data in different chunk sizes and then measure the time it took for the communication to take
place. This time is then used to calculated the overall energy consumption for sending a specific amount of
data. It must be mentioned here that the chunk size is also bounded by the protocol being used and
the local disk space of the device.
It is provided as a pseudocode in algorithm \ref{alg:two} on the next page. For both evaluation subjects,
we use the same pseudocode but had to implement it in Python and Java for both applications respectively. \\
\SetKwComment{Comment}{/* }{ */}

\begin{algorithm}
\caption{Pseudocode for determining optimal chunk size}\label{alg:two}
\Comment{n is the upper limit of chunk size as exponent of 2, p is the power computed from datasheet }
\KwData{$n \geq 0, p$}
\Comment{Array of energy consumption for each chunk size}
\KwResult{$energyArray$}
$N \gets n$\;
$P \gets p$\;
% $timeArray \gets \phi$\;
$energyArray \gets \phi$\;
\While{$N \neq 0$}{
     \Comment{Create a byte array of the given size using a helper function}
     $array \gets CreateByteArray(2^N)$\;
     \Comment{Start a timer}
     $start \gets GetCurrentTime()$\;
     \Comment{Send the data to the server}
     $SendToServer(array)$\;
     \Comment{Stop the timer and compute the difference}
     $end \gets GetCurrentTime()$\;
     $executionTime \gets end-start$\;
     \Comment{Compute the EPB and store it in array}
     $energy \gets P * executionTime$\;
     $EPB \gets energy/2^N$\;
     $energyArray \gets energyArray \cup EPB$\;
}
\end{algorithm}
This is a pretty straightforward but novel approach to aid programmers in developing applications for
a target edge device where they can optimize the communication cost in terms of energy. In some use cases, the
difference is considerable while in others it may not be that much. In short, it depends on the nature of the app
itself. The following section will clarify more as to why it is as we describe our experimental and nature of the
applications, and discuss our results. \\