\def\Arccosh{{\rm Arccosh}}
\advance\sectioncount by -1
\section{Introduction}

This paper documents a computer-assisted procedure
for rigorously analyzing small hyperbolic $3$-manifolds.
Briefly, we will define a compact six-dimensional space ${\cal P}$
that parameterizes pairs of elements of ${\rm Isom}({\bf H}^3)$,
and then construct a regular binary space partition (BSP) tree
which subdivides ${\cal P}$ into subregions ${\cal P_i}$
and whose leaves are --- with a few exceptions --- labeled with killerwords.
These killerwords will encode miniature proofs that ${\cal P_i}$
cannot contain any points which correspond to
particular choices of pairs of generators of
any torsion-free discrete group of ${\rm Isom}({\bf H}^3)$.
This tree of mini-proofs will then be used
to exhaustively isolate all possible manifolds
which can have properties related to the dimensions of ${\cal P}$.

The first two applications of the procedure
were used to prove a proposition from [GMT]:
\proclaim{Proposition [GMT]}
Let $M$ be an orientable hyperbolic $3$-manifold, and let $\delta$ be
a shortest geodesic. Then, either ${\it tuberadius}(\delta) > \ln(3)/2$,
or $M$ lies within one of seven tightly constrained
exceptional shortest-geodesic-geometry regions.
\endproclaim
and a related proposition; both of which were used in the proof of
the main technical result of [GMT]:
\proclaim{Theorem [GMT]}
Every closed hyperbolic $3$-manifold
has a non-coalescible insulator family,
indeed one coming from a shortest geodesic.
As a consequence,
homotopy hyperbolic $3$-manifolds are hyperbolic.
\endproclaim
More recently, the proposition has been sharpened:
\proclaim{Theorem}
Let $M$ be an orientable hyperbolic $3$-manifold,
and let $\delta$ be a shortest geodesic.
Then, either ${\it tuberadius}(\delta) > \ln(3)/2$, or
$M$ is isometric to one of seven specific manifolds.
\endproclaim
\demo{Proof}
Let $X_0, \cdots, X_6$ denote the exceptional regions of Theorem FIXME(2.XX),
with $N_i$ the corresponding conjectural manifold.
[GMT] showed that $N_0$=Vol3 is the unique manifold in the region
and [JR] showed that Vol3 covered no 3-manifold.
[JR] also proved that $N_5$ and $N_6$ are isometric.
[CLLMR] and [L] identify a manifold in each region
and [CLLMR] show that these manifolds are the unique ones in its region.
[CLLMR] show that $N_1$, $N_5$ and $N_6$ cover no manifold.
In [GT] the proof is completed by showing that $N_3$ covers no manifold
and each of $N_2$ and $N_4$ 2-fold cover manifolds,
however the quotients are all non exceptional,
i.e. each shortest geodesic has a $ln(3)/2$ tube.
\enddemo

Other applications of the procedure:

Theorem [G]  (Smale conjecture of hyperbolic 3-manifolds)
If N is a closed hyperbolic 3-manifold,
then the natural inclusion ${\rm Isom}(N)\to {\rm Diff}(N)$ is a homotopy equivalence.

The proof made essential use of the fact that a shortest geodesic
of a closed hyperbolic 3-manifold satisfies the insulator condition [GMT].

Theorem [GMM], [Mi] The Week's manifold
is the unique closed orientable hyperbolic 3-manifold of minimal volume.

This result relies on

Lemma [ACS] Suppose that M is a closed, orientable hyperbolic 3-manifold,
and that C is a shortest geodesic in M.
Set $N = \rm{drill}_C(M)$. If $\rm{tuberad}(C) \ge \ln(3)/2$ then
$\rm{vol} N < 3:0177 \rm{vol}M$.

This is based on a result of [ADST],
that makes essential use of Perelman's [Pe] monotonicty result.
a key element of his proof of geometrization and the $\ln(3)/2$
theorem of [GMT].
Lemma [ACS] is used to prove other results such as

Theorem [ACS] Suppose that M is a closed, orientable, hyperbolic
3-manifold such that ${\rm vol}(M) \le 1.22$.
Then $H_1(M:Zp)$ has dimension at most 3 for every prime p.

(The statement is sharpened slightly to take into account [GT])

Theorem [LM] Let M be a compact orientable 3-manifold with boundary a torus,
and with interior admitting a complete finite-volume hyperbolic structure.
Then the number of exceptional slopes on M is at most 10.

This result, known as the Gordon conjecture,
relies on rigorous computer assistance using the AffApprox technology.

Finally, the procedure is currently in use
by Gabai, Haraway, Meyerhoff, Thurston, and Yarmola
to rigorously analyze small orientable cusped hyperbolic $3$-manifolds,
and to rigorously analyze small non-orientable closed hyperbolic $3$-manifolds.

This paper is organized as follows.

In Section 1 we introduce [GMT; Proposition 2.8] as Theorem FIXME(2.19),
and sketch its proof.

In Section 2 we provide a formal statement and proof of Theorem FIXME(2.19).

In Section 3,
the method for describing the decomposition
of the parameter space ${\cal W}$ into sub-regions is given,
and the conditions used to eliminate sub-regions are discussed.
Near the end of this section, the first part of a detailed example is given.

Eliminating
a sub-region requires that a certain function is shown to be bounded
appropriately over the entire sub-region.  This is carried out by using a
first-order Taylor approximation of the function together with a
remainder
bound.
Our computer version of such a Taylor approximation with remainder bound
is called an {\it AffApprox} and in Section 4,
the relevant theory is developed.
At this point, the detailed example of Section 3 can be completed.

In Sections 5 and 6, round-off error analysis appropriate to our
set-up is introduced.  Specifically, in Section 6, round-off error is
incorporated
into the {\it AffApprox} formulas introduced in Section 4.  The proofs here
require an analysis of round-off error for complex numbers, which is carried
out in Section 5.

In Section 7 we give some hints about the search for a atree,
in the hope that they will help others endeavoring to apply these methods.

Finally, in Section 8, we present an updated version of
the code used to check that the proof is valid,
with self-contained copies of the proofs required for the reader
to check its own validity.

{\it Prior publication}
Sections 2 through 6 originally appeared in [GMT],
and are reproduced here with only minor revision.
Section 1 is an abridged version of the parts of the rest of [GMT].
Section 7 borrows from material which originally appeared in remarks in [GMT].

{\it Acknowledgements}.
FIXME


% \documentclass[a4paper, 10px]{ctexart}
\documentclass{ctexart}
\usepackage[left=1in, right=1in, top=1.2in, bottom=1.2in]{geometry}
\usepackage{ctex}
\usepackage[utf8]{inputenc}
\usepackage{boxproof}
\usepackage{fontspec}
\usepackage{a4wide}
% \setmainfont[Scale = 1]{SF Display}
% \setCJKmainfont{Songti SC}
\usepackage{fancyhdr}

% Automata
\usepackage{tikz}
\usetikzlibrary{automata, positioning, arrows}

\pagestyle{fancy}
\fancypagestyle{plain}{
    \fancyhead[L]{East China Normal University}
    \fancyhead[R]{}
    \fancyfoot[C]{\thepage}
}

\tikzset{
->, % makes the edges directed
>=stealth, % makes the arrow heads bold
node distance=3cm, % specifies the minimum distance between two nodes. Change if necessary.
every state/.style={thick, fill=gray!10}, % sets the properties for each ’state’ node
initial text=$start$, % sets the text that appears on the start arrow
}

\def\premise{\mathrm{premise}}
\def\assumption{\mathrm{assumption}}
\def\MT{\mathrm{MT\ }}
\def\LEM{\mathrm{LEM}}
\def\intro{\mathrm{i\ }}
\def\elim{\mathrm{e\ }}
\def\introa{\mathrm{i_1\ }}
\def\elima{\mathrm{e_1\ }}
\def\introb{\mathrm{i_2\ }}
\def\elimb{\mathrm{e_2\ }}

\title{Computation Theory Assignment 4}
\author{10185101210 陈俊潼}
\date{September 2020}

\begin{document}

\maketitle

\section{Automata}

\subsection{This is an automata.}

To draw an automata, you need to first import \texttt{tikz} package.

Figure \ref{aut1} is an example:

\begin{figure}[ht]
    \centering
    \begin{tikzpicture}[scale=2]
        \node[state, initial] (0) {$q_0$};
        \node[state, above right of=0] (1) {$q_1$};
        \node[state, right of=1] (2) {$q_2$};
        \node[state, above right of=2, accepting] (3) {$q_3$};
        \node[state, below right of=2, accepting] (4) {$q_4$};
        \node[state, below right of=0] (5) {$q_5$};
        \node[state, right of=5] (6) {$q_6$};
        \node[state, right of=6] (7) {$q_7$};
        \node[state, right of=7, accepting] (8) {$q_8$};
        \draw (0) edge[above] node{$a$} (1)
                (1) edge[above] node{$b$} (2)
                (2) edge[above] node{$c$} (3)
                (2) edge[above] node{$d$} (4)
                (0) edge[above] node{$c$} (5)
                (5) edge[above] node{$c$} (6)
                (6) edge[above] node{$c$} (7)
                (7) edge[above] node{$c$} (8);
    \end{tikzpicture}
    \caption{An automata example}
    \label{aut1}
\end{figure}
\end{document}


