\lstset{
  captionpos=b,
  language=Haskell,
  basicstyle=\scriptsize,
  numbers=left,
  numberstyle=\tiny,
  columns=fullflexible,
  stepnumber=1,
  escapechar=\#,
  keepspaces=true,
  belowskip=-10pt,
  literate={<}{{$\langle$}}1 {>}{{$\rangle$}}1,
  morekeywords={function,rr,int,float,bool,isnull,partition,as,downregion,upregion,reads,writes,rdwrs,reduces,read,write,reduce,using,unpack,pack,coloring,multicoloring,color,newcolor,atomic,simultaneous},
  deletekeywords={float,head,min,max}
}
\begin{lstlisting}[float={t},label={lst:circuit_ex},caption={Circuit Simulation}]
--                        <voltage,current,charge,capacitance>
type CircuitNode        = <float,float,float,float>
--                     < owned node, owned or ghost node, resistance, current>
type CircuitWire<rn,rg>  = <CircuitNode@rn, CircuitNode@(rn,rg),float,float>

type node_list<rl,rn>       = < CircuitNode@rn, node_list<rl,rn>@rl >
type wire_list<rl,rw,rn,rg>= < CircuitWire<rn,rg>@rw, wire_list<rl,rw,rn,rg>@rl >

type CircuitPiece<rl,rw,rn> = rr[rpw,rpn,rg]
                            < wire_list<rl,rpw,rpn,rg>@rl, node_list<rl,rpn>@rl >
                            where rpn #$\le$# rn and rg #$\le$# rn and rpw #$\le$# rw and
                                  rn * rw and rl * rn and rl * rw

-- Simulation initialization and invocation
function simulate_circuit[rl,rw,rn] ( all_nodes : node_list<rl,rn>@rl,
                            all_wires : wire_list<rl,rw,rn,rn>@rl, steps : int ),
      reads(rn,rw,rl), writes(rn,rw,rl) : bool =
  let pc : <coloring(rn),multicoloring(rn),coloring(rw)>
            = color_circuit[rn,rw,rl](all_nodes,all_wires) in
  -- Disjoint partition for the owned nodes of each piece
  partition rn using pc.1 as rn0,rn1 in
  -- Aliased partition for ghost nodes of each piece
  partition rn using pc.2 as rg0,rg1 in
  -- Disjoint partition for the owned wires of each piece
  partition rw using pc.3 as rw0,rw1 in
  let lists0 : <wire_list<rl,rw0,rn0,rg0>@rl,node_list<rl,rn0>@rl> =
        build_lists[rl,rw,rn,rw0,rn0,rg0](all_nodes,all_wires,pc.1,pc.2,pc.3,0) in
  let piece0 : CircuitPiece<rl,rw,rn> =
        pack lists0 as CircuitPiece<rl,rw,rn>[rw0,rn0,rg0] in
  let lists1 : <wire_list<rl,rw1,rn1,rg1>@rl,node_list<rl,rn1>@rl> =
        build_lists[rl,rw,rn,rw1,rn1,rg1](all_nodes,all_wires,pc.1,pc.2,pc.3,1) in
  let piece1 : CircuitPiece<rl,rw,rn> =
        pack lists1 as CircuitPiece<rl,rw,rn>[rw1,rn1,rg1] in
      execute_time_steps[rl,rw,rn](piece0,piece1,steps)

-- Time Step Loop
function execute_time_steps[rl,rw,rn] ( p0 : CircuitPiece<rl,rw,rn>,
      p1 : CircuitPiece<rl,rw,rn>, steps : int ) , reads(rn,rw,rl), writes(rn,rw) : bool =
  if steps #$<$# 1 then true else
  unpack p0 as piece0 : CircuitPiece<rl,rw,rn>[rw0,rn0,rg0] in
  unpack p1 as piece1 : CircuitPiece<rl,rw,rn>[rw1,rn1,rg1] in
  let _ : bool = calc_new_currents[rl,rw0,rn0,rg0](piece0.1) in
  let _ : bool = calc_new_currents[rl,rw1,rn1,rg1](piece1.1) in
  let _ : bool = distribute_charge[rl,rw0,rn0,rg0](piece0.1) in
  let _ : bool = distribute_charge[rl,rw1,rn1,rg1](piece1.1) in
  let _ : bool = update_voltage[rl,rn0](piece0.2) in
  let _ : bool = update_voltage[rl,rn1](piece1.2) in
      execute_time_steps[rl,rw,rn](p0,p1,steps-1)

function color_circuit[rn,rw,rl] ( all_nodes : node_list<rl,rn>@rl,
                               all_wires : wire_list<rl,rw,rn>@rl ),
        reads(rn,rw,rl) : <coloring(rn), multicoloring(rn), coloring(rw)> =
  -- Invoke programmer chosen coloring algorithm (e.g. METIS)
  -- return owned, ghost, wire colorings

-- Helper method
function build_lists[rl,rw,rn,rpw,rpn,rg] ( nodes : node_list<rl,rn>@rl,
       wires : wire_list<rl,rw,rn>@rl, oc : coloring(rn), gc : multicoloring(rn),
       wc : coloring(rw), c : int), reads(rn,rw,rl), writes(rl)
       : < wire_list<rl,rpw,rpn,rg>@rl, node_list<rl,rpn>@rl > =
  -- Construct lists of node and wire pointers for the given colorings
\end{lstlisting}

\section{Circuit Example}
\label{sec:example}

Listing~\ref{lst:circuit_ex} shows a circuit simulation written
in the core Legion language (see
Section~\ref{sec:legioncore}).  The input is a graph of circuit
elements and connecting wires.  To perform parallel
simulation the graph is partitioned into pieces, after which the
simulation is run for a number of time steps.  Each time step has
three phases: calculation of each wire's current, distribution of charge to
the nodes connected to each wire, and updating of node voltages.

The entry function is {\tt simulate\_circuit} (line 15), which accepts a
linked list of nodes contained in region {\tt rn} and a linked list of
wires contained in region {\tt rw}.  The linked list elements themselves
are in region {\tt rl}.
When {\tt simulate\_circuit} is invoked it must have both read and
write privileges for the regions {\tt rl}, {\tt rw}, and {\tt rn}
(line 17); the type system statically verifies that
{\tt simulate\_circuit} only accesses these regions and their subregions.

Partitioning of the graph is done using {\em colorings} built in the
{\tt color\_circuit} function (line 18-19).  A coloring maps region
elements to colors (integers in Core Legion), with each color corresponding
 to a new subregion
to be created.  Note that it is impossible to pick a single static
partitioning scheme that would do well for all graphs.  Dynamic
partitioning using colorings enables the programmer
to make partitioning decisions based on input data.

The {\tt color\_circuit} function is responsible for specifying how the
circuit is to be partitioned.  The body of this function is not shown as the
ideal algorithm for partitioning data will be application specific.  The
only restriction imposed by the Legion programming model is that the result of
the algorithm be provided in the form of colorings.  For our circuit example,
there are three colorings.  The first maps each node to the graph piece that owns it.
The third maps each wire to a graph piece that
owns one of its nodes.  The second coloring captures, for each piece $p$,
the nodes in other pieces on the boundary of $p$, often referred to as
{\em ghost nodes}.
%We describe how ghost node regions are used in
%conjunction with the owned nodes shortly.
Note that
ghost nodes may be on the boundary of multiple pieces and therefore be included in
multiple ghost regions.  For conciseness, a bit of syntactic sugar is used here the
form of a {\em multicoloring}, which allows the mapping of an element to multiple
colors.  Although multicolorings are not part of the Core Legion described in
Section~\ref{sec:legioncore}, they can be easily implemented using a separate
coloring for each color in the multicoloring.

After creating the colorings, the application partitions the node and wire
regions into {\em subregions} according to the colorings (lines 21-25).  For
simplicity, our example only partitions the circuit into two pieces.
Line 21 uses coloring {\tt pc.1} to partition {\tt rn} into {\tt rn0}, and {\tt rn1}.
Subregion {\tt rn0} will contain all locations with a color of 0 in {\tt pc.1},
while {\tt rn1} will contain all locations with a color of 1.  This
partitioning results in {\em disjoint} subpartitions.
Constraints are introduced into the static environment describing both the
disjointness of the subregions (i.e. {\tt rn0 $*$ rn1}) and the inclusion of
each subregion in the original region (e.g. {\tt rn0 $\leq$ rn}).  Line
23 is similar, but uses a multicoloring, so the subregions may be {\em aliased},
and only the inclusion constraints are introduced into the static environment.

The circuit simulation uses an {\em allocate-then-partition} style of
computation, where a large data structure is first allocated and then
partitioned.  Legion also supports a {\em partition-then-allocate} style,
where empty regions are first partitioned and later populated with
data.  Both are useful; e.g., Sequoia \cite{Fatahalian06} and DPJ
\cite{Bocchino09} support static forms of allocate-then-partition and
partition-then-allocate, respectively.  Legion supports both
approaches dynamically.

After partitioning the circuit into pieces, the application creates
instances of {\tt CircuitPiece} (defined on lines 9-12) for each piece
(lines 28-33).  {\tt CircuitPiece} is a {\em region relationship}, a
bounded existential type.  Region relationships allow the programmer
to {\em pack} a group of regions and pointers into those regions together
and remember properties
about them such as disjointness and subregion relationships (lines 29
and 33).  The type system verifies the properties hold statically when
packing; when region relationships are {\em unpacked} the same
properties are reintroduced into the static checking environment
(lines 40-41).  A key feature underlying the soundness of the Legion
type system is that privileges cannot be packed in a region
relationship---privileges belong to functions. When a function unpacks
a region relationship it must already hold privileges for the unpacked regions.
%new regions it finds in the packed value.
For example, on line 40 the
function {\tt execute\_time\_steps} has read/write privileges for
region {\tt rn0} because it has read/write privileges for {\tt rn} and
the {\tt CircuitPiece} region relationship constraints ensure $\tt rn0
\leq rn$ (line 12).

The {\tt execute\_time\_steps} function (lines 37-48)
also illustrates the importance of using different partitions to give
multiple views onto the same logical region.  Both {\tt
  calc\_new\_currents} and {\tt distribute\_charge}
use the owned and ghost regions of a piece, which are from different partitions. In
{\tt calc\_new\_currents} these regions only need read
privileges, allowing both instances of {\tt calc\_new\_currents} to be
run in parallel.  In {\tt distribute\_charge} the
privilege is for a reduction which can also be done in parallel
because of the atomic and commutative nature of reductions.  Finally,
the {\tt update\_voltage} function modifies only the owned regions, permitting
each piece to be updated in parallel.  No
single partition of the nodes
describes these data sharing patterns.

%This function also demonstrates the benefit of being able to dynamically
%(re-)discover disjointness.  Safely running both instances of
%{\tt calc\_new\_currents} in parallel depends on knowing that {\tt rw0} and
%{\tt rw1} in {\tt execute\_time\_steps} are disjoint.  Similarly, parallel
%execution of the instances of {\tt update\_voltage} requires knowing that
%{\tt rn0} is disjoint from {\tt rn1}.  In both cases, this knowledge was
%statically available in {\tt simulate\_circuit} and could have been captured
%in a region relationship, but it would have resulted in much more complicated
%code.
%Instead, an inexpensive dynamic disjointness check is performed by the Legion
%runtime, and the safety of parallel execution follows from the soundness of
%the type system.
The {\tt execute\_time\_steps} function also demonstrates the benefit of dynamically
being able to discover disjointness.  To run the two instances of
{\tt calc\_new\_currents} in parallel requires knowing that {\tt rw0}
and {\tt rw1} are disjoint.  There is a similar requirement for parallel
execution of the two {\tt update\_voltage} calls with {\tt rn0} and {\tt rn1}.  In
both cases, this knowledge was statically available in {\tt simulate\_circuit}
and could have been captured in a region relationship at the cost
of much more complicated code.  Instead, an inexpensive dynamic disjointness
check by the Legion runtime will (re)discover the parallelism.

Listing~\ref{lst:circuit_leaf} shows the leaf functions for each phase.
Each function iterates over the list of wires or
nodes for its piece.  Each function specifies the region privileges it
requires (lines 2,14,23).
%These privileges
%are statically checked to match the operations performed inside of
%each function (e.g. read and write).
In the case of {\em reduce} the
privilege must also specify which reduction function is used
(line 14).

