\documentclass[12pt]{article}

\usepackage[tracking]{microtype}

\usepackage[sc]{mathpazo}
% \usepackage[euler-digits,small]{eulervm}
\usepackage[small]{eulervm}

\usepackage{amsmath,amsfonts,amssymb}
\usepackage{stmaryrd} % for semantic brackets [[ ]]

\usepackage{algorithm}
\usepackage[noend]{algpseudocode}
\usepackage{calc}

\usepackage{varwidth}

% Modify this to change the format of function names in algoritms
\renewcommand{\textproc}{\textsl}

% Define let command in algorithm
\newcommand{\Let}{\textbf{let} }
\newcommand{\In}{\textbf{in}}
\newcommand{\Raise}{\textbf{raise} }

\algblock{LetBlock}{EndLet}
% customising the new block
\algnewcommand\algorithmicletblock{\textbf{let}}
\algnewcommand\algorithmicendlet{\textbf{in}}
\algrenewtext{LetBlock}[1]{\algorithmicletblock\ #1\ =}
\algrenewtext{EndLet}{\algorithmicendlet}

% Widest label is "Invariant:"
\newcommand{\algorithmicwidestlabel}{\widthof{\textbf{Invariant:}}}

% Make ensures and requires of equal width
\algrenewcommand\algorithmicensure{%
  \makebox[\algorithmicwidestlabel][l]{\textbf{Ensure:}}}
\algrenewcommand\algorithmicrequire{%
  \makebox[\algorithmicwidestlabel][l]{\textbf{Require:}}}

% Invariants in pseudocode
\algnewcommand\algorithmicinvar{%
  \makebox[\algorithmicwidestlabel][l]{\textbf{Invariant:}}}
\algnewcommand\Invar{\item[\algorithmicinvar]}%

% Assertions in pseudocode
\algnewcommand\algorithmicassert{%
  \makebox[\algorithmicwidestlabel][l]{\textbf{Assert:}}}
\algnewcommand\Assert{\item[\algorithmicassert]}%

\renewcommand{\vec}[1]{\mathbf{#1}}            % bold vector

\newcommand{\lo}{\mathcal{L}}                  % a logic
\newcommand{\lent}{\,\models_\lo\,}            % entailment in a logic
\newcommand{\ext}[1]{\llbracket #1 \rrbracket} % model of a formula

\newcommand{\sspace}{\ensuremath{\mathcal{S}}}

\newcommand{\init}{\ensuremath{I}}
\newcommand{\trans}{\ensuremath{T}}
\newcommand{\transt}{\ensuremath{\mathcal{T}}}

\newcommand{\reachablek}[1]{\ensuremath{\mathcal{R}_{#1}}}
\newcommand{\reachable}{\ensuremath{\mathcal{R}_\infty}}

\newcommand{\pvalid}{\ensuremath{\mathcal{P}_\mathrm{valid}}}
\newcommand{\pinvalid}{\ensuremath{\mathcal{P}_\mathrm{invalid}}}

\begin{document}

\title{Multi-Property $k$-induction in Kind 2}

\author{Christoph Sticksel}
\maketitle

\section{Preliminaries}
\label{sec:prelim}

Let~${(I[\vec x], T[\vec x, \vec x'])}$ be the encoding of a transition system with the initial state constraint~$I$ and the transition relation~$T$. Let~${\mathcal{P} = \{ P_1[\vec x], \dotsc, P_n[\vec x] \}}$ be a set of~$n$ properties to be checked for invariance. The variables~$I[\vec x]$,~$T[\vec x, \vec x']$ and~$\mathcal{P}[\vec x]$ are static and always in scope.

\[ \mathcal{P}[\vec x] = \bigwedge_{P\in\mathcal{P}} P[\vec x] \]

\[ \mathcal{P}[\vec x_s,\dotsc,\vec x_t] = \bigwedge_{i=s}^t P[\vec x_i] \]

\[ \mathcal{T}[\vec x_s,\dotsc,\vec x_t] = \bigwedge_{i=s}^{t-1}  T[\vec x_i,\vec x_{i+1}]  \]

\[ \reachablek{0} = \{ \vec x_k \in \sspace \mid \init[\vec x_k] \} \]

\[ \reachablek{k} = \{ \vec x_k \in \sspace \mid \exists \vec x_0,\dotsc,\vec x_{k-1} \in \sspace \colon \init[\vec x_0] \land \transt[\vec x_0,\dotsc,\vec x_k] \} \]

\[ \reachable = \bigcup_{k \geq 0} \reachablek{k} \]

% \[ \mathcal{T}(\mathcal{P})[\vec x_s,\dotsc,\vec x_t] = \left( \bigwedge_{i=s}^{t-1} \mathcal{P}[\vec x_i] \land T[\vec x_i,\vec x_{i+1}] \right) \land \mathcal{P}[\vec x_t] \]

% The relation~$\mathcal{T}$ is to be extended with path compression etc.

% \section{Implementation}
% \label{sec:impl}

% The transition system~${(I[\vec x], T[\vec x, \vec x'])}$ is static and always in scope.

% A global state consisting of the following variables that are shared by all procedures is maintained, it is realized by message passing. Every function maintains its own consistent snapshot of the global state that only changes after an explicit call to a function~\textproc{update} --- this corresponds to receiving incoming queued messages in a message passing model. Changes to the global state are denoted by the~$:=$ operator, which corresponds to sending a message. Implicitly, the~$:=$ operator ensures to modify only an up to date view and correctly serializes concurrent writes to the global state.

% \begin{description}
% \item[$\mathcal{P}_\mathrm{invalid}$] A subset of~$\mathcal{P}$ such that for each~$P\in\mathcal{P}_\mathrm{invalid}$ there is a counterexample trace~$\vec x_0,\dotsc,\vec x_k$ where
%   \[ I[\vec x_0] \land \mathcal{T}[\vec x_0,\dotsc,\vec x_{k}] \land \lnot P[\vec x_{k}]. \]
% \item[$\mathcal{P}_\mathrm{valid}$] A subset of~$\mathcal{P}$ such that each~$P\in\mathcal{P}_\mathrm{valid}$ is invariant:
%   \[ I[\vec x] \lent P[\vec x], \]
%   \[ P[\vec x] \land T[\vec x,\vec x'] \lent P[\vec x']. \]
% \item[$k_\textproc{bmc}$] For all~${k \leq k_\textproc{bmc}}$ there is no counterexample of length~$k$ to any property${P \in \mathcal{P} \setminus \mathcal{P}_\mathrm{invalid}}$: \[ I[\vec x_0] \land \mathcal{T}[\vec x_0,\dotsc,\vec x_{k}] \lent P[\vec x_{k}]. \]
% \end{description}

\begin{figure}[tp]
  \centering
  \begin{algorithmic}
    \Require $\forall P \in \pvalid \ \forall \vec x \in \reachable \colon P[\vec x]$
    \Require $\forall P \in \pinvalid \ \exists \vec x_0,\dotsc,\vec x_k \in \sspace \colon \init[\vec x_0] \land \transt[\vec x_0,\dotsc,\vec x_k] \land \lnot P[\vec x_k]$
    \Function{send$_\mathcal{P}$}{$\pvalid$, $\pinvalid$}
    \State \Return
    \EndFunction

    \bigskip

    \Ensure $\forall P \in \pvalid \ \forall \vec x \in \reachable \colon P[\vec x]$
    \Ensure $\forall P \in \pinvalid \ \exists \vec x_0,\dotsc,\vec x_k \in \sspace \colon \init[\vec x_0] \land \transt[\vec x_0,\dotsc,\vec x_k] \land \lnot P[\vec x_k]$
    \Function{receive$_\mathcal{P}$}{\null}
    \State \Return $\langle \pvalid, \; \pinvalid \rangle$
    \EndFunction

    \bigskip
    \Require $\forall P \in \mathcal{P} \setminus \pinvalid \; \forall \vec x_0,\dotsc,\vec x_k \in \sspace \colon \init[\vec x_0] \land \transt[\vec x_0,\dotsc,\vec x_k] \models P[\vec x_k]$
    \Require $\forall P \in \pinvalid \; \exists i \leq k \; \exists \vec x_0,\dotsc,\vec x_i \in \sspace \colon \init[\vec x_0] \land \transt[\vec x_0,\dotsc,\vec x_i] \models P[\vec x_i]$

    \Function{send$_{k_\textproc{bmc}}$}{$k$, $\pinvalid$}
    \State \Return
    \EndFunction

    \bigskip

    \Ensure $\forall P \in \mathcal{P} \setminus \pinvalid \; \forall \vec x_0,\dotsc,\vec x_k \in \sspace \colon \init[\vec x_0] \land \transt[\vec x_0,\dotsc,\vec x_k] \models P[\vec x_k]$
    \Ensure $\forall P \in \pinvalid \; \exists i \leq k \; \exists \vec x_0,\dotsc,\vec x_i \in \sspace \colon \init[\vec x_0] \land \transt[\vec x_0,\dotsc,\vec x_i] \models P[\vec x_i]$
    \Function{receive$_{k_\textproc{bmc}}$}{\null}
    \State \Return $\langle k, \; \pinvalid \rangle$
    \EndFunction

  \end{algorithmic}
  \caption{Interface and Guarantees of Message Passing Architecture}
  \label{fig:message-passing}
\end{figure}

% \section{Bounded Model Checking (BMC)}
% \label{sec:bmc}

\begin{figure}[tp]
  \label{fig:bmc}
  \centering
  \begin{algorithmic}[1]
    \Function{bmc}{$k$, $\mathcal{P}_\mathrm{in}$, $\pinvalid$}

    % Update global state
    \State \Let $\langle \mathcal{P}_\mathrm{valid},\; \mathcal{P}_\mathrm{invalid}\rangle$ = \Call{receive$_\mathcal{P}$}{\null} \In

    % Reduce to unknown properties
    \State \Let $\mathcal{P} = \mathcal{P}_\mathrm{in} \setminus \mathcal{P}_\mathrm{valid} \setminus \mathcal{P}_\mathrm{invalid}$ \In

    % Premise of entailment check
    \State \Let $\Phi = I[\vec x_0] \land \mathcal{T}[\vec x_0,\dotsc,\vec x_{k}] \land \mathcal{P}_\mathrm{valid}[\vec x_0,\dotsc,\vec x_k]$ \In

    % Conclusion of entailment check
    \State \Let $\Psi =  \mathcal{P}[\vec x_{k}]$ \In

    % Entailment check
    \If {$\Phi \lent \Psi$}

      % Found no invalid properties
      \State \Call{send$_{k_\textproc{bmc}}$}{$k$, $\pinvalid$}
      \label{alg:bmc-send-k}

      % Recurse to find longer counterexamples
      \State \Call{bmc}{$k+1$, $\mathcal{P}$, $\pinvalid$}

    \Else

      % Counterexample to entailment
      \State \Let $\mathcal{M} \in \ext{\Phi \land \lnot \Psi}$ \In

      % Properties that can still be valid
      \State \Let $\mathcal{P}' = \{P \in \mathcal{P} \mid \mathcal{M} \lent P[\vec x_{k}] \}$ \In

      % Properties that are invalid
      \State \Let $\pinvalid' = \mathcal{P} \setminus \mathcal{P}'$ \In

      % Send invalid properties
      \State \Call{send$_\mathcal{P}$}{$\emptyset$, $\pinvalid'$}
      \label{alg:bmc-send-pinvalid}

      % Unknown properties left?
      \If {$\mathcal{P}' \not = \emptyset$}

        % Recurse to find counterexamples for potentially valid
        % properties
        \State \Call{bmc}{$k$, $\mathcal{P}'$, $\pinvalid \cup \pinvalid'$}

      \Else

        % Terminate
        \State \Return

      \EndIf
    \EndIf
    \EndFunction
  \end{algorithmic}
  \caption{BMC Algorithm}
\end{figure}

% Soundness: show that preconditions of~\textproc{send$_x$} in Lines~\ref{alg:bmc-send-k} and~\ref{alg:bmc-send-pinvalid} are satisfied.

% Termination:

%  to add all properties~$P\in\mathcal{P}$ that are not invariant to~$\mathcal{P}_\mathrm{invalid}$ and preserves the invariants about the global state. It is not guaranteed to terminate unless all invariant properties are eventually added to~$\mathcal{P}_\mathrm{valid}$.

%  $I[\vec x_0] \land \mathcal{T}[\vec x_0,\dotsc,\vec x_{k}] \land \mathcal{P}_\mathrm{valid}[\vec x_0,\dotsc,\vec x_k] \lent \mathcal{P}[\vec x_{k}]$

% Called as~\textproc{bmc}($0$, $\mathcal{P}$), it guarantees to add all properties~$P\in\mathcal{P}$ that are not invariant to~$\mathcal{P}_\mathrm{invalid}$ and preserves the invariants about the global state. It is not guaranteed to terminate unless all invariant properties are eventually added to~$\mathcal{P}_\mathrm{valid}$.

% Since a property in~$\mathcal{P}_\mathrm{valid}$ is invariant, the entailment check in Line~\ref{alg:bmc-check} is equivalent to checking the stronger~${I[\vec x_0] \land \mathcal{T}[\vec x_0,\dotsc,\vec x_{k}] \lent \mathcal{P}[\vec x_{k}]}$ thus will find all counterexamples of length~$k$.

% \section{$k$-induction}
% \label{sec:k-induction}

\begin{figure}[tp]
  \label{fig:k-induction-update}
  \centering

  \begin{algorithmic}[1]
    \Function{update$_{\mathcal{P},\mathcal{D}}$}{$\mathcal{P}_\mathrm{in}$, $\mathcal{D}$, $\pvalid$}

    % New valid and invalid properties
    \State \Let $\langle \pvalid',\; \pinvalid' \rangle$ = \Call{receive$_\mathcal{P}$}{\null} \In

    % New k in BMC
    \State \Let $\langle k^\textproc{bmc}, \pinvalid^\textproc{bmc} \rangle$ = \Call{receive$_\textproc{bmc}$}{\null} \In

    \State \Let $\pvalid'' = \pvalid \cup \pvalid'$ \In
    \State \Let $\pinvalid'' = \pinvalid' \cup \pinvalid^\textproc{bmc}$ \In

    % New valid and invalid properties do not need to be proved
    \State \Let $\mathcal{P}_\mathrm{out}$ = $\mathcal{P}_\mathrm{in} \setminus \pvalid'' \setminus \pinvalid''$ \In

    % Any tentatively valid property disproved?
    \If {$\exists (l, D) \in \mathcal{D} \colon D \in \pinvalid''$}

      % Prove all dependent properties again
      \State \Return $\langle \mathcal{P}_\mathrm{out} \cup \{ D \mid (l,D) \in \mathcal{D} \}  \setminus \pinvalid'',\; \emptyset,\; k_\textproc{bmc}, \pvalid'' \rangle$

    % All tentatively valid properties proved?
    \ElsIf {$\forall (l, D) \in \mathcal{D} \colon D \in \pvalid \lor k_\textproc{bmc} \geq l$}

      % Commit all properties as valid
      \State \Call{send$_\mathcal{P}$}{$\{ D \mid (l, D) \in \mathcal{D} \}$, $\emptyset$}

      % Continue with properties to prove and no tentatively valid
      % properties
      \State \Return $\langle \mathcal{P}_\mathrm{out},\; \emptyset,\; k_\textproc{bmc},\; \pvalid'' \rangle$

    \Else

      % Continue with properties to prove and tentatively valid properties
      \State \Return $\langle \mathcal{P}_\mathrm{out},\; \mathcal{D},\; k_\textproc{bmc},\; \pvalid'' \rangle$

    \EndIf

    \EndFunction

  \end{algorithmic}
  \caption{Updating Dependencies in $k$-Induction}
\end{figure}

\begin{figure}[tp]
  \label{fig:k-induction}
  \centering

  \begin{algorithmic}[1]
    \Function{ind}{$k$, $\mathcal{P}_\mathrm{in}$, $\mathcal{Q}$, $\mathcal{D}_\mathrm{in}$, $\pvalid$}

    % Update properties to prove and tentative properties
    \State \Let $\langle \mathcal{P}_\mathrm{prove},\; \mathcal{D},\; k_\textproc{bmc},\; \pvalid' \rangle$ = \Call{update$_{\mathcal{P},\mathcal{D}}$}{$\mathcal{P}_\mathrm{in}$, $\mathcal{D}_\mathrm{in}$, $\pvalid$} \In

    % Terminate when no more properties to prove
    \If {$\mathcal{P}_\mathrm{prove} = \emptyset$} \State \Return \EndIf

    % Assume tentative properties
    \State \Let $\mathcal{P}_\mathrm{assume}$ = $\{ D \mid (l, D) \in \mathcal{D} \}$ \In

    % Premises that can be disproved later
    \State \Let {$\Phi_1 = \mathcal{P}_\mathrm{prove}[\vec x_0,\dotsc,\vec x_k] \land \mathcal{P}_\mathrm{assume}[\vec x_0,\dotsc,\vec x_{k+1}]$} \In

    % Premises that cannot be disproved
    \State \Let {$\Phi_2 = \pvalid'[\vec x_0,\dotsc,\vec x_{k+1}] \land \mathcal{T}[\vec x_0,\dotsc,\vec x_{k+1}] $} \In

    % Conclusion
    \State \Let {$\Psi = \mathcal{P}_\mathrm{prove}[\vec x_{k+1}]$} \In

    % k-induction check
    \If {$\Phi_1 \land \Phi_2 \lent \Psi$}

      % Can there be counterexamples of length up to k?
      \If {$\left(k_\textproc{bmc} \geq k\right)$}

        % Premises can safely be assumed, properties are certainly valid
        \State \Call{send$_\mathcal{P}$}{$\mathcal{P}_\mathrm{prove} \cup \mathcal{P}_\mathrm{assume}$, $\emptyset$}

        % Properties to prove for next k?
        \If {$\mathcal{Q} \not = \emptyset$}

          % Increment k and prove remaining properties
          \State \Call{ind}{$k+1$, $\mathcal{Q}$, $\emptyset$, $\emptyset$, $\pvalid'$}

        \Else

          % All properties proved
          \State \Return

        \EndIf

      % Premises can be disproved
      \Else

          % Each property must be in D only for one l
          \State \Let $\mathcal{D}'$ = $\{ (k, P) \mid P \in \mathcal{P}_\mathrm{prove} \}$ \In

        % Still more properties to prove?
        \If {$\mathcal{Q} \not = \emptyset$}

          % Continue trying to prove failed properties k+1-inductive,
          % properties P are proved dependent on P and P_assume
          \State \Call{ind}{$k+1$, $\mathcal{Q}$, $\emptyset$, $\mathcal{D} \cup \mathcal{D}'$, $\pvalid'$}

        \Else

          % Wait for BMC to catch up
          \Repeat

            % New valid and invalid properties
            \LetBlock {$\langle \mathcal{P}_\mathrm{prove},\; \mathcal{D},\; k_\textproc{bmc}, \pvalid' \rangle$}
            \State \Call{update$_{\mathcal{P},\mathcal{D}}$}{$\emptyset$, $\mathcal{D} \cup \mathcal{D}'$, $\pvalid'$}
            \EndLet

            \If {$\mathcal{P}_\mathrm{prove} \not = \emptyset$}
            \State \Call{ind}{$k$, $\mathcal{P}_\mathrm{prove}$, $\emptyset$, $\emptyset$, $\pvalid'$}
            \EndIf

          \Until {$k_\textproc{bmc} \geq k \lor \mathcal{D} = \emptyset$}

          \State \Return

        \EndIf

      \EndIf

      \Else

      % Get an inductive counterexample
      \State \Let $\mathcal{M} \in \ext{\Phi_1 \land \Phi_2 \land \lnot \Psi}$ \In

      % Properties that may be k-inductive for this k
      \State \Let $\mathcal{P}' = \{P \in \mathcal{P}_\mathrm{prove} \mid \mathcal{M} \lent P[\vec x_{k+1}] \}$ \In

      % Properties that are not k-inductive for this k
      \State \Let $\mathcal{Q}' = \mathcal{Q} \cup \mathcal{P}_\mathrm{prove} \setminus \mathcal{P}'$

      % Try proving properties at the same k
      \State \Call{ind}{$k$, $\mathcal{P}'$, $\mathcal{Q}'$, $\mathcal{D}$, $\pvalid'$}

    \EndIf
    \EndFunction
  \end{algorithmic}
  \caption{$k$-Induction Algorithm}
\end{figure}

% The (tail-)recursive $k$\nobreakdash-induction procedure~\textproc{ind}($k$, $\mathcal{P}$, $\mathcal{Q}$, $\mathcal{D}$) is initially called with the parameters~${k = 0}$,~${\mathcal{Q} = \emptyset}$, and~${\mathcal{D} = \emptyset}$. The set~$\mathcal{P}$ contains all properties that are not~$l$\nobreakdash-inductive for any $l < k$ and are true for at least~$k_\textproc{bmc}$ steps from the initial state. Properties that are in addition not $k$\nobreakdash-inductive are in~$\mathcal{Q}$. The set~$\mathcal{D}$ contains pairs~$(l,D)$ with~${l \geq 0}$ and~$D$ being a set of properties that are~$l$\nobreakdash-inductive if all properties in~$D$ hold for at least~$l$ steps from the initial state.

% The function~\textproc{ind} starts by partitioning~$\mathcal{D}$ into three disjoint sets based on the global state:~the set~$\mathcal{D}_\mathrm{invalid}$ of pairs~$(l,D)$ where at least one property in~$D$ has a counterexample;~the set~$\mathcal{D}_\mathrm{valid}$ of pairs~$(l,D)$ where no property in~$D$ has an~$l$ step counterexample; and the remaining pairs~$(l,D)$ where none of the properties in~$D$ has a counterexample of length~$k_\textproc{bmc} < l$.

% All properties of~$D$ in any pair~$(l,D)$ of~$\mathcal{D}_\mathrm{valid}$ have no counterexample of length~$l$, and are~$l$\nobreakdash-inductive, therefore  certainly valid and are added to the global state.

% All properties of~$D$ of some pair~$(l,D)$ of~$\mathcal{D}_\mathrm{invalid}$ are either in~$\mathcal{P}_\mathrm{invalid}$ or~$l$\nobreakdash-inductive, but under the now violated assumption that some property in~$\mathcal{P}_\mathrm{invalid}$ is valid. Those properties not in~$\mathcal{P}_\mathrm{invalid}$ are still candidates for invariance and are added back to the set of properties~$\mathcal{P}$ to be proved.

% All properties of~$D$ in some pair~$(l,D)$ of~$\mathcal{D}$ are optimistically assumed to be invariant, and make up the set~$\mathcal{P}_\mathrm{assume}$. These properties are used to strengthen the~$k$\nobreakdash-inductive check, but every property proved~$k$\nobreakdash-inductive is only so relative to~$\mathcal{P}_\mathrm{assume}$ and its proof is invalid as soon as a counterexample to one property~$\mathcal{P}_\mathrm{assume}$ is found.

% The~$k$\nobreakdash-inductive check uses the premise~$\Phi_1$, which is a conjunction of properties in~$\mathcal{P}$ and~$\mathcal{P}_\mathrm{assume}$ that have not been proven invariant. Thus the check is conditional on the non-existence of a counterexample of length~$k$ for each of the properties in~$\mathcal{P}$ and~$\mathcal{P}_\mathrm{assume}$.

% The second half of the premises in the~$k$\nobreakdash-inductive check contains properties that have been proven valid and the transition relation. Both are unconditionally true.

% If the~$k$\nobreakdash-inductive check succeeds, the properties~$\mathcal{P}$ are invariant if there is no~$k$ step counterexample to any property in~$\mathcal{P}$ or~$\mathcal{P}_\mathrm{assume}$. For this we check if in the global state~${k_\textproc{bmc}\geq k}$. Then, the global state is modified to include~$\mathcal{P}$ and~$\mathcal{P}_\mathrm{assume}$ in~$\mathcal{P}_\mathrm{valid}$. The properties in~$\mathcal{P}_\mathrm{assume}$ were proved under the condition of the non-existence of a counterexample of some length~${l < k \leq k_\textproc{bmc}}$ and hence are now invariant, too. If the set of properties~$\mathcal{Q}$ is not empty, the procedure continues to check those for~${k+1}$\nobreakdash-in\-duct\-ive\-ness, otherwise it exits.

% If the~$k$\nobreakdash-inductive check succeeds, but it is unknown if there are counterexamples of length~$k$, the properties in~$\mathcal{P}$ are invariant if no counterexamples of length~$k$ exist for any of the properties in~$\mathcal{P}$ and~$\mathcal{P}_\mathrm{assume}$. This condition is added to the set~$\mathcal{D}$ and the procedure continues to check if the properties in~$\mathcal{Q}$ are~${k+1}$\nobreakdash-inductive, if~$\mathcal{Q}$ is not empty. If~$\mathcal{Q}$ is empty, the procedure monitors the global state for additions to~$\mathcal{P}_\mathrm{invalid}$ that are in~$D$ of some pair~${(l,D)\in\mathcal{D}}$. This triggers a reentry to the procedure with~${\mathcal{P}=\mathcal{Q}=\emptyset}$, where the properties that were proved conditional on properties in~$\mathcal{P}_\mathrm{invalid}$ are checked for~$k$\nobreakdash-inductiveness again. If the global state changes to~$k_\textproc{bmc} \geq k$, then the condition on~$k$\nobreakdash-inductiveness of all properties of~$\mathcal{P}$ and~$\mathcal{P}_\mathrm{assume}$ is satisfied. These properties are added to~$\mathcal{P}_\mathrm{valid}$ in the global state and the procedure terminates.

% If the~$k$\nobreakdash-inductive check fails, some properties of~$\mathcal{P}$ are not~$k$\nobreakdash-inductive. By examining the inductive counterexample, those properties that are false in the final state~$\vec x_{k+1}$ are added to~$\mathcal{Q}$ to be checked for~${k+1}$\nobreakdash-inductiveness. The~$k$\nobreakdash-inductive check is then tried again for those properties that are true in the final state~$\vec x_{k+1}$.

\end{document}

%%% Local Variables:
%%% TeX-command-default: "LaTeX"
%%% TeX-parse-self: t
%%% TeX-auto-save: t
%%% TeX-PDF-mode: t
%%% TeX-master: t
%%% ispell-dictionary: "american"
%%% flyspell-default-dictionary: "american"
%%% End:


\chapter{Gravity Inversion}\label{Chp:cook:gravity inversion}

\section{Introduction}

In this part of the documentation we give an introduction on how to use the
\downunder module and the inversion driver functions to perform inversion
of gravity and magnetic data.
The driver functions enable geologists and geophysicists to apply the
\downunder module quickly and easily without requiring detailed
knowledge of either the theory behind inversion or programming skills.
However, users who are interested in specializing or extending the inversion
capacity are referred to Part~\ref{part2} of this manual.
It is beyond the intention of this manual to give a detailed introduction to
geophysical inversion, in particular to the appropriate preprocessing of data
sets.

The \downunder module described here is designed to calculate estimations for
the 3-D distribution of density and/or susceptibility from 2-D gravity and
magnetic data measured in ground or airborne surveys.
This process is generally called inversion of geophysical data.
Following the standard assumption it is assumed that data are measured as
perturbation of an expected gravity and/or magnetic field of the Earth.
In this context measured gravity and magnetic data describe
anomalies in the gravity and magnetic field.
As a consequence, the inversion process provides corrections to an average
density (typically $2670 kg/m^3$) and susceptibility (typically $0$).
In the following we always assume that the given data are anomalies and
just use the terms gravity and density to describe  them.

In this chapter we give a detailed introduction for using the driver
functions for inversion of gravity data.
In the following chapters~\ref{Chp:cook:magnetic inversion} and~\ref{Chp:cook:joint inversion}
we discuss the inversion of magnetic data, and the joint inversion of
gravity and magnetic data using \downunder.
Note, that the principles introduced in this chapter apply to magnetic and
joint inversion so the presentation for these problem classes is kept short
and users interested in magnetic data only should still work through this
chapter on gravity data.

To run the examples discussed you need to have \escript (version 3.3.1 or
newer) installed on your computer.
To visualize the results you need to have access to a
data plotting software which is able to process \VTK input files, e.g.
\mayavi or \VisIt.
As \mayavi can be easily obtained and installed for most platforms the
tutorial includes commands to visualize output files using \mayavi .
However, it is pointed out that \VisIt is the preferred visualization tool for
\escript as it can deal with very large data sets more efficiently.

\begin{figure}
\centering
\includegraphics[width=0.7\textwidth]{QLDWestGravityDataPlot.png}
\caption{Gravity Anomaly Data in $mgal$ from Western Queensland, Australia
    (file \examplefile{data/QLDWestGravity.nc}). Data obtained from Geoscience Australia.}
%\AZADEH{Tracey R, Bacchin M, \& Wynne P. 2008. In preparation. AAGD07: A new absolute gravity datum for Australian gravity and new standards for the Australian National Gravity Database. Exploration Geophysics.}
\label{FIG:P1:GRAV:0}
\end{figure}

\begin{figure}
\centering%
\includegraphics[width=0.9\textwidth]{QLDGravContourMu10.png}
\caption{3-D contour plot of the density distribution obtained by inversion of
    file \file{data/QLDWestGravity.nc} (with $\mu=10$).
    Colours represent values of density where high values are represented by
    blue and low values are represented by red.}
\label{FIG:P1:GRAV:1}
\end{figure}

\section{How does it work?}
Inversion execution is controlled by a script that can be edited using any text editor.
The script contains a series of statements to be read and executed line by line by an
interpreter.  In the case of \downunder this interpreter is \Python.
In order to process each statement in the script certain rules (called syntax) need to be obeyed.
There are many online tutorials for \Python available\footnote{e.g.
\url{http://www.tutorialspoint.com/python} and \url{http://doc.pyschools.com}}.
For a deeper understanding we also refer the reader to the \escript cook book \cite{ESCRIPTCOOKBOOK} and user's
guide \cite{ESCRIPT}.
For this part of the manual no \Python knowledge is required but it is
recommended that users acquire some basic \Python knowledge as they
progress in their work with \downunder.

The following script~\ref{code: gravity1}\footnote{The script is similar to
\examplefile{grav_netcdf.py} within the \escript example file directory.} is a
simple example to run an inversion for gravity data:

\begin{pyc}\label{code: gravity1}
\
\begin{python}
# Header:
from esys.downunder import *
from esys.weipa import *
from esys.escript import unitsSI as U

# Step 1: set up domain
dom=DomainBuilder()
dom.setVerticalExtents(depth=40.*U.km, air_layer=6.*U.km, num_cells=28)
dom.setFractionalPadding(pad_x=0.2, pad_y=0.2)
dom.fixDensityBelow(depth=40.*U.km)

# Step 2: read gravity data
source0=NetCdfData(NetCdfData.GRAVITY, 'GravitySmall.nc')
dom.addSource(source0)

# Step 3: set up inversion
inv=GravityInversion()
inv.setSolverTolerance(1e-4)
inv.setSolverMaxIterations(50)
inv.setup(dom)

# Step 4: run inversion
inv.getCostFunction().setTradeOffFactorsModels(10.)
rho = inv.run()

# Step 5: write reconstructed density to file
saveVTK("result.vtu", density=rho)
\end{python}
\end{pyc}
The result, in this case the density distribution, is written to an external
file for further processing. You can copy and paste the text of the script
into a file of any name, let's say for further reference we use the file
name \file{grav.py}.
It is recommended to use the extension \file{.py} to identify the file as a
\Python script.
We will discuss the statements of the script later in this chapter.

The inversion needs to be fed with some gravity data. You can find
example data from western Queensland, Australia in two resolutions in the
\escript example directory. In this case data are loaded from the file
\examplefile{GravitySmall.nc} which is in \netcdf file format.
After you have copied this file into the directory in which you have saved the
script \file{grav.py} you can run the program using the command line
\begin{verbatim}
run-escript grav.py
\end{verbatim}
We are running \file{grav.py} through the \escript start-up command since
\escript is used as a back end for the inversion algorithm\footnote{Please see
the \escript user's guide~\cite{ESCRIPT} on how to run your script in parallel
using threading and/or MPI.}.  It is assumed that you have an installation of \escript available on
your computer, see \url{https://launchpad.net/escript-finley}.

After the execution has successfully completed you will find the result file
\file{result.vtu} in the directory where you started the execution
of the script.
The file has the \VTK format and can be imported easily into many
visualization tools.
One option is the \mayavi package which is available on most platforms.
You can invoke the visualization using the commands
\begin{verbatim}
mayavi2 -d result.vtu -m SurfaceMap
\end{verbatim}
from the command line.
Figure~\ref{FIG:P1:GRAV:1} shows the result of this inversion as a contour
plot\footnote{These plots were generated by \VisIt using the higher resolution
data.}, while the gravity anomaly data is shown in Figure~\ref{FIG:P1:GRAV:0}.
We will discuss data later in Section~\ref{SEC:P1:GRAV:DATA}.

Let us take a closer look at the script\footnote{In \Python lines starting
with `\#` are comments and are not processed further.}. Besides the header
section one can separate the script into five steps:
\begin{enumerate}
    \item set up domain on which the inversion problem is solved
    \item load the data
    \item set-up the inversion problem
    \item run the inversion
    \item further processing of the result. Here we write the reconstructed
          density distribution to a file.
\end{enumerate}
In the following we will discuss the steps of the scripts in more detail.
Before we do this it is pointed out that the header section, following
\Python conventions, makes all required packages available to access within
the script.
At this point we will not discuss this in more details but emphasize that the
header section is a vital part of the script.
It is is required in each \downunder inversion script and should not be
altered except if additional modules are needed.

\begin{figure}
\centering
\includegraphics[width=\textwidth]{dom2D.pdf}
\caption{2-D domain set-up for gravity inversion}
\label{FIG:P1:GRAV:2}
\end{figure}

\section{Creating the Inversion Domain}
The first step in Script~\ref{code: gravity1} is the definition of the domain over
which the inversion is performed.
We think of the domain as a block with orthogonal, plain faces.
Figure~\ref{FIG:P1:GRAV:2} shows the set-up for a two-dimensional domain
(see also Figure~\ref{fig:domainBuilder} for 3-D).
The lateral coordinates along the surface of the Earth are denoted by $x$ and
$y$ (only $x$-direction is used in 2-D).
The $z$ direction defines the vertical direction where the part above the
surface ($z=0$) has positive coordinates and the subsurface negative coordinates.
The height of the section above the surface, which is assumed to be filled
with air, needs to be set by the user.
The inversion assumes that the density in the section is known to be
zero\footnote{Always keeping in mind that these are not absolute values but
anomalies.}.
The density below the surface is unknown and is calculated through inversion. The user needs to specify the depth below the surface in which the
density is to be calculated.
The lateral extension of the domain is defined by the data sets fed into the
inversion.
It is chosen large enough to cover all data sets (in case more than one is
used). In order to reduce the impact of the boundary a padding zone around the
data sets can be introduced.

\begin{figure}
\centering
\includegraphics[width=\textwidth]{dom2DFEM.pdf}
\caption{Cell distribution and boundary conditions for a 2-D domain}
\label{FIG:P1:GRAV:3}
\end{figure}

The reconstruction of the gravity field from an estimated density distribution
is the key component of the inversion process.
To do this \downunder uses the finite element method (FEM).
We need to introduce a grid over the domain, see Figure~\ref{FIG:P1:GRAV:3}.
The number of vertical cells is set by the user while the number of horizontal
cells is derived from the grid spacing of the gravity data set(s).
It is assumed that gravity field data given are constant across a cell.
To be able to reconstruct the gravity field some assumptions on the values of
the gravity field on the domain boundary have to be made.
\downunder assumes that on all faces the lateral gravity field component
equals zero. No assumptions on the horizontal components are
made\footnote{It is assumed that the gravity potential equals zero on the top
and bottom surface, see Section~\ref{sec:forward gravity} for details}%
\footnote{Most inversion codes use Green's functions over an unbounded domain
to reconstruct the gravity field. This approach makes the assumption that the
gravity field (or potential) converges to zero when moving away from the
region of interest. The boundary conditions used here are stronger in the
sense that the lateral gravity component is enforced to be zero in a defined
distance of the region of interest but weaker in the sense that no constraint
on the horizontal component is applied.}.

In script~\ref{code: gravity1} the statement
\begin{verbatim}
dom=DomainBuilder()
\end{verbatim}
creates something like a factory to build a domain.
We then define the features of the domain we would like to create:
\begin{verbatim}
dom.setVerticalExtents(depth=40.*U.km, air_layer=6.*U.km, num_cells=28)
dom.setFractionalPadding(pad_x=0.2, pad_y=0.2)
\end{verbatim}
Here we specify the depth of the domain to $40 km$, the thickness of the air
layer above the surface to $6 km$ and the number of vertical cells to $28$.
We also introduce a lateral padding of $20 \%$ of the expansion of the gravity
data on each side of the data and in both lateral directions.

In some cases it can be appropriate to assume that the density below a certain
depth is zero\footnote{As we are in fact calculating density corrections this
means that the density is assumed to be the average density.}.
The statement
\begin{verbatim}
dom.fixDensityBelow(depth=40.*U.km)
\end{verbatim}
introduces this constraint.
As in the case discussed here if the depth for zero density is not less than
the depth of the domain no constraint at depth is applied to the density.

\downunder uses the metre-kilogram-second based International System of Units
(SI)\footnote{see \url{http://en.wikipedia.org/wiki/International_System_of_Units}}\index{SI}.
So all values must be converted to appropriate units.
This does not apply to geographic coordinates which in \module{downunder} are given in
fractional degrees (as a floating point number) to represent longitude and
latitude. In the script we have used the expression
\begin{verbatim}
depth=40.*U.km
\end{verbatim}
to define the depth of the domain to $40 km$.
The expression \verb|U.km| denotes the unit $km$ (kilometer) and ensures
appropriate conversion of the value $40$ into the base unit $m$ (meter).
It is recommended that units are added to values (where present) in order to ensure
that the values used in  \downunder are given with the appropriate
units.
The physical units module of \escript, which we have imported here under the
name \verb|U| in the script header, defines a large number of physical units
and constants, please see~\cite{ESCRIPT} and~\cite{ESCRIPTONLINE}.

\section{Loading Gravitational Data}\label{SEC:P1:GRAV:DATA}
In practice gravity acceleration is measured in various ways, including
airborne surveys~\cite{Telford1990a} or surface surveys.
The\\ \downunder library assumes that all data supplied as input are already appropriately
pre-processed. In particular, corrections for
\begin{itemize}
 \item free-air, to remove effects from altitude above ground;
 \item latitude, to remove effects from ellipsoidicity of the Earth;
 \item terrain, to remove effects from topography
\end{itemize}
must have been applied to the data.  In general, data prepared in such a form are called Bouguer anomalies~\cite{Telford1990a}.

To load gravity data into \downunder the data are given on a plane parallel
to the surface of the Earth at a constant altitude, see
diagram~\ref{FIG:P1:GRAV:2}.
The data need to be defined over a rectangular grid covering a subregion of
the Earth surface.
The grid uses a geographic coordinate system with latitudes and longitudes
assumed to be given in the Clarke 1866 geodetic system.
Figure~\ref{FIG:P1:GRAV:0} shows an example of such a data set from
western Queensland, Australia.
The data set covers a rectangular region between $140^o$ and $141^o$ east
and between $20^o$ and $21^o$ south.
Notice that latitude varies between $-90^o$ to $90^o$ where negative signs
refer to places in the southern hemisphere and longitude varies between
$-180^o$ to $180^o$ where negative signs refer to places west of Greenwich.
The colour at a location represents the value of the vertical Bouguer gravity
anomaly at this point at the surface of the Earth.
Values in this data set range from $-160 \; mgal$ to about $500 \; mgal$\footnote{The unit
$mgal$ means milli $gal$ (galileo) with $1 \; gal = 0.01 \frac{m}{sec^2}$.}
over a $121 \times 121$ grid.

In general, a patch of gravity data needs to be defined over a plane
\verb|NX| $\times$ \verb|NY| where \verb|NX| and \verb|NY| define the number
of grid lines in the longitude (\verb|X|) and the latitude (\verb|Y|)
direction, respectively.
The grid is spanned from an origin with spacing \verb|DELTA_X| and
\verb|DELTA_Y| in the longitude and the latitude direction, respectively.
Gravity data for all grid points need to be given as an \verb|NX|
$\times$ \verb|NY| array.
If available, measurement errors can be associated with gravity data.
The values are given as an \verb|NX| $\times$ \verb|NY| array matching the
shape of the gravity array.
Note that data need not be available on every single point of the grid, see
Section~\ref{SEC:P1:GRAV:REMARK:DATAHOLES} for more information on this.

Currently, two data file formats are supported, namely \emph{ER Mapper Raster}
\cite{ERMAPPER} files and \netcdf~\cite{NETCDF} files.
The examples from this chapter use \netcdf files and we refer the reader to
Section~\ref{SEC:P1:GRAV:REMARK:ERMAPPER} and
Section~\ref{sec:ref:DataSource:ERM} for more information on using ER Mapper
Raster files.
If you have data in any other format you have the option of writing a suitable
reader (for advanced users, see Chapter~\ref{Chp:ref:data sources}) or,
assuming you are able to read the data in \Python, refer to the example
script \examplefile{create_netcdf.py} which shows how to create a file
in the \netcdf file format~\cite{NETCDF} compatible with \downunder from
a data array.

In script~\ref{code: gravity1} we use the statement
\begin{verbatim}
source0=NetCdfData(NetCdfData.GRAVITY, 'GravitySmall.nc')
\end{verbatim}
to load the gravity data stored in \examplefile{GravitySmall.nc} in the
\netcdf format.
Within the script the data set is now available under the name \verb|source0|.
We need to link the data set to the \verb|DomainBuilder| using
\begin{verbatim}
dom.addSource(source0)
\end{verbatim}
To build the domain for inversion, \verb|DomainBuilder| uses the information about origin,
extent, spacing and other options used to build an appropriate domain.
A flat Earth is assumed and geographic coordinates used to
represent data in the input file are mapped to a (local) Cartesian coordinate
system. This is achieved by projecting the geographic coordinates into the
\emph{Universal Transverse Mercator} (UTM) coordinate system\footnote{See e.g.
\url{http://en.wikipedia.org/wiki/Universal_Transverse_Mercator_coordinate_system}}.

There are a few optional arguments that can be added when constructing a data source.
While Section~\ref{sec:ref:DataSource} has a detailed description of all
arguments it is worth noting a few.
Firstly, it is important to know that data slices are assumed to be at altitude
$0$m by default. This can be easily changed though:
\begin{verbatim}
source0=NetCdfData(NetCdfData.GRAVITY, 'GravitySmall.nc',
    altitude=2.5*U.km)
\end{verbatim}
Another important setting is the scale or unit of the measurements.
The default is dependent on the data type and for gravity anomalies a scale
of $\frac{\mu m}{sec^2}$ (or $0.1 \; mgal$) is assumed. For instance to
change the default scale to $mgal$ (which is $10^{-5} \frac{m}{sec^2}$),
you could use:
\begin{verbatim}
source0=NetCdfData(NetCdfData.GRAVITY, 'GravitySmall.nc',
    scale_factor=U.mgal)
\end{verbatim}
Finally, it is possible to specify measurement errors (i.e. uncertainties)
alongside the data.
Since these can never be zero, a value of $2$ units is used if nothing else
has been specified.
The error value is assumed to be given in the same units as the data so the
default value translates to an error of $0.2 \; mgal$.
There are two possibilities to specify the error, namely by providing a
constant value which is applied to all data points:
\begin{verbatim}
source0=NetCdfData(NetCdfData.GRAVITY, 'GravitySmall.nc', error=1.7)
\end{verbatim}
or, if the information is available in the same \netcdf file under the name
\verb|errors|, provide \downunder with the appropriate variable name:
\begin{verbatim}
source0=NetCdfData(NetCdfData.GRAVITY, 'GravitySmall.nc', error="errors")
\end{verbatim}

It is important to keep an eye on the complexity of the inversion.
A good measure is the total number of cells being used.
Assume we have given a data set on a $20 \times 20$ grid and we add lateral
padding of, say, $20 \%$ to each side of the data, the lateral number of cells
becomes $(20\cdot 1.4)\times (20\cdot 1.4)=1.4^2\cdot 20^2\approx 2\cdot 10^2=800$.
If we use $20$ cells in the vertical direction we end up with a total number
of $800 \times 20 = 16,000$ cells.
This size can be easily handled by a modern desktop PC.
If we increase the grid size of the data to $40 \times 40$ points and use $40$
cells in the vertical extent we get a total of $(2\cdot 40^2)\cdot 40=128,000$
cells, a problem size which is considerably larger but can still be handled by
a desktop computer.
Taking this one step further, if the amount of data is increased to
$200\times 200$ points and we use $200$ cells in the vertical extent the
domain will contain $16,000,000$ ($16$ million) cells.
This scenario requires a computer with enough memory and (a) fast processor(s)
to run the inversion.
This estimate of complexity growth applies to the case where the increase
of data grid size is driven by an increase of resolution where it is
recommended to increase the vertical resolution in synch with the lateral
resolution. Note that if more than one data set is used the target resolution
will be the resolution of the finest data set (see also
Section~\ref{SEC:P1:GRAV:REMARK:MULTIDATA}).
In other cases, the expansion of the region of interest drives an increase of
data grid size and the increase of total number of cells is less dramatic as
the vertical number of cells can remain constant while keeping a balanced
resolution in vertical and lateral direction.

\section{Setting up the Inversion and Running it}
We are now at step three of script~\ref{code: gravity1} where the
inversion is set up.
First we create an empty inversion under the name \verb|inv|:
\begin{verbatim}
inv=GravityInversion()
\end{verbatim}
As indicated by the name we can use \verb|inv| to perform an inversion of
gravity data\footnote{\verb|GravityInversion| is a driver with a simplified
interface which is provided for convenience. See Part~\ref{part2} for more
details on how to write inversion scripts with more general functionality, e.g.
constraints.}. The inversion is an iterative process which sequentially
calculates updates to the density distribution in an attempt to improve the
match of the gravity field produced by the density distribution with the data.
Termination of the iteration is controlled by the tolerance which is set by
the user:
\begin{verbatim}
inv.setSolverTolerance(1e-4)
\end{verbatim}
Here we set the tolerance to $10^{-4}$, i.e. the iteration is terminated if
the maximum density correction is less than or equal to $10^{-4}$ relative to
the maximum value of estimated density anomaly.
In case the iteration does not converge a maximum number of iteration steps is
set:
\begin{verbatim}
inv.setSolverMaxIterations(50)
\end{verbatim}
If the maximum number of iteration steps (here $50$) is reached the iteration
process is aborted and an error message is printed.
In this case you can try to rerun the inversion with a larger value for the
maximum number of iteration steps.
If even for a very large number of iteration steps no convergence is achieved,
it is very likely that the inversion has not been set up properly.

The statement
\begin{verbatim}
inv.setup(dom)
\end{verbatim}
links the inversion with the domain and the data.
At this step -- as we are solving a gravity inversion problem -- only
gravitational data attached to the domain builder \verb|dom| are considered.
Internally a cost function $J$ is created which is minimized during the
inversion iteration.
It is a combination of a measure of the data misfit of the gravity field from
the given density distribution and a measure of the smoothness of the density
distribution.
The latter is often called the regularization term.
By default the gradient of density is used as the regularization term, see
also Section~\ref{SEC:P1:GRAV:REMARK:REG}.
Obviously, the result of the inversion is sensitive to the weighting between
the misfit and the regularization.
This trade-off factor $\mu$ for the misfit function is set by the following
statement:
\begin{verbatim}
inv.getCostFunction().setTradeOffFactorsModels(0.1)
\end{verbatim}
Here we set $\mu=0.1$. The statement \verb|inv.setup| must appear in the
script before setting the trade-off factor.
A small value for the trade-off factor $\mu$ will give more emphasis to the
regularization component and create a smoother density distribution.
A large value of the trade-off factor $\mu$ will emphasize the misfit more
and typically creates a better fit to the data and a rougher density
distribution.
It is important to keep in mind that the regularization reduces noise in the
date and in fact gives the problem a unique solution.
Consequently, the trade-off factor $\mu$ may not be chosen too large in order
control the noise on the solution and ensure convergence in the iteration
process.

We can now run the inversion:
\begin{verbatim}
rho = inv.run()
\end{verbatim}
The answer as calculated during the inversion is returned and can be accessed
under the name \verb|rho|.
As pointed out earlier the iteration process may fail in which case the
execution of the script is aborted with an error message.

\section{Taking a Look}
In the final step of script~\ref{code: gravity1} the calculated density
distribution is written to an external file.
A popular file format used by several visualization packages such as
\VisIt~\cite{VISIT} and \mayavi~\cite{mayavi} is the \VTK file format.
The result of the inversion which has been named \verb|rho| can be written to
the file \file{result.vtu} by adding the statement
\begin{verbatim}
saveVTK("result.vtu", density=rho)
\end{verbatim}
at the end of script.
The inversion solution is tagged with the name \verb|density| in the result
file, however any other name for the tag could be used.
As the format is text-based (as opposed to binary) \VTK files tend to be very
large and take compute time to create, in particular when it comes to large
numbers of cells ($>10^6$).
For large problems it is more efficient to use the \SILO file format~\cite{SILO}
preferred by the visualization program \VisIt~\cite{VISIT}.  \SILO files are smaller
and can be generated more quickly than \VTK files.  \VisIt is particularly suited for visualizing
large data sets and can read \SILO files faster than \VTK files.
Inversion results can be directly exported into \SILO files using the statement
\begin{verbatim}
saveSilo("result.silo", density=rho)
\end{verbatim}
replacing the \verb|saveVTK(...)| statement.
Similar to \VTK files the result \verb|rho| is tagged with the name
\verb|density| so it can be identified in the visualization program.

Another useful output option is the \Voxet format which is understood by the
\GOCAD\cite{GOCAD} geologic modelling software.
In order to write inversion results to \Voxet files use the statement
\begin{verbatim}
saveVoxet("result.vo", density=rho)
\end{verbatim}
Unlike the other output formats \Voxet data consists of a header file with the
file extension \verb|.vo| and separate \emph{property} files without file
extension. The call to \verb|saveVoxet(...)| above would produce the files
\file{result.vo} and \file{result_density}.

\begin{figure}
    \begin{center}
        \subfigure[$\mu=0.1$]{%
            \label{FIG:P1:GRAV:10 MU01}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravContourMu01.png}}
        }%
        \subfigure[$\mu=1.$]{%
            \label{FIG:P1:GRAV:10 MU1}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravContourMu1.png}}
        }\\ %  ------- End of the first row ----------------------%
        \subfigure[$\mu=10.$]{%
            \label{FIG:P1:GRAV:10 MU10}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravContourMu10.png}}
        }%
        \subfigure[$\mu=100.$]{%
            \label{FIG:P1:GRAV:10 MU100}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravContourMu100.png}}
        }\\ %  ------- End of the second row ----------------------%
        \subfigure[$\mu=1000.$]{%
            \label{FIG:P1:GRAV:10 MU1000}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravContourMu1000.png}}
        }%
    \end{center}
    \caption{3-D contour plots of gravity inversion results with data from
    Figure~\ref{FIG:P1:GRAV:0} for various values of the model trade-off
    factor $\mu$. Visualization has been performed in \VisIt.}
    \label{FIG:P1:GRAV:10}
\end{figure}

\begin{figure}
    \begin{center}
        \subfigure[$\mu=0.1$]{%
            \label{FIG:P1:GRAV:11 MU01}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravDepthMu01.png}}
        }%
        \subfigure[$\mu=1.$]{%
            \label{FIG:P1:GRAV:11 MU1}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravDepthMu1.png}}
        }\\ %  ------- End of the first row ----------------------%
        \subfigure[$\mu=10.$]{%
            \label{FIG:P1:GRAV:11 MU10}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravDepthMu10.png}}
        }%
        \subfigure[$\mu=100.$]{%
            \label{FIG:P1:GRAV:11 MU100}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravDepthMu100.png}}
        }\\ %  ------- End of the second row ----------------------%
        \subfigure[$\mu=1000.$]{%
            \label{FIG:P1:GRAV:11 MU1000}
            \scalebox{0.95}{\includegraphics[width=0.45\textwidth]{QLDGravDepthMu1000.png}}
        }%
    \end{center}
    \caption{3-D slice plots of gravity inversion results with data from
    Figure~\ref{FIG:P1:GRAV:0} for various values of the model trade-off
    factor $\mu$. Visualization has been performed \VisIt.%
    }
%    \AZADEH{check images.}
    \label{FIG:P1:GRAV:11}
\end{figure}

Figures~\ref{FIG:P1:GRAV:10} and~\ref{FIG:P1:GRAV:11} show two different
styles of visualization generated in \VisIt using the result of the inversion
of the gravity anomalies shown in Figure~\ref{FIG:P1:GRAV:0}.
The inversions have been performed with different values for the model
trade-off factor $\mu$.
The visualization shows clearly the smoothing effect of lower values for the
trade-off factors.
For larger values of the trade-off factor the density distribution becomes
rougher showing larger details.
Computational costs are significantly higher for larger trade-off factors.
Moreover, noise in the data has a higher impact on the result.
Typically several runs are required to adjust the value for the trade-off
factor to the datasets used.

For some analysis tools it is useful to process the results in form of
Comma-separated Values (\CSV)\footnote{see
\url{http://en.wikipedia.org/wiki/Comma-separated_values}}.
Such a file can be created using the statement
\begin{verbatim}
saveDataCSV("result.csv", x=rho.getFunctionSpace().getX(), density=rho)
\end{verbatim}
in the script.
This will create a \file{result.csv} with columns separated by a comma.
Each row contains the value of the density distribution and the three
coordinates of the corresponding location in the domain.
There is a header specifying the meaning of the corresponding column.
Notice that rows are not written in a particular order and therefore, if
necessary, the user has to apply appropriate sorting of the rows.
Columns are written in alphabetic order of their corresponding tag names.
For the interested reader: the statement \verb|rho.getFunctionSpace()| returns
the type used to store the density data \verb|rho|.
The \verb|getX()| method returns the coordinates of the sampling points used
for the particular type of representation, see~\cite{ESCRIPT} for details.

\section{Remarks}

\subsection{ER Mapper Raster Files}\label{SEC:P1:GRAV:REMARK:ERMAPPER}
The \downunder module can read data stored in ER Mapper Raster files. A data
set in this format consists of two files, a header file whose name usually ends
in \verb|.ers| and the actual data file which has the same filename as the
header file but without any file extension.
These files are usually produced by a commercial software package and the
contents can be quite diverse.
Therefore, it is not guaranteed that every data set is supported by \downunder
but the most common types of raster data should work\footnote{If your data
does not load please contact us through \url{https://launchpad.net/escript-finley}.}.

The interface for loading ER Mapper files is very similar to the \netcdf
interface described in Section~\ref{SEC:P1:GRAV:DATA}.
To load gravity data stored in the file pair\footnote{These files are available
in the example directory.} \examplefile{GravitySmall.ers} (the
header) and \examplefile{GravitySmall} (the data) without changing any of the
defaults use:
\begin{verbatim}
source0=ErMapperData(ErMapperData.GRAVITY, 'GravitySmall.ers')
\end{verbatim}
If your data set does not follow the default naming convention you can specify
the name of the data file explicitly:
\begin{verbatim}
source0=ErMapperData(ErMapperData.GRAVITY, 'GravitySmall.ers',
                     datafile='GravityData')
\end{verbatim}
Please note that there is no way for the reader to determine if the two files
really form a pair so make sure to pass the correct filenames when constructing
the reader object.
The same optional arguments explained in sections \ref{SEC:P1:GRAV:DATA} and
\ref{SEC:P1:GRAV:REMARK:DATAHOLES} are available for ER Mapper data sets.
However, due to the limitation of the file format only a constant error value
is supported.

\subsection{Data With Holes}\label{SEC:P1:GRAV:REMARK:DATAHOLES}
As described previously in this chapter, input data is always given in the form
of a rectangular grid with constant cell size in each dimension.
However, there are cases when this is not necessarily the case.
Consider an onshore data set which includes parts of the offshore region as in
Figure~\ref{FIG:P1:GRAV:onshoreoffshore}.
The valid data in this example has a value range of about $-600$ to $600$ and
the inversion is to be run based on these values only, disregarding the
offshore region.
In order to achieve that, the offshore region is \emph{masked} by using a
constant value which is not found within the onshore area.
Figure~\ref{FIG:P1:GRAV:onshoreoffshore} clearly shows this masked area in
dark blue since a mask value of $-1000$ was used.

\begin{figure}[ht]
    \centering
    \includegraphics[width=0.45\textwidth]{onshore-offshore.png}
    \caption{Plot of a rectangular gridded onshore data set that includes
    offshore regions which have a value (here $-1000$) not found within the
    real data (Bouguer anomalies in Tasmania, courtesy Geoscience Australia)}
    \label{FIG:P1:GRAV:onshoreoffshore}
\end{figure}

The \netcdf conventions supported in \downunder include a standard way of
specifying such a mask value.
The example script \examplefile{create_netcdf.py} demonstrates how this is
accomplished in an easy way with any data.
If, for any reason, the mask value in the input file is invalid it can be
overridden via the \verb|null_value| argument when constructing the
\verb|NetCdfData| object:
\begin{verbatim}
source0=NetCdfData(NetCdfData.GRAVITY, 'data0.nc', null_value=-1000)
\end{verbatim}
In this example, all data points that have a value of $-1000$ are ignored and
not used in the inversion.
Please note that the special value \emph{NaN} (not-a-number) is sometimes used
for the purposes of masking in data sets.
Areas marked with this value are always disregarded in \downunder.

\subsection{Multiple Data Sets}\label{SEC:P1:GRAV:REMARK:MULTIDATA}
It is possible to run a single inversion using more than one input data set,
possibly in different file formats.
To do so, simply create the data sources and add them to the domain builder:
\begin{verbatim}
source0=NetCdfData(NetCdfData.GRAVITY, 'data0.nc')
source1=ErMapperData(ErMapperData.GRAVITY, 'data1.ers')
dom.addSource(source0)
dom.addSource(source1)
\end{verbatim}
However, there are some restrictions when combining data sets:
\begin{itemize}
    \item Due to the coordinate transformation all data sets must be located in
        the same UTM zone. If a single dataset crosses UTM zones only the zone
        of the central longitude is used when projecting.
        For example, if one data set lies mostly in zone 51 but contains areas
        of zone 52, it is transformed using zone 51. In this case more data
        from zone 51 can be added, but not from any other zone.
    \item All data sets should have the same spatial resolution but this is not
        enforced. Combining data with different resolution is currently
        considered experimental but works best when the resolutions are
        multiples of each other. For example if the first data set has a
        resolution (or cell size) of $100$ metres and the second has a cell
        size of $50$ metres then the target domain will have a cell size of
        $50$ metres (the finer resolution) and each point of the coarse data
        will occupy two cells (in the respective dimension).
\end{itemize}

\subsection{Regularization Term}\label{SEC:P1:GRAV:REMARK:REG}
The \verb|GravityInversion| class supports the following form for the
regularization:
\begin{equation}
\int w^{(0)} \cdot \rho^2 + w^{(1)}_0  \rho_{,0}^2 +  w^{(1)}_1  \rho_{,1}^2 +  w^{(1)}_2  \rho_{,2}^2\; dx
\end{equation}
where the integral is calculated across the entire domain.  %In vector notation, this is
%\begin{equation}
%\int w^{(0)} \cdot \rho^2 + {w}\nabla  \rho\cdot \nabla \rho \; dx
%\end{equation}
$\rho$ represents the density distribution where $\rho_{,0}$ $\rho_{,1}$ and
$\rho_{,2}$ are the spatial derivatives of $\rho$ with respect to the two
lateral and vertical directions, respectively.
$w^{(0)}$, $w^{(1)}_0$, $w^{(1)}_1$ and $w^{(1)}_2$ are weighting
factors\footnote{A more general form, e.g. spatially variable values for the
weighting factors, is supported, see Part~\ref{part2}}.
By default these are $w^{(0)}=0$, $w^{(1)}_0=w^{(1)}_1=w^{(1)}_2=1$.
Other weighting factors can be set in the inversion set-up.
For instance to set $w^{(0)}=10$, $w^{(1)}_0=w^{(1)}_1=0$ and $w^{(1)}_2=100$
use the statement:
\begin{verbatim}
inv.setup(dom, w0=10, w1=[0,0,100])
\end{verbatim}
It is pointed out that the weighting factors are rescaled in order to improve
numerical stability. Therefore the relative size of the weighting factors is
relevant and using
\begin{verbatim}
inv.setup(dom, w0=0.1, w1=[0,0,1])
\end{verbatim}
would lead to the same regularization as the statement above.


% \documentclass[final,3p,times,twocolumn]{elsarticle}
\documentclass[final,3p,times]{elsarticle}
\usepackage[american]{babel}
\usepackage[font=normal]{caption}
\usepackage[font=normal]{subcaption}
\usepackage[tensorialbold]{userCommands}
\usepackage{mathtools,cuted}
\usepackage{empheq}
\usepackage{tikz} % geometrical figures
\usetikzlibrary{calc,trees,positioning,arrows,chains,shapes.geometric,decorations.pathreplacing,decorations.pathmorphing,shapes,
    matrix,shapes.symbols,shapes.multipart,patterns,shapes,snakes,pgfplots.groupplots,spy,backgrounds}
\usetikzlibrary{external}
\tikzexternalize[prefix=external/]
\usetikzlibrary{spy,backgrounds}
\usetikzlibrary{decorations.markings}
\usetikzlibrary{arrows.meta}
\tikzset{
  arrows along my path/.style={
    postaction={
      decorate,
      decoration={
        markings,
        mark=between positions 0.03 and 1 step 24pt with {\arrow{Stealth[length=8pt]}},
   }}}}

\usepackage{pgfplots} % pdf picture declaration

\usepackage{array}
\newcolumntype{M}[1]{>{\centering\arraybackslash}m{#1}}
\newcolumntype{N}{@{}m{0pt}@{}}

%% The amssymb package provides various useful mathematical symbols
\usepackage{amssymb}
\usepackage{lineno}
\usepackage{float}
% \linenumbers

\usepackage{float}

\usepackage{mathtools}
\mathtoolsset{showonlyrefs}

%\journal{Journal of the Mechanics and Physics of Solids}
\journal{}

\pgfplotsset{%compat=1.3,
  %compat=1.8,
  compat=newest,
  grid=both,
  tick label style={font=\normalsize},
  label style={font=\normalsize},
  legend style={font=\normalsize},
  legend cell align={left},
  yticklabel style={/pgf/number format/fixed},
  %scaled y ticks=false,
  % define user colormap
  colormap={tol}{[1cm] rgb255(0cm)=(120,28,129) rgb255(1cm)=(63,96,174) rgb255(2cm)=(83,158,182) rgb255(3cm)=(109,179,136) rgb255(4cm)=(202,184,67) rgb255(5cm)=(231,133,50) rgb255(6cm)=(217,33,32)}
}

\definecolor{Purple}{RGB}{120,28,129}
\definecolor{Orange}{RGB}{231,133,50}
\definecolor{Blue}{RGB}{63,96,174}
\definecolor{Red}{RGB}{217,33,32}
\definecolor{Duck}{RGB}{83,158,182}
\definecolor{Green}{RGB}{109,179,136}
\definecolor{Yellow}{RGB}{202,184,67}

\newcommand{\review}[1]{\color{Red}#1\color{black}}

\newtheorem{remark}{Remark}
\newtheorem{property}{Property}

\begin{document}

\begin{frontmatter}

  %% Title, authors and addresses

  %% use the tnoteref command within \title for footnotes;
  %% use the tnotetext command for theassociated footnote;
  %% use the fnref command within \author or \address for footnotes;
  %% use the fntext command for theassociated footnote;
  %% use the corref command within \author for corresponding author footnotes;
  %% use the cortext command for theassociated footnote;
  %% use the ead command for the email address,
  %% and the form \ead[url] for the home page:
  %% \title{Title\tnoteref{label1}}
  %% \tnotetext[label1]{}
  %% \author{Name\corref{cor1}\fnref{label2}}
  %% \ead{email address}
  %% \ead[url]{home page}
  %% \fntext[label2]{}
  %% \cortext[cor1]{}
  %% \address{Address\fnref{label3}}
  %% \fntext[label3]{}

  %\title{A unified framework for simple wave solutions in two-dimensional elastic-plastic solids}
  \title{On loading paths followed inside plastic simple waves in two-dimensional elastic-plastic solids}

  %% use optional labels to link authors explicitly to addresses:
  %% \author[label1,label2]{}
  %% \address[label1]{}
  %% \address[label2]{}

  \author{Adrien Renaud$^{1,2}$, Thomas Heuz{\'e}$^2$, Laurent Stainier$^2$}
  \address{$^1$ Laboratory MSSMat (UMR 8579 CNRS)\\
    CentraleSup{\'e}lec, Universit{\'e} Paris-Saclay\\
    8-10 rue Joliot-Curie, 91190 Gif-sur-Yvette\\
    e-mail: adrien.renaud@centralesupelec.fr }

  \address{$^2$ Research Institute in Civil and Mechanical Engineering (GeM, UMR 6183 CNRS)\\
    Ecole Centrale de Nantes \\
    1 rue de la No\"e, Nantes\\
    e-mail: \{thomas.heuze,laurent.stainier\}@ec-nantes.fr}

  \begin{abstract}
    Although the solution of hyperbolic partial differential equations in elastic-plastic media is of major importance in solid mechanics, the mathematical complexity of such problems increases with the space dimensionality.
    As a result, the development of analytical solutions is in general not possible.
    % Whereas the wave structure arising in one-dimensional problems is known and well understood, several gaps still need to be filled for problems with more space dimensions.
    Whereas the wave structure resulting from given external loads is known and well understood for one-dimensional problems, several gaps still need to be filled for problems with more space dimensions.
    Indeed, the literature related to the propagation of simple waves in elastic-plastic solids is rather sparse since only particular two-dimensional and three-dimensional problems have been considered.
    Following the general three-dimensional framework of \textsc{Mandel} (1962), the object of the paper is to construct the loading paths followed inside the simple waves under plane strain and plane stress conditions.
    It is believed that the mathematical and numerical studies of the waves presented here could help %(i) relate the boundary conditions of the Picard problem to the wave pattern; (ii)
    define the characteristic structure involved in a Riemann problem. % so that the latter can be solved.
    % The object of the paper is first to derive a unified framework for the study of the propagation of waves in elastic-plastic media that gathers configurations already investigated as well as other ones not treated so far.
    % A generic three-dimensional formulation of hyperbolic problems in these solids, which can be easily specialized to plane strain and plane stress problems, is then proposed in the linearized geometrical framework.
    % This work focuses on simple waves arising in the solution in two space dimensions.
    % Mathematical as well as numerical studies of these waves under plane strain and plane stress conditions are next carried out in order to emphasize typical loading paths followed and hence, characteristic physical responses.
  \end{abstract}

  \begin{keyword}
    Hyperbolic problems; Elastic-plastic solids; Simple waves; Loading paths; Characteristic analysis.
  \end{keyword}

\end{frontmatter}

\section{Introduction}
\label{sec:introduction}
\input{introduction}

\section{Hyperbolic system in elastic-plastic media}
\label{sec:charac_plast}
\input{characteristic_analysis}

\section{The eigen-value problem in two space dimensions}
\label{sec:2dproblem}
\input{2dFormulation}

\section{Integral curves for two-dimensional problems}
\label{sec:integral_curves}
\input{integral_curves}

% \section{Loading paths through simple waves}

\section{Some properties of the loading paths for several cases}
\label{sec:stress_paths}
\input{analytical_results}

% should we talk about lin & ballman after the numerical results about the thin-walled tube?
\section{Numerical integration of stress paths}
\label{sec:numerical_results}
\input{numerical_results}

\section{Conclusion}
\label{sec:conclusion}
\input{conclusion}

\section*{References}
\bibliographystyle{elsarticle-num}
\bibliography{Biblio}

\end{document}
\endinput
%%% Local Variables:
%%% mode: latex
%%% TeX-master: t
%%% End:


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\chapter{Background}
\label{chap:Background}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

This chapter sets the stage for type systems in later chapters. \Cref{sec:HM}
reviews the Hindley-Milner type system \citep{Damas:Milner,hindley,milner}, a
classical type system for the lambda calculus with parametric polymorphism.
\Cref{sec:OL} presents the Odersky-L{\"a}ufer type system
\citep{odersky:putting}, which extends upon the Hindley-Milner type system by
putting higher-rank type annotations to work. Finally in \Cref{sec:DK} we
introduce the Dunfield-Krishnaswami type system, a bidirecitonal higher-rank
type system. Here we pay particular attention to the Dunfield-Krishnaswami
system as it serves as a basis for extensions in later chapters; for example,
\Cref{chap:Gradual} is a direct extension of Dunfield-Krishnaswami. There is
plenty of other related work to higher-rank type system (e.g.,
\cite{practical:inference}), and we include a more substantive discussion of
those works in \Cref{chap:related}.

\input{Gen/Background/HM}
\input{Gen/Background/OL}
\input{Gen/Background/DK}

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "../Thesis"
%%% org-ref-default-bibliography: "../Thesis.bib"
%%% End:


\chapter{Bayes minimum risk}\label{ch:6}

\begin{remark}{Outline}
In this chapter, we propose the cost-sensitive Bayes minimum risk classifier. The method
consists in quantifying tradeoffs between various decisions using probabilities and the costs that
accompany such decisions. First, in Section~\ref{sec:6:bmr}, we present the Bayes minimum risk
algorithm. Then, in Section~\ref{sec:6:prob}, we discuss the impact of calibrating the probabilities
in the model. Finally, in Section~\ref{sec:6:experiments},  using the five real-world cost-sensitive
databases, we compare the results of the proposed algorithm, against state-of-the-art methods.
\end{remark}

\section{Bayes minimum risk model}
\label{sec:6:bmr}

% % As decribed in Section \ref{sec:3:cs}, state-of-the-art example dependent techniques, only
% introduce the cost by modifying the training set. In \citep{CorreaBahnsen2013,CorreaBahnsen2014},
% we proposed a cost-sensitive model called Bayes minimum risk classifier ($BMR$).

As defined in \citep{Ghosh2006}, the BMR classifier is a decision model based on quantifying
tradeoffs between various decisions using probabilities and the costs that accompany such decisions.
This is done in a way that for each example the expected losses are minimized. In  what follows, we
consider the probability estimates $\hat p_i$ as known, regardless of the algorithm used to
calculate them.  The risk that accompanies each decision is calculated using the cost matrix
as described in \tablename{ \ref{tab:3:cost_matrix}}. In the specific framework of binary
classification, the risk of predicting the example $i$ as negative is
\begin{equation}
  R(c_i=0|\mathbf{x}_i)=C_{TN_i}(1-\hat p_i)+C_{FN_i} \cdot \hat p_i,
\end{equation}
and
\begin{equation}
  R(c_i=1|\mathbf{x}_i)=C_{TP_i} \cdot \hat p_i + C_{FP_i}(1- \hat p_i),
\end{equation}
is the risk when predicting the example as positive, where $\hat p_i$ is the estimated positive
probability for example $i$. Subsequently, if
\begin{equation}
  R(c_i=0|\mathbf{x}_i) \le R(c_i=1|\mathbf{x}_i),
\end{equation}
then  the example $i$ is classified as negative. This means that the risk associated with the
decision $c_i$ is lower than the risk associated with classifying it as positive.

\section{Calibration of probabilities}
\label{sec:6:prob}

When using the output of a binary classifier as a basis for decision making, there is a
need for a probability that not only separates well between positive and negative examples, but
that also assesses the real probability of the event \citep{cohen2004}.

In this section, two methods for calibrating probabilities are explained. First, the method proposed
in \citep{Elkan2001} to adjust the probabilities based on the   difference in bad rates  between the
training and testing datasets.  Then, the method proposed in \cite{Hernandez-Orallo2012}, in which
calibrated probabilities are extracted after modifying the ROC curve using the ROC convex hull
methodology, is described.

\subsection{Calibration due to a change in base rates}

One of the reasons why a probability may not be calibrated is because the algorithm is trained
using a dataset with a different base (or positive) rate than the one on the evaluation dataset.
This is something common in machine learning since using under-sampling or over-sampling is a
typical method to solve problems such as class imbalance and cost sensitivity \citep{Hulse2007}.

In order to solve this and find probabilities that are calibrated, in \citep{Elkan2001} a formula
that corrects the probabilities based on the difference of the base rates is proposed.  The
objective is using $\hat p$ which was estimated using a population with base rate $\pi_1$,
to find $\hat p'$ for the real population which has a base rate $\pi_1'$. A solution for $\hat p'$
is given as follows:
\begin{equation}
  \hat p'=\pi_1' \frac{\hat p - \hat p \pi_1}{\pi_1- \pi_1 \hat p +\pi_1' \hat p - \pi_1 \pi_1'}.
\end{equation}

% Nevertheless, a strong assumption is made by taking: $P'(x|j=1)=P(x|j=1)$} and
% \mbox{$P'(x|j=0)=P(x|j=0)$}, meaning that there
%   is no change in the example probability within the positive and negative
%   subpopulations density functions.

\subsection{Calibration using the ROC convex hull}

In order to illustrate the ROC convex hull approach proposed in \citep{Hernandez-Orallo2012},
let us consider the set of probabilities given in \figurename{~\ref{tab:6:example_prob}}.
Their corresponding  ROC curve  is shown in \figurename{~\ref{fig:6:ROC_1}}.  It can be seen that
this set of probabilities is not calibrated, since when $fpr=0.1$ there is a positive example
followed by 2 negative examples. This inconsistency is represented in the ROC curve as a non convex
segment  over the curve.

\begin{figure}[!t]
\hskip 1cm
\hbox{
  \vtop{
    \hbox{
      \subfloat[Set of probabilities and their respective class label]{
   \footnotesize
	\begin{tabular}{cc}
	\hline
	Probability & Label\\
	\hline
	0.0&	0\\
	0.1&	1\\
	0.2&	0\\
	0.3&	0\\
	0.4&	1\\
	0.5&	0\\
	0.6&	1\\
	0.7&	1\\
	0.8&	0\\
	0.9&	1\\
	1.0&	1\\
	\hline
	\end{tabular}\label{tab:6:example_prob}
      }
    }
  }\hskip 1.5cm
  \vtop{\vskip -2.5cm
    \subfloat[ROC curve of the set of probabilities]{
      \includegraphics[scale=0.5]{ch6_fig2}\label{fig:6:ROC_1}
    }%
  }%
}
\vskip 1.5cm

\hbox{
  \vtop{ \vskip -0.5cm
    \hbox{
      \subfloat[Convex hull of the ROC curve]{
	\includegraphics[scale=0.5]{ch6_fig1}\label{fig:6:ROC_2}
      }
    }
  }\hskip 1.75cm
  \vtop{ \vskip -1cm
    \subfloat[Calibrated probabilities]{
   \footnotesize
	\begin{tabular}{cc}
	\hline
	Prob & Cal Prob\\
	\hline
	0.0&	0\\
	0.1&	0.333\\
	0.2&	0.333\\
	0.3&	0.333\\
	0.4&	0.5\\
	0.5&	0.5\\
	0.6&	0.666\\
	0.7&	0.666\\
	0.8&	0.666\\
	0.9&	1\\
	1.0&	1\\
	\hline
	\end{tabular}\label{fig:6:cal_prob}
    }
  }
}
\caption{Estimation of calibrated probabilities using the ROC convex hull.}\label{fig:6:rocch}
\end{figure}

In order to obtain a set of calibrated probabilities, first the ROC curve must be modified in
order to be convex. The way to do that, is to find the convex \mbox{hull
\citep{Hernandez-Orallo2012}} to find the minimal convex set containing the different
points of the ROC curve. In \figurename{~\ref{fig:6:ROC_2}}, the convex hull algorithm is applied
to the previously evaluated ROC curve shown in \figurename{~\ref{fig:6:ROC_1}}. It is shown that
the new curve is convex, and includes all the points of the previous ROC curve.

Now that there is a new convex ROC curve or ROCCH, the calibrated probabilities can be extracted
as shown in  \figurename{~\ref{fig:6:cal_prob}}. The procedure to extract the new probabilities is
to first group the probabilities according to the points in the ROCCH curve, and then make the
calibrated  probabilities be the slope of the ROCCH for each group.

\section{Experiments}
\label{sec:6:experiments}

For the experiments we use five datasets from four different real world example-dependent
cost-sensitive problems: Credit card fraud detection (see Section~\ref{sec:4:fraud}), credit
scoring (see Section~\ref{sec:4:creditscoring}), churn modeling (see Section~\ref{sec:5:churn}) and
direct marketing (see Section~\ref{sec:5:directmarketing}). The different datasets are summarized
in \tablename{~\ref{tab:4:databases}} and \tablename{~\ref{tab:5:databases}}.

For the experiments, we first used three classification algorithms, decision tree ($DT$), logistic
  regression ($LR$) and random forest ($RF$). Using the implementation of \textit{Scikit-learn}
  \citep{Pedregosa2011}, each algorithm is trained using the different training sets: training
  ($t$), under-sampling ($u$), cost-proportionate rejection-sampling  ($r$) \citep{Zadrozny2003}
  and   cost-proportionate over-sampling ($o$) \citep{Elkan2001}. Afterwards,  we evaluate the
  results of  the algorithms using $BMR$ methods. In particular, we   check the impact on the
  results of the different calibration methods. The implementation of the cost-sensitive algorithms
  is done using the \textit{CostCla} library, see Appendix~\ref{ch:A}.

  \begin{table}
    \centering
    \footnotesize
    %\hspace{-3.5cm}
    \rotatebox{90}{
    \begin{tabular}{l l r@{\hskip 0in}c@{\hskip 0in}l r@{\hskip 0in}c@{\hskip 0in}l r@{\hskip
    0in}c@{\hskip 0in}l  r@{\hskip 0in}c@{\hskip 0in}l r@{\hskip 0in}c@{\hskip 0in}l} %sum 7.7
    \hline
    \bf{Family} & \bf{Algorithm} & \multicolumn{3}{c}{\bf{Fraud}} &
    \multicolumn{3}{c}{\bf{Churn}} & \multicolumn{3}{c}{\bf{Credit 1}}
    &  \multicolumn{3}{c}{\bf{Credit 2}} & \multicolumn{3}{c}{\bf{Marketing}} \\
    \hline
CI&DT-t & 0.3176 &$\pm$& 0.0357 & -0.0018 &$\pm$& 0.0194 & 0.1931 &$\pm$& 0.0087& -0.0616 &$\pm$& 0.0229 & -0.2342 &$\pm$& 0.0609\\
&LR-t & 0.0092 &$\pm$& 0.0002 & -0.0001 &$\pm$& 0.0002 & 0.0177 &$\pm$& 0.0126& 0.0039 &$\pm$& 0.0012 & -0.2931 &$\pm$& 0.0602\\
&RF-t & 0.3342 &$\pm$& 0.0156 & -0.0026 &$\pm$& 0.0079 & 0.1471 &$\pm$& 0.0071 & 0.0303 &$\pm$& 0.0040 & -0.2569 &$\pm$& 0.0637\\
&DT-u & 0.5239 &$\pm$& 0.0118 & -0.0389 &$\pm$& 0.0583 & 0.3287 &$\pm$& 0.0125 & -0.1893 &$\pm$& 0.0314 & -0.0278 &$\pm$& 0.0475\\
&LR-u & 0.1243 &$\pm$& 0.0387 & 0.0039 &$\pm$& 0.0492 & 0.4118 &$\pm$& 0.0313 & 0.1850 &$\pm$& 0.0231 & 0.2200 &$\pm$& 0.0376\\
&RF-u & 0.5684 &$\pm$& 0.0097 & 0.0433 &$\pm$& 0.0533 & 0.4981 &$\pm$& 0.0079 & 0.1237 &$\pm$& 0.0228 & 0.1227 &$\pm$& 0.0443\\
\hline
CPS&DT-r & 0.3439 &$\pm$& 0.0453 & 0.0054 &$\pm$& 0.0568 & 0.3310 &$\pm$& 0.0126 & 0.0724 &$\pm$& 0.0212 & 0.1960 &$\pm$& 0.0527\\
&LR-r & 0.3077 &$\pm$& 0.0301 & 0.0484 &$\pm$& 0.0375 & 0.3965 &$\pm$& 0.0263& 0.2650 &$\pm$& 0.0115 & 0.4210 &$\pm$& 0.0267\\
&RF-r & 0.3812 &$\pm$& 0.0264 & 0.1056 &$\pm$& 0.0412 & \bf{0.4989} &\bf{$\pm$}& \bf{0.0080}& 0.3055 &$\pm$& 0.0106 & 0.3840 &$\pm$& 0.0360\\
&DT-o & 0.3172 &$\pm$& 0.0274 & 0.0251 &$\pm$& 0.0195 & 0.1738 &$\pm$& 0.0092 & 0.0918 &$\pm$& 0.0225 & -0.2598 &$\pm$& 0.0559\\
&LR-o & 0.2793 &$\pm$& 0.0185 & 0.0316 &$\pm$& 0.0228 & 0.3301 &$\pm$& 0.0109 & 0.2554 &$\pm$& 0.0090 & 0.3129 &$\pm$& 0.0277\\
&RF-o & 0.3612 &$\pm$& 0.0295 & 0.0205 &$\pm$& 0.0156 & 0.2128 &$\pm$& 0.0081& 0.2242 &$\pm$& 0.0070 & -0.1782 &$\pm$& 0.0618\\
\hline
BMR&DT-t-BMR & 0.6045 &$\pm$& 0.0386 & 0.0226 &$\pm$& 0.0200 & 0.1931 &$\pm$& 0.0087 & -0.0616 &$\pm$& 0.0230 & -0.2185 &$\pm$& 0.0611\\
&LR-t-BMR & 0.4552 &$\pm$& 0.0203 & 0.0872 &$\pm$& 0.0308 & 0.1973 &$\pm$& 0.0404 & 0.3119 &$\pm$& 0.0089 & 0.4915 &$\pm$& 0.0090\\
&RF-t-BMR & 0.6175 &$\pm$& 0.0149 & 0.0435 &$\pm$& 0.0356 & 0.4878 &$\pm$& 0.0082 & 0.3027 &$\pm$& 0.0096 & 0.3722 &$\pm$& 0.0263\\
\hline
CAL&DT-t-BMR-cal & 0.5936 &$\pm$& 0.0386 & 0.0298 &$\pm$& 0.0145 & 0.1054 &$\pm$& 0.0358& 0.2740 &$\pm$& 0.0067 & 0.4598 &$\pm$& 0.0089\\
BMR&LR-t-BMR-cal & 0.0897 &$\pm$& 0.0203 & \bf{0.1082} &\bf{$\pm$}& \bf{0.0316} & 0.2189 &$\pm$&
0.0541 & \bf{0.3148} &\bf{$\pm$}& \bf{0.0094} & \bf{0.4973} &\bf{$\pm$}& \bf{0.0084}\\
&RF-t-BMR-cal & \bf{0.6414} &\bf{$\pm$}& \bf{0.0154} & 0.0856 &$\pm$& 0.0354 & 0.4924 &$\pm$&
0.0087 & 0.3133 &$\pm$& 0.0094 & 0.4807 &$\pm$& 0.0093\\
\hline
  \multicolumn{17}{c}{(Models with the highest savings are marked in bold)}
  \end{tabular}
  }
    \caption{Results of the algorithms measured by savings}
    \label{tab:6:results_savings}
  \end{table}

The results are shown in \tablename{ \ref{tab:6:results_savings}}. First, when observing  the
results of the cost-insensitive methods ($CI$), that is, $DT$, $LR$ and $RF$ algorithms trained
on the $t$ and $u$ sets, the $RF$ algorithm produces the best result by savings in three out of
the five sets, followed by the $LR-u$. It is also clear that the results on the $t$ dataset are
not as good as the ones on the $u$ dataset, this is highly related to the unbalanced distribution
of the positives and negatives in all the databases.

In the case of cost-proportionate sampling methods ($CPS$), specifically the
cost-proportionate rejection sampling ($r$) and cost-proportionate over
sampling ($o$), it is observed that in four cases the savings increase quite
significantly. It is on the fraud detection database where these methods do not outperform the
algorithms trained on the under-sampled set. This may be related to the fact that in this
database the initial percentage of positives is 1.5\% which is similar to the percentage in the
$r$ and   $o$ sets. However, it is 50.42\% in the $u$ set, which may help explain why this method
performs much better as measured by savings.

\begin{figure}[!t]
  \centering
  \includegraphics{ch6_fig3}
  \caption{\textbf{Comparison of the average savings of the algorithms versus the
    highest savings by family of classifiers.} When the probabilities are calibrated there is a
    significant increase in savings.}
  \label{fig:6:comparison_family}
  \vspace{1cm}
\end{figure}

  \begin{table}[!t]
    \centering
    \footnotesize
    \rotatebox{90}{
    \begin{tabular}{l l r@{\hskip 0in}c@{\hskip 0in}l r@{\hskip 0in}c@{\hskip 0in}l r@{\hskip
    0in}c@{\hskip 0in}l  r@{\hskip 0in}c@{\hskip 0in}l r@{\hskip 0in}c@{\hskip 0in}l} %sum 7.7
    \hline
    \bf{Family} & \bf{Algorithm} & \multicolumn{3}{c}{\bf{Fraud}} &
    \multicolumn{3}{c}{\bf{Churn}} & \multicolumn{3}{c}{\bf{Credit 1}}
    &  \multicolumn{3}{c}{\bf{Credit 2}} & \multicolumn{3}{c}{\bf{Marketing}} \\
    \hline
CI&DT-t & 0.0134 &$\pm$& 0.0005 & 0.0932 &$\pm$& 0.0054 & 0.1054 &$\pm$& 0.0016& 0.3103 &$\pm$& 0.0041 & 0.1924 &$\pm$& 0.0035\\
&LR-t & 0.0440 &$\pm$& 0.0008 & 0.0449 &$\pm$& 0.0025 & 0.0598 &$\pm$& 0.0016& 0.1511 &$\pm$& 0.0016 & 0.0960 &$\pm$& 0.0018\\
&RF-t & 0.0064 &$\pm$& 0.0002 & 0.0532 &$\pm$& 0.0027 & 0.0519 &$\pm$& 0.0007 & 0.1525 &$\pm$& 0.0016 & 0.1090 &$\pm$& 0.0018\\
&DT-u & 0.1424 &$\pm$& 0.0071 & 0.4152 &$\pm$& 0.0205 & 0.3141 &$\pm$& 0.0052& 0.4526 &$\pm$& 0.0057 & 0.4125 &$\pm$& 0.0062\\
&LR-u & 0.1872 &$\pm$& 0.0195 & 0.2439 &$\pm$& 0.0139 & 0.1718 &$\pm$& 0.0088 & 0.2317 &$\pm$& 0.0017 & 0.2016 &$\pm$& 0.0027\\
&RF-u & 0.0724 &$\pm$& 0.0007 & 0.2442 &$\pm$& 0.0134 & 0.1565 &$\pm$& 0.0019& 0.2325 &$\pm$& 0.0024 & 0.2256 &$\pm$& 0.0036\\
\hline
CPS&DT-r & 0.2041 &$\pm$& 0.0111 & 0.3595 &$\pm$& 0.0185 & 0.2884 &$\pm$& 0.0054 & 0.5516 &$\pm$& 0.0070 & 0.3581 &$\pm$& 0.0111\\
&LR-r & 0.1726 &$\pm$& 0.0098 & 0.1906 &$\pm$& 0.0112 & 0.1448 &$\pm$& 0.0063& 0.2657 &$\pm$& 0.0051 & 0.2029 &$\pm$& 0.0055\\
&RF-r & 0.1764 &$\pm$& 0.0127 & 0.1964 &$\pm$& 0.0101 & 0.1374 &$\pm$& 0.0028& 0.3613 &$\pm$& 0.0055 & 0.2123 &$\pm$& 0.0054\\
&DT-o & 0.1264 &$\pm$& 0.0102 & 0.0963 &$\pm$& 0.0048 & 0.1020 &$\pm$& 0.0014& 0.4550 &$\pm$& 0.0039 & 0.1904 &$\pm$& 0.0028\\
&LR-o & 0.2158 &$\pm$& 0.0098 & 0.1136 &$\pm$& 0.0025 & 0.1134 &$\pm$& 0.0014& 0.2258 &$\pm$& 0.0023 & 0.1517 &$\pm$& 0.0013\\
&RF-o & 0.1694 &$\pm$& 0.0146 & 0.0701 &$\pm$& 0.0031 & 0.0550 &$\pm$& 0.0008& 0.3283 &$\pm$& 0.0030 & 0.1190 &$\pm$& 0.0016\\
\hline
BMR&DT-t-BMR & 0.0134 &$\pm$& 0.0005 & 0.0932 &$\pm$& 0.0054 & 0.1054 &$\pm$& 0.0016 & 0.3103 &$\pm$& 0.0041 & 0.1924 &$\pm$& 0.0035\\
&LR-t-BMR & 0.0440 &$\pm$& 0.0008 & 0.0449 &$\pm$& 0.0025 & 0.0598 &$\pm$& 0.0016& 0.1511 &$\pm$& 0.0016 & 0.0960 &$\pm$& 0.0018\\
&RF-t-BMR & 0.0064 &$\pm$& 0.0002 & 0.0532 &$\pm$& 0.0027 & 0.0519 &$\pm$& 0.0007 & 0.1525 &$\pm$& 0.0016 & 0.1090 &$\pm$& 0.0018\\
\hline
CAL&DT-t-BMR-cal & 0.0098 &$\pm$& 0.0004 & 0.0448 &$\pm$& 0.0029 & 0.0604 &$\pm$& 0.0009& 0.1586 &$\pm$& 0.0019 & 0.1075 &$\pm$& 0.0017\\
BMR&LR-t-BMR-cal & 0.0148 &$\pm$& 0.0007 & \bf{0.0444} &\bf{$\pm$}& \bf{0.0025} & 0.0590 &$\pm$&
0.0018& \bf{0.1505} &\bf{$\pm$}& \bf{0.0016} & \bf{0.0952} &\bf{$\pm$}& \bf{0.0017}\\
&RF-t-BMR-cal & \bf{0.0058} &\bf{$\pm$}& \bf{0.0003} & 0.0446 &$\pm$& 0.0026 & \bf{0.0514}
&\bf{$\pm$}& \bf{0.0008}& 0.1510 &$\pm$& 0.0016 & 0.0999 &$\pm$& 0.0019\\
\hline
  \multicolumn{17}{c}{(Models with the lowest Brier score are marked as bold)}
  \end{tabular}
 }
    \caption{Results of the algorithms measured by Brier score}
    \label{tab:6:results_brier}
\end{table}

Afterwards, in the case of the $BMR$ algorithms, the results show that this method outperforms
the previous ones in four cases and has almost the same result in the other set. In the fraud
detection  set, the results are better, since the savings of the three classification
algorithms increase when using this methodology. Moreover, we found that by calibrating the
probabilities, the results of the Bayes minimum risk increase. In
\figurename{~\ref{fig:6:comparison_family}}, we compare the different families of algorithms, by
calculating in each dataset the performance of the methods compared with the best method. First, it
is shown the huge difference of using only cost-insensitive methods, compared with any of the
cost-sensitive families. Furthermore, the Bayes minimum risk methods outperforms the
cost-proportionate sampling methods.

Moreover, we evaluate the Brier score of the different algorithms. The objective of this, is
because as mention in  \citep{cohen2004}, when using the output of a binary classifier as a basis
for decision making, there is a need for a probability that not only separates well between
positive
and negative examples, but that also assesses the real probability of the event. The results are
shown in \tablename{~\ref{tab:6:results_brier}}. First of all, as expected, the logistic regression
models are very well calibrated regardless of the dataset used for train them. This is because, the
logistic regression algorithm is intended to estimate the most reliable probabilities as we will
discuss in \chaptername{~\ref{ch:7}}.

When comparing the results of the Bayes minimum risk with and without calibration, it is clear that
the calibration of the probabilities lead to a lower Brier score as shown in
\figurename{~\ref{fig:6:comparison_family_brier}}. Interestingly, the results of Brier score
and the savings are highly correlated, confirming the intuition behind the need to calibrate the
probabilities before using the Bayes minimum risk method.

\begin{figure}[ht!]
  \centering
  \includegraphics{ch6_fig4}
  \caption{\textbf{Comparison of the average Brier score of the algorithms versus the
    lowest Brier score by family of classifiers.} Overall, the models that are calibrated are
indeed the ones with the best Brier score.}
  \label{fig:6:comparison_family_brier}
\end{figure}

\makeatletter
\setlength{\@fptop}{0pt}
\makeatother


% This file was converted to LaTeX by Writer2LaTeX ver. 1.4
% see http://writer2latex.sourceforge.net for more info
\documentclass[a4paper]{article}
%\usepackage[latin1]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[english]{babel}
\usepackage{amsmath}
\usepackage{amssymb,amsfonts,textcomp}
\usepackage{color}
\usepackage{xcolor,colortbl}
\usepackage{sectsty}
\usepackage{tocloft}
\usepackage{fancyhdr}
\usepackage{afterpage}
\fancyhf{}
\usepackage{lastpage}
\usepackage{datetime}
\usepackage{colortbl}
\usepackage{array}
%\usepackage[top=0.7882in,bottom=0.4917in,left=1.25in,right=1.25in,nohead,includefoot,foot=0.5083in,footskip=0.97720003in]{geometry}
\usepackage[headheight=110pt]{geometry}
%\usepackage{supertabular}
\usepackage{hhline}
\usepackage{caption}
\usepackage{hyperref}

\usepackage{graphicx}
\usepackage{verbatim}
\pagestyle{fancy}
%\usepackage{titlesec}
\afterpage{\cfoot{\thepage}}

%new packages & rules
\linespread{1.1} % Definition of the linespread
%\usepackage[square,sort,comma,numbers]{natbib}
\usepackage{amsmath}
\usepackage{amssymb}
\mathchardef\mhyphen="2D % Define a "math hyphen"
\usepackage{amsthm}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{amsthm}

\usepackage[utf8]{inputenc}
\usepackage[english]{babel}
\usepackage{amsthm}
\theoremstyle{definition}
\newtheorem{definition}{Definition}
\newtheorem{example}{Example}

%\usepackage{eufrak}
\newcommand{\R}{\mathbb{R}}
\newcommand{\N}{\mathbb{N}}
\usepackage[ruled,vlined,noend]{algorithm2e}
\usepackage{natbib}
\usepackage{pgf}
\usepackage{tikz}
\usetikzlibrary{arrows,automata}
% to start new page for each new section
%\titlespacing*{\section}
%{0pt}{6.5ex plus 1ex }{6.3ex plus .2ex}
%\titlespacing*{\subsection}
%{0pt}{6.5ex plus 1ex }{6.3ex plus .2ex}

%\allsectionsfont{\centering}
\setlength{\headsep}{0.2in}

%\newdateformat{bkdate}{\twodigit{\THEDAY}-\twodigit{\THEMONTH}-\twodigit{\THEYEAR}}
%\dmyydate

\definecolor{datacroninner}{rgb}{0.0,0.0,0.5647059}
\newcommand{\datacroncolor}{\color{datacroninner}}
\chapterfont{\datacroncolor}  % sets colour of chapters
\sectionfont{\datacroncolor}  % sets colour of sections
\subsectionfont{\datacroncolor}  % sets colour of sections
\subsubsectionfont{\datacroncolor}
\hypersetup{colorlinks=true, linkcolor=datacroninner, citecolor=datacroninner, filecolor=datacroninner, urlcolor=blue}

\newcommand{\documenttitle}{\ Master Thesis Proposal}
%\newcommand{\horizongeneral}{\ H2020-ICT-2015 \dmyydate \today}
%\lhead{\includegraphics[width=122pt]{figures/datACRONDXYTemplate201512162-img001.png}}
\chead{\documenttitle}
%\rhead{\horizongeneral}
\lfoot{}
\fancyfoot[C]{Page \thepage \hspace{1pt}}
%\cfoot{Page \thepage \hspace{1pt} of \pageref{LastPage}}

\cfoot{Page \thepage}
\rfoot{}

%\makeatletter
\newcommand\arraybslash{\let\\\@arraycr}
%\makeatother
% Footnote rule
\setlength{\skip\footins}{0.0469in}
\renewcommand\footnoterule{\vspace*{-0.0071in}\setlength\leftskip{0pt}\setlength\rightskip{0pt plus 1fil}\noindent\textcolor{black}{\rule{0.0\columnwidth}{0.0071in}}\vspace*{0.0398in}}
\setlength\tabcolsep{1mm}
\renewcommand\arraystretch{1.3}
\newcounter{Table}
\renewcommand\theTable{\arabic{Table}}

\title{\documenttitle}
\author{Ehab Qadah \\\\Supervisor:
	PD Dr. Michael Mock}
\date{\dmyydate \today}
\begin{document}
\pagestyle{fancy}
\newcommand{\sectionbreak}{
\clearpage{\pagestyle{fancy}}}

\pagenumbering{gobble}

%\cfttoctitlefont{\datacroncolor}
%

%\title{\Huge Grant Agreement No: 687591}
%{\centering
%\par}
%\clearpage{\pagestyle{fancy}}
%%\setcounter{page}{1}
%\maketitle{\Huge}
%%\centering
%\title{\Large \textbf{ Predicting patterns of moving objects based
%	on contextual information with distributed online learning \\
%Distributed Online Learning for Forecasting Patterns of Moving Objects Events Streams \\
%Distributed Online Learning for Forecasting Patterns in Event Streams of Moving Objects}}
%{\centering
%\Large
%\par}
%\maketitle

%{\centering
%\includegraphics[width=2.5835in,height=0.6634in]{figures/datACRONDXYTemplate201512162-img001.png}
% \par}

%\begin{flushleft}
%\centering
%\begin{tabular}{lm{5.83516in}l}
%\hline
%%\centering
%\title{\documenttitle}
%\maketitle
%\\\hline
%\end{tabular}
%\end{flushleft}

%\begin{flushleft}
%\begin{tabular}{|m{0.25\textwidth}|m{0.75\textwidth}|}
%%\multicolumn{2}{|m{5.8350596in}|}{Deliverable Form}\\\hline
%\rowcolor{datacroninner}
%{\bfseries\color{white}Deliverable Form}& \\\hline
%Project Reference No. &
%H2020-ICT-2015 687591\\\hline
%Deliverable No.  & 8.1\\\hline
%Relevant Work Package: & WP 8\\\hline
%Nature: &R\\\hline
%Dissemination Level: &PU\\\hline
%Document version: &1.0\\\hline
%Due Date: &29/02/2016\\\hline
%Date of latest revision: &16/12/2015\\\hline
%Completion Date: &~\\\hline
%Lead partner: &UPRC\\\hline
%Authors: &
%George Vouros\\\hline
%Reviewers: &~\\\hline
%Document description: &
%This deliverable documents the main project procedures. These procedures have been presented and agreed at the kickoff
%
%meeting chaired by the coordinator.\\\hline
%Document location: &
%Desktop/Projects/datACRON/Project/Dels\\\hline
%\end{tabular}
%\end{flushleft}

%\clearpage

%\section*{HISTORY OF CHANGES}
%\thispagestyle{empty}
%\addcontentsline{toc}{section}{HISTORY OF CHANGES}
%\begin{flushleft}
%\begin{tabular}{|m{1.10in}|m{1.10in}|m{1.10in}|m{1.10in}|m{1.10in}|}
%\hline
%\rowcolor{datacroninner}
%{\bfseries\color{white} Version} &{\bfseries\color{white} Date} & {\bfseries\color{white} Changes} & {\bfseries\color{white} Author} & {\bfseries\color{white} Remarks}\\\hline
%~ &~ &~ &~ &~\\\hline
%\end{tabular}
%\end{flushleft}

%\clearpage

%\section*{EXECUTIVE SUMMARY}
%\addcontentsline{toc}{section}{EXECUTIVE SUMMARY}
%%\clearpage

%\section*{TABLE OF CONTENTS}
%\addcontentsline{toc}{section}{TABLE OF CONTENTS}
%
%
%
%\setcounter{tocdepth}{3}
%\renewcommand\contentsname{}
%\renewcommand{\cfttoctitlefont}{\datacroncolor}
%\tableofcontents
%\section*{TERMS \& ABBREVIATIONS}
%\addcontentsline{toc}{section}{TERMS \& ABBREVIATIONS}
%
%\section*{LIST OF FIGURES}
%\addcontentsline{toc}{section}{LIST OF FIGURES}
%%\cftloftitlefont{\datacroncolor}
%\listoffigures
%\section*{LIST OF TABLES}
%\addcontentsline{toc}{section}{LIST OF TABLES}
%
%\listoftables

\input{title}
\clearpage

\section*{Abstract}

Predicting full matches of complex patterns from various real-time event streams is an important utility for the decision maker in many application domains such as maritime surveillance, financial services, and sensor networks. Such a utility allows him/her to proactively react to the new situations and enhances the operational decision making. An event stream is an unbounded collection of timely ordered data observations in the form of an attribute tuple that is composed of a value from finite event types along with other categorical and numerical features. For example, in the context of maritime surveillance, patterns prediction over real-time tracking streams of moving vessels is useful to alert maritime operation mangers about suspicious activities (e.g., fast sailing vessels near ports) before they happen, in this scenario, the event stream of a moving vessel consists of spatial-temporal and kinematic information along with the vessel's identification and its trajectory related event types. However, processing real-time streaming data is challenging since data streams are large in nature and continuously keep on coming at a high rate.
% we describe the design and implementation of a system called%
\par To this end, in this thesis, we present an online, distributed and scalable patterns prediction system over massive input event streams. The proposed approach is based on a novel approach that combines the  distributed online prediction protocol \citep{kamp2014communication} with the event forecasting with Pattern Markov Chain system\citep{alevizos2017event}, in order to provide an online and large-scale patterns prediction system over distributed real-time event streams.

 \par We leverage an existing online probabilistic forecasting model, which consists of the event forecasting with Pattern Markov Chain~\citep{alevizos2017event}. This system gives the ability to predicate when a pattern within a stream of events will be fully matched. In addition, we integrate the distributed online synchronization protocol \citep{kamp2014communication} to provide distributed online learning capabilities between the prediction models in a communication-efficient manner. This protocol enables us to dynamically synchronize the distributed local prediction models of the multiple input event streams.

  In some practical applications the input event streams may belong to different distributions, we propose to divide the input event streams into similar groups, in order to combine the corresponding predictions models to construct a representative global model in each group. The aggregation operation refers to the synchronization operation (e.g., joint average of the local models) in the distributed online learning protocol, which is performed by a central coordinator that constructs and distributes a global prediction model for the input event streams based on the  local models. In addition, we are using one of the modern Big Data frameworks for stream processing i.e., Apache Flink \footnote{\url{https://flink.apache.org/}} to implement the proposed system.
\par We aim to provide an architecture and implementation of a system for large-scale patterns prediction over multiple input event streams. Our approach exploits the collaborative learning from multiple input streams by combing their associated predication models in a dynamic way.

\par We will analysis and develop the proposed approach, and evaluate the effectiveness through empirical experiments over synthetic event streams and real-word data streams of moving objects, in particular, events streams related to trajectories of moving vessels, which are provided in the context of the datAcron project\footnote{\url{http://www.datacron-project.eu/}}.

%Furthermore, we will try to provide probabilistic guarantees for the new proposed %method by performing theoretical analysis procedures.

{\large\textbf{\\ \\ Acknowledgment\\\\}}
This work is supported by the EU H2020 datAcron project (grant agreement No 6875).

{\large\textbf{\\ Keywords\\\\}}
Big Event Data Streams, Stream processing,Large-scale Patterns Prediction, Maritime Surveillance, Apache Flink, Distributed Pattern Markov Chain\\

\pagenumbering{arabic}
\setcounter{page}{1}
\thispagestyle{fancy}
\input{introduction}
\input{related_work}
\input{implementation}
\input{experimental_evaluation}
\input{work_plan}

%\input{extra_rources}

%{\centering
%\includegraphics[width=4.972in,height=3.5693in]{figures/datACRONDXYTemplate201512162-img002.png}
% \par}
%
%\captionof{figure}{datACRON Overall Architecture }
%
%
%
%\begin{flushleft}
%\begin{tabular}{m{0.48in}|m{3.29in}|m{1.89in}c|}
%\hline
%\rowcolor{datacroninner}
%{\bfseries\color{white}lala}&{\bfseries\color{white} Bla} &{\bfseries\color{white} bla}\\\hline
%1 &~ &~\\\hline
%2 &~ &~\\\hline
%\end{tabular}
%\end{flushleft}

\clearpage
%\nocite{*}
%\bibliographystyle{plain-annote}
%\bibliographystyle{plainnat}
 \bibliographystyle{agsm}
\bibliography{myrefs}
\end{document}