\documentclass{article}
\usepackage{a4wide}
\usepackage{amsmath}
\usepackage[colorlinks=true,linkcolor=blue,citecolor=blue]{hyperref}
\usepackage[sort&compress,comma,authoryear]{natbib}
\newcommand{\Prob}[0]{\mbox{Prob}}
\newcommand{\ul}[1]{\underline{#1}}
\newcommand{\ol}[1]{\overline{#1}}
\usepackage{bm}
\usepackage{latexsym}

\title{DEB model description: 'hex'}
%\author{S.A.L.M. Kooijman and K. Lika and S. Augustine and N. Marn and others?}

\begin{document}

\maketitle

This document specifies the standard DEB model 'hex'.
The {\sc deb} model for holometabolic insects (and some other hexapods). Its characteristics are
\begin{description}
  \item[$\circ$] morphological life stages: egg, larva, (pupa), imago; functional stages: embryo, adult, (pupa), imago

  \item[$\circ$] the embryo still behaves like the std-model

  \item[$\circ$] the larval stage accelerates (V1-morph) and behaves as adult, i.e. no maturation, allocation to reproduction and $E_H^b = E_H^p$.

  \item[$\circ$] pupation occurs when reproduction buffer density hits a threshold, $E_R/ L^3 = [E_R^j]$

  \item[$\circ$] pupa behaves like an isomorphic embryo of the std-model, emergence occurs at $E_H = E_H^e$
	  Larval structure rapidly transforms to pupal reserve just after start of pupation, and sets $E_H = 0$ at $j$.

  \item[$\circ$] the reproduction buffer remains unchanged during the pupal stage

  \item[$\circ$] the imago does not grow or allocate to reproduction.
	  Imago's reserve mobilisation matched somatic plus maturity maintenance $\dot{p}_C = \dot{p}_M + \dot{p}_J$.
\end{description}
Hemi-metabolic insects skip the pupal stage, don't convert larval structure to reserve.
Imago structure equals larval structure when reproduction buffer density hits a threshold.
The model is discussed in the comments for Section 7.8.

For $\dot{k}_E = \dot{v}/ L_b$, reserve mobilisation prior to pupation (i.e. during acceleration) is $\dot{p}_C = E (\dot{k}_E - \dot{r})$
  with $\dot{r} = \frac{\kappa [E] \dot{k}_E - [\dot{p}_M]} {\kappa [E] + [E_G]} = g \dot{k}_M \frac{e/ l_b - 1} {e + g}$.
The larva allocates to reproduction as $\dot{p}_R = (1- \kappa) \dot{p}_C - \dot{p}_J$, with $\dot{p}_J = \dot{k}_J E_H^p$.
$[E_R]$ has a maximum at $[E_R^m] = [E_R^{\mbox{\tiny ref}}] f \frac{1 - l_b} {f - l_b}$ with$[E_R^{\mbox{\tiny ref}}] = (1 - \kappa) [E_m] \frac{g + l_b} {1 - l_b}$, so pupation occurs when $[E_R] = s_j [E_R^{\mbox{\tiny ref}}]$, with $s_j = [E_R^j]/ [E_R^{\mbox{\tiny ref}}]$.

Reserve mobilisation of the imago is $\dot{p}_C = \dot{p}_M^e + \dot{p}_J^e$, where $\dot{p}_M^e = [\dot{p}_M] L_e^3$ and $\dot{p}_J^e = \dot{k}_J E_H^e$.

\section{Background}

\input{model_intro}

\input{std_description}

\bibliographystyle{apalike}
\bibliography{debmodels}

\end{document}


\subsection{Shields}

\begin{longtable}{|C{2cm} L{2cm} L{2cm} L{8cm}|}
\hline
\large{\textbf{Name}} &
\large{\textbf{Cost}} &
\large{\textbf{ }} &
\large{\textbf{Resistance}}
\\ \hline
\WeaponRow{Buckler}{120 m}{ }{
\textbf{Holding hand + protected body part:} \hfill \break
\textit{Slashing:} $+100\%$ \hfill \break
\textit{Crushing:} $+15\%$ \hfill \break
\textit{Piercing:} $+100\%$
}{A \textbf{Buckler} is a rather small shield, less than 45 cm - or 18 inches - in diameter. The small size of shield means it offers minimal protection against crushing damage, but it compensates by having increased mobility, with enemy attacks being blocked by it if $4d5 <= \frac{Dexterity}{1.1}$.\hfil \break
Bucklers also do a crushing damage of $\frac{2d4 \pm modifiers}{5}*Strength$ during a Shield Bash.
}
\WeaponRow{Single-Pointed Shield}{200 m}{ }{
\textbf{Holding hand + protected body part:} \hfill \break
\textit{Slashing:} $+100\%$ \hfill \break
\textit{Crushing:} $+55\%$ \hfill \break
\textit{Piercing:} $+100\%$
}{A \textbf{Single-Pointed Shield} is a shield typically made out of wood, larger than a Buckler, and named as such due to being attached to its user at a single point, which sacrifices stability for mobility, causing such shields to be ease to move even at larger sizes - enemy attacks being blocked by it if $4d5 <= \frac{Dexterity}{1.3}$.\hfil \break
Single-Pointed Shields also do a crushing damage of $\frac{2d8 \pm modifiers}{5}*Strength$ during a Shield Bash.
}
\WeaponRow{Double-Pointed Shield}{200 m}{ }{
\textbf{Holding hand + protected body part:} \hfill \break
\textit{Slashing:} $+100\%$ \hfill \break
\textit{Crushing:} $+75\%$ \hfill \break
\textit{Piercing:} $+100\%$
}{A \textbf{Double-Pointed Shield} is a shield typically made out of a mixture of wood and metal, larger than a Buckler, and named as such due to being attached to its user at two points, which sacrifices mobility for stability, making it difficult to make these shields bulge - enemy attacks being blocked by it if $4d5 <= \frac{Dexterity}{2}$.\hfil \break
Single-Pointed Shields also do a crushing damage of $\frac{2d6 \pm modifiers}{5}*Strength$ during a Shield Bash.
}
\end{longtable}


\documentclass[10pt]{beamer} % aspect ratio 4:3, 128 mm by 96 mm
%\documentclass[10pt,aspectratio=169]{beamer} % aspect ratio 16:9
\graphicspath{{../journal_papers/Elsevier/figs/}}
%\includeonlyframes{frame1,frame2,frame3}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Packages
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\usepackage{appendixnumberbeamer}
\usepackage{booktabs}
\usepackage[scale=2]{ccicons}
\usepackage{pgfplots}
\usepackage{xspace}
\usepackage{amsmath}
\usepackage{totcount}
\usepackage{tikz}
%\usepackage{comment}
%\usetikzlibrary{external} % speedup compilation
%\tikzexternalize % activate!
%\usetikzlibrary{shapes,arrows}

%\usepackage{bibentry}

\usepackage{caption}%
\captionsetup[figure]{labelformat=empty}%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Metropolis theme custom modification file
\input{metropolis_mods.tex}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Custom commands
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% matrix command
\newcommand{\matr}[1]{\mathbf{#1}} % bold upright (Elsevier, Springer)
%\newcommand{\matr}[1]{#1}          % pure math version
%\newcommand{\matr}[1]{\bm{#1}}     % ISO complying version
% vector command
\newcommand{\vect}[1]{\mathbf{#1}} % bold upright (Elsevier, Springer)
\newcommand{\ud}{\mathrm{d}}
\renewcommand{\vec}[1]{\mathbf{#1}}
\newcommand{\veca}[2]{\mathbf{#1}{#2}}
\newcommand{\bm}[1]{\mathbf{#1}}
\newcommand{\bs}[1]{\boldsymbol{#1}}
% derivative upright command
\DeclareRobustCommand*{\drv}{\mathop{}\!\mathrm{d}}
%
\newcommand{\themename}{\textbf{\textsc{metropolis}}\xspace}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  Title page options
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% \date{\today}
\date{15.08.2019}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% option 1
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\title{Parallel spectral element method for guided wave based structural health monitoring}
%\subtitle{}
%\author{\textbf{Paweł Kudela}\\Jochen Moll \\Piotr Fiborek}
% logo align to Institute
%\institute{Institute of Fluid Flow Machinery\\Polish Academy of Sciences \\ \vspace{-1.5cm}\flushright \includegraphics[width=4cm]{../images/logo/logo_eng_40mm.eps}}
%\institute{Institute of Fluid Flow Machinery\\Polish Academy of Sciences \\ \vspace{-1.5cm}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% option 2 - authors in one line
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
	\title{Parallel spectral element method for guided wave based structural health monitoring}
%	\subtitle{Lamb-opt}
	\author{\textbf{Paweł Kudela}\textsuperscript{1}, Jochen Moll\textsuperscript{2}, Piotr Fiborek\textsuperscript{1} }
%	% logo align to Institute
%	\institute{\textsuperscript{1}Xi'an Jiaotong University \\ \textsuperscript{2}Institute of Fluid Flow Machinery\\ \hspace*{1pt} Polish Academy of Sciences \\ \vspace{-1.5cm}\flushright \includegraphics[width=4cm]{../images/logo/logo_eng_40mm.eps}}
	\institute{ \textsuperscript{1}Institute of Fluid Flow Machinery\\ \hspace*{1pt} Polish Academy of Sciences \\ \\ \textsuperscript{2}J.W. Goethe University\\ \hspace*{1pt} Department of Physics \vspace{-1.5cm}}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% option 3 - multilogo vertical
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\title{Elastic constants identification of composite laminates by using Lamb wave dispersion curves and optimization methods}
%\subtitle{Lamb-opt}
%	\author{\textbf{Paweł Kudela}\inst{1}, Maciej Radzieński\inst{1}, Wiesław Ostachowicz\inst{1}, Zhibo Yang\inst{2} }
%	% logo under Institute
%	\institute%
%	{
%		\inst{1}%
%		Institute of Fluid Flow Machinery\\ \hspace*{1pt} Polish Academy of Sciences \\ \includegraphics[height=0.85cm]{../images/logo/logo_eng_40mm.eps} \\
%		\and
%		\inst{2}%
%	    Xi'an Jiaotong University \\ \includegraphics[height=0.85cm]{../images/logo/logo_box.eps}
%    }
% end od option 3
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% option 4 - 3 Institutes and logos horizontal centered
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\title{Elastic constants identification of composite laminates by using Lamb wave dispersion curves and optimization methods}
%\subtitle{Lamb-opt }
%\author{\textbf{Paweł Kudela}\textsuperscript{1}, Maciej Radzieński\textsuperscript{1}, Marco Miniaci\textsuperscript{2}, Zhibo Yang\textsuperscript{3} }
%
%\institute{
%\begin{columns}[T,onlytextwidth]
%	\column{0.39\textwidth}
%	\begin{center}
%		\textsuperscript{1}Institute of Fluid Flow Machinery\\ \hspace*{3pt}Polish Academy of Sciences
%	\end{center}
%	\column{0.3\textwidth}
%	\begin{center}
%		\textsuperscript{2}Zurich University
%	\end{center}
%	\column{0.3\textwidth}
%	\begin{center}
%		\textsuperscript{3}Xi'an Jiaotong University
%	\end{center}
%\end{columns}
%\vspace{6pt}
%% logos
%\begin{columns}[b,onlytextwidth]
%	\column{0.39\textwidth}
%		\centering
%		\includegraphics[width=\textwidth,height=0.85cm,keepaspectratio]{../images/logo/logo_eng_40mm.eps}
%	\column{0.3\textwidth}
%		\centering
%		\includegraphics[width=\textwidth,height=0.85cm,keepaspectratio]{../images/logo/logo_box.eps}
%	\column{0.3\textwidth}
%		\centering
%		\includegraphics[width=\textwidth,height=0.85cm,keepaspectratio]{../images/logo/logo_box2.eps}
%\end{columns}
%}
%\makeatletter
%\setbeamertemplate{title page}{
%	\begin{minipage}[b][\paperheight]{\textwidth}
%		\centering  % <-- Center here
%		\ifx\inserttitlegraphic\@empty\else\usebeamertemplate*{title graphic}\fi
%		\vfill%
%		\ifx\inserttitle\@empty\else\usebeamertemplate*{title}\fi
%		\ifx\insertsubtitle\@empty\else\usebeamertemplate*{subtitle}\fi
%		\usebeamertemplate*{title separator}
%		\ifx\beamer@shortauthor\@empty\else\usebeamertemplate*{author}\fi
%		\ifx\insertdate\@empty\else\usebeamertemplate*{date}\fi
%		\ifx\insertinstitute\@empty\else\usebeamertemplate*{institute}\fi
%		\vfill
%		\vspace*{1mm}
%	\end{minipage}
%}
%
%\setbeamertemplate{title}{
%	%  \raggedright%  % <-- Comment here
%	\linespread{1.0}%
%	\inserttitle%
%	\par%
%	\vspace*{0.5em}
%}
%\setbeamertemplate{subtitle}{
%	%  \raggedright%  % <-- Comment here
%	\insertsubtitle%
%	\par%
%	\vspace*{0.5em}
%}
%\makeatother
% end of option 4
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% option 5 - 2 Institutes and logos horizontal centered
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\title{Elastic constants identification of composite laminates by using Lamb wave dispersion curves and optimization methods}
%\subtitle{Lamb-opt }
%\author{\textbf{Paweł Kudela}\textsuperscript{1}, Maciej Radzieński\textsuperscript{1}, Marco Miniaci\textsuperscript{2}}
%
%\institute{
%	\begin{columns}[T,onlytextwidth]
%		\column{0.5\textwidth}
%			\centering
%			\textsuperscript{1}Institute of Fluid Flow Machinery\\ \hspace*{3pt}Polish Academy of Sciences
%		\column{0.5\textwidth}
%			\centering
%			\textsuperscript{2}Zurich University
%	\end{columns}
%	\vspace{6pt}
%	% logos
%	\begin{columns}[b,onlytextwidth]
%		\column{0.5\textwidth}
%		\centering
%		\includegraphics[width=\textwidth,height=0.85cm,keepaspectratio]{../images/logo/logo_eng_40mm.eps}
%		\column{0.5\textwidth}
%		\centering
%		\includegraphics[width=\textwidth,height=0.85cm,keepaspectratio]{../images/logo/logo_box.eps}
%	\end{columns}
%}
%\makeatletter
%\setbeamertemplate{title page}{
%	\begin{minipage}[b][\paperheight]{\textwidth}
%		\centering  % <-- Center here
%		\ifx\inserttitlegraphic\@empty\else\usebeamertemplate*{title graphic}\fi
%		\vfill%
%		\ifx\inserttitle\@empty\else\usebeamertemplate*{title}\fi
%		\ifx\insertsubtitle\@empty\else\usebeamertemplate*{subtitle}\fi
%		\usebeamertemplate*{title separator}
%		\ifx\beamer@shortauthor\@empty\else\usebeamertemplate*{author}\fi
%		\ifx\insertdate\@empty\else\usebeamertemplate*{date}\fi
%		\ifx\insertinstitute\@empty\else\usebeamertemplate*{institute}\fi
%		\vfill
%		\vspace*{1mm}
%	\end{minipage}
%}
%
%\setbeamertemplate{title}{
%	%  \raggedright%  % <-- Comment here
%	\linespread{1.0}%
%	\inserttitle%
%	\par%
%	\vspace*{0.5em}
%}
%\setbeamertemplate{subtitle}{
%	%  \raggedright%  % <-- Comment here
%	\insertsubtitle%
%	\par%
%	\vspace*{0.5em}
%}
%\makeatother
% end of option 5
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%  End of title page options
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% logo option - alternative manual insertion by modification of coordinates in \put()
%\titlegraphic{%
%	%\vspace{\logoadheight}
%	\begin{picture}(0,0)
%	\put(305,-185){\makebox(0,0)[rb]{\includegraphics[width=4cm]{../images/logo/logo_eng_40mm.eps}}}
%	\end{picture}}
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%\tikzexternalize % activate!
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\maketitle
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% SLIDES
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Table of contents}
  \setbeamertemplate{section in toc}[sections numbered]
  \tableofcontents[hideallsubsections]
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Introduction}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[fragile,label=frame1]{Funding}

	NAWA – Polish National Agency for Academic Exchange

	Mobility project to carry out research at Johann Wolfgang Goethe University, Frankfurt am Main, Germany, 2019 (3 months)

	\emph{Towards model assisted structural health monitoring}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[fragile,label=frame2]{Context}

	National Science Centre, Poland

	2019--2021 (3 years)

  	\emph{Feasibility studies of artificial intelligence-driven diagnostics}

\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[label=frame3]{Small project within big project}
	\begin{figure}
		\centering
		\only<1>{
		\includegraphics[width=\textwidth]{beamer_figs/Plan-scheme-nn-small-eng.png}
		\label{fig:plan_scheme}
		}
		\only<2>{
		\includegraphics[width=\textwidth]{beamer_figs/Plan-scheme-nn-small-eng2.png}
		\label{fig:plan_scheme2}
		}
	\end{figure}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{Motivation}
	\biblioref{C.A.C Leckey, K.R. Wheeler,V.N. Hafiychuk, H. Hafiychuk, D.A. Timucin}{2018}{Simulation of guided-wave ultrasound propagation in composite laminates: Benchmark comparisons of numerical codes and experiment}{Ultrasonics}
	\begin{figure}
		\includegraphics[width=\textwidth]{beamer_figs/Leckey-2018-table.png}
		\caption{Performance metrics of commercial software for wave propagation modelling}
	\label{fig:Leckey_table}
	\end{figure}
	\begin{alertblock}{Potential Problems}
		Shortest run time \textbf{19.5 h} is for COMSOL but requires huge amount of~memory space\\
		19.5 h $\times$ 1000 simulations $\approx$ \textbf{812 days}
	\end{alertblock}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Numerical modelling}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{Flat shell spectral element (theoretical background)}
	\def\myindenta{0.0\textwidth} % define myindenta variable  for correcting caption placement
	\only<1->{
	\begin{columns}[T]
		\column{0.5\textwidth}
		\begin{figure}
			\includegraphics[width=\textwidth]{shell.png}
			\caption{\hspace{\myindenta}36--node spectral shell element.}
			\label{fig:spectral_shell_element}
		\end{figure}
		\column{0.5\textwidth}
		The displacement field is based on Mindlin--Reissner theory:
		\begin{equation*}
		\begin{split}
		& u(x,y,z)=u_0(x,y) - \varphi_x(x,y) \cdot z\\
		& v(x,y,z)=v_0(x,y) - \varphi_y(x,y) \cdot z\\
		& w(x,y,z)=w_0(x,y) \label{eq:delam_platedispl}
		\end{split}
		\end{equation*}
	\end{columns}
	}
	\only<2>{
		\begin{alertblock}{Important properties}
			\begin{itemize}
				\item Non--uniform distribution of nodes which coincide with Gauss--Lobatto--Legendre integration points
				\item Diagonality of mass matrix
				\item Fast convergence (spectral, exponential)
			\end{itemize}
		\end{alertblock}
	}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{Approximation}
	\begin{equation*}
	\left[\begin{array}{l} u_0^e(\xi, \eta) \\ \varphi_x^e(\xi, \eta)\\ v_0^e(\xi, \eta) \\ \varphi_y^e(\xi, \eta)\\ w_0^e(\xi, \eta)\\ \end{array}\right] = \bm{N}^e \vec{\hat{u}}^e = \sum \limits_{j=1}^{6} \sum \limits_{i=1}^{6} N^e_i(\xi) N^e_i(\eta)\, \bm{I} \left[ \begin{array}{l} {\hat{u}_0}^e(\xi_i,\eta_j)\\\hat{\varphi}_x^e(\xi_i,\eta_j)\\{\hat{v}_0}^e(\xi_i,\eta_j) \\\hat{\varphi}_y^e(\xi_i,\eta_j) \\ \hat{w}_0^e(\xi_i,\eta_j)\end{array} \right]\label{eq:delam_plateaproxim}
	\end{equation*}
	where $\bm{N}^e$ are shape functions, $\vec{\hat{u}}^e$ are nodal degrees of freedom in the element, $\bm{I}$ is the unit matrix of the size 5x5.
	\begin{equation*}
	\left[\begin{array}{l} x_0^e(\xi, \eta) \\ y_0^e(\xi, \eta)  \end{array}\right] = \sum \limits_{j=1}^{6} \sum \limits_{i=1}^{6} N^e_i(\xi) N^e_j(\eta)\, \left[ \begin{array}{l} x^e(\xi_i,\eta_j)\\y^e(\xi_i,\eta_j)\end{array} \right]\label{eq:delam_plategeom}
	\end{equation*}
	\begin{alertblock}{Shape functions are orthogonal Lagrange polynomials}
	\end{alertblock}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{Equation of motion}
	\only<1->{
	\begin{equation*}
	\bm{M} \vec{\ddot{U}} + \bm{C} \vec{\dot{U}} + \bm{K} \vec{U} = \vec{F} \label{eq:motion}
	\end{equation*}
	}
	\vspace{0.4cm}
	\only<2->{
	\begin{equation*}
	\ddot{\vec{U}}\simeq \frac{1}{\Delta t^2} \left(\vec{u}_{t+\Delta t} - 2\,\vec{u}_t + \vec{u}_{t-\Delta t}\right) \label{eq:central_scheme}
	\end{equation*}
	\begin{equation*}
	\dot{\vec{U}}\simeq \frac{\vec{u}_{t+\Delta t} -\vec{u}_{t-\Delta t}}{2 \Delta t}
	\label{eq:first_derivative_scheme}
	\end{equation*}
	}
	\vspace{0.4cm}
	\only<3>{
	\begin{equation*}
	\begin{split}
	\underbrace{\left(\frac{1}{\Delta t^2} \,\bm{M} + \frac{1}{2 \Delta t} \bm{C}\right)}_{\vec{M}_0} \vec{u}_{t+\Delta t} &= \vec{F}_t - \underbrace{\left(\bm{K} \vec{u}_t\right)}_{\vec{F}^i} + \underbrace{\left(\frac{2}{\Delta t^2} \,\bm{M} \right)}_{\vec{M}_1}\vec{u}_t \\
	&+ \underbrace{\left(- \frac{1}{\Delta t^2} \,\bm{M} + \frac{1}{2 \Delta t} \bm{C}\right)}_{\vec{M}_2} \vec{u}_{t-\Delta t}.
	\label{eq:explicit_integration}
	\end{split}
	\end{equation*}
}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{Vectorization of the code}
	\vspace{-0.4cm}
	\begin{equation*}
		\underbrace{\left(\bm{K} \vec{u}_t\right)}_{\vec{F}^i}
	\end{equation*}
	\vspace{0.4cm}
	\begin{equation*}
	\begin{split}
	\vec{F}_u^i&=\bm{N},_{\xi}^T \left(\bs{\sigma}_{xx}\,.*(\vec{J}^{-1})_{11}\,.*\vec{W}\right)+\bm{N},_{\eta}^T \left(\bs{\sigma}_{xx}\,.*(\vec{J}^{-1})_{21}\,.*\vec{W}\right)\\
	&+\bm{N},_{\xi}^T \left(\bs{\sigma}_{xy}\,.*(\vec{J}^{-1})_{12}\,.*\vec{W}\right)+\bm{N},_{\eta}^T \left(\bs{\sigma}_{xy}\,.*(\vec{J}^{-1})_{22}\,.*\vec{W}\right),
	\label{eq:internal_forces_u}
	\end{split}
	\end{equation*}
	\vspace{0.4cm}
	\begin{equation*}
	\begin{split}
	\bs{\sigma}_{xx}&=\left((\bm{N},_{\xi}\vec{U}_x).*(\vec{J}^{-1})_{11}+(\bm{N},_{\eta}\vec{U}_x).*(\vec{J}^{-1})_{21}\right).*\vec{A}_{11}\\
	&+\left((\bm{N},_{\xi}\bs{\Phi}_x).*(\vec{J}^{-1})_{11}+(\bm{N},_{\eta}\bs{\Phi}_x).*(\vec{J}^{-1})_{21}\right).*\vec{B}_{11}\\
	&+\left((\bm{N},_{\xi}\vec{U}_y).*(\vec{J}^{-1})_{12}+(\bm{N},_{\eta}\vec{U}_y).*(\vec{J}^{-1})_{22}\right).*\vec{A}_{12}\\
	&+\left((\bm{N},_{\xi}\bs{\Phi}_y).*(\vec{J}^{-1})_{12}+(\bm{N},_{\eta}\bs{\Phi}_y).*(\vec{J}^{-1})_{22}\right).*\vec{B}_{12}\\
	&+\left((\bm{N},_{\xi}\vec{U}_x).*(\vec{J}^{-1})_{12}+(\bm{N},_{\eta}\vec{U}_x).*(\vec{J}^{-1})_{22}\right).*\vec{A}_{16}\ldots,
	\end{split}
	\end{equation*}

	where $.*$ denotes element-wise operation known as Hadamarad product (the same symbol for element-wise operation is used in Matlab).
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Mesh colouring}
	\begin{figure}
		\centering
			\includegraphics[width=0.8\textwidth]{beamer_figs/mesh_colouring_scheme4.jpg}
			\label{fig:mesh_colouring}
	\end{figure}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{Delamination modelling}
	\begin{figure} [h!]
		\centering
		\includegraphics[width=0.9\textwidth]{delam_modelling_shell.png}
		\caption{The concept of delamination modelling: cross-section through the composite laminate and delamination showing three regions: (I) undelaminated, (II) above delamination interface, and (III) below delamination interface and corresponding elements.}
		\label{fig:delam_modelling_shell}
	\end{figure}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Computation speedup analysis}
	\begin{table}
		\renewcommand{\arraystretch}{1.3}
		\centering \small
		Computation run times depending on the number of degrees of freedom (NDOF) for the wave propagation duration 400~$\mu$s; GPU: Nvidia Tesla K20X; CPU: Intel Xeon X5660 2.8~GHz.

		\begin{tabular}{ccccccc}
			%\hline
			\toprule
			plate size [cm] & 30$\times$30  & 40$\times$40 & 50$\times$50 & 70$\times$70 & 90$\times$90 & 100$\times$100 \\
			NDOF $\cdot 10^6$ & 1.02  & 1.46 & 1.98 & 3.09 & 5.23 & 6.36 \\
			\midrule
			CPU time [h]& 4.03& 5.71 & 8.42 & 13.13 & 22.37 & 27.33\\
			\midrule
			GPU time [h]& 1.00& 1.19 & 1.26 & 1.50 & 2.00 & 2.28\\
			%\hline
			\bottomrule
		\end{tabular}
		\label{tab:run_time}
	\end{table}
	\begin{alertblock}{Run time}
		The longest run time on GPU was \textbf{2.28 h}\\
		The typical run time for simulations performed next was about 3 hours ($t = 1300\, \mu$s, NDOF $= 2.23\cdot 10^6$) \\
		The GPU memory usage was about 925 MB\\
		3 h $\times$ 1000 simulations $\approx$ \textbf{125 days}
	\end{alertblock}
\end{frame}
\begin{frame}{Computation speedup analysis}
	\begin{figure} [h!]
		\centering
		\includegraphics{speedup.png}
		\caption{Computation speedup; NDOF - number of degrees of freedom.}
		\label{fig:speedup}
	\end{figure}
	\begin{equation*}
	speedup = \frac{CPU_{time}}{GPU_{time}}
	\label{eq:speedup}
	\end{equation*}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Experimental validation}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Open Guided Waves}
	\begin{block}{\url{http://www.open-guided-waves.de}}
		Open Guided Waves is an extendable online platform where high--quality and well documented datasets for guided wave--based inspections are provided.
	\end{block}

	CFRP plates [45/0/-45/90/-45/0/45/90]\textsubscript{S}

	500 mm $\times$ 500 mm, thickness of 2 mm.

	Piezoelectric transducers diameter 10 mm, thickness 0.2 mm.

	\begin{table}
		\renewcommand{\arraystretch}{1.3}
		\centering \small
		Material properties of unidirectional Hexply M21/34\%/UD134/T700/300; Units: GPa.

		\begin{tabular}{cccccc}
			%\hline
			\toprule
			$Q_{11}$ & $Q_{12}$  & $Q_{22}$ & $Q_{44}$ & $Q_{55}$ & $Q_{66}$\\
			% \cmidrule(lr){1-3} \cmidrule(lr){4-6} \cmidrule(lr){7-7}
			%\hline
			\midrule
			130& 6.1& 11.2 & 3.0 & 4.2 & 4.2\\
			%\hline
			\bottomrule
		\end{tabular}
		\label{tab:mat_prop}
	\end{table}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Open Guided Waves}

	\begin{table}
		\renewcommand{\arraystretch}{1.3}
		\centering \small
		Coordinates of analysed defects; Units: [m].

		\begin{tabular}{cccc}
			%\hline
			\toprule
			\multicolumn{2}{c}{\textbf{Data set I} }	& \multicolumn{2}{c}{\textbf{Data set II} } \\
			\multicolumn{2}{c}{\textbf{(wavefield plate)} }	& \multicolumn{2}{c}{\textbf{(SHM plate)} } \\
			%\midrule
			\cmidrule(lr){1-2} \cmidrule(lr){3-4}
			x & y &  x &  y  \\
			% \cmidrule(lr){1-3} \cmidrule(lr){4-6} \cmidrule(lr){7-7}
			%\hline
			0.191 & 0.145 & 0.250  & 0.427 \\
			%\hline
			\bottomrule
		\end{tabular}
		\label{tab:defect_coordinates}
	\end{table}
	\begin{block}{Wavefield plate}
		Wavefield measured by scanning laser Doppler vibrometer
	\end{block}
	\begin{block}{SHM plate}
		Signals excited and registered by an array of piezoelectric transducers
	\end{block}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[b]{Meshing - GMSH quadrilateral elements}
	\begin{figure}
		\centering
		\includegraphics[width=0.7\textwidth]{delam_Jochen_signals_D5_a_5mm_b_5mm_angle_0added_mass.png}
		\caption{red -- piezoelectric transducers; green -- defect location}
		\label{fig:quad_mesh}
	\end{figure}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{Meshing - spectral element mesh close up}
	\begin{figure}
		\centering
		\includegraphics[width=0.7\textwidth]{delam_Jochen_signals_D5_a_5mm_b_5mm_angle_0added_mass_spec_zoom.png}
		\label{fig:spec_mesh_zoom}
	\end{figure}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{Wavefield plate: comparison of wavefields}
%\vspace{6pt}
\def\myindenta{0.001\textwidth} % define myindenta variable  for correcting caption placement
\begin{columns}[T]
	\column{0.5\textwidth}
		\begin{figure}
			\only<1>{
			\includegraphics[width=\textwidth]{exp_frame64.png}
			\caption{\hspace{\myindenta}Experimental wavefield: $t=112.5\, \mu$s}
			}
			\only<2>{
			\includegraphics[width=\textwidth]{exp_frame100.png}
			\caption{\hspace{\myindenta}Experimental wavefield: $t=169\, \mu$s}
			}
			\only<3>{
				\includegraphics[width=\textwidth]{exp_frame64.png}
				\caption{\hspace{\myindenta}Experimental wavefield: $t=112.5\, \mu$s}
			}
			\only<4>{
				\includegraphics[width=\textwidth]{exp_frame100.png}
				\caption{\hspace{\myindenta}Experimental wavefield: $t=169\, \mu$s}
			}
			\only<5>{
				\includegraphics[width=\textwidth]{cut_Vz_1_frame128_top.png}
				\caption{\hspace{\myindenta}Simulation (delamination): $t=200\, \mu$s}
			}
		\end{figure}
	\column{0.5\textwidth}
		\begin{figure}
			\only<1>{
			\includegraphics[width=\textwidth]{Vz_1_frame72_bottom.png}
			\caption{\hspace{\myindenta}Simulation (\textbf{delamination}): $t=112.5\, \mu$s}
			}
			\only<2>{
			\includegraphics[width=\textwidth]{Vz_1_frame108_bottom.png}
			\caption{\hspace{\myindenta}Simulation (\textbf{delamination}): $t=169\, \mu$s}
			}
			\only<3>{
				\includegraphics[width=\textwidth]{added_mass_Vz_1_frame72_bottom.png}
				\caption{\hspace{\myindenta}Simulation (\textbf{added mass}): $t=112.5\, \mu$s}
			}
			\only<4>{
				\includegraphics[width=\textwidth]{added_mass_Vz_1_frame108_bottom.png}
				\caption{\hspace{\myindenta}Simulation (\textbf{added mass}): $t=169\, \mu$s}
			}
			\only<5>{
				\includegraphics[width=\textwidth]{added_mass_cut_Vz_1_frame128_top.png}
				\caption{\hspace{\myindenta}Simulation (added mass): $t=200\, \mu$s}
			}
			\label{fig:wavefield}
		\end{figure}
\end{columns}
	\only<6>{
	\begin{alertblock}{Remarks}
		\begin{itemize}
			\item Simulated wavefield patterns matches the experimental data very well.
			\item The interaction of wave front with added mass is slightly different than with delamination.
			\item The phenomenon of wave entrapment is visible for the case of delamination whereas it is not present in case of added mass.
			\item A reversible damage in the form of added mass coupled to the structure by tacky tape is a good way for collecting benchmark data set. Such benchmark data set is a good starting point for development of algorithms based on full wavefield data for visualization of defect location even in the form of delamination.
		\end{itemize}
	\end{alertblock}
	}
\end{frame}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}[t]{SHM plate: comparison of signals}
	\begin{figure}
		\centering
		\only<1>{
		\includegraphics[width=0.9\textwidth]{path_1_7.png}
		\label{fig:path1_7}
		}
		\only<2>{
			\includegraphics[width=0.9\textwidth]{path_2_4.png}
			\label{fig:path2_4}
		}
		\only<3>{
			\includegraphics[width=0.9\textwidth]{path_4_8.png}
			\label{fig:path4_8}
		}
		\only<4>{
			\includegraphics[width=0.9\textwidth]{path_2_4_diff.png}
			\label{fig:path2_4_diff}
		}
	\end{figure}
	\only<5>{
		\begin{alertblock}{Remarks}
			\begin{itemize}
				\item Differences between experimental and numerical signals are evident and are related to amplitude rather than wave velocity.
				\item The amplitude difference can be attributed to the damping coefficient selected in numerical simulation.
				\item The delamination affect signals more than added mass.
			\end{itemize}
		\end{alertblock}
	}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Conclusions}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Summary}
	\begin{itemize}
		\item The developed code is highly parallel and enables GPU computation. It allows up to \textbf{12$\times$} computation speedup in comparison to CPU. It also \textbf{does not require assembly of stiffness matrix}. Therefore, larger guided wave propagation problems can be solved than in case of conventional finite element approach.
		\item The simulated wave propagation in composite laminates \textbf{matches well the experimental data} from Open Guided Waves platform in terms of full wavefield patterns.
		\item There are differences in wave packets' amplitudes -- proper \textbf{wave attenuation modelling is still a challenge}.
		\item The current implementation is very well suited for any parametric studies or \textbf{model--assisted} approaches for structural health monitoring but is not feasible for \textbf{model--based} approach in which numerical signals are directly compared to experimental one.

	\end{itemize}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Future works}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Random excitation}
	\begin{figure}
		\centering
		\includegraphics[width=0.9\textwidth]{beamer_figs/random_exc_sig.png}
		\label{fig:random_exc_sig}
	\end{figure}
      \begin{alertblock}{Advantage}
        Wide frequency range increases probability that the guided wave will interact with damage.
      \end{alertblock}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Random excitation: full wavefield}
	\begin{figure}
		\centering
		\only<1>{
			\includegraphics[width=0.75\textwidth]{beamer_figs/Vz_5_frame16_top.png}
			\label{fig:random_exc_wavefield_16}
		}
		\only<2>{
			\includegraphics[width=0.75\textwidth]{beamer_figs/Vz_5_frame32_top.png}
			\label{fig:random_exc_wavefield_32}
		}
		\only<3>{
			\includegraphics[width=0.75\textwidth]{beamer_figs/Vz_5_frame48_top.png}
			\label{fig:random_exc_wavefield_48}
		}
		\only<4>{
			\includegraphics[width=0.75\textwidth]{beamer_figs/Vz_5_frame64_top.png}
			\label{fig:random_exc_wavefield_64}
		}
		\only<5>{
			\includegraphics[width=0.75\textwidth]{beamer_figs/Vz_5_frame80_top.png}
			\label{fig:random_exc_wavefield_80}
		}
	\end{figure}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Random excitation: RMS}
	\begin{figure}
		\centering
		\only<1>{
			\includegraphics[width=0.75\textwidth]{beamer_figs/RMS5.png}
			\label{fig:random_exc_wavefield_RMS5}
		}
		\only<2>{
			\includegraphics[width=0.75\textwidth]{beamer_figs/RMS14.png}
			\label{fig:random_exc_wavefield_RMS14}
		}
		\only<3>{
			\includegraphics[width=0.75\textwidth]{beamer_figs/RMS22.png}
			\label{fig:random_exc_wavefield_RMS22}
		}
	\end{figure}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{\setbeamercolor{palette primary}{fg=black, bg=white}
\begin{frame}[standout]
  Thank you for your attention!\\ \vspace{12pt}
  Questions?\\ \vspace{12pt}
  \url{pk@imp.gda.pl}
\end{frame}
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% END OF SLIDES
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\appendix
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Model--based vs model--assisted SHM}
	 In the \textbf{model--based} approach, numerical signals must match very well experimental signals. It is because numerical signals are used in an inverse method in which certain objective function include terms such as:
	\begin{equation*}
	g(t) = \sum_{i=1}^{N} \left(s(t)_i^{exp} - s(t)_i^{num}\right)^2,
	\label{eq:obj_fun}
	\end{equation*}
	where $s(t)^{exp}$ and $s(t)^{num}$ are experimental and numerical signals (or damage indexes), respectively.

	In the \textbf{model--assisted} approach, on the other hand, the modelled phenomenon must reflect the real behaviour, e.g. the amplitude of transmitted wave packet decreases when the size of the damage increases. But in this case, the perfect match between numerical and experimental signals is not necessary. The aim of the presented method is model--assisted structural health monitoring.
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Backup slides}
  \begin{equation*}
  \begin{split}
  \bs{\sigma}_{xx}&=\left((\bm{N},_{\xi}\vec{U}_x).*(\vec{J}^{-1})_{11}+(\bm{N},_{\eta}\vec{U}_x).*(\vec{J}^{-1})_{21}\right).*\vec{A}_{11}\\
  &+\left((\bm{N},_{\xi}\bs{\Phi}_x).*(\vec{J}^{-1})_{11}+(\bm{N},_{\eta}\bs{\Phi}_x).*(\vec{J}^{-1})_{21}\right).*\vec{B}_{11}\\
  &+\left((\bm{N},_{\xi}\vec{U}_y).*(\vec{J}^{-1})_{12}+(\bm{N},_{\eta}\vec{U}_y).*(\vec{J}^{-1})_{22}\right).*\vec{A}_{12}\\
  &+\left((\bm{N},_{\xi}\bs{\Phi}_y).*(\vec{J}^{-1})_{12}+(\bm{N},_{\eta}\bs{\Phi}_y).*(\vec{J}^{-1})_{22}\right).*\vec{B}_{12}\\
  &+\left((\bm{N},_{\xi}\vec{U}_x).*(\vec{J}^{-1})_{12}+(\bm{N},_{\eta}\vec{U}_x).*(\vec{J}^{-1})_{22}\right).*\vec{A}_{16}\\
  &+\left((\bm{N},_{\xi}\bs{\Phi}_x).*(\vec{J}^{-1})_{12}+(\bm{N},_{\eta}\bs{\Phi}_x).*(\vec{J}^{-1})_{22}\right).*\vec{B}_{16}\\
  &+\left((\bm{N},_{\xi}\vec{U}_y).*(\vec{J}^{-1})_{11}+(\bm{N},_{\eta}\vec{U}_y).*(\vec{J}^{-1})_{21}\right).*\vec{A}_{16}\\
  &+\left((\bm{N},_{\xi}\bs{\Phi}_y).*(\vec{J}^{-1})_{11}+(\bm{N},_{\eta}\bs{\Phi}_y).*(\vec{J}^{-1})_{21}\right).*\vec{B}_{16},
  \end{split}
  \end{equation*}
  where $.*$ denotes element-wise operation known as Hadamarad product (the same symbol for element-wise operation is used in Matlab). It should be noted that $\vec{A}$, $\vec{B}$, $\vec{D}$ and $(\vec{J}^{-1})$ with appropriate indexes are arranged in the form of vectors respective to GLL nodes of consecutive disjoint spectral elements.
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Backup slides}
	\begin{equation*}
	\vec{U}_x = \left[
	\begin{array}{c}
	\hat{\vec{u}}_0^{e=1}  \\[2pt]
	\hat{\vec{u}}_0^{e=2} \\[2pt]
	\vdots\\[2pt]
	\hat{\vec{u}}_0^{e=n}\\[2pt]
	\end{array}\right],
	\quad
	\vec{U}_y = \left[
	\begin{array}{c}
	\hat{\vec{v}}_0^{e=1}  \\[2pt]
	\hat{\vec{v}}_0^{e=2} \\[2pt]
	\vdots\\[2pt]
	\hat{\vec{v}}_0^{e=n}\\[2pt]
	\end{array}\right],
	\quad
	\vec{U}_z = \left[
	\begin{array}{c}
	\hat{\vec{w}}_0^{e=1}  \\[2pt]
	\hat{\vec{w}}_0^{e=2} \\[2pt]
	\vdots\\[2pt]
	\hat{\vec{w}}_0^{e=n}\\[2pt]
	\end{array}\right],
	\end{equation*}
	\begin{equation*}
	\bs{\Phi}_x = \left[
	\begin{array}{c}
	\hat{\bs{\varphi}}_x^{e=1}  \\[2pt]
	\hat{\bs{\varphi}}_x^{e=2} \\[2pt]
	\vdots\\[2pt]
	\hat{\bs{\varphi}}_x^{e=n}\\[2pt]
	\end{array}\right],
	\quad
	\bs{\Phi}_y = \left[
	\begin{array}{c}
	\hat{\bs{\varphi}}_y^{e=1}  \\[2pt]
	\hat{\bs{\varphi}}_y^{e=2} \\[2pt]
	\vdots\\[2pt]
	\hat{\bs{\varphi}}_y^{e=n}\\[2pt]
	\end{array}\right],
	\end{equation*}
	$n$ is the total number of elements.\\
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Backup slides}
	Sparse matrices of shape function derivatives:
	\begin{equation*}
	\bm{N},_{\xi} = \left[
	\begin{array}{cccc}
	\bm{N},_{\xi}^{e=1} & 0 & \ldots & 0\\[2pt]
	0& \bm{N},_{\xi}^{e=2}  & \ldots& 0\\[2pt]
	\vdots&\vdots&\ddots&0\\[2pt]
	0& 0 &0&\bm{N},_{\xi}^{e=n}\\[2pt]
	\end{array}\right].
	\end{equation*}
\end{frame}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{frame}{Backup slides}
\begin{equation*}
\begin{split}
\vec{F}_u^i&=\bm{N},_{\xi}^T \left(\bs{\sigma}_{xx}\,.*(\vec{J}^{-1})_{11}\,.*\vec{W}\right)+\bm{N},_{\eta}^T \left(\bs{\sigma}_{xx}\,.*(\vec{J}^{-1})_{21}\,.*\vec{W}\right)\\
&+\bm{N},_{\xi}^T \left(\bs{\sigma}_{xy}\,.*(\vec{J}^{-1})_{12}\,.*\vec{W}\right)+\bm{N},_{\eta}^T \left(\bs{\sigma}_{xy}\,.*(\vec{J}^{-1})_{22}\,.*\vec{W}\right), \\
\vec{F}_v^i&=\ldots ,\\
\vec{F}_w^i&=\ldots ,\\
\vec{M}_x^i&=\bm{N},_{\xi}^T \left(\bs{\sigma}_{xxz}\,.*(\vec{J}^{-1})_{11}\,.*\vec{W}\right)+\bm{N},_{\eta}^T \left(\bs{\sigma}_{xxz}\,.*(\vec{J}^{-1})_{21}\,.*\vec{W}\right)\\
&+\bm{N},_{\xi}^T \left(\bs{\sigma}_{xyz}\,.*(\vec{J}^{-1})_{12}\,.*\vec{W}\right)+\bm{N},_{\eta}^T \left(\bs{\sigma}_{xyz}\,.*(\vec{J}^{-1})_{22}\,.*\vec{W}\right)\\
&+\bs{\sigma}_{xz}\,.*\vec{W},\\
\vec{M}_y^i&=\ldots ,
\label{eq:internal_forces}
\end{split}
\end{equation*}
where $^T$ is the matrix transpose and $\vec{W}$ is the vector resulting from multiplication of integration weights and Jacobian determinant at appropriate GLL points:
\begin{equation*}
\vec{W} = \vec{w}_{\xi}\,.*\vec{w}_{\eta}\,.*\left(\det\vec{J}\right).
\end{equation*}
\end{frame}
\end{document}


\begin{myenv}
	\part{main title}
		part body
		\chapter{\emph{emphasise}title text}
		 body text body text
		 \section{section text}
		  section body
		 \section{section text}
		  section body
		  \subsection{sub title}
			  subsection body subsection body
			  \subsubsection{subsub section title}
				  subsubsubsubsubsubsub
		\chapter{second chapter}
		 chapter body chapter body
	\part{another part}
		more parts!
		\chapter{more chapter! :)}
		 some mathematics:
		 \[
			 x^2
		 \]
		 \subsection{and some section}
			 to wrap things up
\end{myenv}


% !TeX root = ../main.tex
\section{Basic Conditional Narrowing}
From the same motivations as in the unconditional narrowing case we pursuit the objective of define basic conditional narrowing derivations.

\begin{definition}
    Let $T$ be a goal clause. A \textit{position constraint} for $T$ is a mapping $B$ that assigns to every goal $e \in T$ a subset of $\basicPos{e}$. The position constraint that assigns to every $e \in T$ the set $\basicPos{e}$ will be denoted by $\overline{T}$.
\end{definition}

\begin{definition}
    \begin{enumerate}
        \item A narrowing derivation
        $$T \narrow_{[e_1, p_1, l_1 \contr r_1 \Leftarrow c_1, \sigma_1]} \narrow \cdots \narrow_{[e_{n-1}, p_{n_1}, l_{n-1} \contr r_{n-1} \Leftarrow c_{n-1}, \sigma_{n-1}]} T_n$$
        is basic if $p_i \in B_i(e_i)$ for $1 \leq i \leq n - 1$ where the position constraints $B_1, \dots, B_n$ are inductively defined by $B_1 = \overline{T}_1$ and
        \begin{displaymath}
            B_{i+1}(e) =
            \begin{cases}
                B_i(e') & \text{ if } e' \in T_i \setminus \{e_i\} \\
                \mathcal{B}(B_i(e_i), p_i, r_i) & \text{ if } e' = e_i[r_i]_{p_i} \\
                \basicPos{e'} & \text{ if } e' \in \overline{c}_i
            \end{cases}
        \end{displaymath}
        \item A rewrite sequence
        $$T \rewriteOnGoals_{[e_1, p_1, l_1 \contr r_1 \Leftarrow c_1, \sigma_1]} \rewriteOnGoals \cdots \rewriteOnGoals_{[e_{n-1}, p_{n_1}, l_{n-1} \contr r_{n-1} \Leftarrow c_{n-1}, \sigma_{n-1}]} T_n$$
        is \textit{based} on a position constraint $B_1$ for $T_1$ if $p_i \in B_i$ for $1 \leq i \leq n - 1$ with $B_2, \dots, B_n$ defined by
        \begin{displaymath}
            B_{i+1}(e) =
            \begin{cases}
                B_i(e) & \text{ if } e' \in T_i \setminus \{e_i\} \\
                \mathcal{B}(B_i(e_i), p_i, r_i) & \text{ if } e = e_i[r_i\sigma_i]_{p_i} \\
                \basicPos{e'} & \text{ if } e=e'\sigma \text{ with } e' \in \overline{c}_i
            \end{cases}
        \end{displaymath}
        for all $1 \leq i < n$ and $e \in T_{i+1}$.
    \end{enumerate}
\end{definition}

Holldobler \cite{Holldobler:1989:FEL:76924}, showed that basic conditional narrowing is complete for complete 1-CTRSs. However, the following example shows that this result is indeed not valid.

\begin{example}
    Consider the 1-CTRS
    \begin{displaymath}
        \trs =
        \begin{cases}
            f(x) & \contr a                               \\
            d & \contr b \\
            d & \contr c\\
            b & \contr c \Leftarrow f(d) = a
        \end{cases}
    \end{displaymath}
\end{example}

The authors in \cite{Middeldorp1994} have shown that $\trs$ is complete. Note that basic conditional narrowing is not able to solve the goal $eq(f(d),a)$ as can be seen form the figure below.

\begin{figure}[!ht]
    \begin{displaymath}
        \xymatrix{
            & & eq(f(d),a) \ar@{~>}[dll] \ar@{~>}[drr] \ar@{~>}[d] &  & \\
            eq(\underline{d},b),eq(\underline{d},c) \ar@{~>}[d] & & eq(f(b),a) \ar@{~>}[dl] \ar@{~>}[dr] & & eq(f(c),a) \ar@{~>}[d] \\
            eq(\underline{d},c), eq(f(d),a) &  eq(\underline{b},c) &  & eq(f(c),a), eq(f(d),a) & eq(\underline{c},b) \ar@{~>}[d]\\
            & & & & eq(f(d),a)
        }
    \end{displaymath}
    \caption{Derivation tree for the objective $eq(f(d),a)$}
    \label{figure:counterexample-basic-conditional-narrowing}
\end{figure}
Note that this derivation tree is basic-normalised, i.e., we explore all basic reductions. However, the following non-basic narrowing derivation shows that the goal can be solved:
\begin{align*}
    eq(f(d),a) &\narrow eq(a,a), eq(\underline{d},b), eq(\underline{d},c) \\
    & \narrow eq(a,a), eq(b,b), eq(\underline{d},c) \\
    & \narrow eq(a,a), eq(b,b), eq(c,c) \\
    & \narrow^* \top
\end{align*}
Note further that basic conditional narrowing is unable to solve the normalised goal $eq(f(x),a)$. In \cite{Middeldorp1994}, Holldobler himself has found the problem in his previous proof. The mistake was due to the incorrect assumption that the strong normalization of $\rewriteOnGoals_\trs$ is implied by the strong normalization of $\trs$. We now show, following his own steps, that completeness of basic conditional narrowing can be ensured by strengthening strong normalization. We begin with a definition.

\begin{definition}
    A 1-CTRS $\trs$ is decreasing if there exists a well-founded extension $>$ of the rewrite relation $\contr_\trs$ with the following properties:
    \begin{enumerate}
        \item $>$ has the subterm property, i.e. $t > \restr{t}{p}$ for all positions $p \in \pos{t} \setminus \{\Lambda\}$
        \item if $l \contr r \Leftarrow c \in \trs$ and $\sigma$ is a substitution then $l\sigma > s \sigma$ for all $s = t \in c$.
    \end{enumerate}
\end{definition}

Every decreasing 1-CTRS is strongly normlizing and moreover -- when the number of rewrite rules is finite -- its rewrite relation is decidable.

\begin{example}
    The CTRS of the above example is not decreasing: as $f(d) \contr a \Leftarrow d = b, d = c$ is an instance of the first rewrite rule we must have $f(d) > b$, but the rule $b \contr c \Leftarrow f(d) = a$ requires $b > f(d)$.
\end{example}

With the decreasing hypothesys one can show:
\begin{lemma}
    If $\trs$ is a decreasing 1-CTRS then $\rewriteOnGoals_\trs$ is strongly normalizing.
\end{lemma}

Is now standard to give statements as in the basic non-conditional case. That is the content of the next lemma.
\begin{lemma}
    Let $\trs$ be a 1-CTRS, $T$ a goal clause, and $\sigma$ a normalized substitution. Every innermost $\rewriteOnGoals_\trs$-sequence starting from $T \sigma$ is based on $\overline{T}$.
\end{lemma}

Finally, we have our desired completeness result for conditional basic narrowing.
\begin{theorem}
    Basic conditional narrowing is complete for decreasing and confluent 1-CTRS.
\end{theorem}


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

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

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

Discussion of units

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

\gls{LHC} coordinate systems

\section{Statistics}\label{section:statistics}

Statistics in particle physics


\section{Background} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{sec:bg}

Pattern matching in the context of a programming language was first introduced
in a string manipulation language SNOBOL\cite{SNOBOL64}. Its fourth
reincarnation SNOBOL4 had patterns as first-class data types providing
operations of concatenation and alternation on them\cite{SNOBOL71}. The first
reference to a pattern-matching construct that resembles the one found in
statically typed functional languages today is usually attributed to Burstall
and his work on structural induction\cite{Burstall69provingproperties}.

In the context of object-oriented programming, pattern matching has been first
explored in Pizza programming language\cite{Odersky97pizzainto}. These efforts
have been continued in Scala\cite{Scala2nd} and together with notable work of
Burak Emir on \emph{Object-Oriented Pattern Matching}\cite{EmirThesis} have
resulted in incorporation of pattern matching into the language.

%The first tree based pattern matching methods were found in Fred McBride's
%extension of LISP in 1970.

%ML and Haskell further popularized pattern matching ...

Pattern matching has been closely related to \emph{algebraic data types} and
\emph{equational reasoning} since the early days of functional programming.
In languages like ML and Haskel an \emph{Algebraic Data Type} is a data type
each of whose values is picked from a disjoint sum of (possibly recursive) data
types, called \emph{variants}. Each of the variants is marked with a unique
symbolic constant called \emph{constructor}, while the set of all constructors
of a given type is called \emph{signature}. Constructors provide a convenient
way of creating a value of its variant type as well as a way of discriminating
its variant type from the algebraic data type through pattern matching.

Algebraic data type \codeocaml{expr} from Section~\ref{sec:intro} consists of 5
variants, marked with constructors \codeocaml{Value}, \codeocaml{Plus},
\codeocaml{Minus}, \codeocaml{Times} and \codeocaml{Divide} respectively.
Constructor \codeocaml{Value} expects a value of type \codeocaml{int} during
construction, as well as any pattern that admits values of type \codeocaml{int}
during decomposition through pattern matching. Similarly, the other four
constructors expect a value of a cartesian product of two \codeocaml{expr}
types during construction, as well as any pattern that would admit a value of
such type during decomposition.

Algebraic data types can be parameterized and recursive, as demonstrated by the
following Haskell code that defines a binary tree parameterized on type
\codehaskell{k} of keys and type \codehaskell{d} of data stored in the nodes:

\begin{lstlisting}[language=Haskell]
data Tree k d = Node k d (Tree k d) (Tree k d) | Leaf
\end{lstlisting}

\noindent
Naturally, they can be decomposed in a generic algorithm like the function
\code{find} below, defined through case analysis on the tree's structure:

\begin{lstlisting}[language=Haskell]
find :: (Ord k) => k -> Tree k d -> Maybe d
find i Leaf = Nothing
find i (Node key item left right) =
    if i == key
    then Just item
    else
        if i [<] key
        then find i left
        else find i right
\end{lstlisting}

\noindent
The set of values described by such an algebraic data type is defined
inductively as the least set closed under constructor functions of its variants.
Algebraic data types draw their name from the practice of using case distinction
in mathematical function definitions and proofs that involve \emph{algebraic
terms}.

One of the main differences of algebraic data types from classes in
object-oriented languages is that an algebraic data type definition is
\emph{closed} because it fixes the structure of its instances once and for all.
Once we have listed all the variants a given algebraic data type may have we
cannot extend it with new variants without modifying its definition. This is not
the case in object-oriented languages, where classes are \emph{open} to
extension through subclassing. Notable exceptions to this restriction in
functional community are \emph{polymorphic variants} in OCaml\cite{garrigue-98}
and \emph{open data types} in Haskell\cite{LohHinze2006}, which allow addition
of new variants later. These extensions, however, are simpler than object-oriented
extensions as neither polymorphic variants nor open data types form subtyping
relation between themselves: open data types do not introduce any subtyping
relation, while the subtyping relation on polymorphic variants is a
\emph{semantic subtyping} similar to that of XDuce\cite{HosoyaPierce2000}, which
is based on the subset relation between values of the type. In either case they
maintain the important property that each value of the underlying algebraic data
type belongs to exactly one disjoint subset tagged with a constructor. The
\emph{nominative subtyping} of object-oriented languages does not usually have
this disjointness making classes effectively have multiple types. In particular,
the case of disjoint constructors can be seen as a degenerated case of a flat
class hierarchy among the multitude of possible class hierarchies.

Closedness of algebraic data types is particularly useful for reasoning about
programs by case analysis and allows the compiler to perform an automatic
\emph{incompleteness} check -- test of whether a given \emph{match statement}
covers all possible cases. Similar reasoning about programs involving extensible
data types is more involved as we are dealing with potentially open set of
variants. \emph{Completeness} check in such scenario reduces to checking presence
of a case that handles the static type of the subject. Absence of such a case,
however, does not necessarily imply incompleteness, only potential incompleteness,
as the answer will depend on the actual set of variants available at run-time.

A related notion of \emph{redundancy} checking arises from the
tradition of using \emph{first-fit} strategy in pattern matching. It warns the
user of any \emph{case clause} inside a match statement that will
never be entered because of a preceding one being more general. Object-oriented
languages, especially C++, typically prefer \emph{best-fit} strategy (e.g. for
overload resolution and class template specialization) because it is not prone
to errors where semantics of a statement might change depending on the ordering
of preceding definitions. The notable exception in C++ semantics that prefers
the \emph{first-fit} strategy is ordering of \code{catch} handlers of a
\code{try}-block. Similarly to functional languages the C++ compiler will perform
\emph{redundancy} checking on catch handlers and issue a warning that lists the
redundant cases. We use this property of the C++ type system to perform redundancy
checking of our match statements in \textsection\ref{sec:redun}.

The patterns that work with algebraic data types we have seen so far are
generally called \emph{tree patterns} or \emph{constructor patterns}. Their
analog in object-oriented languages is often referred to as \emph{type pattern}
since it may involve type testing and type casting. Special cases of these patterns
are \emph{list patterns} and \emph{tuple patterns}. The former lets one split a
list into a sequence of elements in its beginning and a tail with the help of
list constructor \codehaskell{:} and an empty list constructor \codehaskell{[]}
e.g. \codehaskell{[x:y:rest]}. The latter does the same with tuples using tuple
constructor \codehaskell{(,,...,)} e.g. \codehaskell{([x:xs],'b',(1,2.0),"hi",True)}.

Pattern matching is not used solely with algebraic data types and can equally
well be applied to built-in types. The following Haskell code defines factorial
function in the form of equations:

\begin{lstlisting}[language=Haskell]
factorial 0 = 1
factorial n = n * factorial (n-1)
\end{lstlisting}

\noindent
Here 0 in the left hand side of the first \emph{equation} is an example of a
\emph{value pattern} (also known as \emph{constant pattern}) that will only
match when the actual argument passed to the function factorial is 0. The
\emph{variable pattern} \codehaskell{n} (also referred to as \emph{identifier
pattern}) in the left hand side of the second equation will match any value,
\emph{binding} variable \codehaskell{n} to that value in the right hand side of
equation. Similarly to variable pattern, the \emph{wildcard pattern} \codehaskell{_}
will match any value, neither binding it to a variable nor even obtaining it.
Value patterns, variable patterns and wildcard patterns are
generally called \emph{primitive patterns}. Patterns like variable and wildcard
patterns that never fail to match are called \emph{irrefutable}, in contrast to
\emph{refutable} patterns like value patterns, which may fail to match.

In Haskell 98\cite{Haskell98Book} the above definition of factorial could also
be written as:

\begin{lstlisting}[language=Haskell]
factorial 0 = 1
factorial (n+1) = (n+1) * factorial n
\end{lstlisting}

\noindent
The \codehaskell{(n+1)} pattern in the left hand side of equation is an example of
\emph{n+k pattern}. According to its informal semantics ``Matching an $n+k$
pattern (where $n$ is a variable and $k$ is a positive integer literal) against
a value $v$ succeeds if $v \ge k$, resulting in the binding of $n$ to $v-k$, and
fails otherwise''\cite{haskell98}. n+k patterns were introduced into Haskell to
let users express inductive functions on natural numbers in much the same way as
functions defined through case analysis on algebraic data types. Besides
succinct notation, such language feature could facilitate automatic proof of
termination of such functions by compiler. Peano numbers, used as an analogy to
algebraic data type representation of natural numbers, is not always the best
abstraction for representing other mathematical operations however. This,
together with numerous ways of defining semantics of generalized n+k patterns
were some of the reasons why the feature was never generalized in Haskell to
other kinds of expressions, even though there were plenty of known applications.
Moreover, numerous debates over semantics and usefulness of the feature
resulted in n+k patterns being removed from the language altogether in Haskell
2010 standard\cite{haskell2010}. Generalization of n+k patterns, called
\emph{application patterns} has been studied by Nikolaas N. Oosterhof in his
Master's thesis\cite{OosterhofThesis}. Application patterns essentially treat
n+k patterns as equations, while matching against them attempts to solve or
validate the equation.

While n+k patterns were something very few languages had, another common feature of
many programming languages with pattern matching are guards. A \emph{guard}
is a predicate attached to a pattern that may make use of the variables bound in
it. The result of its evaluation will determine whether the case clause and the
body associated with it will be \emph{accepted} or \emph{rejected}. The
following OCaml code for $exp$ language from Section~\ref{sec:intro} defines the
rules for factorizing expressions $e_1e_2+e_1e_3$ into $e_1(e_2+e_3)$ and
$e_1e_2+e_3e_2$ into $(e_1+e_3)e_2$ with the help of guards spelled out after
keyword \codeocaml{when}:

\begin{lstlisting}[language=Caml,keepspaces,columns=flexible]
let factorize e =
    match e with
      Plus(Times(e1,e2), Times(e3,e4)) when e1 = e3
          -> Times(e1, Plus(e2,e4))
    | Plus(Times(e1,e2), Times(e3,e4)) when e2 = e4
          -> Times(Plus(e1,e3), e4)
    |   e -> e
    ;;
\end{lstlisting}

\noindent
One may wonder why we could not simply write the above case clause as
\codeocaml{Plus(Times(e,e2), Times(e,e4))} to avoid the guard? Patterns that
permit use of the same variable in them multiple times are called
\emph{equivalence patterns}, while the requirement of absence of such patterns
in a language is called \emph{linearity}. Neither OCaml nor Haskell support such
patterns, while Miranda\cite{Miranda85} as well as Tom's pattern matching
extension to C, Java and Eiffel\cite{Moreau:2003} supports \emph{non-linear
patterns}.

The example above illustrates yet another common pattern-matching facility --
\emph{nesting of patterns}. In general, a constructor pattern composed of a
linear vector of (distinct) variables is called a \emph{simple pattern}. The
same pattern composed not only of variables is called \emph{nested pattern}.
Using nested patterns, with a simple expression in the case clause we could
define a predicate that tests the top-level expression to be tagged with a
\codeocaml{Plus} constructor, while both of its arguments to be marked with
\codeocaml{Times} constructor, binding their arguments (or potentially pattern
matching further) respectively. Note that the visitor design pattern does not
provide this level of flexibility and each of the nested tests might have
required a new visitor to be written. Nesting of patterns like the one above is
typically where users resort to \emph{type tests} and \emph{type casts} that in
case of C++ can be combined into a single call to \code{dynamic_cast}.

Related to nested patterns are \emph{as-patterns} that help one take a value
apart while still maintaining its integrity. The following rule could have been
a part of a hypothetical rewriting system in OCaml similar to the one above. Its
intention is to rewrite expressions of the form $\frac{e_1/e_2}{e_3/e_4}$ into
$\frac{e_1}{e_2}\frac{e_4}{e_3} \wedge e_2\neq0 \wedge e_3\neq0 \wedge e_4\neq0$.

\begin{lstlisting}[language=Caml]
    | Divide(Divide(_,e2) as x, Divide(e3,e4))
          -> Times(x, Divide(e4, e3))
\end{lstlisting}

\noindent
We introduced a name ``x'' as a synonym of the result of matching the
entire sub-expression \codeocaml{Divide(_,e2)} in order to refer it without
recomposing in the right-hand side of the case clause. We omitted the
conjunction of relevant non-zero checks for brevity, one can see that we will
need access to \codeocaml{e2} in it however.

Decomposing algebraic data types through pattern matching has an important
drawback that was originally spotted by Wadler\cite{Wadler87}: they expose
concrete representation of an abstract data type, which conflicts with the
principle of \emph{data abstraction}. To overcome the problem he proposed the
notion of \emph{views} that represent conversions between different
representations that are implicitly applied during pattern matching. As an
example, imagine polar and cartesian representations of complex numbers. A user
might choose polar representation as a concrete representation for the abstract
data type \codeocaml{complex}, treating cartesian representation as view or vice
versa:\footnote{We use the syntax from Wadler's original paper for this example}

\begin{lstlisting}[language=Haskell,columns=flexible]
complex ::= Pole real real
view complex ::= Cart real real
  in  (Pole r t) = Cart (r * cos t) (r * sin t)
  out (Cart x y) = Pole (sqrt(x^2 + y^2)) (atan2 x y)
\end{lstlisting}

\noindent
The operations then might be implemented in whatever representation is the most
suitable, while the compiler will implicitly convert representation if needed:

\begin{lstlisting}[language=Haskell,columns=flexible]
  add  (Cart x1 y1) (Cart x2 y2) = Cart (x1 + x2) (y1 + y2)
  mult (Pole r1 t1) (Pole r2 t2) = Pole (r1 * r2) (t1 + t2)
\end{lstlisting}

\noindent
The idea of views were later adopted in various forms in several languages:
Haskell\cite{views96}, Standard ML\cite{views98}, Scala (in the form of
\emph{extractors}\cite{EmirThesis}) and F$\sharp$ (under the name of
\emph{active patterns}\cite{Syme07}). We demonstrate our support of views in
\textsection\ref{sec:view}.

%Views in functional programming languages [92, 71] are conversions from one data type to
%another that are implicitly applied in pattern matching. They play a role similar to extractors
%in Scala, in that they permit to abstract from the concrete data-type of the matched objects.
%However, unlike extractors, views are anonymous and are tied to a particular target data
%type.

Logic programming languages like Prolog take pattern matching to even greater
level. The main difference between pattern matching in logic languages and
functional languages is that functional pattern matching is a ``one-way''
matching where patterns are matched against values, possibly binding some
variables in the pattern along the way. Pattern matching in logic programming is
``two-way'' matching based on \emph{unification} where patterns can be matched
against other patterns, possibly binding some variables in both patterns and
potentially leaving some variables \emph{unbound} or partially bound -- i.e.
bound to patterns. A hypothetical example of such functionality can be matching
a pattern \codeocaml{Plus(x,Times(x,1))} against another pattern
\codeocaml{Plus(Divide(y,2),z)}, which will result in binding \codeocaml{x} to a
\codeocaml{Divide(y,2)} and \codeocaml{z} to \codeocaml{Times(Divide(y,2),1)}
with \codeocaml{y} left unbound, leaving both \codeocaml{x} and \codeocaml{z}
effectively a pattern.

\subsection{Algebraic Data Types in C++}
\label{sec:adt}

C++ does not have a direct support of algebraic data types, but they can usually
be emulated in a number of ways. A pattern-matching solution that strives to be
general will have to account for different encodings and be applicable to all of
them.

Consider an ML data type of the form:

\begin{lstlisting}[language=ML,keepspaces,columns=flexible,escapechar=@]
datatype DT = @$C_1$@ of {@$L_{11}:T_{11},...,L_{1m}:T_{1m}$@}
              | ...
              | @$C_k$@ of {@$L_{k1}:T_{k1},...,L_{kn}:T_{kn}$@}
\end{lstlisting}

\noindent There are at least 3 different ways to represent it in C++. Following
Emir, we will refer to them as \emph{encodings}~\cite{EmirThesis}:

\begin{itemize}
\setlength{\itemsep}{0pt}
\setlength{\parskip}{0pt}
\item Polymorphic Base Class (or \emph{polymorphic encoding} for short)
\item Tagged Class (or \emph{tagged encoding} for short)
\item Discriminated Union (or \emph{union encoding} for short)
\end{itemize}

\noindent
In polymorphic and tagged encoding, base class \code{DT} represents algebraic
data type, while derived classes represent variants. The only difference between
the two is that in polymorphic encoding base class has virtual functions, while
in tagged encoding it has a dedicated member of integral type that uniquely
identifies the variant -- derived class.

The first two encodings are inherently \emph{open} because the classes can be
arbitrarily extended through subclassing. The last encoding is inherently
\emph{closed} because we cannot add more members to the union without modifying
its definition.

%In order to be able to provide a common syntax for these representations, we
%need to understand better similarities and differences between them. Before we
%look into them let's fix some terminology.

When we deal with pattern matching, the static type of the original expression
we are matching may not necessarily be the same as the type of expression we
match it with. We call the original expression a \emph{subject} and its static
type -- \emph{subject type}. We call the type we are trying to match subject
against -- a \emph{target type}.

In the simplest case, detecting that the target type is a given type or a type
derived from it, is everything we want to know. We refer to such a use-case as
\emph{type testing}. In the next simplest case, besides testing we might want to
get a pointer or a reference to the target type of subject as casting it to such
a type may involve a non-trivial computation only a compiler can safely
generate. We refer to such a use-case as \emph{type identification}. Type
identification of a given subject against multiple target types is typically
referred to as \emph{type switching}.

Once we uncovered the target type, we may want to be able to decompose it
\emph{structurally} (when the target type is a \emph{structured} data type like
array, tuple or class) or \emph{algebraically} (when the target type is a scalar
data type like \code{int} or \code{double}). Structural decomposition in our
library can be performed with the help of \emph{tree patterns}, while algebraic
decomposition can be done with the help of \emph{generalized n+k patterns}.

\subsubsection{Polymorphic Base Class}
\label{sec:pbc}

In this encoding user declares a polymorphic base class \code{DT} that will
be extended by classes representing all the variants. Base class might declare
several virtual functions that will be overridden by derived classes, for example
\code{accept} used in a Visitor Design Pattern.

\begin{lstlisting}[keepspaces,columns=flexible]
class DT { virtual @$\sim$@DT{} };
class @$C_1$@ : public DT {@$T_{11} L_{11}; ... T_{1m} L_{1m};$@}
...
class @$C_k$@ : public DT {@$T_{k1} L_{k1}; ... T_{kn} L_{kn};$@}
\end{lstlisting}

The uncover the actual variant of such an algebraic data type, the user might
use \code{dynamic_cast} to query one of the $k$ expected run-time types (an
approach used by Rose\cite{SQ03}) or she might employ a visitor design pattern
devised for this algebraic data type (an approach used by Pivot\cite{Pivot09}
and Phoenix\cite{Phoenix}). The most attractive feature of this approach is that
it is truly open as we can extend classes arbitrarily at will (leaving the
orthogonal issues of visitors aside).

\subsubsection{Tagged Class}
\label{sec:tc}

This encoding is similar to the \emph{Polymorphic Base Class} in that we use
derived classes to encode the variants. The main difference is that the user
designates a member in the base class, whose value will uniquely
determine the most derived class a given object is an instance of. Constructors
of each variant $C_i$ are responsible for properly initializing the dedicated
member with a unique value $c_i$ associated with that variant. Clang\cite{Clang}
among others uses this approach.

\begin{lstlisting}[keepspaces,columns=flexible]
class DT { enum kinds {@$c_1, ..., c_k$@} m_kind; };
class @$C_1$@ : public DT {@$T_{11} L_{11}; ... T_{1m} L_{1m};$@}
...
class @$C_k$@ : public DT {@$T_{k1} L_{k1}; ... T_{kn} L_{kn};$@}
\end{lstlisting}

In such scenario the user might use a simple switch statement to uncover the
type of the variant combined with a \code{static_cast} to properly cast the
pointer or reference to an object. People might prefer this encoding to the one
above for performance reasons as it is possible to avoid virtual dispatch with
it altogether. Note, however, that once we allow for extensions and not limit
ourselves with encoding algebraic data types only it also has a significant
drawback in comparison to the previous approach: we can easily check that given
object belongs to the most derived class, but we cannot say much about whether
it belongs to one of its base classes. A visitor design pattern can be
implemented to take care of this problem, but control inversion that comes along
with it will certainly diminish the convenience of having just a switch
statement. Besides, forwarding overhead might lose some of the performance
benefits gained originally by putting a dedicated member into the base class.

\subsubsection{Discriminated Union}
\label{sec:du}

This encoding is popular in projects that are either implemented in C or
originated from C before coming to C++. It involves a type that contains a union
of its possible variants, discriminated with a dedicated value stored as a part
of the structure. The approach is used by EDG front-end\cite{EDG} and many others.

\begin{lstlisting}[keepspaces,columns=flexible]
struct DT
{
    enum kinds {@$c_1, ..., c_k$@} m_kind;
    union {
        struct @$C_1$@ {@$T_{11} L_{11}; ... T_{1m} L_{1m};$@} @$C_1$@;
        ...
        struct @$C_k$@ {@$T_{k1} L_{k1}; ... T_{kn} L_{kn};$@} @$C_k$@;
    };
};
\end{lstlisting}

As before, the user can use a switch statement to identify the variant $c_i$ and
then access its members via $C_i$ union member. This approach is truly closed, as
we cannot add new variants to the underlying union without modifying class
definition.

Note also that in this case both subject type and target types are the same and
we use an integral constant to distinguish which member(s) of the underlying union
is active now. In the other two cases the type of a subject is a base class of
the target type and we use either run-time type information or the integral
constant associated by the user with the target type to uncover the target type.

\subsection{Expression Templates}

Interestingly enough C++ has a pure functional sublanguage in it that has a
striking similarity to ML and Haskell. The sublanguage in question is template
facilities of C++ that has been shown to be Turing
complete\cite{veldhuizen:templates_turing_complete}.

Haskell definition of \code{factorial} we saw earlier can be rewritten in
template sublanguage of C++ as following:

\begin{lstlisting}
template <int N>
    struct factorial { enum { result = N*factorial<N-1>::result }; };
template <>
    struct factorial<0> { enum { result = 1 }; };
\end{lstlisting}

\noindent
One can easily see similarity with equational definitions in Haskell, with the
exception that more specific cases (specialization for 0) have to follow the
general definition in C++. The main difference between Haskell definition and
its C++ counterpart is that the former describes computations on \emph{run-time
values}, while the latter can only work with \emph{compile-time values}.

Turns out we can even express our $exp$ language using this functional
sublanguage:

\begin{lstlisting}
template <class T>
struct value {
    value(const T& t) : m_value(t) {}
    T m_value;
};

template <class T>
struct variable {
    variable() : m_value() {}
    T m_value;
};

template <typename E1, typename E2>
struct plus {
    plus(const E1& e1, const E2& e2) : m_e1(e1), m_e2(e2) {}
    const E1 m_e1; const E2 m_e2;
};

// ... definitions of other expressions
\end{lstlisting}

\noindent The idea is that expressions can be composed out of subexpressions,
whose shape (type) is passed as arguments to above templates. Explicit
description of such expressions is very tedious however and is thus never
expressed directly, but as a result of corresponding operations:

\begin{lstlisting}[keepspaces,columns=flexible]
template <typename T>
    value<T> val(const T& t) { return value<T>(t); }
template <typename E1, typename E2>
    plus<E1,E2> operator+(const E1& e1, const E2& e2)
    { return plus<E1,E2>(e1,e2); }
\end{lstlisting}

\noindent With this, one can now capture various expressions as following:

\begin{lstlisting}
variable<int> v;
auto x = v + val(3);
\end{lstlisting}

\noindent The type of variable \code{x} -- \code{plus<variable<int>,value<int>>}
 -- captures the structure of the expression, while the values inside of it
represent various subexpressions the expression was created with. Such an
expression can be arbitrarily, but finitely nested. Note that value 3 is not
added to the value of variable \code{v} here, but the expression \code{v+3} is
recorded, while the meaning to such expression can be given differently in
different contexts. A general observation is that only the shape of the
expression becomes fixed at compile time, while the values of variables involved
in it can be changed arbitrarily at run time, allowing for \emph{lazy
evaluation} of the expression. Polymorphic function \code{eval} below implements
just that:

\begin{lstlisting}[keepspaces,columns=flexible]
template <typename T>
    T eval(const value<T>& e) { return e.m_value; }
template <typename T>
    T eval(const variable<T>& e) { return e.m_value; }
template <typename E1, typename E2>
    auto eval(const plus<E1,E2>& e)
         -> decltype(eval(e.m_e1) + eval(e.m_e2))
            { return eval(e.m_e1) + eval(e.m_e2); }
\end{lstlisting}

\noindent One can now modify value of the variable \code{v} and re-evaluate
expression as following:

\begin{lstlisting}
v = 7;           // assumes overloading of assignment
int r = eval(x); // returns 10
\end{lstlisting}

\noindent The above technique for lazy evaluation of expressions was
independently invented by Todd Veldhuizen and David Vandevoorde and is generally
known in the C++ community by the name \emph{Expression Templates} that Todd
coined\cite{Veldhuizen95expressiontemplates, vandevoorde2003c++}.

Note again how implementation of \code{eval} resembles equations in Haskell that
decompose an algebraic data type. The similarities are so striking that there
were attempts to use Haskell as a pseudo code language for template
metaprogramming in C++\cite{Milewski11}. A key observation in this analogy is
that partial and explicit template specialization of C++ class templates are
similar to defining equations for Haskell functions. Variables introduced via
template clause of each equation serve as \emph{variable patterns}, while the
names of actual templates describing arguments serve as \emph{variant
constructors}. An important difference between the two is that Haskell's
equations use \emph{first-fit} strategy making order of equations important,
while C++ uses \emph{best-fit} strategy, thus making the order irrelevant.

Patterns expressed this way can be arbitrarily nested as long as they can be
expressed in terms of the types involved and not the values they store. Using
the above example, for instance, it is very easy to specialize \code{eval} for
an expression of form $c_1*x+c_2$ where $c_i$ are some (not known) constant
values and $x$ is any variable. Specializing for a concrete instance of that
expression $2*x+3$ will be much harder, because in the representation we chose
values 2 and 3 become run-time values and thus cannot participate in
compile-time computations anymore. In this case we could have devised a template
that allocates a dedicated type for each constant making such value part of the
type:

\begin{lstlisting}[keepspaces,columns=flexible]
template <class T, T t> struct constant {};

template <typename T, T t>
    T eval(const constant<T,t>& e) { return t; }
template <typename E>
    auto eval(const times<constant<int,0>,E>& e)
        -> decltype(eval(e.m_e2))
            { return (decltype(eval(e.m_e2)))(0); }
template <typename E>
    auto eval(const times<E,constant<int,0>>& e)
        -> decltype(eval(e.m_e1))
            { return (decltype(eval(e.m_e1)))(0); }
\end{lstlisting}

\noindent Here the first equation for \code{eval} describes the necessary general
case for handling expressions of type \code{constant<T,t>}, while the other two
are redundant cases that can be seen as an optimization detecting expressions of
the form $e*0$ and $0*e$ for any arbitrary expression $e$ and returning 0
without actually computing $e$.

Unfortunately, a similar pattern to detect expressions of the form $x-x$ for any
variable $x$ cannot be expressed because expression templates are blind to
object identity and can only see their types. This means that expression
templates of the form $x-y$ are indisthinguishable at compile time from
expressions of the form $x-x$ because their types are identical.

Nevertheless, with all the limitations, expression templates provide an
extremely powerful abstraction mechanism, which we use to express a
pattern-language for our SELL. Coincidentally, we employ the compile-time
pattern-matching facility already supported by C++ as a meta-language to
implement its run-time counterpart.