In addition to privileges, functions can also specify {\em coherence}
on regions.  Coherence specifies what updates the function may
observe from other functions using aliased regions.
If not otherwise specified, coherence defaults to {\em exclusive},
meaning the function must appear to execute in program order relative to
other function calls.
Line 14 in Listing~\ref{lst:circuit_leaf} shows
an example of {\tt atomic}, a relaxed coherence mode requiring
that operations to {\tt rn} and {\tt rg} appear atomic relative
to other functions using regions which may alias.  The most relaxed coherence
mode is {\tt simult}; simultaneous coherence allows concurrent access
to the region by all functions that are using the region
in a simultaneous mode.  The interaction between {\em tasks} (which are functions chosen to execute in parallel) using the same
region with different coherence
modes is formalized in Section~\ref{sec:coherence}.

% This is a description of how the listings should be formatted.
% It can go anywhere before the listings.
\lstset{
  captionpos=b,
  language=Haskell,
  basicstyle=\scriptsize,
  numbers=left,
  numberstyle=\tiny,
  columns=fullflexible,
  stepnumber=1,
  escapechar=\#,
  keepspaces=true,
  belowskip=-10pt,
  literate={<}{{$\langle$}}1 {>}{{$\rangle$}}1,
  morekeywords={function,rr,int,float,bool,isnull,partition,as,downregion,upregion,reads,writes,rdwrs,reduces,read,write,reduce,using,unpack,pack,coloring,multicoloring,color,newcolor,atomic,simultaneous},
  deletekeywords={float,head,min,max}
}

\begin{lstlisting}[float={t},label={lst:circuit_leaf},caption={Circuit Leaf Functions}]
function calc_new_currents[rl,rw,rn,rg] ( ptr_list : wire_list<rl,rw,rn,rg>@rl ),
      reads(rl,rw,rn,rg), writes(rw) : bool =
  if isnull(ptr_list) then true else
  let wire_node : wire_list<rl,rw,rn,rg> = read(ptr_list) in
  let wire : CircuitWire<rn,rg> = read(wire_node.1) in
  let in_node : CircuitNode = read(wire.1) in
  let out_node : CircuitNode = read(wire.2) in
  let current : float = (in_node.1 - out_node.1) /  wire.3 in
  let new_wire : CircuitWire<rn,rg> = <wire.1,wire.2,wire.3,current> in
  let _ : CircuitWire<rn,rg>@rw = write(wire_node.1, new_wire) in
      calc_new_currents[rl,rw,rn,rg](wire_node.2)

function distribute_charge[rl,rw,rn,rg] ( ptr_list : wire_list<rl,rw,rn,rg>@rl ),
      reads(rl,rw,rn), reduces(reduce_charge,rn,rg), atomic(rn,rg) : bool =
  if isnull(ptr_list) then true else
  let wire_node : wire_list<rl,rw,rn,rg> = read(ptr_list) in
  let wire : CircuitWire<rn,rg> = read(wire_node.1) in
  let _ : CircuitNode@rn = reduce(reduce_charge, wire.1, wire.4) in
  let _ : CircuitNode@(rn,rg) = reduce(reduce_charge, wire.2, wire.4) in
      distribute_charge[rl,rw,rn,rg](wire_node.2)

function update_voltage[rl,rn] ( ptr_list : node_list<rl,rn>@rl ),
      reads(rl,rn), writes(rn) : bool =
  if isnull(ptr_list) then true else
  let node_node : node_list<rl,rn> = read(ptr_list) in
  let node : CircuitNode = read(node_node.1) in
  let voltage : float = (node.3/node.4) in
  let new_node : CircuitNode = <voltage,node.2,node.3,node.4> in
  let _ : CircuitNode@rn = write(node_node.1, new_node) in
      update_voltage[rl,rn](node_node.2)

-- Reduction function for distribute charge
function reduce_charge ( node : CircuitNode, current : float ) : CircuitNode =
    let new_charge : float = node.3 + current in
        < node.1,new_charge,node.3,node.4>
\end{lstlisting}


Having established how to convert an ER diagram into an equivalent relational model, we can now describe the operations for the relational model.

\subsubsection{Relational Algebra}\label{sec:relationalAlgebra}
Relational algebra describes a set of unary and binary operations on relations\cite{DBSBook}.
The operations are used to define new relations --- often, the tuples within the set will satisfy defined predicates.
The relational operators form the foundations of data manipulation languages (see section \ref{sec:SQL}) which can be used to define database operations\cite{DBSBook}.
A few of the common operaterations can be seen in table \ref{Relational algebra operators}.

\begin{table}[h]
    \centering
    \begin{tabular}{|ll|}
    \hline
    \multicolumn{1}{|l|}{\textbf{Operator}}          & \multicolumn{1}{l|}{\textbf{Example}}   \\ \hline
    \multicolumn{1}{|l|}{Select}                     & \multicolumn{1}{l|}{$\sigma_{predicate}(R)$}            \\ \hline
    \multicolumn{1}{|l|}{Projection}                 & \multicolumn{1}{l|}{$\pi_{A_1, A2,...,A_n}(R)$}           \\ \hline
    \multicolumn{1}{|l|}{Join}                 & \multicolumn{1}{l|}{$r_1 \Join_\Theta r_2$}             \\ \hline
    \multicolumn{1}{|l|}{Cartesian product}          & \multicolumn{1}{l|}{$r_1\times r_2$}              \\ \hline
    \end{tabular}
    \caption{Table of operators.}
    \label{Relational algebra operators}
\end{table}

We will describe some operators of relational algebra, and use them to describe implemented queries later.
\subsubsection*{Select}
The select operator defines a set $R_{result}\subseteq R$ where all tuples $t \in R_{result}$ satisfies a given predicate\cite{DBSBook}.
That is, $\forall t \in R_{result} \vDash predicate$.
As an example, we can produce a relation containing all books with the title "Database System Concepts":
$$\sigma_{title = "Database System Concepts"}(books)$$
\subsubsection*{Projection}
The projection operator specifies a relation containing only a subset of the attributes of the operand relation\cite{DBSBook}.
That is, attributes $A_1, ..., A_n$ of relation $R_{result}$ will be a subset of or equal to the attributes of the operand.
We can use the projection in combination with the select operator to produce a relation containing only the ISBN and title of books titled "Database System Concepts":
$$\pi_{ISBN,title} (\sigma_{title = "Database\ System\ Concepts"}(books))$$
\subsubsection*{Cartesian Product}
The Cartesian product of two relations $R_1$ and $R_2$ produces a set containing concatenated tuples of the two operands\cite{DBSBook}.
That is, taking the attributes of the two sets, $A_1,...,A_n \in R_1$ and $A_{n+1},...,A_k \in R_2$ produces a set with attributes $A_1,...,A_k$.
If the attributes of the operands have the same names, we distinguish between them by denoting their original relation: $R_1.AttributeName$, $R_2.AttributeName$. \cite{DBSBook}
For instance, we can concatenate the information in the $book\_owner$ and $owns$ relations.

$book\_owner \times owns = r$ will result a relation with the structure as seen in equation \ref{eq:cart_struct}.
\begin{equation}\label{eq:cart_struct}
    r(owns.owner\_id, owns.ISBN,book\_owner.name,book\_owner.owner\_id)
\end{equation}
\textbf{Join}\\
The join operator defines a relation consisting of tuples from the Cartesian product of the operand, containing only tuples satisfying the given predicate\cite{DBSBook}.
It is defined as $\sigma_{\Theta} (R_1 \times R_2)$ \cite{DBSBook}.

Thus, we can express the relation describing the name of all $book\_owner$ entities, that owns the book with $ISBN$ "987-1-...50-4" as both equation \ref{eq:join_s} and equation \ref{eq:join_j}.
\begin{equation}\label{eq:join_s}
    \pi_{book\_owner.name} (\sigma_{owns.ISBN = book.ISBN \wedge owns.ISBN = 987-1-...50-4}  (book\_owner \times owns))
\end{equation}
\begin{equation}\label{eq:join_j}
    \pi_{book\_owner.name} (\sigma_{book.ISBN = 987-1-...50-4} (book \Join_{owns.ISBN = book.ISBN} owns))
\end{equation}\\

Other variations of the join operation exist\cite{DBSBook}, however these will not be discussed in this report.\\
\subsubsection*{Aggregate Functions}
In conjunction with the basic relational operators, aggregate functions can be used over a set of values.
Aggregate functions take a set of values as input and outputs a single value\cite{DBSBook}. Some common aggregate functions are
\begin{itemize} \label{aggregateFunctions}
    \item \texttt{count} - returns the number of tuples in the set.
    \item \texttt{sum} - returns the sum of the values in the set.
    \item \texttt{min} - returns the smallest value in the set.
    \item \texttt{max} - returns the largest value in the set.
    \item \texttt{avg} - returns the average value in the set.
\end{itemize}

As we have now established both how to model database relations as well fundamental operations used to extract data (tuples) from these relations, we can now look at how to implement the relations in a database.

\subsubsection{SQL}\label{sec:SQL}
SQL is one of the most commonly used data definition language (DDL) and data manipulation languages (DML) \cite{DBSBook}.
SQL is a declarative query language where one executes a query to instruct the database system to perform a set of operations to compute a desired result.
Collectively, the resulting set of operations is known as a transaction.
A transaction can be considered as a set of operations that is performed on data.
To a user or connected system, the collection of operations must seem like a single, indivisible operation\cite{DBSBook}.
We will describe the effect of transactions in section \ref{sec:ACID}.

In PostgreSQL, all queries, both to define and to manipulate data, are executed as transactions\cite{postgres_transactions}.
As a DDL, SQL provides queries to define and modify relation schemas, as well as provide constraints for the attributes of the schema such that data in the relation satisfies the constraint.

\begin{lstlisting}[
    label=lst:CreatingTablesInSQL,
    language=SQL,
    caption=Implementing the relations from in equation \ref{eq:bookOwnerExample} and \ref{eq:relational_schema},
    showspaces=false,
    basicstyle=\footnotesize\ttfamily,
    numbers=left,
    numberstyle=\tiny,
    commentstyle=\color{gray},
    escapechar=|
 ]
CREATE TABLE book (
    author_name varchar(250) not null,
    title varchar(250) NOT NULL,
    number_of_pages INTEGER NOT NULL CHECK(number_of_pages > 0),
    ISBN char(10) UNIQUE NOT NULL,
    primary key (ISBN)
);
CREATE SEQUENCE ownerSequence INCREMENT BY 1 START 1; |\label{line:sequence}|
CREATE TABLE book_owner (
    name varchar(250),
    owner_id integer NOT NULL DEFAULT nextval('ownerSequence')
);
CREATE TABLE owns (
    owner_id INTEGER NOT NULL REFERENCES book_owner(owner_id),
    isbn char(10) NOT null REFERENCES book(isbn),
    PRIMARY KEY (isbn, owner_id)
);
\end{lstlisting}

Code snippet \ref{lst:CreatingTablesInSQL} shows a possible definition of the relations from equation \ref{eq:relational_schema} and \ref{eq:bookOwnerExample}.
On line \ref{line:sequence}, a sequence describing the \texttt{owner\_id} primary key for the \texttt{owner} relation is defined.
Whenever a new tuple is inserted into the table, the sequence will generate a unique owner\_id for the data.
As a DML, SQL provides functionality to fetch data stored in the database\cite{DBSBook}.
Many of the operators presented in the previous section is predefined in SQL and describe the exact same operation\cite{DBSBook}.
Code snippet \ref{lst:join} shows a simple join operation, returning all book titles of books that are owned by the \texttt{book\_owner} with \texttt{owner\_id} 10.

\begin{lstlisting}[
    label=lst:join,
    language=SQL,
    caption=Query returning the title of all books owned by book\_owner with owner\_id = 10,
    showspaces=false,
    basicstyle=\footnotesize\ttfamily,
    numbers=left,
    numberstyle=\tiny,
    commentstyle=\color{gray},
    escapechar=|
 ]
 SELECT title FROM
 owns JOIN book ON owns.isbn = book.isbn WHERE owns.owner_id = 10
\end{lstlisting}

In relational algebra, an equivalent operation could be described as \\$\pi_{title}\sigma_{owns.owner\_id = 10}(owns \Join_{book.isbn = book.isbn} book )$.

% Having established how one can define a database schemas using SQL as a DDL, as well as query data from the database using SQL as a DML.


