\documentclass[12pt]{article} %{{{
\usepackage[margin=1in]{geometry}

% Figures
\usepackage{graphicx}
\graphicspath{{../../plots/}}

% Math
\usepackage{amsmath}
\usepackage{amssymb}
\DeclareMathOperator*{\argmin}{\arg\!\min}
\DeclareMathOperator*{\argmax}{\arg\!\max}

% abbreviations
\def\eg{e.g.,~}
\def\ie{i.e.,~}
\def\cf{cf.\ }
\def\viz{viz.\ }
\def\vs{vs.\ }

% Refs
\usepackage[style=nature, backend=bibtex]{biblatex}
\addbibresource{main.bib}

\usepackage{url}

\newcommand{\secref}[1]{Section~\ref{sec:#1}}
\newcommand{\figref}[1]{Fig.~\ref{fig:#1}}
\newcommand{\tabref}[1]{Table~\ref{tab:#1}}
%\newcommand{\eqnref}[1]{\eqref{eq:#1}}
%\newcommand{\thmref}[1]{Theorem~\ref{#1}}
%\newcommand{\prgref}[1]{Program~\ref{#1}}
%\newcommand{\algref}[1]{Algorithm~\ref{#1}}
%\newcommand{\clmref}[1]{Claim~\ref{#1}}
%\newcommand{\lemref}[1]{Lemma~\ref{#1}}
%\newcommand{\ptyref}[1]{Property~\ref{#1}}

% for quick author comments
\usepackage[usenames,dvipsnames,svgnames,table]{xcolor}
\definecolor{light-gray}{gray}{0.8}
\def\del#1{ {\color{light-gray}{#1}} }
\def\yy#1{\footnote{\color{red}\textbf{yy: #1}} }

% subfigures
\usepackage{caption}
\usepackage{subcaption}

%}}}

\begin{document} %{{{

\title{Information theory for discrete modelling} %{{{
\date{\today}
\maketitle %}}}

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

%}}}

\section{Boolean Minimization}\label{sec:boolmin} %{{{

Boolean functions consist of a set of inputs that take boolean values and
collectively determine the transition of the overall function. The function
itself also takes a boolean value as its state and can transition between these
state values. The rule by which the function transitions is often described in a
look up table (LUT). An example of such a LUT can be seen in
\figref{parity_lut}. [I supose I should give a proper treatment to what exactly
a boolean automaton is here. That can be filled in later once I have the
skeleton laid out.]

\begin{figure}[h]
    \centering
    \begin{subfigure}[A]{0.48\textwidth}
        \centering
        \includegraphics[height=6cm]{example_luts_schemata/high_synergy/parity_lut.pdf}
        \label{fig:parity_lut}
        \caption{\label{fig:parity_lut}}
    \end{subfigure}
    \begin{subfigure}[B]{0.48\textwidth}
        \centering
        \includegraphics[height=6cm]{example_luts_schemata/high_synergy/parity_ts.pdf}
        \label{fig:parity_ts}
        \caption{\label{fig:parity_ts}}
    \end{subfigure}
    \caption{Visual descriptions of three bit parity:
    (\subref{fig:parity_lut}) Unmodified look up table (LUT);
    (\subref{fig:parity_ts}) Minimized schemata.}
    \label{fig:parity}
\end{figure}

Boolean minimization is a process by which the number of rows in the LUT of a
boolean function is minimized. Typically, this is achieved by replacing
non-informative input states with ``wildcards" (shown as \# in the schemata in
\figref{parity_ts}) that represent an indifference to the actual state of that
input in determining the transition. This process can be achieved efficiently
through the Quine-McCluskey method of prime implicants \cite{quine_way_1955}.

Boolean functions can be further reduced by leveraging the observation that in
many cases it does not matter which input adopts a particular state. In the case
of the parity function shown in \figref{parity} it does not matter which input
is in the ON (1) state so long as only one input is in the ON state. The inputs
can be symmetrical with respect to one another's states
\cite{marques-pita_canalization_2013}. This can be seen very
obviously in the \textit{two-symbol schemata} for the three bit parity function
shown in \figref{parity_ts}. The name \textit{two-symbol} refers to the use
of a second, ``position-free," symbol $^\circ$.

These redescriptions highlight the role of boolean functions as models of
information processing elements. \textit{Boolean networks} composed of many
boolean functions, each serving as inputs to other functions in the network are
canonical models of complex systems, particularly those involved in information
processing in biological systems \cite{kauffman_emergent_1984,willadsen_robustness_2007,marques-pita_canalization_2013}
[get more of these into the .bib probably]. Despite their use in modelling
information processing, formal measures from information theory lag behind. This
stems largely from the fact that measures based on Shannon entropy are unsuited
to dealing with polyadic relationships
\cite{james_information_2016,james_multivariate_2017} such as the ones almost
universally present in boolean functions.
%}}}

\section{Partial Information Decomposition}\label{sec:partial}

Partial Information Decomposition (PID) is a framework originally proposed by
Williams and Beer \cite{williams_nonnegative_2010}. In this framework the
total information between a set of source varibles ($S = \{X_1, X_2\}$) and a
target variable ($T$) are decomposed into different non-overlapping pieces.
\textit{Redundancy} is information that could be provided by any variable in
the set of sources.

\section{Canalization Enables Non-Synergistic Information}\label{sec:enables}

\subsection{Unique information}

\begin{figure}[h]
    \centering
    \begin{subfigure}{0.48\textwidth}
        \centering
        \includegraphics[height=4cm]{k2_schemata/unique/lut_3.pdf}
        \label{fig:lut3}
        \caption{\label{fig:lut3}}
    \end{subfigure}
    \begin{subfigure}{0.48\textwidth}
        \centering
        \includegraphics[height=4cm]{k2_schemata/unique/sc_3.pdf}
        \label{fig:ts3}
        \caption{\label{fig:ts3}}
    \end{subfigure}
    \caption{lookup table and minimized schemata for a two input boolean
    function showing unique information.
    (\subref{fig:lut3}) lookup table;
    (\subref{fig:ts3}) Left: Wildcard schemata, Right: Two symbol schemata}
    \label{fig:rule3}
\end{figure}

Figure \ref{fig:rule3} shows a visual description of a two input boolean
function for which most of our partial information decompositions attribute all
of the information to come uniquely from input 1. Looking at the lookup table,
we can see this pattern (\figref{lut3}), however by looking at the schemata it
is quite obvious (\figref{ts3}).

The schemata in \figref{ts3}, particularly the two-symbol schemata
($\mathbf{F^{''}}$) shown on the right explicitly tell us all of the ways in
which information moves through this logic gate. Each row of the table describes
a schema and these schema are the ways in which information moves through the
gate. In this case we have two modes of information transfer
$f^{''}_1 \in \mathbf{F^{''}}, f^{''}_2 \in \mathbf{F^{''}}$. In both entries
to $\mathbf{F^{''}}$ input 2 contains a wildcard. This indicates that either
ON of OFF is allowed in that position---we "don't care". This lack of dependence
implies a lack of information coming from that input when it contains a wildcard.
Because both entries to $\mathbf{F^{''}}$ contain wildcards in input 2, input 1
must be solely responsible for the information through the gate. Input 2 is
wholly "redundant" but it does not provide "redundant" information in the
information theoretic sense.

\del{I want to give this kind of canalization--all states of one input
sufficient to control transition--a name, maybe like "hard canalization"
or something.}

\subsection{Synergy}

\begin{figure}[h]
    \centering
    \begin{subfigure}{0.48\textwidth}
        \centering
        \includegraphics[height=4cm]{k2_schemata/synergy/lut_6.pdf}
        \label{fig:lut6}
        \caption{\label{fig:lut6}}
    \end{subfigure}
    \begin{subfigure}{0.48\textwidth}
        \centering
        \includegraphics[height=4cm]{k2_schemata/synergy/sc_6.pdf}
        \label{fig:ts6}
        \caption{\label{fig:ts6}}
    \end{subfigure}
    \caption{lookup table and minimized schemata for a two input boolean
    function showing synergistic information.
    (\subref{fig:lut6}) lookup table;
    (\subref{fig:ts6}) Left: Wildcard schemata, Right: Two symbol schemata}
    \label{fig:rule6}
\end{figure}

Here in \figref{rule3} we have the non-canalizing XOR function. All of our PID
methods attribute all of the information across this gate to synergy between
both inputs. We can see the lack of canalization in this function on the left
in \figref{ts6} where no wildcards ever appear in $\mathbf{F^{'}}$. This means
that all inputs are always needed to control the transition. This dependency on
multiple inputs for the same transition is synergy.

On the right in \figref{ts6} we see the position-free symbol for both inputs in
$f^{''}_3$. This indicates that these states may be permuted across any of the
inputs that share this symbol without changing the transition. Groups of states
that share the same position-free symbol are called group-invariant enputs. We
will show later that these group-invariant enputs serve as fundamental
information sources rather than inputs. Whether a function contains schema with
position-free symbols alone, however, does not change the way that information
flows across the gate. Group-invariant enputs are also not necessary nor
sufficient for the existence of synergy. Indeed, $f^{''}_1$ and $f^{''}_2$ are
also synergistic modes of information transfer as we still need both inputs to
determine the transition.

\subsection{Redundancy}

\begin{figure}[h]
    \centering
    \begin{subfigure}{0.48\textwidth}
        \centering
        \includegraphics[height=4cm]{k2_schemata/redundancy/lut_1.pdf}
        \label{fig:lut1}
        \caption{\label{fig:lut1}}
    \end{subfigure}
    \begin{subfigure}{0.48\textwidth}
        \centering
        \includegraphics[height=4cm]{k2_schemata/redundancy/sc_1.pdf}
        \label{fig:ts1}
        \caption{\label{fig:ts1}}
    \end{subfigure}
    \caption{lookup table and minimized schemata for a two input boolean
    function showing redundant information.
    (\subref{fig:lut1}) lookup table;
    (\subref{fig:ts1}) Left: Wildcard schemata, Right: Two symbol schemata}
    \label{fig:rule1}
\end{figure}

Redundancy is where things get interesting with canalization and partial
information. \figref{rule1} shows the lookup table and schemata for the OR
gate. Here, we see both wildcards and position-free symbols. Importantly, we
see wildcards and literals appear in the same group-invariant enput. This is
where redundancy comes from. In $f^{''}_2$ we see a transition where one input
must be ON, regardless of the value of the other input, and regardless of which
input is ON. Either input in the ON state is sufficient to determine the
transition. The information about this transition is distributed across the
group-invariant enput, but unlike in the synergistic case there is no
dependency within the group-invariant enput.

This is distinct from unique information because there is never a case where
one input is able to provide information on its own that another input is
incapable of providing on its own. No single input is privileged over another
except in the transition covered by $f^{''}_1$ where both inputs together
provide information that could not be provided by either input alone.

\subsection{A three-input example}

Two-input boolean functions neatly show off the principles at play in how
canalization impacts information flow. These principles can be extended into
boolean functions with a higher number of inputs and applied to each of the
schema shown in the two-symbol schemata.

\begin{figure}[h]
    \centering
    \begin{subfigure}{0.48\textwidth}
        \centering
        \includegraphics[height=6cm]{example_luts_schemata/high_synergy/no_middle_lut.pdf}
        \label{fig:lutk3}
        \caption{\label{fig:lutk3}}
    \end{subfigure}
    \begin{subfigure}{0.48\textwidth}
        \centering
        \includegraphics[height=6cm]{example_luts_schemata/high_synergy/no_middle_ts.pdf}
        \label{fig:tsk3}
        \caption{\label{fig:tsk3}}
    \end{subfigure}
    \caption{lookup table and minimized schemata for a modified three-input
    parity function where input 2 is insufficient to determine transition to
    ON.
    (\subref{fig:lutk3}) lookup table;
    (\subref{fig:tsk3}) Left: Wildcard schemata, Right: Two symbol schemata}
    \label{fig:rulek3}
\end{figure}

\figref{rulek3} shows the lookup table for a modified parity function that
breaks the full synergy and introduces partial canalization (ECA rule 73). We
can determine the way that information moves through the function by looking
at each of the entries in the two symbol schemata shown on the right in
\figref{tsk3}. Two of these are very straight forward. $f^{''}_2$ and
$f^{''}_4$ contain neither wildcards nor position-free symbols and are easily
identified as the three-way synergy $\{123\}$. Additionally, $f^{''}_5$
redescribes a pair of transitions with more flexible dependencies but that
still require all three inputs. Thus, $f^{''}_5$ is also an example of the
synergy $\{123\}$.

There is another simple synergy captured in $f^{''}_1$. Input 2 provides no
information, but both inputs 1 and 2 control the transition. This is an
example of the synergy $\{13\}$. Finally, $f^{''}_3$ shows us the most complex
case. There are two situations that both provide information about the same
transition. The first is the one shown in the table where the states of inputs
1 and 2 can control the transition. The second is if the wildcard is in
position 1 and the OFF in input 3. In this case, inputs 2 and 3 collectively
control the transition. This means that we have two cases of synergy, both of
which provide exactly the same information. This entry describes a redundancy
between two synergies $\{12\}\{23\}$.

\section{Methods}\label{sec:methods} %{{{

%}}}

\printbibliography

\end{document} %}}}


\section{Electrostatic potential}

\begin{framenologo}
  \frametitle{Electrostatic potential}
  \tableofcontents[currentsection]
\end{framenologo}

\subsection{Boundary conditions}

\begin{frame}
  \frametitle{Electrostatic potential}
  \framesubtitle{Boundary conditions}

  Boundary conditions are fulfilled via:
  \begin{itemize}[<+->]
    \item<.-> Electrodes behave bulk

    \item Extended electrode regions helps the above

    \item Corrections to the Hartree potential are necessary (TranSiesta solves Poisson
    equation via Fourier transforms, i.e. periodic)

    \item Always remember that the self-energy \emph{forces} the boundary conditions,
    i.e. a long range decay-potential may be forced too short

  \end{itemize}

  \uncover<.->{
  \begin{center}

    \begin{tikzpicture}[z=.5cm,>=latex,scale=.75,font=\scriptsize]
      \drawcube[draw]
      \begin{scope}[xshift=-3cm,x=3cm]
        \begin{scope}
          \drawcube[draw,densely dotted]
          \fill[red!50!black,fill opacity=0.5] (0,0,1) -- (1,0,1) -- (1,1,1) -- (0,1,1)
          -- cycle;
        \end{scope}
      \end{scope}
      \begin{scope}[xshift=1cm,x=3cm]
        \begin{scope}
          \drawcube[draw,densely dotted]
          \fill[blue!50!black,fill opacity=0.5] (0,0,1) -- (1,0,1) -- (1,1,1) -- (0,1,1)
          -- cycle;
        \end{scope}
      \end{scope}

      % Draw arrows
      \node[anchor=center] at (-1.5,.5,.5) {$-\infty=\SE_\leftarrow$};
      \node[anchor=center] at (2.5,.5,.5) {$+\infty=\SE_\rightarrow$};

      \draw[<-] (0.5,0,0.) -- ++(0,-1,0) node[below] {Simulation cell};
      % \draw[->] (.5,.5,.5) -- (1.5,.5,.5);
      % \draw[->] (.5,.5,.5) -- (.5,1.5,.5);

    \end{tikzpicture}

  \end{center}}

\end{frame}

\begin{frame}
  \frametitle{Electrostatic potential}
  \framesubtitle{Boundary conditions}

  \begin{block}<+->{Hartree potential}

    NEGF calculations are \emph{very} different from periodic calculations because of the
    semi-infinite leads.

  \end{block}

  \begin{block}<+->{Boundary conditions}

    The electrode Hartree potential are the boundary conditions.

    In TranSiesta this is accomplished by fixing the electrostatic potential at one of the
    electrode planes (the plane farthest from the device region).

    \begin{itemize}
      \item For $N_\idxE=2$ and aligned semi-infinite directions the potential profile can
      easily be approximated by a linear ramp $V(x) = ax+b$.

      \item For un-aligned semi-infinite directions (or $N_\idxE\neq2$) the potential
      profile cannot easily be approximated.

      \begin{itemize}[<+->]
        \item By default, TranSiesta implements a \emph{box} solution (bad guess) which
        only defines the boundary conditions on the electrode atoms. I.e. sets the Hartree
        potential equal to the chemical potential in the cell region of the electrode.

        \item A much better approach is to provide an \emph{external} potential profile
        guess, i.e. solve the boundary conditions using external Poisson
        solvers\footnote{\uncover<4->{This may seem like a more daunting task than it
                is. The guess is the Poisson solution \emph{without} charges, only the
                boundary conditions.}}

      \end{itemize}
    \end{itemize}

  \end{block}

\end{frame}

\subsection{Multi-electrode electrostatic potential}

\begin{frame}
  \frametitle{Electrostatic potential}
  \framesubtitle{Multi-electrode electrostatic potential}

  \begin{itemize}
    \item 6-electrode system
    \item Default \emph{box} solution for the Poisson equation
    \item External Poisson solution with electrode regions correct chemical potential
  \end{itemize}

  \begin{center}
    \incg[width=.8\linewidth]{ts-poisson-initial}
  \end{center}

  \begin{block}<2->{Help needed!}

    This is where TranSiesta could benefit the most from external help!

    A proper, Poisson solver with arbitrary boundary conditions.

  \end{block}

\end{frame}


\subsection{Air Dehumidification}
\label{sec:dehum}

\textbf{Purpose}: Actively \textit{decreases} growth environment air humidity.

\textbf{Function}:
\begin{itemize}
    \item \textbf{Inputs}: Humid air (high water vapour content), dehumidification control signal (shutter servo open/close, fan speed), dry desiccant
    \item \textbf{Outputs}: Dry air (low water vapour content), saturated desiccant
\end{itemize}

\textbf{Method}:
\begin{enumerate}
    \item \textit{Setup}:
    \begin{enumerate}
        \item Dehumidification control signals are hooked up;
        \item Dry desiccant is added to cartridge, which is inserted;
    \end{enumerate}
    \item \textit{Testing}:
    \begin{itemize}
        \item Desiccant removes moisture from air;
        \item Desiccant indicates saturation as expected, which is sensed by computer;
        \item Shutters operate as intended, and no dehumidification occurs when closed;
        \item Maximum dehumidification rate exceeds total plant transpiration rate;
    \end{itemize}
    \item \textit{Process}:
    \begin{enumerate}
        \item Humidity sensor sends data to control module (\ref{sec:automation});
        \item Dehumidification control signal activates fans and opens shutters;
        \item Humid air passes over the desiccant, and dry air exits the unit;
        \item Desiccant becomes saturated, and indicates this;
        \item Indication is sensed by computer (\ref{sec:automation}), which notifies the user;
        \item Cartridge is removed by the user, and swapped for a dry one. Process continues;
        \item Saturated cartridge is recharged;
    \end{enumerate}
    \item \textit{Shutdown}:
    \begin{enumerate}
        \item Control signals are disconnected;
        \item Final recharging of cartridge;
        \item Desiccant is removed from cartridge;
    \end{enumerate}
\end{enumerate}

\textbf{Calculations}:

Assuming an air temperature of 30$\degree$ C, water vapour saturation of $30.4g/m^{3}$, RH of 90\%, target RH of 20\%, and 6\% weight dessicant capacity:
\vspace{.05cm}
\begin{gather*}
    90\% RH = 0.90 * 30.4g/m^{3} = 27.36g/m^{3} \\
    20\% RH = 0.20 * 30.4g/m^{3} = 6.08g/m^{3} \\
    Vol_{4 Units} = 0.5m * 0.5m * 0.5m * 4 = 0.5m^{3} \\
    Mass_{water} = (27.36g/m^{3} * 0.5m^{3}) - (6.08g/m^{3} * 0.5m^{3}) = 10.64g \\
    \frac{10.64}{0.06} = 177.3g \\
\end{gather*}

$\therefore$ 177.3g of dessicant will change the RH\% of a 4 unit setup from 90\% to 20\%.

\textbf{Features}:
\begin{itemize}
    \item \textit{Humidity Sensor}: See Section \ref{sec:airhum}.
    \item \textit{Dehumidification Unit}: One input port and one output port. Comprised of:
    \begin{itemize}
        \item \textit{Fans}: Draws moist air through input port and dried air through output port.
        \item \textit{Filter}: HEPA filter is located at inlet of dehumidification chamber. Eliminates risk of any airborne pathogens being transferred onto silica beads.
        \item \textit{Airtight Shutters} - Isolates dehumidification chamber when not in use. Prevents unintended dehumidification. Located at input and output ports. Controlled by a servo.
        \item \textit{Desiccant Cartridge}: Oven-safe. Easily removable for swapping and "recharging".
        \item \textit{Silica Beads}: Cheap, efficient, non-toxic desiccant. Changes color when saturated. Can be reused indefinitely when water is evaporated.
    \end{itemize}
    \item \textit{Evaporator Oven}: \textbf{Onboard systems} provide an oven that can maintain 200°C for 60 minutes. Heats cartridge to evaporate/"bake off" moisture collected by silica beads, thus "recharging" them. Vapour is collected by onboard dehumidifier.
\end{itemize}


\section{Paper 5}
\subsection{\emph{"An End-to-End Multi-Task and Fusion CNN for Inertial-Based Gait Recognition"}}

\begin{frame}{INTRODUCTION}
    The gait recognition is an activity used in the medical, security and
    authentication fields. The following paper shows a convolutional neural
    network (CNN) which takes as input a series of inertial data, coming
    from different sensors, and produces as output a prediction useful for
    recognizing a subject.
    \begin{figure}[htbp]
        \centering
        \includegraphics[width = 0.6 \linewidth]{images/paper5/usecase.png}
        \centering
        \caption{A preview of how the model works.}
        \label{fig:preview}
    \end{figure}
\end{frame}

\begin{frame}{RELATED WORK}
    Some methods have placed inertial sensors in different parts of the body
    such as legs \footfullcite{0857651733}, hips \footfullcite{0857651732}, ankles, or even in objects such as bags and
    pockets. Other methods \footfullcite{0857651736} directly use all the inertial sensors present in
    the smartphone. In the proposed method, the data coming from the
    different sensors are merged and sent to the network which will have the
    task of predicting some tasks such as: {\bfseries{Identification}}, {\bfseries{age}} and {\bfseries{gender}} of
    the subject.
\end{frame}

\begin{frame}{PROPOSED APPROACH - CNN Architecture}
    \begin{figure}[htbp]
        \centering
        \includegraphics[width = 0.8 \linewidth]{images/paper5/architecture.png}
        \centering
        \caption{Pipeline for multi-task and multi-sensor learning in a gait-based system}
        \label{fig:pipeline}
    \end{figure}
    The network consists of two branches, one for each sensor (accelerometer
    and gyroscope). The Input is split into 3 channels, 1 for each physical
    size of the signal (axis x, y and z). After merging the data into a single
    branch, the feature vector is extracted and then the three classes are
    predicted. The data used are those present in the OU-ISIR dataset \small\footfullcite{0857651721}.
\end{frame}

\begin{frame}{PROPOSED APPROACH - Multi-Task}
    A network that manages different labels falls into the category of deep
    multitask (\emph{DMT}) networks. To train this network, the sequence S of data
    coming in input is splitted into $ s_i $ sub-sequences each of which will be
    inserted in a tuple $ I = (s_i, y_i^m, y_1^1, ..., y_i^T) $ where $ y_i^m $ is the label of the
    main task, $ y_i^t $, with $ t \in [1,T] $, is the label for each auxilary task. Both
    the subsequences $ s_i $ and the tasks have their own loss function. The  total
    accuracy  is  obtained  by combining the accuracies derived from the output
    of each sub-sequence $ s_i $  of  the  input  S.
\end{frame}

\begin{frame}{PROPOSED APPROACH - Identity Authentication}
    Unlike the recognition, the authentication problem aims to see if
    two different inputs belong to the same subject. To do this, it is necessary
    to calculate the Euclidean distances between the input data and the data
    vectors present in the training set. Once this is done, the resulting vector
    must be translated into probabilities that will be useful in order to
    calculate two indexs (Area Under Curve (AUC), Equal-Error-Rate
    (EER)) that will be useful for evaluating the CNN network.
\end{frame}

\begin{frame}{EXPERIMENTS AND RESULTS - Gait recognition}
    For recognition, different types of experiments on different models and
    their respective performances in terms of accuracy and F1-measure are
    presented below.
    \begin{minipage}{\linewidth}
        \centering
        \begin{minipage}{0.45\linewidth}
            \begin{table}[h!]
            \centering
                \begin{adjustbox}{max width=\textwidth}
                \begin{tabular}{|c||ccc|c||ccc|c|}
                    \hline
                        & \multicolumn{4}{c||}{Acc} & \multicolumn{4}{c|}{F1-Score} \\
                    \hline
                        Architecture & Id & Age & Gender & Avg & Id & Age & Gender & Avg\\
                    \hline
                        SingleTask Accelerometer & 89.7 & 91.0 & 94.8 & 91.8 & 87.6 & 91.3 & 94.5 & 91.2\\
                        SingleTask Gyroscope& 89.1 & 89.1 & 94.4 & 90.9 & 87.5 & 89.7 & 94.4 & 90.5\\
                    \hline
                \end{tabular}
                \end{adjustbox}
                \caption{Accuracy and F1-score (1 Task, 1 Sensor). 3 Tasks - 2 Sensors - 6 CNNs.}
                \label{table accuracy and F1 (1 Task - 1 Sensor)}
            \end{table}
            \centering
            \begin{table}[h!]
                \centering
                \begin{adjustbox}{max width=\textwidth}
                \begin{tabular}{|c||ccc|c||ccc|c|}
                    \hline
                        & \multicolumn{4}{c||}{Acc} & \multicolumn{4}{c|}{F1-Score} \\
                    \hline
                        Architecture & Id & Age & Gender & Avg & Id & Age & Gender & Avg\\
                    \hline
                        SingleTask Fusion & 94.2 & 95.0 & 95.6 & 94.9 & 93.5 & 95.0 & 95.6 & 94.7\\
                    \hline
                \end{tabular}
                \end{adjustbox}
                \caption{Accuracy and F1-score (1 Task, + Sensor). 1 CNN for each Task.}
                \label{table accuracy and F1 (1 Task, + Sensor)}
            \end{table}
        \end{minipage}
        \hspace{0.05\linewidth}
        \begin{minipage}{0.45\linewidth}
            \begin{figure}[htbp]
                \centering
                \begin{table}[h!]
                    \centering
                    \begin{adjustbox}{max width=\textwidth}
                    \begin{tabular}{|c||ccc|c||ccc|c|}
                        \hline
                            & \multicolumn{4}{c||}{Acc} & \multicolumn{4}{c|}{F1-Score} \\
                        \hline
                            Architecture & Id & Age & Gender & Avg & Id & Age & Gender & Avg\\
                        \hline
                            MultiTask Accelerometer & 90.9 & 93.3 & 95.9 & 93.4 & 89.1 & 93.3 & 95.9 & 92.8\\
                            MultiTask Gyroscope & 90.1 & 90.1 & 94.8 & 91.7 & 88.3 & 90.5 & 94.9 & 91.2\\
                        \hline
                    \end{tabular}
                    \end{adjustbox}
                    \caption{Accuracy and F1-score (+ Task, 1 Sensor). 2 CNNs, one for each 3 Tasks.}
                    \label{table accuracy and F1 (more Task - 1 Sensor)}
                \end{table}
                \centering
                \begin{table}[h!]
                    \centering
                    \begin{adjustbox}{max width=\textwidth}
                    \begin{tabular}{|c||ccc|c||ccc|c|}
                        \hline
                            & \multicolumn{4}{c||}{Acc} & \multicolumn{4}{c|}{F1-Score} \\
                        \hline
                            Architecture & Id & Age & Gender & Avg & Id & Age & Gender & Avg\\
                        \hline
                            MultiTask Fusion & \bfseries{94.8} & \bfseries{96.1} & \bfseries{97.7} & \bfseries{96.2} & \bfseries{93.8} & \bfseries{96.3} & \bfseries{97.7} & \bfseries{95.9}\\
                        \hline
                    \end{tabular}
                    \end{adjustbox}
                    \caption{Accuracy and F1-score (+ Task, + Sensor). Only 1 CNN for all Tasks.}
                    \label{table accuracy and F1 (+ Task, + Sensor)}
                \end{table}
            \end{figure}
        \end{minipage}
    \end{minipage}
\end{frame}

\begin{frame}{EXPERIMENTS AND RESULTS - Authentication}
    For identity authentication, on the other hand, the results shown in the table show that for this type of problem the single task model is better than the multi-task model. This happens because in this problem a single label (id) is required and not others. The introduction of other labels leads the multitask model to have worse accuracy than the single task model. The indices AUC (higher is better) and EER (lower is better) are calculated thanks to the probabilities obtained from the Euclidean distance vector.
    \begin{table}[h!]
        \centering
        \begin{adjustbox}{max width=\textwidth}
        \begin{tabular}{|c|cc|}
            \hline
            Architecture & EER & AUC\\
            \hline
            SingleTask Accelerometer & 1.47 & 99.91\\
            SingleTask Gyroscope & 2.50 & 99.80\\
            \hline
            MultiTask Accelerometer & 1.61 & 99.90\\
            MultiTask Gyroscope & 2.85 & 99.72\\
            \hline
            SingleTask Fusion & \bfseries{1.14} & \bfseries{99.93}\\
            \hline
            MultiTask Fusion & 1.34 & 99.92\\
            \hline
        \end{tabular}
        \end{adjustbox}
        \caption{Authentication accuracy.}
        \label{Authentication}
    \end{table}
\end{frame}

\begin{frame}{EXPERIMENTS AND RESULTS - State of the art Comparison}
    Comparing the proposed system with those already existing in the state
    of the art, both for recognition and authentication, the performance, in
    terms of accuracy, achieved outperforms those competitors.
        \begin{minipage}{\linewidth}
        \centering
        \begin{minipage}{0.45\linewidth}
            \begin{table}[h!]
                \centering
                \begin{adjustbox}{max width=\textwidth}
                \begin{tabular}{|c|ccc|c|}
                    \hline
                    CNN & Id & Age & Gender & Avg\\
                    \hline
                    AE-GDI-CC & 61.0 & - & - & -\\
                    Muaaz et al. & 63.5 & - & - & -\\
                    Ngo et al. & 70.2 & - & - & -\\
                    Wei et al. & 83.8 & - & - & - \\
                    \hline
                    MultiTask Fusion & \bfseries{94.8} & \bfseries{96.1} & \bfseries{97.7} & \bfseries{96.2}\\
                    \hline
                \end{tabular}
                \end{adjustbox}
                \caption{Gait recognition comparison with some methods.}
                \label{Gait comparison}
            \end{table}
        \end{minipage}
        \hspace{0.05\linewidth}
        \begin{minipage}{0.45\linewidth}
            \begin{table}[h!]
                \centering
                \begin{adjustbox}{max width=\textwidth}
                \begin{tabular}{|c|c|}
                    \hline
                    Approach & EER\\
                    \hline
                    Gafurov et al. & 15.8 \\
                    Derawi et al. & 14.3 \\
                    Rong et al. & 14.3 \\
                    Ngo et al. & 13.5 \\
                    Imp GDI + i-vector & 7.1 \\
                    NC GDI + i-vector & 5.6 \\
                    \hline
                    SingleTask Fusion & \bfseries{1.1}\\
                    \hline
                \end{tabular}
                \end{adjustbox}
                \caption{Authentication comparison with some methods.}
                \label{Authentication comparison}
            \end{table}
        \end{minipage}
    \end{minipage}
\end{frame}

\begin{frame}{CONCLUSIONS}
    As a final consideration, the model to be used, in the case of gait recognition,
    is the one that merges the input information and adopts a multitask
    approach. On the other hand, as regards the authentication problem, it has
    been seen that it is better to use a singletask model.
\end{frame}


\documentclass{tufte-handout}
\usepackage{amsmath}
\usepackage[utf8]{inputenc}
\usepackage{mathpazo}
\usepackage{booktabs}
\usepackage{microtype}

\pagestyle{empty}

\title{Gorilla Report}
\author{Alice Cooper and Bob Marley}

\begin{document}
  \maketitle

  \section{Results}

  Our implementation produces the expected results on all pairs of species, except for Unicorn and Yog-Soggoth.
  We have no idea why this happens.%
  \sidenote{%
  Complete the report by filling in your correct names,
  filling in the parts marked $[\ldots]$,
  and changing other parts wherever necessary.
  For instance, if your implementation passes all tests, then write that.
  Remove the sidenotes in your final hand-in.
  }

  We compared the species in \verb!HbB_FASTAs-in.txt!
  with the common rat, given by

  \begin{verbatim}
  MVHLTDAEKA AVNALWGKVN PDDVGGEALG RLLVVYPWTQ RYFDSFGDLS
  SASAIMGNPK VKAHGKKVIN AFNDGLKHLD NLKGTFAHLS ELHCDKLHVD
  PENFRLLGNM IVIVLGHHLG KEFTPCAQAA FQKVVAGVAS ALAHKYH
  \end{verbatim}

  The closest species to \emph{Rattus rattus} is $[\ldots]$, with the following optimal alignment:\sidenote{Replace with actual alignment between the two species.}

\medskip
  \begin{fullwidth}\small
  \begin{verbatim}
  MVHLTDAEKAAVNALWGKVNPDDV-YGGEAL----VVYPWTQRYFDSFGDLS
  MVHLTDAEKAAVNALWGKVNPDDVX-GGEALGRLLVVYPWTIRYFDSFGDLS

  SASAIMGNPKVKAHGKKVINAFND---KHLDNLKGTFAHLSELHTDKLHVDPENFRLLGN
  SASAIMGNPKVKAHGKKVINAFNDDVHKHLDNLKGTFAHLSELHSDKLHVDPENFRLLGN

  MIVIVLGHHLGKEFTPC----------AQAAFQKVVAGVASALAHKYH
  MIVIVLGHHLGKEFTPCVOLKSWAGENAQAAFQKVVAGVASALAHKYH
  \end{verbatim}
\end{fullwidth}

  \section{Implementation details}

  We chose a recursive/iterative implementation.
  For two sequences of length $n$ and $m$, respectively, our implementation uses $O((n^3+\log^2 m)\cos n)$ time and
  $O(1)$ space.\sidenote{%
  Correct, replace, rewrite as necessary.}

\end{document}


\documentclass{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}

\usepackage{qtree}
\usepackage{dirtree}

\usebackgroundtemplate{
	\includegraphics[width=\paperwidth,height=\paperheight]{img/background}
}

\title{Chapter 02: Other Classical Techniques}

\begin{document}
	\begin{frame}
		\titlepage
	\end{frame}

	\section{Introduction}
	\begin{frame}{Introduction}
		\begin{itemize}
		    \item Other classical techniques exists
		    \item We will review some of them, and later discuss about comparison
		    \item We will rarely use it, just so you know
		\end{itemize}
	\end{frame}

	\section{Finite State Machine}
	\begin{frame}{Finite State Machine}
    	\begin{itemize}
    	    \item Example originally from \cite{brady1977theory}: a safe has combination lock that can be in one out of three positions: 1, 2, and 3.
    	    \item It can go left (L) or right (R), hence 6 possible movements: 1L, 1R, 2L, 2R, 3L, 3R.
    	    \item Combination of the safe is 1L, 3R, 2L. Any other movement will set the alarm.
    	    \item Diagram here is made by free ``Qfsm'' tool.
	    \end{itemize}
	    \includegraphics[scale=0.5]{img/03_safe_fsm.png}
	\end{frame}
	\begin{frame}{Finite State Machine}
    	\begin{itemize}
    	    \item More ways to represent finite state machine: transition table and a 5-tuple \{J, K, T, S, F\} (states, inputs, transition function, initial state, final states)
    	    \item Later in discussions of Unified Modeling Language (UML), we will find out that UML has also a state machine diagram
	    \end{itemize}
	\end{frame}
	\section{Petri Nets}
	\begin{frame}{Petri Nets}
    	\begin{itemize}
            \item Major difficulty with specifying concurrent systems is coping with timing.
            \item One technique to specifying systems with potential timing problems, is Petri nets.
            \item A petri-net consist of 4 parts:
            \begin{itemize}
                \item Set of places P
                \item Set of transitions T
                \item Input function I
                \item Output function O
            \end{itemize}
	    \end{itemize}
	\end{frame}
	\begin{frame}{Petri Nets: Example}
    	\begin{itemize}
            \item Set of places P is $\{p_1, p_2, p_3\}$
            \item Set of transitions T is $\{t_1, t_2\}$
            \item Input function $I(t_1) = \{p2, p4\}$ and $I(t_2) = \{p2\}$
            \item Output function $O(t_1) = \{p1\}$ and $O(t_2) = \{p3\}$
	    \end{itemize}
	    \includegraphics[scale=0.7]{img/03_petrinet_simple.png}
	\end{frame}
	\section{Z}
	\begin{frame}{Z}
    	\begin{itemize}
            \item Use of Z \cite{Spivey:1989:ZNR:61690} requires knowledge of set theory, functions, and discrete mathematics, including first-order logic.
            \item In this slide, we will use "The Elevator Problem" \cite[page 378]{Schach:2006:OCS:1207045} for use case
            \item In its simplest form, Z specification consists of:
            \begin{enumerate}
                \item Given sets, data types, and constants
                \item State definition
                \item Initial state
                \item Operations
            \end{enumerate}
	    \end{itemize}
	\end{frame}
	\begin{frame}{Z: 1 Given Sets}
    	\begin{itemize}
            \item Begins with a list of ``given sets''
            \item Name of such sets appear in brackets
            \item In elevator case, it is the \texttt{Button}, set of all buttons
            \item i.e. \texttt{[Button]}
            \item This \texttt{Button}, perhaps, is like a package name, since later we will meet a different one \texttt{button}
	    \end{itemize}
	\end{frame}
	\begin{frame}{Z: 2. State Definition}
    	\begin{itemize}
            \item Consists of a number of schemas (schemata)
            \item Each schema consists of a group of variable declarations and predicates that constrain the possible values of variables.
            \item In elevator case, there are four subsets of \texttt{Button}: floor buttons, elevator buttons, \texttt{buttons} (set of all buttons in case study), and pushed (set of buttons that have been pushed)
	    \end{itemize}
	    \includegraphics[scale=0.5]{img/03_z_button_state_schema.png}
	\end{frame}
	\begin{frame}{Z: 3. Initial State}
    	\begin{itemize}
            \item Abstract initial state describes the state when the system first is turned on.
            \item For elevator problem, the abstract initial state is as below.
	    \end{itemize}
	    \includegraphics[scale=0.5]{img/03_z_initial_state.png}
    	\begin{itemize}
            \item This asserts that when the elevator system is first turned on, the set \texttt{pushed} initially is empty; i.e. all buttons are off.
	    \end{itemize}
	\end{frame}
	\begin{frame}{Z: 4. Operations}
    	\begin{itemize}
            \item If a button is pushed for the first time, then that button is turned on. It is depicted below.
	    \end{itemize}
	    \includegraphics[scale=0.5]{img/03_z_push_button.png}
    	\begin{itemize}
            \item The following specification is for when an elevator arrives at a floor.
	    \end{itemize}
	    \includegraphics[scale=0.5]{img/03_z_floor_arrival.png}
	\end{frame}
	\section{Comparison}
	\begin{frame}{Comparison of Classical Techniques}
	\begin{footnotesize}
        \begin{table}[]
        \centering
        \begin{tabular}{| p{1.5cm} | p{1.5cm} | p{2.5cm} | p{2.5cm} |}
        \hline
        \textbf{Method} & \textbf{Category} & \textbf{Strengths}                                                                                & \textbf{Weakness}                                                                                \\ \hline
Natural Language                   & Informal          & Easy to learn, use, and understand                                                               & Imprecise, specification can be ambiguous                           \\ \hline
Structured Analysis                & Semiformal        & Can be understood by client, more precise than informal                                          & Not as precise as formal techniques; generally cannot handle timing \\ \hline
Petri Nets \& Z                    & Formal            & Extremely precise; can reduce analysis faults, development cost; can support correctness proving & Hard to learn and use; almost impossible for client to understand   \\ \hline
        \end{tabular}
        \end{table}
        \end{footnotesize}
\end{frame}

	\section{References}
	\begin{frame}[allowframebreaks]
        \frametitle{References}
        \bibliographystyle{amsalpha}
        \bibliography{module_03}
	\end{frame}

\end{document}
\end


\section{Standard Module \sectcode{whrandom}}

\stmodindex{whrandom}
This module implements a Wichmann-Hill pseudo-random number generator.
It defines the following functions:

\renewcommand{\indexsubitem}{(in module whrandom)}
\begin{funcdesc}{random}{}
Returns the next random floating point number in the range [0.0 ... 1.0).
\end{funcdesc}

\begin{funcdesc}{seed}{x\, y\, z}
Initializes the random number generator from the integers
\var{x},
\var{y}
and
\var{z}.
When the module is first imported, the random number is initialized
using values derived from the current time.
\end{funcdesc}


\section{Introduction}

A large proportion of systems programming is focused on the proper
handling of resources, like file handles, network connections, or
dynamically allocated memory. Each of these resources comes with a
protocol that prescribes the correct use of its API.
For examples, a file handle appears as the result of opening a
file. If it was opened for reading, then read operations will succeed,
but write operations will fail. Once the handle is closed, it cannot
be used for reading or writing, anymore.
%
Dynamic allocation of memory is similar. An API call returns a
pointer to a memory area, which can then be read and written to until
the area is released by another API call.

In both cases, a resource is created in a certain state and a resource
handle is returned to the program. Depending on this state, certain API calls
can safely be applied to it. Finally, there is another API call to
release the resource, which renders the handle invalid.
Taken to the extreme, each API call changes the state so that a
different set of API calls is enabled afterwards.
Ignoring such life cycle protocols is a common source of errors.
%% this is about typestate \cite{DBLP:conf/ecoop/BeckmanKA11}.

Most type systems provide type soundness and memory safety, but neglect the
protocol aspect. Systems that can support reasoning about protocols
build on linear types \cite{DBLP:journals/tcs/Girard87} and/or
uniqueness types~\cite{DBLP:conf/plilp/BarendsenS95}. A value of linear
type is guaranteed to be consumed
exactly once. That is, a file that has been opened must be closed and
memory that has been allocated must be released. A value of unique
type is guaranteed to have a single reference to it. Thus, memory can
be reused on consumption of the value.

These systems work well if one is prepared to write programs
functionally in resource-passing style. In this style, all operations
in the resource's API take the resource as a parameter and return it
in possibly modified state~\cite{DBLP:journals/jfp/AchtenP95}. In
typestate-oriented programming, they would also modify its
type~\cite{DBLP:conf/oopsla/AldrichSSS09}. Functional session types
represent a popular
example~\cite{DBLP:journals/jfp/GayV10,lindley17:_light_funct_session_types}.

Explicit resource passing places a heavy burden on the programmer and
complicates the program structure. For imperative APIs,
resource-passing style is not an option at all. To this end,
\citet{DBLP:conf/popl/BoylandR05}  proposed the notion of
\emph{borrowing} a resource. The idea is that a linear resource can be
borrowed to a function call. The function can work with a borrow of
the resource, but it cannot release the resource. Only the original
owner of the resource has the rights to release it.

The concepts of ownership and borrowing have grown popular over time
and they form the foundation of the type system of the Rust language
\cite{rust}, which considers any memory-allocated data structure a
resource. Rust supports two kinds of borrows,
shared and exclusive ones.
Exclusive borrows enable modification of the data structure
whereas shared borrows only grant read access.
At any given time, either a single exclusive borrow is active or
any number of shared borrows can be active.
Moreover, Rust makes sure that the lifetime of a
borrow is properly contained in the lifetime of its lender.

The design of Rust is geared towards programmers with a low-level
imperative programming background, like C or C++. Its management of
lifetimes supports the manual way of memory management customary in
these languages very well and makes it safe. However, programmers with
a background in managed languages feel alienated from the lack of garbage
collected data. They would prefer a setting where automatic memory
management with garbage collection was the default, but where they
could seemlessly switch to safe, manual resource management if that
was required.
%
As a concrete example, consider a functional programmer who wants to
safely interact with a C library. Invoking a C function is easy via
the existing foreign function interface, but managing the underlying
resources like malloc'd storage is not: it cannot be left to the
garbage collector, but proper release of the storage via calls to \texttt{free()} must be
ensured by programming conventions.

Our work provides a safe solution to programmers in this situation. We
propose an extended type system for ML-like languages that comes with
linear and affine types, exclusive and shared borrows, but all that
integrated with full principal type inference, garbage collected data, and
automatic placement of borrowing regions.
In our system, it is a type error to omit the call to release the
storage given a suitably typed API for storage allocation.

The most closely related contenders in this design space are Linear Haskell
\cite{DBLP:journals/pacmpl/BernardyBNJS18}, henceforth LH,
Quill \cite{DBLP:conf/icfp/Morris16}, and ALMS \cite{DBLP:conf/popl/TovP11}.
Compared to LH and Quill, the goals and means are
similar as these systems also permit abstraction over the number of uses of
values and retain type inference, but the details are different.
\begin{enumerate}
\item Multiplicities in LH and Quill are either linear or unrestricted whereas
  we also distinguish affine values.
\item In \lang{} and in Quill multiplicities are directly attached to the type of a
  value. For example, in \lang{} the function type \lstinline/'a-{lin}>'b/
  denotes the type of a \emph{single-use function} that can be called
  just once, whereas the multiplicities in LH choose
  between $\alpha\to\beta$ and $\alpha \multimap\beta$ where the
  latter is a function that promises to \emph{use its argument exactly
    once}.
\item \lang{} makes use of multiplicity contraints (like Quill) and kind
  subsumption (unlike Quill). Kind subsumption results in significantly simpler, more readable
  inferred types.
\item Neither LH nor Quill have borrowing whereas \lang{} supports
  two flavors: affine (exclusive, mutable) and unrestricted (shared, immutable) borrows.
\end{enumerate}
See \cref{sec:related-work} for further in-depth discussion of these
and other related works.

\subsection{First examples}
\label{sec:first-example}

\lstMakeShortInline[keepspaces,basicstyle=\small\ttfamily]@

\begin{figure}[tp]
  \begin{subfigure}[t]{0.35\linewidth}
    \lstinputlisting{code/writefiles.affe}
    \vspace{-15pt}
    \caption{File API}
    \label{fig:writing-files-api}
  \end{subfigure}~
  \begin{subfigure}[t]{0.3\linewidth}
\begin{lstlisting}
let main () =
  let h = File.fopen "foo" in
  File.write &!h "Hello ";(*@\label{line:hello}*)
  File.write &!h "world!";(*@\label{line:world}*)
  File.close h
\end{lstlisting}
    \vspace{-10pt}
    \caption{File example}
    \label{fig:writing-files-example}
  \end{subfigure}~
  \begin{subfigure}[t]{0.3\linewidth}
\begin{lstlisting}
let main () =
  let h = File.fopen "foo" in
  {| File.write &!h "Hello " |};(*@\label{line:hello}*)
  {| File.write &!h "world!" |};(*@\label{line:world}*)
  File.close h
\end{lstlisting}
    \vspace{-10pt}
    \caption{File example with regions}
    \label{fig:writing-files-example-region}
  \end{subfigure}
  \vspace{-10pt}
  \caption{Writing files}
  \label{fig:writing-files}
\end{figure}

As a first, well-known example we consider a simplified API for
writing files shown in \cref{fig:writing-files-api}.  It introduces a
linear abstract type @File.t@. A call like
@File.fopen "foo"@ returns a linear handle to a newly created
file, which \emph{must} be released later on with @File.close@
as shown in \cref{fig:writing-files-example}. Failing to do so is a
static type error.  To write to the file, we must take an exclusive
borrow @&!h@ of the handle and pass it to the
@File.write@ function. Exclusive borrows are affine:
they must not be duplicated, but there is no requirement to use
them. This affinity shows up in the annotation @-{aff}>@ of the second arrow in
the type of @File.write@: a partial application like
@File.write &!h@ captures the affine borrow and hence the
resulting function is also affine. It
would be an error to use the affine closure twice as in
\begin{lstlisting}[numbers=none]
let w = File.write &!h in w "Hello "; w "world!" (*type error*)
\end{lstlisting}
The remaining arrows are unrestricted and we write @->@ instead of the
explicitly annotated @-{un}>@.

Every borrow is restricted to a \emph{region}, i.e., a lexically
scoped program fragment from which the borrow must not escape. In
\cref{fig:writing-files-example}, there are two regions visualized in \cref{fig:writing-files-example-region}, one
consisting of \cref{line:hello} and another consisting of
\cref{line:world}. Both are fully contained in the scope of the linear
handle @h@, hence we can take one exclusive borrow @&!h@ in each
region. In both regions the borrow is consumed immediately by passing
it to @File.write@. \lang elaborates regions automatically before type
inference. Alternatively, programmers may mark regions explicitly (See
\cref{sec:imper-progr}).

This example demonstrates three features of our system:
\begin{enumerate}
\item type and region inference without annotations in user code (\cref{fig:writing-files-example}),
\item types carry multiplicity annotations in the form of kinds,
\item resource APIs can be written in direct style as linearity is a
  property of the type @File.t@.
\end{enumerate}

Direct style means that there is a function like @fopen@ that creates
and returns a linear resource. In contrast, LH forces programmers to
use resource-passing style because, in LH, linearity is a property of
a function, rather than a property of a value that restricts the way
that value can be handled (as in \lang). An LH API analogous to @File@
might provide functions like
\begin{itemize}
\item @withFile : path -> (handle o-> Unrestricted r) -> r@, which creates a new
  file handle and takes a continuation that uses the @handle@
  linearly, but returns an unrestricted value\footnote{For technical
    reasons, LH  requires the programmer to use a type like
    \lstinline/Unrestricted/ at this  point.},
\item @writeFile : string -> handle o-> handle@, which
  returns the transformed resource @handle@, and
\item @closeFile : handle o-> unit@, which consumes the @handle@ by
  closing the file.
\end{itemize}

In general, kinds can be polymorphic and constrained. Function
application and composition are the archetypical
examples for functions exploiting that feature.\footnote{\lang{}'s signature
  for application and composition are simpler than
  Quill \cite{DBLP:conf/icfp/Morris16} thanks to kind subsumption.}
For application, \lang{} infers the following type.
\begin{lstlisting}[numbers=none]
let app f x = f x
# app : ('a -{'k}> 'b) -> ('a -{'k}> 'b)
\end{lstlisting}
The reading of the inferred type is straightforward. If
@f@ is a @'k@-restricted function, then so is
@app f@. The multiplicities of @'a@ and
@'b@ play no role. As usual in ML-like languages, we
implicitly assume prenex quantification by
$\forall\kappa\forall\alpha\forall\beta$. Internally, the
type checker also quantifies over the kinds of $\alpha$ and $\beta$,
but the full prefix
$\forall\kappa\kappa_1\kappa_2\forall(\alpha:\kappa_1)\forall(\beta:\kappa_2)$
of the type of @app@ is only revealed as much as necessary for
understanding the type.

For @compose@, \lang{} infers this type.
\begin{lstlisting}[numbers=none]
let compose f g x = f (g x)
# compose : ('k <= 'k_1) => ('b -{'k}> 'c) -> ('a -{'k_1}> 'b) -{'k}> ('a -{'k_1}> 'c)
\end{lstlisting}
Like in @app@, the multiplicities of the type variables
@'a,'b,'c@ do not matter. However, the multiplicity
@'k@ of @f@ reappears on the second to last arrow
because @compose f@ is a closure that inherits
@f@'s multiplicity. The multiplicities of @g@  and
@f@ both influence the multiplicity of the last arrow, so
we would expect its annotation to be the least upper bound
$\kappa \sqcup \kappa_1$. Thanks to subsumption of multiplicities, it
is sufficient to assume $\kappa \le \kappa_1$ and @g@'s
actual multiplicity gets subsumed to $\kappa_1$. This constraint
simplification is part of our type inference algorithm. As before,
printing the type scheme only mentions the non-trivial constraint
$\kappa\le\kappa_1$ and omits the prenex quantification over $\kappa,
\kappa_1$ as well as the kinds of @'a,'b,'c@.

\lstDeleteShortInline@

\subsection{Contributions}
\label{sec:contributions}

\begin{itemize}
\item A polymorphic type system that encodes linearity and affinity with
  borrowing in lexical regions. Polymorphism covers types and kinds that
  express multiplicity constraints on the number of uses of a
  value. This type system is a conservative extension of
  existing ML-like languages.
\item Expressive type soundness theorem with respect to a big-step linearity-aware semantics.
\item An extension of the \hmx framework
  \cite{DBLP:journals/tapos/OderskySW99} for constrained type
  inference to equip the type system with full, principal type inference.
\item Soundness proof of the inference algorithm.
% \item Constraint simplification techniques.
\item Automatic inference of regions for borrows.
\item A prototype implementation of the type inference algorithm, including all
  constraint simplification and extended with algebraic datatypes and
  pattern matching,
  available at \url{https://affe.netlify.com/}.
\end{itemize}

As \lang{} is built on top of the \hmx{} framework, which is a general
framework for expressing constraint-based typing and type inference,
the extension of our work with features like typeclasses, ad-hoc overloading,
traits, etc is possible and orthogonal to the presentation in this paper.
While the system is geared towards type inference, it is nonetheless
compatible with type annotations and thereby amenable to extensions
where type inference may no longer be possible.

%%% Local Variables:
%%% mode: latex
%%% TeX-master: "main"
%%% End:


%% ----------------------------------------------------------------
%% Chapter 6: Conclusions and future work
%% ----------------------------------------------------------------
%!TeX root = subfile
\label{chapter:conclusions}
\documentclass[../main.tex]{subfiles}
% ----------------------------------------------------------------
\begin{document}

\section{Summary of contributions}

This work proposes to drastically speed up turbulent flow simulation by averaging in a homogeneous direction, such as along the span of a marine riser, a slender building, or an aircraft wing.
Differently from standard strip-theory methods, 3-D turbulence effects are directly incorporated in the 2-D system as closure terms, thus significantly improving current 2-D models.
This has been accomplished with the following main contributions,
\begin{itemize}
	\item Improved physical understanding of the role of small-scale 3-D structures in high-Reynolds incompressible wake flow and the forces induced to the cylinder.
	\item A new 2-D model arising from a dimensionality reduction of the 3-D flow by local spanwise averaging.
	\item The design of a ML closure for the spanwise-averaged equations system based on a CNN.
\end{itemize}

First, the 3-D effects inherent in turbulent flows which present an homogeneous direction have been investigated by a systematic reduction of the span of a circular cylinder at $Re=10^4$.
Multiple span lengths ranging from a pure 2-D system to 10 diameters have been analysed using highly-resolved simulations.
Different turbulence metrics of the wake have revealed that small-scale 3-D structures can be observed even when the span is less than half a diameter long.
The small-scale structures generated in the shear layer are rapidly two-dimensionalised by the natural large-scale rotation of the K\'{a}rm\'{a}n vortices, a mechanism also encountered in obstacle-free turbulent flows \citep{Smith1996,Xia2011}.
It has been found that the critical span at which 3-D turbulence dynamics dominate the wake is the Mode B instability wavelength (approximately one diameter), in agreement with \cite{Bao2016}.
Since the Mode B instability helps sustaining the turbulent structures advected from the shear layer, the lack of it prevents large-scale 3-D structures to be created and less dissipative structures can be sustained.
Additionally, it has been also shown that 2-D and 3-D turbulence dynamics can coexist at certain positions of the wake depending on the domain geometric anisotropy.

In order to reduce the computational cost of simulating turbulent wake flow, a model based on the flow spatial average in its homogeneous direction is proposed, thus reducing the problem dimensionality from 3-D to 2-D.
This 2-D model, namely the spanwise-averaged Navier--Stokes (SANS) equations, incorporates 3-D effects in the form of SSR closure terms, which change the flow dynamics from standard 2-D Navier--Stokes to spanwise-averaged dynamics.
The verification of the SANS equations has been conducted for the Taylor--Green vortex and the cylinder wake flow cases using the perfect closure model.
The perfect closure is the residual between the spanwise-averaged 3-D spatial operator and the 2-D spatial operator of the momentum equations.
For both test cases, extracting the perfect closure from a 3-D simulation and inserting it into the 2-D solver has allowed to recover the unsteady spanwise-averaged flow, as shown in the temporal evolution of global energy and enstrophy.
For the circular cylinder test case, including the perfect closure in the SANS simulation yields forces induced to the cylinder as obtained in the high-fidelity 3-D simulation at a fraction of its computational cost.

Since the perfect closure is not available when deploying SANS in a live simulation, alternative models have been investigated.
A standard EVM employing the Smagorinsky closure has been tested in the a-priori framework.
The EVM has provided very low accuracy for the modelling of the SANS closure terms.
This is related to the intrinsic formulation of the eddy-viscosity hypothesis, which assumes that turbulent fluctuations only have a dissipative effect.
In the spanwise-averaged system, the spanwise stresses can be both dissipative and energising, and this is a fundamental difference which no EVM can reproduce.

Because of the EVM poor performance, a data-driven approach has been designed to improve the SANS closure terms prediction.
The use of data-driven model for a SANS strip-theory method is advantageous because the training dataset can be obtained in a 3-D high-fidelity simulation only comprising the spanwise-averaging length, instead of the full span (as in \fref{fig:strips}, where $L_a\ll L_z$).
This is justified by the flow spanwise homogeneity, since an equivalent dataset would be obtained for a 3-D simulation in a spanwise-shifted location.
The trained ML model could then be used for all the 2-D strips in a SANS strip-theory framework.
A ML model based in a CNN has been considered for the modelling of the spanwise stresses, and a dataset of the closure terms has been generated for a circular cylinder of one diameter span.

In the a-priori analysis, the ML model prediction of the anisotropic SSR tensor components has provided correlations of 90-92\%, thus greatly improving the EVM performance.
While large-scale structures were overall correctly captured, small-scale structures were still hard to predict, as also found in other CNN-based data-driven models for turbulent flows \citep{Lee2019}.
Additionally, the ML model trained with a single test case (circular cylinder at $Re=10^4$) has been assessed for other Reynolds regimes and body geometries.
It has been observed that the ML model is still capable of correctly predicting the SANS closure terms in the downstream wake region with high correlation values ($86\%-96\%$).
On the other hand, the prediction of the near-body region has shown a poorer performance because of the case-dependent shear layer that different flow regimes and body geometries develop.

In the a-posteriori analysis, it has been found that applying the divergence operator to the raw output of the SSR tensor ML model prediction amplifies the modelling error significantly, hence yielding an unstable closure as also observed in \cite{Cruz2019}.
Because of this, the perfect closure has been targeted as the new ML model output, instead of the SSR tensor components, so that no derivatives are directly applied to the ML predictions.
The ML model a-priori performance on the perfect closure terms showed correlations of 89-90\% with the target quantities.
In the a-posteriori analysis, the ML model predicts the perfect closure at every time step based only on the resolved flow quantities $(\vect{U},P)$.
While we found evidence of known stability issues with long-time ML model predictions for dynamical systems, the closed SANS simulations are still capable of predicting wake metrics and induced forces with errors from 1-10\%.
This results in approximately an order of magnitude improvement over standard 2-D simulations while reducing the computational cost of 3-D simulations by 99.5\%.

\section{Technical achievements}

The fluid solver used throughout this thesis is the in-house 3-D iLES immersed-boundary code ``Lotus'', described in \cref{chapter:theoretical_background} and developed by Gabriel D. Weymouth as an extension of the 2-D real-time fluid solver ``Lily Pad'' \citep{Weymouth2015-LilyPad}.
Contributions to ``Lotus'' have been made to accommodate the solver for the needs of this work (or not) such as an extension for internal flows, addition of a passive scalar equation, adaptation of the software package to be run in HPC facilities (supercomputers), and an interface to allow data transfer between the Fortran fluid solver and the Python ML model \citep{Font2019-f2py}.
More details of the Fortran-Python interface can be found in \aref{chapter:appendixE} together with specifications of the hardware employed.

As any computational investigation, a significant part of the workload has been spent in post-processing data.
All the developed post-processing tools have been gathered in \cite{Font2018-postproc}, such as the analysis of turbulence statistics, tracking flow separation points on the cylinder surface, data plotting and video rendering, among others.
On the other hand, the implemented ML model providing closure to the SANS equations can be found in \cite{Font2019-sanspy}.
It has been written using Keras \citep{Chollet2015}, a high-level deep-learning Python library employing TensorFlow \citep{Tensorflow} as backend.

\section{Limitations}

The SANS equations have been proposed as an improvement of current 2-D strip-theory methods, which do not take into account the 3-D turbulence effects of the flow and instead use arbitrarily dissipative turbulence models.
However, some intrinsic limitations of standard strip-theory methods would also apply to a SANS-based strip-theory method.
For example, strip-theory methods cannot directly capture variations of the flow out-of-plane angle of attack or twisting of the cylinder.
In this scenario, the flow would no longer be homogeneous in the spanwise direction and the SANS system would struggle to provide a physical answer.
Regarding the strips spanwise resolution, the minimum number of 2-D planes still depends on the highest mode of the structural response, and three 2-D planes per half wavelength would be required \citep{Willden2004}.

With respect to the SANS equations closure, known limitations of ML models have also been faced.
A certain degree of randomness of the ML model has been observed both in a-priori and a-posteriori frameworks.
This is derived from the fact that the CNN weights are initialised in a random manner and that stochastic backpropagation is used for the CNN weights optimisation.
This has translated in failed trainings of the CNN as well as converged optimisations which yield poor results in the a-posteriori analysis.
In these cases, the training has been repeated until a better local minima was reached.

The generalisation of the ML model to flow configurations different from the training case (in terms of Reynolds number and body geometry) has also presented difficulties in the prediction of the SANS closure terms near the body.
This arises from fact that the shear-layer region is strongly case-dependant and such information was only provided by the single training case.
Adding other flow configurations to the database could help mitigate this issue.

Furthermore, the ML model error accumulation in the resolved quantities during an a-posteriori run is an important limitation of the current approach.
Although successful for short temporal dynamics, the implemented ML model diverges from the spanwise-averaged attractor at every time step.
Eventually, it yields a non-physical solution and the simulation has to be stopped.
Still, the current model works as a proof-of-concept which simultaneously serve the purpose of motivating other authors to develop new closures of the SANS equations.

\section{Recommendations for future work}

All the exposed limitations of the current work offer an opportunity for improvement.
The main impediment encountered is, as exposed, the limited closure stability of the current ML model for the SANS equations.
The development of a general and stable closure for SANS could represent a turning point in the simulation of slender bodies as a result of new SANS strip-theory methods.
In this regard, the following ideas could be worth exploring:
\begin{itemize}
	\item A CNN model embedded in a RNN architecture to capture both the spatial patterns and the temporal dynamics of the SANS closure terms.
	In convolutional RNNs, a series of consecutive snapshots are provided as input data so that the model learns how spatial structures evolve in time.
	RNNs have demonstrated to be successful for the prediction of statistically-stationary metrics in chaotic systems \citep{Vlachas2018,Kim2020a}.

	\item Adding a physical constraint in the loss function (a.k.a physics-based machine learning, or PBML) has also been useful for improving the stability of ML-based closures, as shown in \cite{Lee2019}.
	At the same time, the dataset size required for optimisation can be significantly reduced when using PBML models \citep{Weymouth2019}.

	\item Projection of the ML model predictions into a stable closure. This has been done for a ML model of SGS stresses in a LES framework, where the ML model output is fit into an EVM \citep{Beck2019}.
	This approach would not work for the SANS equations since it has been shown that EVMs are not suited for the modelling of spanwise stresses.
	Still, a stable closure accounting for production and dissipation of the closure terms similarly to Reynolds-stress models in RANS could be investigated.

	\item Learning how to reverse the 2-D dynamics domination over the spanwise-averaged dynamics.
	This could be explored by feeding the ML model a spanwise-averaged snapshot followed by snapshots evolved without the inclusion of the SSR terms.
	The model would be informed that this temporal dynamics are to be corrected by providing the actual spanwise-averaged snapshot of the next time step in the loss function.
	In this way, the ML model weights can be optimise to prevent or reverse 2-D dynamics back to spanwise-averaged flow.

	\item Use of a generative adversarial neural network \citep{Goodfellow2014} able to discern when the ML model prediction is not within the spanwise-averaged system attractor.
	This can also help identifying the 2-D dynamics dominating the flow and trigger a corrective action.
	Such corrective action could be the projection of the 2-D dominated flow field into a realistic spanwise-averaged snapshot according to examples previously shown during training.
\end{itemize}
% ----------------------------------------------------------------
\end{document}


\chapter{Forecasting stochastic processes}


\chapter{Conclusion}
\label{sec:conclusion}
\cleanchapterquote{If you thought that science was certain - well, that is just an error on your part.}{Richard Feynman \citep[p. 349]{feynman2015quotable}}{Theoretical physicist}

To conclude the thesis, we briefly summarize our approach and list our key contributions, followed by an outline for future work and the limitations inherent in our study.

\section{Summary}
Our work demonstrated that supervised hierarchical autoencoders with Sparse-Group-Lasso regularization could effectively integrate multi-omics data in cancer survival models. They performed on-par with the best statistical method in a recent large-scale benchmarking study \citep{herrmann2021large}, \glsxtrfull{bf}, and one of its variants, \glsxtrfull{rbf} in terms of Harell's concordance. We benchmarked all models on $17$ cancer datasets of \glsxtrfull{tcga}, following the dataset selection strategy by \citet{herrmann2021large}.

We further investigated the representations learned by our models by computing correlations between the latent space of our autoencoders and selected input features to understand which variables were preferentially carried through the model. This analysis proved that our models were able to learn feature interactions on a clinical and molecular level. However, we also saw that the study of the latent space correlations could be misleading since it does not capture all of the information inherent in the model. Thus, researchers should always consider a second explanatory technique to understand which features and feature groups their model uses instead of only relying on the latent space.

We established surrogate models of \gls{shae} as an excellent alternative to other sparse regression models (\emph{e.g.,} the Lasso), as they provide comparable sparsity levels but greatly improved performance. The good downstream performance of our surrogate models also suggests the possibility of using neural networks (or other multi-omics integration models) only as a feature selection step rather than a final model.

Summing up, the main novel contributions made by our work were the following:

\begin{enumerate}
    \item We proposed several novel neural architectures for multi-omics integration in cancer survival models based on supervised autoencoders and \gls{sgl} regularization. We showed that the best of these architectures, \gls{shae}, could perform as well as or better than \gls{bf}, the best performing method in a recent benchmarking study of multi-omics integration methods in survival analysis.
    \item We proved that surrogate models could be trained to approximate the predictions of \gls{shae}, even when the surrogate models did not have access to all input variable groups on which \gls{shae} was trained. In turn, this enables the creation of simple regression models which are highly sparse and can outperform \gls{cox}, almost performing as well as the best multi-omics integrative models. This is especially valuable in clinical settings as it allows for the deployment of multi-omics integration methods at high sparsity levels.
    \item We posed and partially answered the question of whether multi-omics integration could be reduced to a feature selection problem. We showed that even when trained on the same subset of variables selected by our surrogate models, a \glsxtrfull{rsf} and Ridge regularized Cox PH model could not perform as well as the surrogates. This preliminarily suggests that the excellent performance of the surrogates was not \emph{only} due to the features they selected. Thus, multi-omics integration seems not \emph{fully} reducible to a feature selection problem. However, choosing a small subset of good features did improve the performance of \gls{rsf}, and Ridge regularized Cox PH relative to fitting them on all features.
\end{enumerate}

\section{Future work}
There are a few avenues of future work connected with our approach in this study which we did not have time or resources to pursue further. First and foremost, it would be interesting to disentangle the effects of \gls{sgl} regularization, the supervised autoencoders, and the hierarchical autoencoder architecture on model performance. This may yield additional insights as to which architectures should be preferentially explored in future work.

Another avenue concerns the favoring of the clinical variables. We explored the residual approach here, where we both fed clinical data into our autoencoder and skipped it to the end, where it was fed directly into the linear layer connected to the final log-partial hazard prediction. One straightforward extension would explore differentially regularizing the latent space from the autoencoder and the skipped clinical data, either using different penalty factors, similar to \emph{ipflasso} \citep{boulesteix2017ipf} or applying Group-Lasso or \gls{sgl} regularization.

There may also be completely different mechanics of favoring clinical (or other modalities) which we did not consider - one such option includes a dense approach in which the favored block could be skipped to each linear layer within the second level encoder as well as to the final log-partial hazard linear layer, reminiscent of the architecture of \emph{DenseNets} \citep{huang2017densely}.

Further exploring the extension of \gls{sgl}, weighted \gls{sgl} could be interesting as well. We could modify the loss of \gls{shae} (Equation \ref{eq:loss-shae}) to include penalty factors \(\zeta, \omega\) for each input modality \(m\) (Equation \ref{eq:shwsglae-loss}).

\begin{equation}
  \begin{split}
  &L_{\text{total}}  \left(\hat \varphi, \hat \phi_1, ..., \hat \phi_{|M|}, X, \hat X, C, \hat C\right) \\ &=  L_{\text{cox}}(T, \delta, \hat \varphi)  + \xi \cdot \text{MSE}(C, \hat C) \\&+ \sum_{q = 1}^{|M|}  \left(L_{\text{cox}}(T, \delta, \hat \phi_q ) + \gamma \cdot \text{MSE}\left(X^{\left(m_q\right)}, \hat X^{\left(m_q\right)}\right)\right) \\&+ \lambda_1 \sum_{a \in A \setminus B} ||a||_F^2 +\lambda_2 (1 - \alpha) \sum_{m \in \{m_1, ..., m_{|M|}\}} \sqrt{|m| \zeta_m} ||B^{(m)}||_F  \\&+  \lambda_2  \alpha ||\omega B||_{1,1}
  \end{split}
\label{eq:shwsglae-loss}
\end{equation}

Where $\zeta$ is a weight vector adjusting the weight of the Group-Lasso penalty for each group, and $\omega$ is a weight vector modifying the weight of the Lasso penalty for each variable. $B^{(m)}$ is a submatrix of $B$ containing only columns corresponding to inputs of modality $m$.

While we implemented this option for weighted \gls{sgl} in our code, we did not have time to investigate the tuning of these penalty factors properly, either through a two-step approach like the adaptive version of \emph{ipflasso} \citep{boulesteix2017ipf} or using cross-validation. Nevertheless, we expect these penalty factors to evoke only minor performance increases in our architectures. Since \gls{shae} already performs multi-omics integration by mapping each modality to the same dimension before the second level autoencoder, we expect any performance gains to be smaller than those seen when comparing \gls{lasso} and \emph{ipflasso}.

There is also a distinct possibility to extend our models using a transfer learning approach, that is, adopting a similar strategy as \citet{kim2020improved} by, \emph{e.g.,} training the first-level autoencoders on all cancers together before fine-tuning the second-level autoencoder on each cancer individually. When we very briefly experimented with a transfer learning approach, we found that great care must be taken to leverage the information shared across cancers while not limiting the model's specificity to each cancer, mainly due to the imbalance with respect to cancer type present in most datasets (Table \ref{tab:tcga-overview}).

\section{Limitations}
Our work has some limitations: First and foremost, we chose a fixed initial learning rate and number of epochs for our models that may have caused overfitting, even though we did not choose these hyper-parameters based on their test performance. Therefore, more experiments should be conducted to validate the robustness of \gls{shae} to its different hyper-parameters as well as modern techniques for learning rate scheduling such as cosine annealing \citep{loshchilov2016sgdr}.

In addition, we did not investigate the tuning or effect of the architectural hyper-parameters of our models. Factors such as the depth and width of the encoders and the latent spaces may play a prominent role in achieving optimal performance and improved understanding of the models. Since our main objective in this work was to validate the effectiveness of supervised autoencoders for multi-omics integration more broadly (instead of optimizing every ounce of performance), we were not concerned with tuning every parameter.

We also only benchmarked on \gls{tcga}; even though this is a common strategy among researchers, future work should run a comparable benchmark, including statistical methods and neural networks on another large-scale multi-omics survival dataset. Furthermore, future studies should ideally run experiments such as the current ones with a higher number of outer repeated cross-validation folds (for example, \citet{hornung2019block, herrmann2021large} both used 5x5 or higher). In addition, ideally, models should even be re-run multiple times with different seeds to guard against having one or more of the models hit a lucky seed. An ideal benchmark would thus run \emph{e.g.,} a 5x5 cross-validation (five times outer cross-validation, five times repeated) where each of the outer cross-validation folds is run with five different seeds, effectively resulting in $5*5*5 = 125$ total (outer) fits.

Lastly, our exploration of surrogate models should be taken with a grain of salt. Despite their good performance, our approach does not have any statistical guarantees that we are aware of.


%!TEX root = soutenance_lei_2018.tex
\subsection{Detection of insulation flaws and thermal bridges in insulated truck box panels}
\frame{\tableofcontents[currentsection,currentsubsection]}

\begin{frame}{Outline}
    ATP standard tests: \textbf{Global} results\\
    % \textbf{Local} defects ==> \alert{Infrared Thermography}

    Time consuming!\\
    In summer, not economical.
    \\
    ATP standard method uses heating inside and cooling outside.\\
    Can we just cool the outside to see the difference?\\
    \pause
    ==> Using {\color{cyan}{compressed air}} instead of \alert{radiator!}
\end{frame}

\begin{frame}{Methods--Specimen}
    \begin{figure}[ht]
    % \centering
    \hspace*{-20pt}
    \subfloat[Panel detail]
    {
        \includegraphics[scale=0.35]{img/ch4/Panel_detail.png}
    }
    \pause
    \subfloat[Panel done]
    {
        \includegraphics[scale=0.265]{img/ch4/Panel_done.jpg}
    }
    \caption{Truck panel specimen}
    \end{figure}

\end{frame}

\begin{frame}{Experimental Set-up}
    \begin{figure}[ht]
        \centering
        \includegraphics[scale=0.4]{img/ch4/Exp.png}
    \end{figure}
\end{frame}

\begin{frame}{Simulation models}
 The governing pure conduction equation:
    \begin{equation*}
        \rho C_p \frac{\partial T}{\partial t}-\nabla \cdot (k\nabla T) = 0
    \end{equation*}
The boundary condition (convection and radiation):
    \begin{equation*}
        n(k\nabla T) = q_0 + h_{cv}(T_{amb}-T)+\sigma \epsilon(T_{amb}^4-T^4)
    \end{equation*}
\pause
    \begin{description}
        \item[Lamp {\color{red}{Heating}}] \textit{Heat transfer in Solid with surface-to-surface Radiation} module
        \item[{\color{cyan}{Air Cooling}}] Heat transfer and CFD modules
    \end{description}
\end{frame}

\begin{frame}{Mesh}
    \begin{figure}[ht]
    % \centering
    \hspace*{-22pt}
    \subfloat[Lamp {\color{red}{Heating}} meshes]
    {
        \includegraphics[scale=0.38]{img/ch4/Mesh_flash.png}
    }
    % \pause
    \subfloat[Air {\color{cyan}{Cooling}} meshes]
    {
        \includegraphics[scale=0.38]{img/ch4/Mesh_laminar.png}
    }
    \caption{Simulation meshes}
    \end{figure}

\end{frame}

\begin{frame}{Results}
Experimental results:

    \begin{figure}
        \hspace*{-20pt}
        \subfloat[Lamp {\color{red}{Heating}}]
        {
            \includegraphics[scale=0.42]{img/ch4/Heat_FT_AMP.png}
        }
        \subfloat[Air {\color{cyan}{Cooling}}]
        {
            \includegraphics[scale=0.42]{img/ch4/Cool_PCT3_2.png}
        }
        \caption{Experimental results (PCT 3rd image)}

    \end{figure}
\end{frame}

\begin{frame}{Results}
Computational results:

    \begin{figure}
        \hspace*{-20pt}
        \subfloat[Lamp {\color{red}{Heating}}]
        {
            \includegraphics[scale=0.50]{img/ch4/Truck_panel_flash_03.png}
        }
        \hspace*{8pt}
        \subfloat[Air {\color{cyan}{Cooling}}]
        {
            \includegraphics[scale=0.50]{img/ch4/Truck_panel_laminar_final_7_3.png}
        }
        \caption{Computational results}

    \end{figure}
\end{frame}

\begin{frame}{Quantitative comparison}

    \begin{figure}
        \hspace*{-20pt}
        \subfloat[{\color{red}{Exp.}} Lamp Heating]
        {
            \includegraphics[scale=0.42]{img/ch4/heating_evolution5.png}
        }
        % \hspace*{8pt}
        \subfloat[{\color{cyan}{Sim.}} Lamp Heating]
        {
            \includegraphics[scale=0.37]{img/ch4/Truck_panel_Flash_TGraph_4.png}
        }
        \caption{Quantitative results}

    \end{figure}
\end{frame}

\begin{frame}{Quantitative comparison}

    \begin{figure}
        \hspace*{-20pt}
        \subfloat[{\color{red}{Exp.}} Air Cooling]
        {
            \includegraphics[scale=0.42]{img/ch4/cooling_evolution4.png}
        }
        % \hspace*{8pt}
        \subfloat[{\color{cyan}{Sim.}} Air Cooling]
        {
            \includegraphics[scale=0.37]{img/ch4/Truck_panel_laminar_TGraph_4.png}
        }
        \caption{Quantitative results}

    \end{figure}
\end{frame}

\begin{frame}{Discussion}
    \begin{itemize}[<+->]
    \pause
    \large
        \item Detection of steel dusts, water defects and thermal bridge
        \item Heating approach provides clearer results
        \item Compressed air spray is faster
        \item Practically convenient with air spray than the heating method in providing successful detection
    \end{itemize}
\end{frame}


\section{Picoquant}
\subsection{Purpose}
This program decodes binary data from the Picoquant software and outputs the data in human-readable format. Currently, \program{picoquant} supports most modes and versions of the Timeharp, Picoharp, and Hydraharp. The board and mode are detected automatically, and if the mode is not supported an error message will explain the details.

Modes and software versions supported:
\begin{itemize}
\item Timeharp: v20 (thd), v30 (thd, t3r), v50 (thd), v60 (thd, t3r)
\item Picoharp: v20 (phd, pt2, pt3)
\item Hydraharp: v10 (hhd, ht2, ht3)
\end{itemize}

\subsection{Command-line syntax}
%\input{programs/picoquant.usage}

\subsubsection{Input}
The input is either binary stream of data from the timing hardware, or the name of a file containing that data. The details of each format are too varied and verbose to be summarized here, but are laid out in section~\ref{sec:formats}.

\subsubsection{Output}
\label{sec:picoquant_output}
The output will either be written to \stdout{} or the file specified. The output format depends on the mode of the data (interactive, t2, t3), with details given below.

\paragraph{Interactive}
Each record is of the form:
\begin{verbatim}
struct {
    int curve;
    double left_edge;
    double right_edge;
    int counts;
};
\end{verbatim}
printed as:
\begin{verbatim}
curve number, left edge of time bin, right edge of bin, counts \n
\end{verbatim}

\paragraph{T2}
Each record is of the form:
\begin{verbatim}
struct {
    int channel;
    long long time;
};
\end{verbatim}
printed as:
\begin{verbatim}
channel number, time \n
\end{verbatim}

\paragraph{T3}
Each record is of the form:
\begin{verbatim}
struct {
    int channel;
    long long pulse_number;
    int time;
};
\end{verbatim}
printed as:
\begin{verbatim}
channel number, pulse number, time \n
\end{verbatim}

\subsection{Examples of usage}
\subsubsection{Reading header information}
\begin{verbatim}
> picoquant --file-in data.phd --header-only
Ident = PicoHarp 300
FormatVersion = 2.0
CreatorName = PicoHarp Software
CreatorVersion = 2.3.0.0
FileTime = 14/05/11 17:55:48
Comment = Untitled
NumberOfCurves = 8
   ....
\end{verbatim}

Reading these values is often a good way to check the integrity of a file, and to make sure that the correct settings are used in later processing. The keywords used here are consistent with those used in the documentation for the file type as provided by Picoquant, so common values like measurement resolution may not be identical across versions and boards.

\subsubsection{Obtaining the resolution of a measurement}
Resolution values must be multiples of 1\pico\second{} for most of the devices, but for the Timeharp they are integer divisions of 1\nano\second, leading to non-integer multiples of 1\pico\second. As such, all resolution values are presented as floats, even those which could be written as integers.
\begin{verbatim}
> picoquant --file-in data.phd --resolution-only
0,1.280000e+02
1,1.280000e+02
2,1.280000e+02
3,1.280000e+02
4,1.280000e+02
5,5.120000e+02
6,1.280000e+02
\end{verbatim}
Interactive mode allows for a large number of curves, so the resolution report gives the resolution for each curve, by index.
\begin{verbatim}
> picoquant --file-in data.pt2 --resolution-only
1.280000e+02
\end{verbatim}

\subsubsection{Reading interactive data}
\begin{verbatim}
> picoquant --file-in data.phd
0,0.000,0
...
3,4.482,4.484,2620
3,4.484,4.486,2595
3,4.486,4.488,2601
3,4.488,4.490,2604
3,4.490,4.492,2447
3,4.492,4.494,2407
3,4.494,4.496,2418
...
\end{verbatim}

\subsubsection{Reading T2/T3 data}
\begin{verbatim}
> picoquant --file-in data.pt2
0,7128264
0,20957636
0,33684532
0,36576452
0,42146280
0,42251400
0,65787700
0,75149552
0,86537580
0,109288316
> picoquant --file-in data.pt3
1,103,47360
1,109,47616
1,115,85760
1,115,248832
1,213,55552
1,245,244992
1,254,49920
1,267,69888
1,268,122368
1,274,58624
\end{verbatim}

\subsubsection{Translating T3 data to T2 data}
\begin{verbatim}
> picoquant --file-in data.pt3 --to-t2
1,41248184
1,43648488
1,46086680
1,46249752
1,85257256
1,98246952
1,101651952
1,106872024
1,107324512
1,109660816
\end{verbatim}

\subsection{Mode- and hardware-specific information}
\label{sec:formats}

While there are many differences between the formats of the files generated by the different boards and modes, they all follow a common structure:
\begin{itemize}
\item a general header identifying the board type and software version
\item a board-specific header, identifying hardware and software configuration
\item a mode-specific header
\item data
\end{itemize}

As such, the process of streaming data can be broken down into the following steps:
\begin{enumerate}
\item Identify the board type (\texttt{picoquant.c})
\item Identify the software version used to generate the file (\texttt{hydraharp.c}, \texttt{picoharp.c}, \texttt{timeharp.c}).
\item Determine the collection mode used (\texttt{hydraharp/hh\_*.c}, $\ldots$).
\item  \begin{enumerate}
  \item If the run is specified as resolution-only or header-only, print the appropriate values.
  \item Otherwise, read through the remaining header information and print the data.
  \end{enumerate}
\end{enumerate}

In this implementation, while the code used to produce the data and headers is very similar between software versions for a given board, there are some small differences which make a general program difficult to write. As such, each version is hard-coded, and any changes to the overall structure of the program must be rolled out to all versions. Fortunately, many common tasks such as printing of data are centralized in \texttt{picoquant.c}, so changes to the output format only require modification of a single function.

In principle, the code can be collected into a nicer data-streaming object which masks the translation process and yields only the resulting data stream. This is probably the most convenient way to deal directly with developing custom tools for data processing, but for most purposes passing the data through pipes should be sufficient. If such an interface is desired, the low-level translation functions (found in \texttt{*/*\_v*.c}) should be sufficient when wrapped with higher-level logical routines like those used to determine the board identity and version. The function structure is uniform across all versions and boards, which should simplify the wrapping process.

The remainder of this section is devoted to a discussion of the details important to each board and measurement type. Most of this information can be found in the manuals included with the hardware, but there is a significant amount of information which is documented in more scattered locations, such as the sample data code. This summary includes the details vital to understanding how the raw data are actually translated into the general data streams, and how various design decisions affect the quality and precision of the result.

\subsubsection{A word about external markers}
Many of the timing boards have a feature which allows the insertion of an external timing pulse into the signal, for use in TTTR modes to designate a raster scan or other time-dependent behavior. These records are not handled directly by \program{picoquant}, but instead a message is passed to \stderr{} indicating that such a record exists. If different behavior is desired (perhaps assignment of the marker to a non-existent channel), modify the function \texttt{external\_marker} in \texttt{picoquant.c}. This will cause problems with the other programs, which assume every record originates from the true signal stream, so such an alteration must be accompanied by code which appropriately splices the signal stream, for example by halting collection into a histogram and initiation of a new one.

\subsubsection{T3 timing carries units of histogram bins, not time}
In T3 modes--including T3R for the Timeharp--the pulse dimension carries units of pulse number, but the time is not strictly a time with fixed units. Instead, the specified resolution of the interactive mode is the unit of time, such that the measurement is affected directly by this choice of resolution. As a result, the T3 record more directly reflects the index of the bin the record would have fallen into in interactive mode. In \program{picoquant} this value is converted to units of \pico\second{} implicitly, but do be aware of this distinction.

\subsubsection{Translation of T3 to T2 data}
In principle, if the sync source of a T3-mode experiment arrives with perfectly uniform spacing, the pulse number can be said to represent some constant amount of time, and a T2-like record recovered. To do this, pass the flag \texttt{--to-t2} for an input of T3 data, but consider the implications of how this translation is performed (see section~\ref{sec:t3_to_t2}).

In \program{picoquant}, the average rate of sync pulses is used to determine the time unit a pulse carries.

%For a frequency $f$ of the arrival of a sync source, pulse number $p$ and time delay $t$ on channel $c$ map as:
%\begin{equation}
%\left(c, p_{j}, t_{j}\right) \rightarrow \left(c_{j}, \frac{p_{j}}{f} + t_{j}\right)
%\end{equation}
%In practice, this mapping is limited in precision in a few important ways. First, the period $1/f$ is not necessarily an integer multiple of 1\pico\second, and any precision will be lost beyond the decimal. This is not usually a problem because typical sync sources operate at 10\mega\hertz{} at most, for a precision of timing to one part in ten thousand, and a purity of the pulse train to this precision is not typical. Additionally, the timing jitter of most lasers will be well above this threshold, so this is not too great a concern.
%
%A more important concern is that of missed pulses. The T3 data reports the detected pulse number, and if a sync pulse is missed no record will exist. However, translation of any subsequent record to an absolute time will be incorrect by the period $1/f$, confusing matters where such spacing is important. Again, a well-designed system should not have problems beating this limit, but it is the greatest single source of error during the translation.
%
%Collectively, these errors can be expressed as:
%\begin{equation}
%\left(c_{j}, p_{j}+\delta p_{j}, t_{j} + \delta t_{j}\right) \rightarrow \left(c_{j}, \frac{p_{j}+\delta p_{j}}{f+\delta f} + \left(t_{j}+\delta t_{j}\right)\right)
%\end{equation}

\subsubsection{Timeharp}
The Timeharp is the least sophisticated of the three boards discussed here, and is fundamentally a histogramming board. It features two input channels, and its three modes are:
\begin{itemize}
\item interactive (thd): Collection of a histogram, using channel 0 as the sync and channel 1 as the signal.
\item continuous interactive (thc): Identical to normal interactive mode, except that the histogram is reported at the end of a user-specified time interval, repeating until halted. This feature is used for experiments requiring time resolution of a time-dependent feature, such as a fluctuating fluorescence lifetime. This feature is not supported by the existing software, due to lack of data or interest in using this mode (it is not present in the other timing boards).
\item time-tagged time-resolved (t3r): TTTR mode, equivalent to T3 mode, with channel 0 as the sync and channel 1 as the signal. Instead of reporting the delay time directly, this mode reports the index of the histogram bin an event would fall into. The time delay represented by the delay can be recovered from the header information, but for homogeneity of the treatment of T3-like data this step is not performed automatically.
\end{itemize}

\subsubsection{Picoharp}
The Picoharp features two input channels. Its three modes are:
\begin{itemize}
\item interactive (phd): Standard interactive mode, using channel 0 as the sync and channel 1 as the signal.
\item t2 (pt2): A T2 mode, with both channels treated equally and all pulse arrivals recorded.
\item t3 (pt3): A T3 mdoe, with channel 0 as the sync and channel 1 as the signal.
\end{itemize}
In both the T2 and T3 mode, internal clocks of limited precision ($<$32 bits) are used to record the passage of time or pulses. As such, many records are devoted to recording the occurrence of an integer overflow. These records are treated by \program{picoquant} automatically, producing data streams of the form specified in section~\ref{sec:picoquant_output}.

\subsubsection{Hydraharp}
The Hydraharp features a dedicated sync channel and four input channels. Its three modes are:
\begin{itemize}
\item interactive (hhd): Standard interactive mode, with four separate histograms assigned to  the four input channels.
\item t2 (ht2): A T2 mode, with all channels treated equally, including the sync channel. If the sync channel is active, these events will be recorded, and for convenience \program{picoquant} will output each event as arriving on channel 4. This channel index can be altered by modifying value of the global variable \texttt{HH\_SYNC\_CHANNEL} (\texttt{hydraharp.h}) at compilation time.
\item t3 (ht3): A standard t3 mode.
\end{itemize}
Future versions of the Hydraharp are being developed with extra input channels. If your model features extra channels, it should be sufficient to modify the value of \texttt{HH\_SYNC\_CHANNEL}, as the number of channels and modules is handled dynamically by \program{picoquant}.