\chapter*{Abstract}

Maximising the economic effectiveness of a wind farm is essential in making wind a more economic source of energy. This effectiveness can be increased through the reduction of operation and maintenance costs, which can be achieved through continuously monitoring the condition of wind turbines. An alternative to expensive condition monitoring systems, which can be uneconomical especially for older wind turbines, is to implement classification algorithms on supervisory control and data acquisition (SCADA) signals, which are collected in most wind turbines. Several publications were reviewed, which were all found to use separate algorithms to predict specific faults in advance. In reality, wind turbines tend to have multiple faults which may happen simultaneously and have correlations with one another. This project focusses on developing a methodology to predict multiple wind turbine faults in advance simultaneously by implementing classification algorithms on SCADA signals for a wind farm with 25 turbines rated at 2,500 kW, spanning a period of 30 months. The data, which included measurements of wind speed, active power and pitch angle, was labelled using corresponding downtime data to detect normal behaviour, faults and varying timescales before a fault occurs. Three different classification algorithms, namely decision trees, random forests and k nearest neighbours were tested using imbalanced and balanced training data, initially to optimise a number of hyperparameters. The random forest classifier produced the best results. Upon conducting a more detailed analysis on the performance of specific faults, it was found that the classifier was unable to detect the varying timescales before a fault with accuracy comparable to that of normal or faulty behaviour. This could have been due to the SCADA data, which are used as features, being unsuitable for detecting the faults, and there is potential to improve this by balancing only these classes.
\\[.5cm]
\noindent\textbf{\textit{Keywords:}} \keywords


\chapter{parelm}

\section{Introduction}

An LPE may have parameters that do not affect the behavior of that process in any way.
These parameters are said to be \emph{inert}.
Removing inert parameters from an LPE reduces the size of state vectors and the state space of that LPE, which both benefits performance.

\section{Algorithm}

The algorithm consists of the following steps \cite{groote2001computer}:

\begin{enumerate}

\item Make it so that all parameters of the LPE are \labeledas{inert}.

\item Consider the guards of all summands of the LPE, and \removelabelfrom{inert} from all LPE parameters that occur in the guard of a summand.

\item Let $X$ be the set of all LPE parameters that are \labeledas{inert}, and consider all expressions $v_s(p)$ that define the value of an LPE parameter $p$ after application of a summand $s$.
For each such expression, if $p$ is \emph{not} \labeledas{inert}, \removelabelfrom{inert} all LPE parameters that occur in $v_s(p)$.

\item Repeat the previous step until the fixpoint of $X$ is reached.
Then remove all LPE parameters that are still \labeledas{inert} from the LPE, substituting references to those parameters by their initial values.

\end{enumerate}

\clearpage
\section{Example}

Consider the following LPE:

\begin{lstlisting}
//Process definition:
PROCDEF example[A :: Int, B](x, y, z :: Int)
  = A ? i [[x==0]] >-> example[A, B](i, y, z)
  + A ? i [[x==1]] >-> example[A, B](0, i, z)
  + B [[x==2]] >-> example[A, B](0, y, z)
  + B [[true]] >-> example[A, B](z, y, x)
  ;

//Initialization:
example[A, B](0, 0, 0);
\end{lstlisting}

First, the `inert' label is removed from $x$ because $x$ occurs in the guards of the first three summands.

In the fourth summand, $z$ is used in the expression of which the value is assigned to $x$.
Therefore $z$ is also no longer \labeledas{inert}.

$y$ remains labeled with `inert': it does not occur in a guard, nor is it used in the assignment to a process parameter other than itself.
Removing $y$ gives

\begin{lstlisting}
//Process definition:
PROCDEF example[A :: Int, B](x, z :: Int)
  = A ? i [[x==0]] >-> example[A, B](i, z)
  + A ? i [[x==1]] >-> example[A, B](0, z)
  + B [[x==2]] >-> example[A, B](0, z)
  + B [[true]] >-> example[A, B](z, x)
  ;

//Initialization:
example[A, B](0, 0);
\end{lstlisting}

\section{Benchmark results}

The following durations were measured with a benchmark for several models:
\begin{itemize}
\item The average duration of \txs{} to make 500 steps in a model after it has been converted to LPE form;
\item The average duration of \txs{} to make 500 steps in a model after it has been converted to LPE form and after the \texttt{parelm} operation has been applied.
\end{itemize}

When plotting the second series of measurements against the first (see Figure~\ref{parelm-vs-lpe-only:fig}), it is easy to see that the impact is insignificant in most cases.
The only model for which a significant performance increase has been measured is the \texttt{ControlLoop} model, which has indeed lost part of its state vector.

\begin{figure}[!ht]
\begin{center}
\includegraphics[width=0.5\linewidth]{charts/parelm-vs-lpe-only}
\caption{Benchmark results: parelm vs LPE transformation}
\label{parelm-vs-lpe-only:fig}
\end{center}
\end{figure}


\section{Building NWAs from other NWAs (namespace \texttt{opennwa::construct})}
\label{Se:Building NWAs}

The library provides functions for performing automata-theoretic operations upon
NWAs. The supported operations are union, intersection, concatenation,
reversal, Kleene star, complement, and determinization.

The library supports two interfaces to each of these operations. In one, the
operation allocates an NWA with \texttt{new}, performs the construction, and
returns a \texttt{NwaRefPtr} to the result.  In the other, the operation takes
a reference to an NWA, clears it, and constructs the result in-place. The
first form is usually more convenient to use, and creates a mini language for
set expressions; the second form makes it possible to store the result of an
operation in a subclass of \texttt{Nwa}, or an existing \texttt{Nwa} object.

Each of these functions is in the namespace \texttt{opennwa::construct}:

\begin{functionlist}

  \functionDefEarly{NwaRefPtr}{unionNwa}{Nwa const \& a, Nwa const \& b}{}
  \functionDef{void}{unionNwa}{Nwa \& out, Nwa const \& a, Nwa const \& b}{}
    Computes the union of the NWAs \texttt{a} and \texttt{b},
    either returning the result or storing it in \texttt{out}.
    See Section
    \ref{Se:Union}. (This function is called \texttt{unionNwa} instead of
    \texttt{union} because the latter is a C++ keyword.) The two NWAs must not
    have any states in common, and the output will be nondeterministic even
    if both input NWAs are deterministic. The running time\footnote{We count
      state lookups, additions, etc.\ as constant time even though they are
      actually logarithmic, and occasionally linear.} is
    $O(|Q^a|+|Q^b|+|\delta^a|+|\delta^b|)$.

  \functionDefFirstEarly{NwaRefPtr}{intersect}{Nwa const \& a, Nwa const \& b}{}
  \functionDef{void}{intersect}{Nwa \& out, Nwa const \& a, Nwa const \& b}{}
    Computes the intersection of the NWAs \texttt{a} and \texttt{b},
    either returning the result or storing it in \texttt{out}.
    See Section \ref{Se:Intersection}. If both input NWAs are deterministic,
    the output will be deterministic. The worst-case running time is
    $O(|Q^a| |Q^b| d_a d_b)$, where $d_a$ is the maximum out-degree
    of a state in \texttt{a} and $d_b$ is the maximum out-degree of a state
    in \texttt{b}.

  \functionDefFirstEarly{NwaRefPtr}{concat}{Nwa const \& left, Nwa const \& right}{}
  \functionDef{void}{concat}{Nwa \& out, Nwa const \& left, Nwa const \& right}{}
    Computes the concatenation of the NWAs \texttt{left} and
    \texttt{right}, either returning the result or storing it in
    \texttt{out}.
    See Section \ref{Se:Concatenation}. The output automaton will be
    nondeterministic. The running time is
    $O(|Q^a|+|Q^b|+|\delta^a|+|\delta^b|+|Q^a||\delta_r^b|)$.

  \functionDefFirstEarly{NwaRefPtr}{star}{Nwa const \& orig}{}
  \functionDef{void}{star}{Nwa \& out, Nwa const \& orig}{}
    Computes the Kleene star of the NWA \texttt{orig}, either
    returning the result or storing it in \texttt{out}. See Section
    \ref{Se:Star}. The output automaton will be nondeterministic. The
    running time is $O(|Q|+|\delta|+|Q_0||Q_f||\delta_c|)$.

  \functionDefFirstEarly{NwaRefPtr}{reverse}{Nwa const \& orig}{}
  \functionDef{void}{reverse}{Nwa \& out, Nwa const \& orig}{}
    Computes the NWA that accepts the reverse of each nested word
    accepted by the NWA \texttt{orig}, either returning the result or
    storing it in \texttt{out}. See Section \ref{Se:Reverse}. The running
    time is $O(|Q|+|\delta|)$.

  \functionDefFirstEarly{NwaRefPtr}{determinize}{Nwa const \& orig}{}
  \functionDef{NwaRefPtr}{determinize}{Nwa \& out, Nwa const \& orig}{}
    Computes a determinization of \texttt{orig}, either returning the
    result or storing it in \texttt{out}.
    See Section \ref{Se:Determinize}. The worst-case running time for this
    algorithm is at least $O({|Q|^3} \cdot2^{|Q|^2})$.

\clearpage
  \functionDefFirstEarly{NwaRefPtr}{complement}{Nwa const \& orig}{}
  \functionDef{void}{complement}{Nwa \& out, Nwa const \& orig}{}
    Computes the complement of the determinization of \texttt{orig},
    either returning the result or storing it in \texttt{out}.
    See Section
    \ref{Se:Complement}. %For complementing the set of final states to work
    %correctly, two things must hold: \texttt{orig} must be deterministic and
    %the transition functions must be total. (That is, for a given state $q$
    %and symbol $\sigma$, there must be exactly one internal transition $(q,
    %5\sigma, q') \in\delta_i$, exactly one call transition $(q, \sigma,
    %q')\in\delta_c$, and exactly one return transition $(q, p, \sigma,
    %q')\in\delta_r$ for each state $p$.)
    \texttt{complement()} determinizes \texttt{orig}, so its worst-case
    running time is also at least $O({|Q|^3} \cdot2^{|Q|^2})$.

    %\vspace{0.5\baselineskip}
    %If \texttt{determinize} is \texttt{true}, it will
    %automatically determinize the input NWA before complementation, which
    %also guarantees the input machine will be total. If you
    %know that \texttt{orig} is already deterministic and total, you can set
    %\texttt{determinize} to
    %\texttt{false} to avoid this step. (Complementing a nondeterministic or
    %non-total NWA can easily lead to an incorrect result.) If
    %\texttt{determinize} is \texttt{true}, the worst-case running time is the
    %same as for the \texttt{determinize} function (roughly
    %$O(2^{|Q|^2})$). If \texttt{determinize} is \texttt{false}, the running
    %time is $O(|Q|+|\delta|)$.

\end{functionlist}

As mentioned above, these functions create a small language of set
expressions. For instance, to compute an automaton \texttt{M} whose language
is $\texttt{A} \cup (\texttt{B} \cap \texttt{C})*$ (where \texttt{A},
\texttt{B}, and \texttt{C} are \texttt{NwaRefPtr}s), one can write
\begin{center}
  \texttt{NwaRefPtr M = unionNwa(*A, *star(*intersect(*B, *C)))}
\end{center}

\begin{figure}[tb]
  \centering
  \begin{minipage}{0.3\textwidth}
    \centering
    \nwaimage[.6]{Figures/figure-1}
    \caption{An example NWA.}
    \label{Fi:Example1}
  \end{minipage}
  \hspace{0.025\textwidth}
  \begin{minipage}{0.3\textwidth}
    \centering
    \nwaimage[0.49]{Figures/union-other}
    \caption{A second example NWA.}
    \label{Fi:Union1}
  \end{minipage}
  \hspace{0.025\textwidth}
  \begin{minipage}{0.3\textwidth}
    \centering
    \nwaimage[0.8]{Figures/union-result}
    \caption{The NWA resulting from the union of the NWA in Figure
      \ref{Fi:Example1} and the NWA in Figure \ref{Fi:Union1}. Note that there
      are two initial states.}
    \label{Fi:Union2}
  \end{minipage}
\end{figure}

\subsection{Union}
\label{Se:Union}
The union of two NWAs is constructed by taking the union of each of the
components of the NWAs. (In
particular, it does \textsl{not} do a cross-product construction, and will
\textsl{always} produce a nondeterministic automaton as a result as long as
both machines have at least one initial state.)

Formally, the union of NWAs $N = (Q_N, \Sigma_N, Q_{0,N}, \delta_N, F_N)$
and $M = (Q_M, \Sigma_M,$ $Q_{0,M}, \delta_M, F_M)$ is
$N \cup M = (Q_N \cup Q_M, \Sigma_N \cup \Sigma_M, Q_{0,N} \cup
   Q_{0,M}, \delta_N \cup \delta_M, F_N \cup F_M)$.

As an example, \figref{Union2} illustrates the union of \figref{Example1} and
\figref{Union1}.

The state sets of the NWAs must not overlap,
i.e., $Q_1 \cap Q_2 = \emptyset$. \textsl{Client code should not rely on
  this condition being checked} or any particular behavior occurring if it
does not hold.

Client information is copied directly from the original NWAs using
\texttt{ClientInfo::clone()}.

\subsection{Intersection}
\label{Se:Intersection}

The intersection of two NWAs is computed in the standard cross-product
fashion, using a worklist algorithm to only compute those states that
are reachable.

The algorithm traverses the original NWAs starting at
the initial states and incrementally adds transitions for each pair of
``intersectable'' transitions that are encountered. By default, transitions
are intersectable when the transitions are the same kind (internal, call,
or return) and the symbols on the edge are identical or one is wild.

For example, \figref{Intersect1} shows the intersection of \figref{Example1} and
\figref{Intersect1}, and \figref{Intersect4} shows the intersection of the
two NWAs in \figref{Intersect3}.

\begin{figure}[tp]
  \centering
  \begin{minipage}{0.48\textwidth}
    \centering
    \nwaimage[0.45]{Figures/intersection-simple-other}
    \caption{Simple NWA to intersect with the NWA in Figure \ref{Fi:Example1}.}
    \label{Fi:Intersect1}
  \end{minipage}\hspace{0.2cm}
  \begin{minipage}{0.49\textwidth}
    \centering
    \nwaimage{Figures/intersection-simple-result}
    \caption{The NWA resulting from the intersection of the NWA in Figure
      \ref{Fi:Example1} and the NWA in Figure \ref{Fi:Intersect1}. Note that
      because each of the input NWAs only accepts a single word and those
      words are different, the language of the intersection is empty. The NWA
    built up by \texttt{intersect()} got as far as it
    could. \texttt{(key\#2,3)} is the pair of states \texttt{(start,start)}
    from the two input automata.}
    \label{Fi:Intersect2}
  \end{minipage}
\end{figure}

\begin{figure}[p]
  \centering
    \adjustbox{width=\textwidth,height=\textheight,keepaspectratio=true}{
    \nwaimage{Figures/intersection-complex-first}
    \nwaimage{Figures/intersection-complex-second}}
  \caption{Two complex NWAs to intersect.}
  \label{Fi:Intersect3}
\end{figure}

\begin{figure}[p]
  \centering
    \nwaimage[.45]{Figures/intersection-complex-result}
  \caption{The NWA resulting from the intersection of the NWAs in Figure \ref{Fi:Intersect3}.}
  \label{Fi:Intersect4}
\end{figure}

\antistupidfloats

It is possible to customize what symbols are considered equivalent, or
otherwise impose constraints on what transitions can be intersected, by
overriding the \texttt{transitionIntersect} function in a subclass of
\texttt{Nwa}. In addition, it is possible to impose additional constraints on
what states can be combined by overriding \texttt{stateIntersect}. Both
functions also produce the result of the intersection:
\texttt{transitionIntersect} produces the symbol that will be used on the
resulting edge, and \texttt{stateIntersect} produces the state that will be
used as the target.

The default behavior of
\texttt{transitionIntersect} is that two transitions are intersectable if
neither symbol is epsilon and either the symbols are the same or at least one of
the symbols is a wild. (Epsilon transitions are dealt with in
\texttt{intersect()} itself. If you override \texttt{transitionIntersect}, it
should return \texttt{false} if either input is epsilon.)

The default behavior of \texttt{stateIntersect} is that any two
states can be combined, the resulting state is labeled with a
key that is uniquely generated from the pair of the keys of
the two states under consideration, and the client information associated
with the resulting state is \texttt{null}.

Client information is initially generated by the helper method \texttt{stateIntersect},
but can be altered through the use of the helper methods
\texttt{intersectClientInfoInternal}, \texttt{intersectClientInfoCall}, and
\texttt{intersect\-Client\-InfoReturn}, which are invoked by
\texttt{intersect()} as transitions of the three different kinds involving the
associated state are added.  The default behavior of these three functions is
to perform no changes to the \texttt{ClientInfo}.  These methods can be
overridden in subclasses to specify alternative behaviors.

\goodbreak
The following operations are virtual functions in class \texttt{Nwa} and are intended
to be overridden to customize behavior:

\begin{functionlist}
  \functionDefNoCloseParen{bool}{stateIntersect}{%
                  \parbox[t]{4in}
                              {Nwa const \& first, State state1,\\
                               Nwa const \& second, State state2,\\
                               State \& resSt, ref\_ptr<ClientInfo> \& resCI)}}
    Determines whether the given states can be combined and,
    if so, creates the combined state. If the two states are incompatable,
    returns \texttt{false}. If the two states are compatable, it computes the
    key of the combined state (storing it in \texttt{resSt} and the client
    information (storing it in \texttt{resCI}), then returns \texttt{true}.

  \functionDefFirstNoCloseParen{bool}{transitionIntersect}{%
                  \parbox[t]{4in}
                              {Nwa const \& first, Symbol sym1,\\
                               Nwa const \& second, Symbol sym2,\\
                               Symbol \& resSym )}}
    Determines whether the given symbols are considered to be equivalent for
    the purposes of intersection. If so, it computes the symbol that should
    be associated with the combined transition (storing it in
    \texttt{resSym}) and returns true. If not, returns false.

  \functionDefFirstEarlyNoCloseParen{void}{intersectClientInfoInternal}{%
                  \parbox[t]{4in}
                     {Nwa const \& first, State src1, State tgt1,\\
                      Nwa const \& second, State src2, State tgt2,\\
                      Symbol resSym, State resSt )}}
    \nopagebreak
  \functionDefEarlyNoCloseParen{void}{intersectClientInfoCall}{%
                  \parbox[t]{4in}
                      {Nwa const \& first ,State call1, State entry1,\\
                       Nwa const \& second, State call2, State entry2,\\
                       Symbol resSym, State resSt )}} \nopagebreak
  \functionDefNoCloseParen{\small void}{\small intersectClientInfoReturn}{%
                  \parbox[t]{4in}
                      {\small Nwa const \& first, State exit1, State call1,State ret1,\\
                       Nwa const \& second, State exit2,State call2, State ret2,\\
                       Symbol resSym, State resSt )}}
    Called after a transition of the corresponding type is added to the
    automaton. It is intended to be used to
    alter the client information associated with \texttt{resSt} given the
    endpoints of the new transition.

\end{functionlist}

\subsection{Concatenation}
\label{Se:Concatenation}

The concatenation of two NWAs is constructed by taking the union of all
states and transitions of the two automata, and adding
internal epsilon transitions from each final state of the first NWA to each
initial state of the second NWA.  In the resulting NWA, the initial states
are the initial states from the first NWA, and the final states are the final
states of the second NWA.

However, the concatenation construction is a bit more complicated than just this,
because we need to address the issue of an unbalanced-left
word being concatenated with an unbalanced-right word.  (Recall the
definition of what happens when an NWA reads a pending return: it is
allowed to take a return transition where the call predecessor is an initial
state of the automaton.)

To deal properly with the case where the first operand generates strings with
pending calls and the second operand generates strings with pending returns,
the
transitions from the second automaton are augmented in the
following manner. When computing the concatenation of \texttt{left} and
\texttt{right}, for each transition $(q, p_0, a, q')
\in\delta_r^{\texttt{right}}$ where $p_0 \in Q_0^\texttt{right}$ (these are
transitions that \texttt{right} can take when reading a pending return) and
each $p \in Q^\texttt{left}$, we add $(q, p, a, q')$ to $\delta_r$ of the
result. (It is actually only necessary to add such a transition for states
$p$ that either appear in the call position of a call transition in
\texttt{left} or are in $Q_0^\texttt{left}$.)

 % If the original NWAs are $(Q_1, \Sigma_1,
%{Q_0}_1, \delta_1, {Q_f}_1)$ and $(Q_2, \Sigma_2, {Q_0}_2, \delta_2,
%{Q_f}_2)$, then the resulting NWA is $(Q, \Sigma, Q_0, \delta, Q_f)$ where $Q
%= Q_1 \cup Q_2$, $\Sigma = \Sigma_1 \cup \Sigma_2$, $Q_0 = {Q_0}_1$, $\delta
%= \delta_1 \cup \delta_2 \cup \delta_\epsilon$ (where $\delta_\epsilon =
%\{(q,\epsilon,q') | q \in {Q_f}_1, q' \in {Q_0}_2\}$, and $Q_f = {Q_f}_2$ .
%The NWA resulting from the concatenation of the NWA in Figure
%\ref{Fi:Example1} and the NWA shown in Figure \ref{Fi:Concat1} is shown in
%Figure \ref{Fi:Concat2}.

\begin{figure}[p]
  \centering
  \begin{minipage}{0.5\textwidth}
    \begin{minipage}{\textwidth}
      \centering
      \nwaimage[1]{Figures/concat-other}
      \caption{Simple NWA to concatenate onto the NWA in Figure \ref{Fi:Example1}.}
      \label{Fi:Concat1}
    \end{minipage}

    \vspace{2\baselineskip}
    \begin{minipage}{0.8\textwidth}
      \centering
      \nwaimage[0.55]{Figures/reverse-of-figure-1}
      \caption{The NWA resulting from performing reverse on the NWA in Figure \ref{Fi:Example1}.}
      \label{Fi:Reverse1}
    \end{minipage}
  \end{minipage}
  \begin{minipage}{0.49\textwidth}
    \centering
    \nwaimage[0.75]{Figures/concat-result}
    \caption{The NWA resulting from the concatenation of the NWA in Figure
      \ref{Fi:Example1} with the NWA in Figure \ref{Fi:Concat1}.}
    \label{Fi:Concat2}
  \end{minipage}
\end{figure}

\antistupidfloats

The state sets of the NWAs must not overlap,
i.e., $Q_1 \cap Q_2 = \emptyset$. \textsl{Client code should not rely on
  this condition being checked.}

Client information is copied directly from the original NWAs using
\texttt{ClientInfo::clone()}.

\figref{Concat2} shows the result of concatenating \figref{Example1} and
\figref{Concat1}.

\subsection{Kleene star}
\label{Se:Star}

Like concatenation, Kleene-star is complicated in the case of NWAs because of
the ability to have unbalanced words in the automaton's
language. Relative to standard FAs, in the concatenation construction we only needed
to add extra transitions; in this construction, we must add additional states
as well.

The NWA resulting from performing Kleene-Star on the NWA shown in
\figref{Star1} is shown in \figref{Star2}.

The construction presented in \cite{JACM:AM2009} has a minor error. The error is
analogous to not adding a distinguished start state in the traditional
Thompson construction,\footnote{The initial state of the automaton $A^*$
  must accept, because $\epsilon$ is in $L^*$; and because of this property it is
  incorrect to merely add epsilon transitions from the old final states to
  the old initial states. If you do this and there is a cycle from the
  initial state back to itself (for example, a self-loop on the initial
  state), the word corresponding to that path would be accepted even though
  it should not be.} and in
fact can be exhibited using the same example (it is not necessary to use NWA
calls or returns). Alur confirmed that our interpretation of the construction
in \cite{JACM:AM2009} is
correct~\cite{AlurNwaStarBroken}. Below, we present
a version that uses $\epsilon$-transitions, and thus it looks a bit
different from the version in \cite{JACM:AM2009}.

When computing $R = A^*$ for some
NWA $A$, the resulting NWA has two ``copies'' of $A$. These are denoted by
primed and unprimed version of states from $A$ in the definition below.

\begin{figure}[p]
  \centering
    \nwaimage[.4]{Figures/star-simple}
  \caption{An NWA on which to perform Kleene-Star.}
  \label{Fi:Star1}
\end{figure}

\begin{figure}[p]
  \centering
    \nwaimage[1.1]{Figures/star-simple-result}
  \caption{The NWA resulting from performing Kleene-Star on the NWA in Figure \ref{Fi:Star1}.}
  \label{Fi:Star2}
\end{figure}
\antistupidfloats

Suppose that $R$ is reading a word $w=w_1w_2\cdots w_n$, where each $w_i \in
L(A)$. $R$ begins in a start state of $A'$. Henceforth it maintains the
following invariant on the state that $R$ is in with respect to the portion
of $w$ read so far: if the next symbol $\sigma$ is in a return position, then
that
symbol is a \emph{pending} return in the current $w_i$ iff $R$ is in the $A'$
portion, i.e., if the current state is primed. (Note that this return only
needs to be
pending in the current $w_i$. In the full string $w$, $\sigma$ may match a
call in an earlier $w_j$, or it may be pending in the whole string.)

Internal transitions thus keep $R$ in the same copy of $A$, and call
transitions always take $R$ to the unprimed copy of $A$ (because if it then
reads a return, the return will match that call). Return transitions can
target either copy of $A$: if the call predecessor is unprimed, then the
target will be unprimed; if the call predecessor is primed, then the target
will be primed.

The description above describes $R$'s operation under ``normal''
conditions. If $R$ is in a final state (either primed or unprimed) of the
automaton $A$, it is also allowed to guess that it should ``restart'' by taking
an epsilon transition to a distinguished start and final state $q_0$. This
guess is correct if it just read the
last character in $w_i$ (making the next character the first one in
$w_{i+1}$). Note that $q_0$ only has transitions to
the $A'$ portion of $R$, maintaining the invariant.

The reason for the two copies of $A$ comes into play when $R$ reads a return
$\sigma$ while in the $A'$ portion. By the invariant, $\sigma$ is pending in the
current $w_i$. In the original automaton $A$, the transitions that the
machine can use are return transitions $(q,r,\sigma,p)$ where the call predecessor
$r$ is in $Q_0$. We need to make sure that $R$ can take those same
transitions. There are two cases we need to consider:
\begin{enumerate}
\item For the cases where
$\sigma$ is pending in the whole string $w$, we need to have a version of the
return transition with $q_0$ in the call-predecessor position, so we add $(q',
q_0, \sigma, p')$.
\item For the cases where $\sigma$ is matched with a call in some
earlier $w_j$, it does not matter what state the machine was in before that
call; thus we add $(q', s, \sigma, p')$ for each state $s$ in $Q \cup Q'$.
\end{enumerate}
\vspace{0.25\baselineskip}

``Normal'' operation corresponds to the transitions introduced by the
\textsc{Internal}, \textsc{Call}, and \textsc{Locally-Matched-Return}
inference rules given below. The source states of both transitions added by
\textsc{Locally-Matched-Return} are unprimed, because if the current symbol
is a return that matches a call in the same $w_i$, $R$ will be in
the $A$ portion by the invariant.
The \textsc{Restart} rule allows $R$ to restart, and the
\textsc{Start} rule allows $R$ to get from $q_0$ to the $A'$ portion; these
transitions target the $A'$ portion because there have been no calls read in
the current $w_i$, and thus a return symbol would be pending.
The \textsc{Globally-Pending-Return} rule addresses the situation where the
current symbol is a return that is pending in the whole string $w$. (This is
the first case in the previous paragraph.) The \textsc{Locally-Pending-Return} rule
addresses the situation where the current symbol is a return that is pending
in the current $w_i$ but matches a call from a previous $w_j$.

Formally, if the original NWA is $(Q, \Sigma, Q_0, \delta, Q_f)$,
then the result of performing Kleene-Star on that NWA is $(Q^*, \Sigma,
Q_0^*, \delta^*, Q_f^*)$. The sets of states are defined by $Q^* = Q \cup
Q' \cup \{q_0\}$ (with $Q' = \{q'\, |\, q \in Q\}$ and $q_0 \not \in Q$),
and  $Q_0^* = Q_f^* = \{q_0\}$.
The transitions in $\delta^*$ are defined by the following rules:

\begin{mathpar}
{\inferrule*[left=\textsc{Internal}]
             {(q,\sigma,p) \in \delta_i }
  { (q,\sigma,p) \in  \delta_i^* \\ (q',\sigma,p') \in \delta_i^*}
}
\and
{\inferrule*[right=\textsc{Call}]
           { (q,\sigma,p) \in \delta_c  }
  { (q,\sigma,p) \in  \delta_c^* \\ (q',\sigma,p) \in \delta_c^*   }
}
\and
{\inferrule*[left=\textsc{Locally-Matched-Return}]
              { (q,r,\sigma,p) \in \delta_r }
  {(q,r,\sigma,p) \in  \delta_r^* \\ (q,r',\sigma,p') \in \delta_r^* }
}
\\
\and
{\inferrule*[left=\textsc{Start}]
  { q \in Q_0 }
  {(q_0, \epsilon, q') \in \delta_i^*}
}
\and
{\inferrule*[right=\textsc{Retart}]
  { q \in Q_f }
  {(q, \epsilon, q_0) \in \delta_i^* \\ (q', \epsilon, q_0) \in \delta_i^* }
}
\and
{\inferrule*[left=\textsc{Globally-Pending-Return}]
  { (q,r,\sigma,p) \in \delta_r \\ r \in Q_0 }
  {(q',q_0,\sigma,p') \in  \delta_r^* }
}
\and
{\inferrule*[left=\textsc{Locally-Pending-Return}]
  { (q,r,\sigma,p) \in \delta_r \\ r \in Q_0 \\ s \in Q \cup Q' }
  {(q',s,\sigma,p') \in \delta_r^* }
}
\end{mathpar}

Client information is copied directly from the original NWA (using
\texttt{ClientInfo::clone()}) such that for each $q \in Q$, $q$
and $q'$ have (different copies of) the same client information.

\emph{Note:} The key for state $q'$ is generated from the key for state $q$
using the expression \texttt{getKey(q, getKey("prime"))}. The input automaton
to the Kleene star function must not already contain both $q$ and $q'$ for
any $q$.

%Consider the slightly more complex example of computing the Kleene-Star of the NWA shown in Figure \ref{Fi:Star3}.  The resulting NWA is shown in Figure \ref{Fi:Star4}.

%\begin{figure}[htbp]
%  \centering
%    \includegraphics[angle=270,width=10cm]{Figures/Figure13.pdf}
%  \caption{Complex NWA on which to perform Kleene-Star.}
%  \label{Fi:Star3}
%\end{figure}

%\begin{figure}[htbp]
%  \centering
%    \includegraphics[angle=270,width=12cm]{Figures/Figure14.pdf}
%  \caption{The NWA resulting from performing Kleene-Star on the NWA in Figure \ref{Fi:Star3}.}
%  \label{Fi:Star4}
%\end{figure}

\subsection{Reverse}
\label{Se:Reverse}

A nested word $n = (w, \rightsquigarrow)$ is reversed by reversing the linear
word $w$ and exchanging calls and returns. Formally,
$n^{rev} = (w^{rev}, \{(|w|+1-r, |w|+1-c) | (c,r)
\in\rightsquigarrow\})$. (Pending calls and returns are handled by defining
$|w|+1-(+\infty) = -\infty$ and $|w|+1-(-\infty) = +\infty$.) Roughly
speaking, call transitions in $A$ correspond to return transitions in
$A^{rev}$ and vice versa, and we reverse the direction of all transitions as
in the standard FA construction. We describe the construction from the
perspective of $A^{rev}$ --- that is, a ``call transition'' is a call
transition in $A^{rev}$, and a ``call'' is a call in the reversed string.

Perhaps unsurprisingly, pending returns pose a problem because the
role of initial and final states are exchanged. Because of this complication,
the algorithm for reversing an NWA has a similar flavor to that of the
Kleene-star procedure. The automaton $A^{rev}$ has two ``copies'' of $A$
(primed and unprimed), and maintains the same invariant as the Kleene-star
construction: if
the next symbol $\sigma$ is in a return position, then that symbol is a
\emph{pending} return iff $A^{rev}$ is in the $A'$ portion.
(For those familiar with the construction in \cite{JACM:AM2009}, ours is more
complicated because the version in \cite{JACM:AM2009} will not work as stated
with a weakly-hierarchical NWA.)

If the original NWA is $(Q, \Sigma, Q_0, \delta, Q_f)$, then the result of
reversing that NWA is $(Q \cup Q', \Sigma, Q_f', \delta^{rev}, Q_0)$ obtained using
the following rules:

\begin{mathpar}
{\inferrule*[left=\textsc{Internal}]
     { (p,\sigma,q) \in \delta_i  }
  { (q,\sigma,p)  \in \delta^{rev}_i \\ (q',\sigma,p')  \in \delta^{rev}_i }
}
\and
{\inferrule*[left=\textsc{Call-Return}]
       { (q_c,\sigma_c,q_e) \in  \delta_c \\ (q_x,\_\!\_\,,\sigma_r,q_r) \in \delta_r }
  { (q_r, \sigma_r, q_x), (q_r', \sigma_r, q_x) \in \delta^{rev}_c \\
    (q_e, q_r, \sigma_c, q_c), (q_e, q_r', \sigma_c, q_c') \in \delta^{rev}_c }
}
\and
{\inferrule*[left=\textsc{Pending-Return}]
       { (q_c,\sigma,q_e) \in  \delta_c \\ q_f \in Q_f }
  { (q_e', q_f, \sigma, q_c') \in \delta^{rev}_R }
}
\end{mathpar}
%The \textsc{Pending-Return} rule is the most perplexing one. The name
%\textsc{Pending-Return} is written from the perspective of the reversed
%automaton -- in other words, the reversed automaton will take a transition
%added by this rule when it reads a pending return, and that pending return
%would have been a pending call in the original automaton. However, $q_f \in
%Q_f$ is written from the perspective of the original automaton: because
%$q_f$ is a final state in the original it is an initial state in the
%reversed automaton, and this is why the transition can be taken on a pending
%return.

The NWA resulting from performing reverse on the NWA shown in
Figure \ref{Fi:Example1} is shown in Figure \ref{Fi:Reverse1}.

Client
information is copied directly from the original NWA using
\texttt{ClientInfo::clone()}.

\subsection{Determinize}
\label{Se:Determinize}

\begin{definition}
An NWA, $(Q,\Sigma,Q_0,\delta,Q_f)$, is \textbf{deterministic} iff

\begin{enumerate}

\item $|Q_0| \leq 1$,

\item For all $q \in Q$, there is never a choice between reading $\sigma$ and
  following a $\sigma$ transition or following a wild (\wild) transition:
  \begin{itemize}
    \item if $(q,\wild,q') \in \delta_i$ then $|\{q'|(q,\sigma,q') \in
      \delta_i, {\sigma\neq@}\}| = 0$; \\ otherwise, for all $\sigma \in \Sigma - \{\wild\}$,
      $|\{q'|(q,\sigma,q') \in \delta_i\}| \leq 1$,

    \item if $(q,\wild,q') \in \delta_c$ then $ |\{q'|(q,\sigma,q') \in
      \delta_c, {\sigma\neq@}\}| = 0$;\\
      otherwise, for all $\sigma \in \Sigma - \{\wild\}$,
      $|\{q'|(q,\sigma,q') \in \delta_c\}| \leq 1$, and

    \item \mbox{for $q' \in Q$, if $(q,q',\wild,q'') \in \delta_r$ then
      $|\{q''|(q,q',\sigma,q'') \in \delta_r, {\sigma\neq@}\}| = 0$;} \\
      otherwise, for all
      $\sigma \in \Sigma - \{\wild\}$, $|\{q''|(q,q',\sigma,q'') \in \delta_r\}|
      \leq 1$,
  \end{itemize}
\item There are no $\epsilon$ transitions:
 \begin{itemize}
   \item for all $(q,\sigma,q') \in \delta_i, \sigma \neq \epsilon$,
   \item for all $(q,\sigma,q') \in \delta_c, \sigma \neq \epsilon$, and
   \item for all $(q,q',\sigma,q'') \in \delta_r, \sigma \neq \epsilon$.
 \end{itemize}
\end{enumerate}
If an NWA is not deterministic, then it is \textbf{non-deterministic}.
\end{definition}

Determinizing an NWA operates like a
generalization of the classical subset construction.  Instead of the states
in the determinized NWA being subsets of states in the original NWA, states of the
determinized NWA are sets of state pairs (i.e., binary relations on states)
\cite{JACM:AM2009}.  To support determinization, the library provides a
typedef of \texttt{std::set$<$pair$<$State, State$>>$} as
\texttt{Nwa::BinaryRelation}. See also \texttt{opennwa/RelationOps.hpp}.

We present the algorithm we use for determinization in
\appref{DeterminizeAlgorithm}.

%There is very experimental support for using the BuDDY

The result of determinizing the automaton in \figref{Det1} is shown in
\figref{Det2}.

\begin{figure}[p]
  \centering
    \nwaimage[0.45]{Figures/determinize}
  \caption{Simple nondeterministic NWA.}
  \label{Fi:Det1}
\end{figure}

\begin{figure}[p]
  \centering
    \nwaimage[.75]{Figures/determinize-result}
    \caption{The NWA resulting from determinizing the NWA in Figure
      \ref{Fi:Det1}. As mentioned in the text, states in the determinized NWA
      are relations on the states in the original NWA. The state
      $\varnothing$ has been removed from this diagram.}
  \label{Fi:Det2}
\end{figure}

Client information is generated through the use of the helper method
\texttt{mergeClientInfo}, but can be altered through the use of the helper
methods \texttt{mergeClientInfoInternal}, \texttt{mergeClientInfoCall}, and
\texttt{mergeClientInfoReturn}, which are invoked by \texttt{determinize} as
transitions of the three kinds involving the associated state are added.  The
default behavior of \texttt{mergeClientInfo} is that the \texttt{ClientInfo}
associated with the resulting state is \texttt{null}.  The default behavior
of \texttt{mergeClientInfoInternal}, \texttt{mergeClientInfoCall}, and
\texttt{mergeClientInfoReturn} is to make no changes to the the
\texttt{ClientInfo}.  These methods can be overridden to specify alternative
behaviors.  As determinization is performed, \texttt{mergeClientInfo} is
called each time a new state is created.  Then, as each transition is added,
\texttt{mergeClientInfoInternal}, \texttt{mergeClientInfoCall}, or
\texttt{mergeClientInfoReturn} is called (depending on the type of transition
being added) to update the \texttt{ClientInfo} associated with the target
state of the transition being added.

The following functions can be overridden in a subclass of \texttt{Nwa} to
customize the behavior of determinization:
\begin{functionlist}
  \functionDefNoCloseParen{void}{mergeClientInfo}{%
     \parbox[t]{4in}{
       Nwa const \& nondet, BinaryRelation const \& binRel, \\
       St resSt, ref\_ptr<ClientInfo>\& resCI)}}
  Callback that gets called when a new state \texttt{resSt} (representing the
  binary relation \texttt{binRel}) is added to the determinized automaton.
  Intended to provide a hook for computing the client information that should
  be associated with the new state; the client information should be set in
  the output parameter \texttt{resCI} (i.e., \texttt{setClientInfo} should not
  be called directly). \texttt{nondet} is the NWA being determinized.

  \functionDefFirstEarlyNoCloseParen{void}{mergeClientInfoInternal}{%
     \parbox[t]{4in}{
       Nwa const \& nondet,\\
       BinaryRelation const \& binRelSource,\\
       BinaryRelation const \& binRelTarget,\\
       State sourceSt, Symbol resSym, State resSt,\\
       ref\_ptr<ClientInfo>\& resCI )}}
  \functionDefEarlyNoCloseParen{void}{mergeClientInfoCall}{%
     \parbox[t]{4in}{
       Nwa const \& nondet,\\
       BinaryRelation const \& binRelCall,\\
       BinaryRelation const \& binRelEntry,\\
       State callSt, Symbol resSym, State resSt,\\
       ref\_ptr<ClientInfo>\& resCI )}}
  \functionDefNoCloseParen{void}{mergeClientInfoReturn}{%
     \parbox[t]{4in}{
       Nwa const \& nondet,\\
       BinaryRelation const \& binRelExit,\\
       BinaryRelation const \& binRelCall,\\
       BinaryRelation const \& binRelReturn,\\
       State exitSt, State callSt, Symbol resSym,\\
       State resSt, ref\_ptr<ClientInfo>\& resCI )}}
    Callbacks that get called when a new transition is added to the given
    automaton. The endpoints and their associated binary relations are
    given.
    Alters the client information associated with \texttt{resSt} given
    information about the transition being added to the determinized
    automaton.
 \end{functionlist}

%Consider the slightly more complex determinization of the NWA shown in Figure \ref{Fi:Det3}.  The resulting NWA is shown in Figure \ref{Fi:Det4}.

%\begin{figure}[htbp]
%  \centering
%    \includegraphics[angle=270,width=12cm]{Figures/Figure18.pdf}
%  \caption{Complex nondeterministic NWA.}
%  \label{Fi:Det3}
%\end{figure}

%\begin{figure}[htbp]
%  \centering
%    \includegraphics[angle=270,width=12cm]{Figures/Figure19.pdf}
%  \caption{The NWA resulting from determinizing the NWA in Figure \ref{Fi:Det3}.}
%  \label{Fi:Det4}
%\end{figure}

\subsection{Complement}
\label{Se:Complement}

Complementing an NWA is performed by determinizing the automaton and then
complementing the set of final states.
\begin{comment}
 In our implementation, an extra flag
to \texttt{complement} controls whether the determinization step is to be
performed, so it can be bypassed if you have \textsl{a priori} knowledge that
the input NWA must already be deterministic.
\end{comment}
The result of
complementing the NWA shown in Figure \ref{Fi:Det1} is
shown in Figure \ref{Fi:Comp1}.

Client information is computed during determinization as described in the
previous section, then cloned during the complement step.

\begin{figure}[h]
  \centering
    \nwaimage[1]{Figures/complement-of-determinize}
  \caption{The complement of the NWA in Figure \ref{Fi:Det1} (the
    determinization of which is shown in Figure \ref{Fi:Det2}).  We omit
    transitions to the state $\{\}$; any action that does not appear in the
    diagram goes to the state $\{\}$.
  }
  \label{Fi:Comp1}
\end{figure}


\documentclass[11pt, a4paper, oneside]{article}

\usepackage{color}
\usepackage{tikz}
\usepackage{showframe}
\usepackage{blindtext}
\usepackage{amsmath}
\usepackage{amsthm}
\usepackage{bm}
\usepackage{calc}
\usepackage{enumitem}
\usepackage{xcolor}
\usepackage{lipsum}
\usepackage{setspace}
\usepackage{glossaries}
\usepackage{latexsym}

\tikzset{
    vertex/.style = {
        circle,
        fill = black,
        outer sep = 2pt,
        inner sep = 1pt,
    }
}

\SetLabelAlign{parright}{\parbox[t]{\labelwidth}{\raggedleft#1}}
\setstretch{0.5}

\DeclareMathOperator*{\argmin}{argmin}

\begin{document}

\title{}
\author{}
\date{}

%Dataset
%name: LS3D-W.
%download: https://www.adrianbulat.com/face-alignment/

\part*{Studies dependency}.

\section*{Face alignment 2D}

Cao, X., Wei, Y., Wen, F., Sun, J.: Face alignment by explicit shape regression. In: CVPR. (2012)

Xiong, X., De la Torre, F.: Supervised descent method and its applications to face alignment. In: CVPR. (2013) 532–539

Jourabloo, A., Liu, X.: Pose-invariant 3d face alignment. In: CVPR. (2015) 3694–3702

Zhu, S., Li, C., Change Loy, C., Tang, X.: Face alignment by coarse-to-fine shape searching. In: CVPR. (2015) 4998–5006

Bulat, A., Tzimiropoulos, G.: Convolutional aggregation of local evidence for large pose face alignment. In: BMVC. (2016)

\section*{Face alignment 3D}

Bulat, A.,Tzimiropoulos, G.: Two-stage Convolutional Part Heatmap Regression for the 1st 3D Face Alignment in the Wild (3DFAW) Challenge. ???? (2016)

\part*{Bulat 2017 Face Alignment}

\noindent
Normalized Mean Error:

\begin{equation}
\text{NME}
= \frac{1}{N} \sum_{k=1}^N \frac{\| \mathbf{x}_k - \mathbf{y}_k \|^2}{d}
\tag{}
\end{equation}

\begin{description}[labelwidth=\widthof{\bfseries 123456789012345},align=parright]
	\item[Input variable: ]	$d = \sqrt{w_{ \mathit{bbox}} * h_{\mathit{bbox}} }$
	\item[$\mathit{bbox}:$] bounding box.
\end{description}

\bigskip

\part*{Bulat 2016 Two stage 3D pose}

\begin{equation}
l_2 = \frac{1}{N} \sum_{n=1}^N (\tilde{z}_n - z_n) _2
\tag{}
\end{equation}

\bigskip

\noindent
Ground Truth Error(GTE):

\begin{equation}
E( \mathbf{X}, \mathbf{Y})
= \frac{1}{N} \sum_{n=1}^N \frac{\| \mathbf{X}_n - \mathbf{Y}_n \|_2}{d_i}
\tag{}
\end{equation}

\begin{description}[labelwidth=\widthof{\bfseries 123456789012345},align=parright]
	\item[$\mathbf{X}$:] Predicted set of points.
	\item[$\mathbf{Y}$:] Corresponding ground truth.
	\item[$d_i$:] Interocular distance for the $i$th image.
\end{description}

\bigskip

\noindent
Cross View Ground Truth Consistency Error(CVGTCE):
\begin{equation}
E_{vc}( \mathbf{X}, \mathbf{Y}, T )
=\frac{1}{N} \sum_{n=1}^1 \frac{\| s\mathbf{Rx}_n - \mathbf{y}_n \|_2}{d_i}
\tag{}
\end{equation}

\begin{equation}
P = \{ s, \mathbf{R}, \mathbf{t} \}
\tag{}
\end{equation}

\begin{equation}
\{ s, \mathbf{R}, \mathbf{t} \}
= \argmin_{s, \mathbf{R}, \mathbf{t}}
\sum_{n=1}^N \| \mathbf{y}_k - (s \mathbf{Rx} + \mathbf{•}mathbf{t}) \|_2 ^2
\end{equation}

\end{document}


The code of this project can be separated into three different
categories: libraries, portable code and platform specific code.
Libraries are Open Source code that are re-used from other projects.
Portable code is generic code that does not contain anything specific to
this processor or board, but is only useful in this project. It can be
moved into a library if another project requires it later. Portable code
is usually well covered by unit tests (see the \texttt{tests} folder),
where non portable code must usually be tested ``by hand''.

\section*{Libraries}\label{libraries}

Most of those libraries have READMEs that describe them in much more
detail.

\begin{itemize}
\tightlist
\item
  \texttt{chibios-syscalls} provides a few extensions for ChibiOS (our
  RTOS) for malloc and printf mostly.
\item
  \texttt{crc} implements some common checksums algorithms.
\item
  \texttt{decadriver} is provided by Decawave to interact with their
  product.
\item
  \texttt{eigen} is a C++ matrix manipulation library used for the EKF.
\item
  \texttt{parameter} provides a unified interface for the application to
  declare parameters.
\item
  \texttt{cmp}, \texttt{cmp\_mem\_access} and
  \texttt{parameter\_flash\_storage} are used to store the parameters in
  non volatile memory.
\item
  \texttt{msgbus} implements a software message bus
  (publisher/subscriber pattern), similar in concept to D-bus or ROS.
\item
  \texttt{libuavcan} is the official UAVCAN stack.
\item
  \texttt{test-runner} is used only to provide an environment during
  unit testing.
\end{itemize}

\section*{Portable code}\label{portable-code}

\begin{itemize}
\tightlist
\item
  \texttt{MadgwickAHRS.\{c,h\}} contains the implementation of the
  Madgwick filter.
\item
  \texttt{lru\_cache.\{c,h\}} contains a generic implementation of a
  Least Recently Used (LRU) cache.
\item
  \texttt{mpu9250.\{c,h\}} contains a portable implementation of a
  driver for the Invensense MPU9250 IMU.
\item
  \texttt{state\_estimation.\{cpp,h\}} contains the code for the state
  estimator (uses ekf.hpp).
\item
  \texttt{ekf.hpp} contains a generic implementation of an EKF using C++
  templates.
\item
  \texttt{uwb\_protocol.\{c,h\}} contains a portable implementation of
  the UWB protocol.
\end{itemize}

\section*{Non portable code}\label{non-portable-code}

\begin{itemize}
\tightlist
\item
  \texttt{ahrs\_thread.\{c,h\}} contains the thread that runs the
  Madgwick filter.
\item
  \texttt{anchor\_position\_cache.\{c,h\}} contains the thread that
  stores the position of the anchors and provides them to the other
  threads.
\item
  \texttt{imu\_thread.\{c,h\}} contains the thread that runs the IMU
  driver.
\item
  \texttt{ranging\_thread.\{c,h\}} contains the thread responsible for
  doing range measurements and other radio operations.
\item
  \texttt{state\_estimation\_thread.\{cpp,h\}} contains the thread that
  runs the state estimation.
\item
  \texttt{usbconf.\{c,h\}} contains the USB setup code.
\item
  \texttt{main.\{c,h\}} contains the entrypoint of the application.
\item
  \texttt{cmd.\{c,h\}} contains the command line interface shown on USB.
\item
  \texttt{decawave\_interface.\{c,h\}} contains the low level bindings
  between Decawave's library and our code.
\item
  \texttt{board.\{c,h\}} contains GPIO contains GPIO configuration.
\item
  \texttt{bootloader\_config.\{c,h\}} contains code for interacting with
  the CAN bootloader used on some boards.
\item
  \texttt{exti.\{c,h\}} contains the external interrupt configuration
  and handlers.
\item
  The \texttt{uavcan} folder contains code related to moving messages
  from the application to the CAN bus and vice versa.
\end{itemize}


\chapter[Agent Based Simulation]{Agent Based Simulation}\label{chp:agent_based_simulation}

\chapterinitial{S}{ometimes} individual behaviours and interactions are well
understood, and an understanding of how a whole population of such individuals
might behave needed. For example psychologists and economists may know a lot
about how individual spenders and vendors behave in response to given stimuli,
but an understanding of how these stimuli might effect the macro-economy is
necessary. Agent based\index{agent based} simulation is a paradigm of thinking
that allows such emergent population level behaviour to be investigated from
individual rules and interactions.

\section{Problem}\label{sec:agent_based_simulation_problem}

Consider a city populated by two categories of household, for example a household
might be fans of Cardiff City FC or Swansea City AFC\footnote{Swansea and
Cardiff are two cities in South Wales with rival football clubs.}.
Each household has a preference for living close to households of the same kind,
and will move around the city while their preferences are not satisfied.
How will these individual preferences affect the overall distribution of fans in
the city?

\section{Theory}\label{sec:agent_based_simulation_theory}

The problem considered here is considered a `classic' one for the paradigm of
agent based simulation, and is referred to as Schelling\index{Schelling}'s
segregation model. It features in Thomas Schelling's book `Micromotives and
Macrobehaviours'~\cite{schelling2006micromotives}, whose title neatly summarises
the world view of agent based modelling: we know, understand, determine, or can
control individual micromotives; and from this we'd like to observe and
understand macrobehaviours.

In general an agent based model consists of two components, agents, and an
environment:

\begin{itemize}
    \item agents are autonomous entities that will periodically choose to take one
        of a number of actions.
        These are chosen in order to maximise that agent's own given utility
        function;
    \item an environment contains a number of agents and defines how their
        interactions affect each other.
        The agents may be homogeneous or heterogeneous, and the
        relationships may change over time, possibly due to the actions taken
        by the agents.
\end{itemize}

In general, an agent will first observe a subset of its environment, for
example it will consider some information about the agents it is currently
close to.
Then it will update some information about itself based on these observations.
This could be recording relevant information from the observations, but could
also include some learning, maybe considering its own previous actions.
It will then decide on an action to take, and carry out this action. This
decision may be deterministic or random and/or based on its own attributes from
some learning process\index{learning process}; with the ultimate aim of
maximising its own utility. In practice, a utility\index{utility} can be
represented by a function that maps the environment to some numeric value.
This process happens to all agents in the environment, possibly simultaneously.
This is summarised in Figure~\ref{fig:abm_diagram}

\begin{figure}
    \begin{center}
        \includestandalone[width=\textwidth]{./assets/abm-diagram}
    \end{center}
    \caption{Representation of an agent interacting with its environment.}
    \label{fig:abm_diagram}
\end{figure}

For the football team supporters problem, each household is an agent.
The environment is the city.
Each household's utility function is to satisfy their preference of living next
to at least a given number of households supporting the same team as them.
Their choices of action are to move house or not to move house.

As a simplification the city will be modelled as a \(50 \times 50\) grid.
Each cell of the grid is a house that can either contain a household of Cardiff
City FC supporters, or contain a household of Swansea City AFC supporters.
A house's neighbours are assumed to be the houses adjacent to it, horizontally,
vertically, and diagonally.
For mathematical simplicity, it is also assumed that the grid is a torus,
where houses in the top row are vertically adjacent to the bottom row, and
houses in the rightmost column are horizontally adjacent to the leftmost column.

Every household has a preference \(p\).
This corresponds to the minimum proportion of neighbours they are happy to live
Figure~\ref{fig:schelling_happyunhappy} shows a household of Cardiff City FC
supporters that are happy with their neighbours, and not happy with their
neighbours, when \(p=0.5\). Households supporting Cardiff City FC are shaded
grey.

\begin{figure}
    \begin{center}
        \subfigure[A happy household, with 6 similar neighbours (\(\frac{6}{8} > p = 0.5\))]{\includestandalone[width=0.4\textwidth]{./assets/schelling_happy}}
        \subfigure[An unhappy household, with 2 similar neighbours (\(\frac{2}{8} < p = 0.5\))]{\includestandalone[width=0.4\textwidth]{./assets/schelling_unhappy}}
    \end{center}
    \caption{Example of a household happy and unhappy with its neighbours, when
    \(p=0.5\). Households supporting Cardiff City FC are shaded grey, households
    supporting Swansea City AFC are white.}
    \label{fig:schelling_happyunhappy}
\end{figure}

The original problem stated that households move around the city whenever they
are unhappy with their neighbours.
This long process of selling, searching for, and buying houses can be simplified
to randomly pairing two unhappy households and swapping their houses.
In fact, this can be simplified to consider the houses themselves as agents,
who swap households with each other.

Therefore the model logic is:

\begin{enumerate}
  \item initialise the model: fill each house in the grid with either a
  household of Cardiff City FC or Swansea City AFC supporters with
  probability \(0.5\) each;
  \item at each discrete time step, for every house:
  \begin{enumerate}
    \item consider their household's neighbours (\textit{observe});
    \item determine if the household is happy (\textit{update});
    \item if unhappy (\textit{decide}), swap household with another randomly
    chosen house with an unhappy household (\textit{action}).
  \end{enumerate}
\end{enumerate}

After a number of time steps the overall structure of the city can be observed.
This agent based model only explicitly defines individual behaviours
and interactions, therefore any population level behaviour that may have emerged
would occur without explicit definition.

\section{Solving with Python}\label{sec:agent_based_simulation_solving-with-python}

Agent based modelling lends itself well to a programming paradigm called
object-orientated programming\index{object-orientated programming}.
This paradigm lets a number of \textit{objects} from a set of instructions
called a \textit{class} to be built.
These objects can both store information (in Python these are called
\textit{attributes}\index{attribute}), and do things (in Python these are called
\textit{methods}\index{method}).
Object-orientated programming allow for the creation of new classes which can be
used to implement the individual behaviours of an agent based model.

For this problem two classes will be built: a
\mintinline{python}{House} and a \mintinline{python}{City} for them to live in.

The following libraries will be used:

\begin{pyin}
import random
import itertools
import numpy as np
\end{pyin}

Now to define the \mintinline{python}{City}:

\begin{pyin}
class City:
    def __init__(self, size, threshold):
        """Initialises the City object.

        Args:
            size: an integer number of rows and columns
            threshold: float between 0 and 1 representing the
            minimum acceptable proportion of similar neighbours
        """
        self.size = size
        sides = range(size)
        self.coords = itertools.product(sides, sides)
        self.houses = {
            (x, y): House(x, y, threshold, self)
            for x, y in self.coords
        }

    def run(self, n_steps):
        """Runs the simulation of a number of time steps.

        Args:
            n_steps: an integer number of steps
        """
        for turn in range(n_steps):
            self.take_turn()

    def take_turn(self):
        """Swaps all sad households."""
        sad = [h for h in self.houses.values() if h.sad()]
        random.shuffle(sad)
        i = 0
        while i <= len(sad) / 2:
            sad[i].swap(sad[-i])
            i += 1

    def mean_satisfaction(self):
        """Finds the average household satisfaction.

        Returns:
            The average city's household satisfaction
        """
        return np.mean(
            [h.satisfaction() for h in self.houses.values()]
        )
\end{pyin}

This defines a class, a template or a set of instructions that can be used to
create instances, called objects.
For the considered problem only one instance of the \mintinline{python}{City}
class will be needed.
However, it is useful to be able to produce more in order to run multiple trials
with different random seeds.
This class contains four methods: \mintinline{python}{__init__},
\mintinline{python}{run}, \mintinline{python}{take_turn} and
\mintinline{python}{mean_satisfaction}.

The \mintinline{python}{__init__} method is run whenever the object is first
created, and initialises the object.
In this case it sets a number of attributes.

\begin{itemize}
     \item First the square grid's \mintinline{python}{size} is defined, which
           is the number of rows and columns of houses it contains;
     \item next the \mintinline{python}{coords} are defined, a list of tuples
           representing all the possible coordinates of the grid, this uses the
           itertools library for efficient iteration;
     \item finally \mintinline{python}{houses} is defined, a dictionary with
           grid coordinates as keys, and instances of the
           \mintinline{python}{House} class.
\end{itemize}

The \mintinline{python}{run} method runs the simulation. For each
\mintinline{python}{n_steps} number of discrete time steps, the city runs the
method \mintinline{python}{take_turn}.
In this method, first a list of all the houses is created with households that
are unhappy with their neighbours; these are put in a random order using the
random library; and then working inwards from the boundary
houses with sad households are paired up and swap households.

The last method defined here is the \mintinline{python}{mean_satisfaction}
method, which is only used to observe any emergent behaviour\index{emergent behaviour}.
This calculates the average satisfaction of all the houses in the grid, using
the numpy library for convenience.

In order to be able to create an instance of the above class, we need to define
a \mintinline{python}{House} class:

\begin{pyin}
class House:
    def __init__(self, x, y, threshold, city):
        """Initialises the House object.

        Args:
            x: the integer x-coordinate
            y: the integer y-coordinate
            threshold: a number between 0 and 1 representing
              the minimum acceptable proportion of similar
              neighbours
            city: an instance of the City class
        """
        self.x = x
        self.y = y
        self.threshold = threshold
        self.kind = random.choice(["Cardiff", "Swansea"])
        self.city = city

    def satisfaction(self):
        """Determines the household's satisfaction level.

        Returns:
            A proportion
        """
        same = 0
        for x, y in itertools.product([-1, 0, 1], [-1, 0, 1]):
            ax = (self.x + x) % self.city.size
            ay = (self.y + y) % self.city.size
            same += self.city.houses[ax, ay].kind == self.kind
        return (same - 1) / 8

    def sad(self):
        """Determines if the household is sad.

        Returns:
            a Boolean
        """
        return self.satisfaction() < self.threshold

    def swap(self, house):
        """Swaps two households.

        Args:
            house: the house object to swap household with
        """
        self.kind, house.kind = house.kind, self.kind
\end{pyin}

It contains four methods: \mintinline{python}{__init__},
\mintinline{python}{satisfaction}, \mintinline{python}{sad} and
\mintinline{python}{swap}.

The \mintinline{python}{__init__} methods sets a number of attributes at the
time the object is created: the house's \mintinline{python}{x} and
\mintinline{python}{y} coordinates (its column and row numbers on the grid);
its \mintinline{python}{threshold} which corresponds to \(p\); its
\mintinline{python}{kind} which is randomly chosen between having a Cardiff City
FC supporting household or a Swansea City AFC supporting household; and finally
its \mintinline{python}{city}, an instance of the \mintinline{python}{City}
class, shared by all the houses.

The \mintinline{python}{satisfaction} method loops though each of the house's
neighbouring cells in the city grid, counts the number of neighbours that are
of the same kind as itself, and returns this as a proportion.
Then the \mintinline{python}{sad} method returns a boolean indicating if the
household's satisfaction is below the minimum threshold.

Finally the \mintinline{python}{swap} method takes another house object, and
swaps their household kinds.

A function to create and run one of these simulations will now be written
with a given random seed\index{random seed}, threshold, and number of steps.
This function returns the resulting mean happiness:

\begin{pyin}
def find_mean_happiness(seed, size, threshold, n_steps):
    """Create and run an instance of the simulation.

    Args:
        seed: the random seed to use
        size: an integer number of rows and columns
        threshold: a number between 0 and 1 representing
            the minimum acceptable proportion of similar
            neighbours
        n_steps: an integer number of steps

    Returns:
        The average city's household satisfaction after
        n_steps
    """
    random.seed(seed)
    C = City(size, threshold)
    C.run(n_steps)
    return C.mean_satisfaction()
\end{pyin}

Now consider each household with a threshold of
0.65, and compare the mean happiness after 0 steps and 100 steps.
First 0 steps:

\begin{pyin}
initial_happiness = find_mean_happiness(
    seed=0, size=50, threshold=0.65, n_steps=0
)
print(initial_happiness)
\end{pyin}

\begin{pyout}
0.4998
\end{pyout}

This is well below the minimum threshold of \(0.65\), and so on average
households are unhappy.
After 100 steps:

\begin{pyin}
final_happiness = find_mean_happiness(
    seed=0, size=50, threshold=0.65, n_steps=100
)
print(final_happiness)
\end{pyin}

\begin{pyout}
0.9078
\end{pyout}

After 100 time steps the average satisfaction level is much higher.
In fact, it is much higher than each individual household's threshold.
Now consider that this satisfaction level is really a level of how similar
each households' neighbours are, it is actually a level of segregation.
This was the central premise of Schelling's original
model~\cite{schelling2006micromotives}
that overall emergent segregation levels are much higher than any individuals'
personal preference for segregation.

More analysis methods can be added, including plotting functions.
Figure~\ref{fig:schelling_python_plot} shows the grid at the beginning, after 20
time steps, and after 100 time steps, with households supporting Cardiff City FC
in grey, and those supporting Swansea City AFC in white.
It visually shows the households segregating over time.

\begin{figure}
\begin{center}
\subfigure[At the beginning.]{\includegraphics[width=0.32\textwidth]{./assets/python_schelling_0}}
\subfigure[After 20 time steps.]{\includegraphics[width=0.32\textwidth]{./assets/python_schelling_20}}
\subfigure[After 100 time steps.]{\includegraphics[width=0.32\textwidth]{./assets/python_schelling_100}}
\end{center}
\caption{Plotted results from the Python code.}
\label{fig:schelling_python_plot}
\end{figure}

\section{Solving with R}\label{sec:agent_based_simulation_solving-with-R}

Agent based modelling lends itself well to a programming paradigm called
object-orientated programming\index{object-orientated programming}.
This paradigm lets a number of \textit{objects} from a set of instructions
called a \textit{class} to be built.
These objects can both store information (in the R package used here these are called
\textit{fields}\index{field}), and do things (in the R package used here these are called
\textit{methods}\index{method}).
Object-orientated programming allow for the creation of new classes which can be
used to implement the individual behaviours of an agent based model.

There are a number of ways of doing object-orientated programming in R.
In this chapter, a package called R6\index{R6} will be used here.

For this problem two classes will be built: a
\mintinline{R}{House} and a \mintinline{R}{City} for them to live in.

Now to define the \mintinline{R}{City}\footnote{
Note that no documentation is included in the definition
of the class and the style is inconsistent with the other chapters in this book.
The authors do not know of any widely accepted convention for documenting classes
in R, furthermore the text of this chapter serves as detailed documentation in this
context.
}

\begin{Rin}
library(R6)
City <- R6Class("City", list(
  size = NA,
  houses = NA,
  initialize = function(size, threshold) {
    self$size <- size
    self$houses <- c()
    for (x in 1:size) {
      row <- c()
      for (y in 1:size) {
        row <- c(row, House$new(x, y, threshold, self))
      }
      self$houses <- rbind(self$houses, row)
    }
  },
  run = function(n_steps) {
    if (n_steps > 0) {
      for (turn in 1:n_steps) {
        self$take_turn()
      }
    }
  },
  take_turn = function() {
    sad <- c()
    for (house in self$houses) {
      if (house$sad()) {
        sad <- c(sad, house)
      }
    }
    sad <- sample(sad)
    num_sad <- length(sad)
    i <- 1
    while (i <= num_sad / 2) {
      sad[[i]]$swap(sad[[num_sad - i]])
      i <- i + 1
    }
  },
  mean_satisfaction = function() {
    mean(sapply(self$houses, function(x) x$satisfaction()))
  }
) )
\end{Rin}

This defines an R6 class, a template or a set of instructions that can be used
to create instances of it, called objects.
For this model only one instance of the \mintinline{R}{City} class is needed,
although it may be useful to be able to produce more in order to run multiple
trials with different random seeds.
This class contains four methods: \mintinline{R}{initialize},
\mintinline{R}{run}, \mintinline{R}{take_turn} and
\mintinline{R}{mean_satisfaction}.

The \mintinline{R}{initialize} method is run at the time the object is first
created.
It initialises the object by setting a number of its fields:

\begin{itemize}
     \item First the square grid's \mintinline{R}{size} is defined, which
           is the number of rows and columns of houses it contains;
     \item then the \mintinline{R}{houses} are defined by iteratively repeating
           the \mintinline{R}{rbind} function to create a two-dimensional vector
           of instances of the, yet to be defined, \mintinline{R}{House} class,
           representing the houses themselves.
\end{itemize}

The \mintinline{R}{run} method runs the simulation. For each discrete time
step from 1 to \mintinline{R}{n_steps}, the world runs the method
\mintinline{R}{take_turn}.
In this method, a list of all the houses with households that
are unhappy with their neighbours is created;
these are put in a random order and then working inwards from the boundary,
houses with sad households are paired up and swap households.

The last method defined here is the \mintinline{R}{mean_satisfaction}
method, which is used to observe the emergent behaviour\index{emergent behaviour}.
This calculates the average satisfaction of all the houses in the grid.

In order to be able to create an instance of the above class,
a \mintinline{R}{House} class is needed:

\begin{Rin}
House <- R6Class("House", list(
  x = NA,
  y = NA,
  threshold = NA,
  city = NA,
  kind = NA,
  initialize = function(x = NA,
                        y = NA,
                        threshold = NA,
                        city = NA) {
    self$x <- x
    self$y <- y
    self$threshold <- threshold
    self$city <- city
    self$kind <- sample(c("Cardiff", "Swansea"), 1)
  },
  satisfaction = function() {
    same <- 0
    for (x in -1:1) {
      for (y in -1:1) {
        ax <- ( (self$x + x - 1) %% self$city$size) + 1
        ay <- ( (self$y + y - 1) %% self$city$size) + 1
        if (self$city$houses[[ax, ay]]$kind == self$kind) {
          same <- same + 1
        }
      }
    }
    (same - 1) / 8
  },
  sad = function() {
    self$satisfaction() < self$threshold
  },
  swap = function(house) {
    old <- self$kind
    self$kind <- house$kind
    house$kind <- old
  }
) )
\end{Rin}

It contains four methods: \mintinline{R}{initialize},
\mintinline{R}{satisfaction}, \mintinline{R}{sad} and \mintinline{R}{swap}.

The \mintinline{R}{initialize} methods sets a number of the class' fields when
the object is created: the house's \mintinline{R}{x} and \mintinline{R}{y}
coordinates (its column and row numbers on the grid); its
\mintinline{R}{threshold} which corresponds to \(p\); its \mintinline{R}{kind}
which is randomly chosen between having a Cardiff City
FC supporting household or a Swansea City AFC supporting household; and finally
its \mintinline{R}{city}, an instance of the \mintinline{R}{City} class, shared
by all the houses.

The \mintinline{R}{satisfaction} method loops though each of the house's
neighbouring cells in the city grid, counts the number of neighbours that are of
the same kind as itself, and returns this as a proportion.
The \mintinline{R}{sad} method returns a boolean indicating of the
household's satisfaction is below its minimum threshold.

Finally the \mintinline{R}{swap} method takes another house object, and
swaps their household kinds.

A function to create and run one of these simulations will now be written
with a given random seed, threshold, and number of steps. This function return
the resulting mean happiness:

\begin{Rin}
#' Create and run an instance of the simulation.
#'
#' @param seed: the random seed to use
#' @param size: an integer number of rows and columns
#' @param threshold: a number between 0 and 1 representing
#'   the minimum acceptable proportion of similar neighbours
#' @param n_steps: an integer number of steps
#'
#' @return The average city's household satisfaction
#'   after n_steps
find_mean_happiness <- function(seed,
                                size,
                                threshold,
                                n_steps){
  set.seed(seed)
  city <- City$new(size, threshold)
  city$run(n_steps)
  city$mean_satisfaction()
}
\end{Rin}

Now consider each household with a threshold of
0.65, and compare the mean happiness after 0 steps and 100 steps.
First 0 steps:

\begin{Rin}
initial_happiness <- find_mean_happiness(
  seed = 0,
  size = 50,
  threshold = 0.65,
  n_steps = 0
)
print(initial_happiness)
\end{Rin}

\begin{Rout}
[1] 0.4956
\end{Rout}

This is well below the minimum threshold of \(0.65\), and so on average
households are unhappy here.
Let's run the simulation for 100 generations and see how this changes:

\begin{Rin}
final_happiness <- find_mean_happiness(
  seed = 0,
  size = 50,
  threshold = 0.65,
  n_steps = 100
)
print(final_happiness)
\end{Rin}

\begin{Rout}
[1] 0.9338
\end{Rout}

After 100 time steps the average satisfaction has increased.
It is now actually much higher that each individual household's threshold.
This satisfaction level can be considered as a level of how similar each
households' neighbours are, and so it is actually a level of segregation.
This was the central premise of Schelling's original
model~\cite{schelling2006micromotives}, that overall
emergent segregation levels are much higher than any individuals' personal
preference for segregation.

More analysis methods can be added, including plotting functions.
Figure~\ref{fig:schelling_R_plot} shows the grid at the beginning, after 20
time steps, and after 100 time steps, with households supporting Cardiff City FC
in grey, and those supporting Swansea City AFC in white.
It shows the households segregating over time.

\begin{figure}
\begin{center}
\subfigure[At the beginning.]{\includegraphics[width=0.32\textwidth]{./assets/schelling_R_0}}
\subfigure[After 20 time steps.]{\includegraphics[width=0.32\textwidth]{./assets/schelling_R_20}}
\subfigure[After 100 time steps.]{\includegraphics[width=0.32\textwidth]{./assets/schelling_R_100}}
\end{center}
\caption{Plotted results from the R code.}
\label{fig:schelling_R_plot}
\end{figure}

\section{Wider context}\label{sec:agent_based_simulation_wider_context}

The simulations described in this chapter come under the larger umbrella term of
multi agent systems, which discusses the theory of systems with multiple
independent agents interacting with one another. A good source on the topic
is~\cite{shoham2008multiagent}.

The model described here is called Schelling's\index{Schelling} segregation
model, and was first described in~\cite{schelling2006micromotives}. Another model
considered as classic in this domain is a model of a flock of birds presented
in~\cite{reynolds1987flocks}, otherwise referred to as Boids\index{Boids}, where the
behaviours of flocks of birds are understood by capturing the individual
interactions between individual birds. Conway's Game of
Life\index{Conway's Game of Life}, described in~\cite{gardener1970mathematical} is
another classic, which comes under the banner of cellular
automata\index{cellular automata}. Here cells on a grid either become alive or
dead depending on a certain simplistic set of rules. Emergent behaviours
observed due to these rules include self replicating as well as oscillating
structures. In the 1970s agent based tournaments were held by Robert
Axelrod\index{Axelrod}~\cite{axelrod1990evolution},
which was the first of a number of studies using agent based modelling and game
theory\index{game theory} (see Chapter~\ref{chp:game_theory}) to understand the
emergence of cooperative behaviours.

In recent years, similar methodologies have been used in a variety of
applications such as~\cite{diaz2021agent} which models parents' choice of school,
in~\cite{romanowska2019agent} archaeological population migration and trade
dynamics are modelled, and~\cite{jing2020agent} offers a systematic
literature review for the use of agent based modelling of autonomous vehicles.