%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Copyright (c) 2003-2018 by The University of Queensland
% http://www.uq.edu.au
%
% Primary Business: Queensland, Australia
% Licensed under the Apache License, version 2.0
% http://www.apache.org/licenses/LICENSE-2.0
%
% Development until 2012 by Earth Systems Science Computational Center (ESSCC)
% Development 2012-2013 by School of Earth Sciences
% Development from 2014 by Centre for Geoscience Computing (GeoComp)
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\section{Example 1: One Dimensional Heat Diffusion in Granite}
\label{Sec:1DHDv00}

The first model consists of two blocks of isotropic material, for instance
granite, sitting next to each other (\autoref{fig:onedgbmodel}).
Initial temperature in \textit{Block 1} is \verb|T1| and in \textit{Block 2} is
\verb|T2|.
We assume that the system is insulated.
What would happen to the temperature distribution in each block over time?
Intuition tells us that heat will be transported from the hotter block to the
cooler one until both
blocks have the same temperature.

\begin{figure}[ht]
\centerline{\includegraphics[width=4.in]{figures/onedheatdiff001}}
\caption{Example 1: Temperature differential along a single interface between
two granite blocks.}
\label{fig:onedgbmodel}
\end{figure}

\subsection{1D Heat Diffusion Equation}
We can model the heat distribution of this problem over time using the one
dimensional heat diffusion equation\footnote{A detailed discussion on how the
heat diffusion equation is derived can be found at
\url{
http://online.redwoods.edu/instruct/darnold/DEProj/sp02/AbeRichards/paper.pdf}};
which is defined as:
\begin{equation}
\rho c_p \frac{\partial T}{\partial t} - \kappa \frac{\partial^{2}
T}{\partial x^{2}} = q_H
\label{eqn:hd}
\end{equation}
where $\rho$ is the material density, $c_p$ is the specific heat and
$\kappa$ is the thermal
conductivity\footnote{A list of some common thermal conductivities is available
from Wikipedia
\url{http://en.wikipedia.org/wiki/List_of_thermal_conductivities}}. Here we
assume that these material
parameters are \textbf{constant}.
The heat source is defined by the right hand side of \refEq{eqn:hd} as
$q_{H}$; this can take the form of a constant or a function of time and
space. For example $q_{H} = q_{0}e^{-\gamma t}$ where we have
the output of our heat source decaying with time. There are also two partial
derivatives in \refEq{eqn:hd}; $\frac{\partial T}{\partial t}$ describes the
change in temperature with time while $\frac{\partial ^2 T}{\partial x^2}$ is
the spatial change of temperature. As there is only a single spatial dimension
to our problem, our temperature solution $T$ is only dependent on the time $t$
and our signed distance from the block-block interface $x$.

\subsection{PDEs and the General Form}
It is possible to solve PDE \refEq{eqn:hd} analytically and obtain an exact
solution to our problem. However, it is not always practical to solve the
problem this way. Alternatively, computers can be used to find the solution. To
do this, a numerical approach is required to discretise
the PDE \refEq{eqn:hd} across time and space, this reduces the problem to a
finite number of equations for a finite number of spatial points and time steps.
These parameters together define the model. While discretisation introduces
approximations and a degree of error, a sufficiently sampled model is generally
accurate enough to satisfy the accuracy requirements for the final solution.

Firstly, we discretise the PDE \refEq{eqn:hd} in time. This leaves us with a
steady linear PDE which involves spatial derivatives only and needs to be solved
in each time step to progress in time. \esc can help us here.

For time discretisation we use the Backward Euler approximation
scheme\footnote{see \url{http://en.wikipedia.org/wiki/Euler_method}}. It is
based on the approximation
\begin{equation}
\frac{\partial T(t)}{\partial t} \approx \frac{T(t)-T(t-h)}{h}
\label{eqn:beuler}
\end{equation}
for  $\frac{\partial T}{\partial t}$  at time $t$
where $h$ is the time step size. This can also be written as;
\begin{equation}
\frac{\partial T}{\partial t}(t^{(n)}) \approx \frac{T^{(n)} - T^{(n-1)}}{h}
\label{eqn:Tbeuler}
\end{equation}
where the upper index $n$ denotes the n\textsuperscript{th} time step. So one
has
\begin{equation}
\begin{array}{rcl}
t^{(n)} & = & t^{(n-1)}+h \\
T^{(n)} & = & T(t^{(n-1)}) \\
\end{array}
\label{eqn:Neuler}
\end{equation}
Substituting \refEq{eqn:Tbeuler} into \refEq{eqn:hd} we get;
\begin{equation}
\frac{\rho c_p}{h} (T^{(n)} - T^{(n-1)}) - \kappa \frac{\partial^{2}
T^{(n)}}{\partial x^{2}} = q_H
\label{eqn:hddisc}
\end{equation}
Notice that we evaluate the spatial derivative term at the current time
$t^{(n)}$ - therefore the name \textbf{backward Euler} scheme. Alternatively,
one can evaluate the spatial derivative term at the previous time $t^{(n-1)}$.
This approach is called the \textbf{forward Euler} scheme. This scheme can
provide some computational advantages, which
are not discussed here. However, the \textbf{forward Euler} scheme has a major
disadvantage. Namely, depending on the
material parameters as well as the domain discretization of the spatial
derivative term, the time step size $h$ needs to be chosen sufficiently small to
achieve a stable temperature when progressing in time. Stability is achieved if
the temperature does not grow beyond its initial bounds and becomes
non-physical.
The backward Euler scheme, which we use here, is unconditionally stable meaning
that under the assumption of a
physically correct problem set-up the temperature approximation remains physical
for all time steps.
The user needs to keep in mind that the discretisation error introduced by
\refEq{eqn:beuler}
is sufficiently small, thus a good approximation of the true temperature is
computed. It is therefore very important that any results are viewed with
caution. For example, one may compare the results for different time and
spatial step sizes.

To get the temperature $T^{(n)}$ at time $t^{(n)}$ we need to solve the linear
differential equation \refEq{eqn:hddisc} which only includes spatial
derivatives. To solve this problem we want to use \esc.

In \esc any given PDE can be described by the general form. For the purpose of
this introduction we illustrate a simpler version of the general form for full
linear PDEs which is available in the \esc user's guide. A simplified form that
suits our heat diffusion problem\footnote{The form in the \esc users guide which
uses the Einstein convention is written as
$-(A_{jl} u_{,l})_{,j}+D u =Y$}
is described by;
\begin{equation}\label{eqn:commonform nabla}
-\nabla\cdot(A\cdot\nabla u) + Du = f
\end{equation}
where $A$, $D$ and $f$ are known values and $u$ is the unknown solution. The
symbol $\nabla$ which is called the \textit{Nabla operator} or \textit{del
operator} represents
the spatial derivative of its subject - in this case $u$. Lets assume for a
moment that we deal with a one-dimensional problem then ;
\begin{equation}
\nabla = \frac{\partial}{\partial x}
\end{equation}
and we can write \refEq{eqn:commonform nabla} as;
\begin{equation}\label{eqn:commonform}
-A\frac{\partial^{2}u}{\partial x^{2}} + Du = f
\end{equation}
if $A$ is constant. To match this simplified general form to our problem
\refEq{eqn:hddisc}
we rearrange \refEq{eqn:hddisc};
\begin{equation}
\frac{\rho c_p}{h} T^{(n)} - \kappa \frac{\partial^2 T^{(n)}}{\partial
x^2} = q_H +  \frac{\rho c_p}{h} T^{(n-1)}
\label{eqn:hdgenf}
\end{equation}
The PDE is now in a form that satisfies \refEq{eqn:commonform nabla} which is
required for \esc to solve our PDE. This can be done by generating a solution
for successive increments in the time nodes $t^{(n)}$ where
$t^{(0)}=0$ and  $t^{(n)}=t^{(n-1)}+h$ where $h>0$ is the step size and assumed
to be constant.
In the following the upper index ${(n)}$ refers to a value at time $t^{(n)}$.
Finally, by comparing \refEq{eqn:hdgenf} with \refEq{eqn:commonform} one can see
that;
\begin{equation}\label{ESCRIPT SET}
u=T^{(n)};
A = \kappa; D = \frac{\rho c _{p}}{h}; f = q _{H} + \frac{\rho
c_p}{h} T^{(n-1)}
\end{equation}

\subsection{Boundary Conditions}
\label{SEC BOUNDARY COND}
With the PDE sufficiently modified, consideration must now be given to the
boundary conditions of our model. Typically there are two main types of boundary
conditions known as \textbf{Neumann} and \textbf{Dirichlet} boundary
conditions\footnote{More information on Boundary Conditions is available at
Wikipedia \url{http://en.wikipedia.org/wiki/Boundary_conditions}},
respectively.
A \textbf{Dirichlet boundary condition} is conceptually simpler and is used to
prescribe a known value to the unknown solution (in our example the temperature)
on parts of the boundary or on the entire boundary of the region of interest.
We discuss the Dirichlet boundary condition in our second example presented in
Section~\ref{Sec:1DHDv0}.

However, for this example we have made the model assumption that the system is
insulated, so we need to add an appropriate boundary condition to prevent
any loss or inflow of energy at the boundary of our domain. Mathematically this
is expressed by prescribing
the heat flux $\kappa \frac{\partial T}{\partial x}$  to zero. In our simplified
one dimensional model this is expressed
in the form;
\begin{equation}
\kappa \frac{\partial T}{\partial x}  = 0
\end{equation}
or in a more general case as
\begin{equation}\label{NEUMAN 1}
\kappa \nabla T \cdot n  = 0
\end{equation}
where $n$  is the outer normal field \index{outer normal field} at the surface
of the domain.
The $\cdot$ (dot) refers to the dot product of the vectors $\nabla T$ and $n$.
In fact, the term $\nabla T \cdot n$ is the normal derivative of
the temperature $T$. Other notations used here are\footnote{The \esc notation
for the normal
derivative is $T_{,i} n_i$.};
\begin{equation}
\nabla T \cdot n  = \frac{\partial T}{\partial n} \; .
\end{equation}
A condition of the type \refEq{NEUMAN 1} defines a \textbf{Neumann boundary
condition} for the PDE.

The PDE \refEq{eqn:hdgenf}
and the Neumann boundary condition~\ref{eqn:hdgenf} (potentially together with
the Dirichlet boundary conditions)  define a \textbf{boundary value problem}.
It is the nature of a boundary value problem to allow making statements about
the solution in the
interior of the domain from information known on the boundary only. In most
cases we use the term partial differential equation but in fact it is a
boundary value problem.
It is important to keep in mind that boundary conditions need to be complete and
consistent in the sense that
at any point on the boundary either a Dirichlet or a Neumann boundary condition
must be set.

Conveniently, \esc makes a default assumption on the boundary conditions which
the user may modify where appropriate.
For a problem of the form in~\refEq{eqn:commonform nabla} the default
condition\footnote{In the \esc user guide which uses the Einstein convention
this is written as
$n_{j}A_{jl} u_{,l}=0$.} is;
\begin{equation}\label{NEUMAN 2}
-n\cdot A \cdot\nabla u = 0
\end{equation}
which is used everywhere on the boundary. Again $n$ denotes the outer normal
field.
Notice that the coefficient $A$ is the same as in the \esc
PDE~\ref{eqn:commonform nabla}.
With the settings for the coefficients we have already identified in
\refEq{ESCRIPT SET} this
condition translates into
\begin{equation}\label{NEUMAN 2b}
\kappa \frac{\partial T}{\partial x} = 0
\end{equation}
for the boundary of the domain. This is identical to the Neumann boundary
condition we want to set. \esc will take care of this condition for us. We
discuss the Dirichlet boundary condition later.

\subsection{Outline of the Implementation}
\label{sec:outline}
To solve the heat diffusion equation (\refEq{eqn:hd}) we write a simple \pyt
script. At this point we assume that you have some basic understanding of the
\pyt programming language. If not, there are some pointers and links available
in Section \ref{sec:escpybas}. The script (discussed in \refSec{sec:key}) has
four major steps. Firstly, we need to define the domain where we want to
calculate the temperature. For our problem this is the joint blocks of granite
which has a rectangular shape. Secondly, we need to define the PDE to solve in
each time step to get the updated temperature. Thirdly, we need to define the
coefficients of the PDE and finally we need to solve the PDE. The last two steps
need to be repeated until the final time marker has been reached. The work flow
is described in \reffig{fig:wf}.
% \begin{enumerate}
%  \item create domain
%  \item create PDE
%  \item while end time not reached:
% \begin{enumerate}
%  \item set PDE coefficients
%  \item solve PDE
%  \item update time marker
% \end{enumerate}
% \item end of calculation
% \end{enumerate}

\begin{figure}[h!]
 \centering
   \includegraphics[width=1in]{figures/workflow.png}
   \caption{Workflow for developing an \esc model and solution}
   \label{fig:wf}
\end{figure}

In the terminology of \pyt, the domain and PDE are represented by
\textbf{objects}. The nice feature of an object is that it is defined by its
usage and features
rather than its actual representation. So we will create a domain object to
describe the geometry of the two
granite blocks. Then we define PDEs and spatially distributed values such as the
temperature
on this domain. Similarly, to define a PDE object we use the fact that one needs
only to define the coefficients of the PDE and solve the PDE. The PDE object has
advanced features, but these are not required in simple cases.

\begin{figure}[htp]
 \centering
   \includegraphics[width=6in]{figures/functionspace.pdf}
   \caption{\esc domain construction overview}
   \label{fig:fs}
\end{figure}

\subsection{The Domain Constructor in \esc}
\label{ss:domcon}
Whilst it is not strictly relevant or necessary, a better understanding of
how values are spatially distributed (\textit{e.g.} Temperature) and how PDE
coefficients are interpreted in \esc can be helpful.

There are various ways to construct domain objects. The simplest form is a
rectangular shaped region with a length and height. There is
a ready to use function for this named \verb rectangle(). Besides the spatial
dimensions this function requires to specify the number of
elements or cells to be used along the length and height, see \reffig{fig:fs}.
Any spatially distributed value
and the PDE is represented in discrete form using this element
representation\footnote{We use the finite element method (FEM), see
\url{http://en.wikipedia.org/wiki/Finite_element_method} for details.}.
Therefore we will have access to an approximation of the true PDE solution
only.
The quality of the approximation depends - besides other factors - mainly on the
number of elements being used. In fact, the
approximation becomes better when more elements are used. However, computational
cost grows with the number of
elements being used. It is therefore important that you find the right balance
between the demand in accuracy and acceptable resource usage.

In general, one can think about a domain object as a composition of nodes and
elements.
As shown in \reffig{fig:fs}, an element is defined by the nodes that are used to
describe its vertices.
To represent spatially distributed values the user can use
the values at the nodes, at the elements in the interior of the domain or at the
elements located on the surface of the domain.
The different approach used to represent values is called \textbf{function
space} and is attached to all objects
in \esc representing a spatially distributed value such as the solution of
a PDE. The three function spaces we use at the moment are;
\begin{enumerate}
\item the nodes, called by \verb|ContinuousFunction(domain)| ;
\item the elements/cells, called by \verb|Function(domain)| ; and
\item the boundary, called by \verb|FunctionOnBoundary(domain)|.
\end{enumerate}
A function space object such as \verb|ContinuousFunction(domain)| has the method
\verb|getX| attached to it. This method returns the
location of the so-called \textbf{sample points} used to represent values of the
particular function space. So the
call \verb|ContinuousFunction(domain).getX()| will return the coordinates of the
nodes used to describe the domain while
\verb|Function(domain).getX()| returns the coordinates of numerical
integration points within elements, see \reffig{fig:fs}.

This distinction between different representations of spatially distributed
values
is important in order to be able to vary the degrees of smoothness in a PDE
problem.
The coefficients of a PDE do not need to be continuous, thus this qualifies as a
\verb|Function()| type.
On the other hand a temperature distribution must be continuous and needs to be
represented with a \verb|ContinuousFunction()| function space.
An influx may only be defined at the boundary and is therefore a
\verb|FunctionOnBoundary()| object.
\esc allows certain transformations of the function spaces. A
\verb|ContinuousFunction()| can be transformed into a
\verb|FunctionOnBoundary()| or \verb|Function()|. On the other hand there is
not enough information in a \verb|FunctionOnBoundary()| to transform it to a
\verb|ContinuousFunction()|.
These transformations, which are called \textbf{interpolation} are invoked
automatically by \esc if needed.

Later in this introduction we discuss how
to define specific areas of geometry with different materials which are
represented by different material coefficients such as the
thermal conductivities $\kappa$. A very powerful technique to define these types
of PDE
coefficients is tagging. Blocks of materials and boundaries can be named and
values can be defined on subregions based on their names.
This is a method for simplifying PDE coefficient and flux definitions. It makes
scripting much easier and we will discuss this technique in
Section~\ref{STEADY-STATE HEAT REFRACTION}.

\subsection{A Clarification for the 1D Case}
\label{SEC: 1D CLARIFICATION}
It is necessary for clarification that we revisit our general PDE from
\refeq{eqn:commonform nabla} for a two dimensional domain. \esc is inherently
designed to solve problems that are multi-dimensional and so
\refEq{eqn:commonform nabla} needs to be read as a higher dimensional problem.
In the case of two spatial dimensions the \textit{Nabla operator} has in fact
two components $\nabla = (\frac{\partial}{\partial x}, \frac{\partial}{\partial
y})$. Assuming the coefficient $A$ is constant, the \refEq{eqn:commonform nabla}
takes the following form;
\begin{equation}\label{eqn:commonform2D}
-A_{00}\frac{\partial^{2}u}{\partial x^{2}}
-A_{01}\frac{\partial^{2}u}{\partial x\partial y}
-A_{10}\frac{\partial^{2}u}{\partial y\partial x}
-A_{11}\frac{\partial^{2}u}{\partial y^{2}}
+ Du = f
\end{equation}
Notice that for the higher dimensional case $A$ becomes a matrix. It is also
important to notice that the usage of the Nabla operator creates
a compact formulation which is also independent from the spatial dimension.
To make the general PDE \refEq{eqn:commonform2D} one dimensional as
shown in \refEq{eqn:commonform} we need to set
\begin{equation}
A_{00}=A; A_{01}=A_{10}=A_{11}=0
\end{equation}

\subsection{Developing a PDE Solution Script}
\label{sec:key}
\sslist{example01a.py}
We write a simple \pyt script which uses the \modescript, \modfinley and \modmpl
modules.
By developing a script for \esc, the heat diffusion equation can be solved at
successive time steps for a predefined period using our general form
\refEq{eqn:hdgenf}. Firstly it is necessary to import all the
libraries\footnote{The libraries contain predefined scripts that are required to
solve certain problems, these can be simple like sine and cosine functions or
more complicated like those from our \esc library.}
that we will require.
\begin{python}
from esys.escript import *
# This defines the LinearPDE module as LinearPDE
from esys.escript.linearPDEs import LinearPDE
# This imports the rectangle domain function from finley.
from esys.finley import Rectangle
# A useful unit handling package which will make sure all our units
# match up in the equations under SI.
from esys.escript.unitsSI import *
\end{python}
It is generally a good idea to import all of the \modescript library, although
if the functions and classes required are known they can be specified
individually. The function \verb|LinearPDE| has been imported explicitly for
ease of use later in the script. \verb|Rectangle| is going to be our type of
domain. The module \verb|unitsSI| provides support for SI unit definitions with
our variables.

Once our library dependencies have been established, defining the problem
specific variables is the next step. In general the number of variables needed
will vary between problems. These variables belong to two categories. They are
either directly related to the PDE and can be used as inputs into the \esc
solver, or they are script variables used to control internal functions and
iterations in our problem. For this PDE there are a number of constants which
need values. Firstly, the domain upon which we wish to solve our problem needs
to be defined. There are different types of domains in \modescript which we
demonstrate in later tutorials but for our granite blocks, we simply use a
rectangular domain.

Using a rectangular domain simplifies our granite blocks (which would in reality
be a \textit{3D} object) into a single dimension. The granite blocks will have a
lengthways cross section that looks like a rectangle.  As a result we do not
need to model the volume of the block due to symmetry. There are four arguments
we must consider when we decide to create a rectangular domain, the domain
\textit{length}, \textit{width} and \textit{step size} in each direction. When
defining the size of our problem it will help us determine appropriate values
for our model arguments. If we make our dimensions large but our step sizes very
small we increase the accuracy of our solution. Unfortunately we also increase
the number of calculations that must be solved per time step. This means more
computational time is required to produce a solution. In this \textit{1D}
problem, the bar is defined as being 1 metre long. An appropriate step size
\verb|ndx| would be 1 to 10\% of the length. Our \verb|ndy| needs only be 1,
this is because our problem stipulates no partial derivatives in the $y$
direction.
Thus the temperature does not vary with $y$. Hence, the model parameters can be
defined as follows; note we have used the \verb|unitsSI| convention to make sure
all our input units are converted to SI.
\begin{python}
mx = 500.*m #meters - model length
my = 100.*m #meters - model width
ndx = 50 # mesh steps in x direction
ndy = 1 # mesh steps in y direction
boundloc = mx/2 # location of boundary between the two blocks
\end{python}
The material constants and the temperature variables must also be defined. For
the granite in the model they are defined as:
\begin{python}
#PDE related
rho = 2750. *kg/m**3 #kg/m^{3} density of iron
cp = 790.*J/(kg*K) # J/Kg.K thermal capacity
rhocp = rho*cp
kappa = 2.2*W/m/K   # watts/m.Kthermal conductivity
qH=0 * J/(sec*m**3) # J/(sec.m^{3}) no heat source
T1=20 * Celsius # initial temperature at Block 1
T2=2273. * Celsius # base temperature at Block 2
\end{python}
Finally, to control our script we will have to specify our timing controls and
where we would like to save the output from the solver. This is simple enough:
\begin{python}
t=0 * day  # our start time, usually zero
tend=50 * yr # - time to end simulation
outputs = 200 # number of time steps required.
h=(tend-t)/outputs #size of time step
#user warning statement
print("Expected Number of time outputs is: ", (tend-t)/h)
i=0 #loop counter
\end{python}
Now that we know our inputs we will build a domain using the
\verb|Rectangle()| function from \FINLEY. The four arguments allow us to
define our domain \verb|model| as:
\begin{python}
#generate domain using rectangle
blocks = Rectangle(l0=mx,l1=my,n0=ndx, n1=ndy)
\end{python}
\verb|blocks| now describes a domain in the manner of Section \ref{ss:domcon}.

With a domain and all the required variables established, it is now possible to
set up our PDE so that it can be solved by \esc. The first step is to define the
type of PDE that we are trying to solve in each time step. In this example it is
a single linear PDE\footnote{in contrast to a system of PDEs which we discuss
later.}. We also need to state the values of our general form variables.
\begin{python}
mypde=LinearPDE(blocks)
A=zeros((2,2)))
A[0,0]=kappa
mypde.setValue(A=A, D=rhocp/h)
\end{python}
In many cases it may be possible to decrease the computational time of the
solver if the PDE is symmetric.
Symmetry of a PDE is defined by;
\begin{equation}\label{eqn:symm}
A_{jl}=A_{lj}
\end{equation}
Symmetry is only dependent on the $A$ coefficient in the general form and the
other coefficients $D$ as well as the right hand side $Y$. From the above
definition we can see that our PDE is symmetric. The \verb|LinearPDE| class
provides the method \method{checkSymmetry} to check if the given PDE is
symmetric. As our PDE is symmetrical we enable symmetry via;
\begin{python}
myPDE.setSymmetryOn()
\end{python}
Next we need to establish the initial temperature distribution \verb|T|. We need
to
assign the value \verb|T1| to all sample points left to the contact interface at
$x_{0}=\frac{mx}{2}$
and the value \verb|T2| right to the contact interface. \esc
provides the \verb|whereNegative| function to construct this. More
specifically, \verb|whereNegative| returns the value $1$ at those sample points
where the argument has a negative value. Otherwise zero is returned.
If \verb|x| are the $x_{0}$
coordinates of the sample points used to represent the temperature distribution
then \verb|x[0]-boundloc| gives us a negative value for
all sample points left to the interface and non-negative value to
the right of the interface. So with;
\begin{python}
# ... set initial temperature ....
T= T1*whereNegative(x[0]-boundloc)+T2*(1-whereNegative(x[0]-boundloc))
\end{python}
we get the desired temperature distribution. To get the actual sample points
\verb|x| we use the \verb|getX()| method of the function space
\verb|Solution(blocks)| which is used to represent the solution of a PDE;
\begin{python}
x=Solution(blocks).getX()
\end{python}
As \verb|x| are the sample points for the function space
\verb|Solution(blocks)|
the initial temperature \verb|T| is using these sample points for
representation.
Although \esc is trying to be forgiving with the choice of sample points and to
convert
where necessary the adjustment of the function space is not always possible. So
it is advisable to make a careful choice on the function space used.

Finally we initialise an iteration loop to solve our PDE for all the time steps
we specified in the variable section. As the right hand side of the general form
is dependent on the previous values for temperature \verb T  across the bar this
must be updated in the loop. Our output at each time step is \verb T  the heat
distribution and \verb totT  the total heat in the system.
\begin{python}
while t < tend:
	i+=1 #increment the counter
	t+=h #increment the current time
	mypde.setValue(Y=qH+rhocp/h*T) # set variable PDE coefficients
	T=mypde.getSolution() #get the PDE solution
	totE = integrate(rhocp*T) #get the total heat (energy) in the system
\end{python}
The last statement in this script calculates the total energy in the system as
the volume integral of $\rho c_{p} T$ over the block.
As the blocks are insulated no energy should be lost or added.
The total energy should stay constant for the example discussed here.

\subsection{Running the Script}
The script presented so far is available under
\verb|example01a.py|. You can edit this file with your favourite text editor.
On most operating systems\footnote{The \texttt{run-escript} launcher is not
supported under {\it MS Windows}.} you can use the
\program{run-escript} command
to launch {\it escript} scripts. For the example script use;
\begin{verbatim}
run-escript example01a.py
\end{verbatim}
The program will print a progress report. Alternatively, you can use
the python interpreter directly;
\begin{verbatim}
python example01a.py
\end{verbatim}
if the system is configured correctly (please talk to your system
administrator).

\subsection{Plotting the Total Energy}
\sslist{example01b.py}

\esc does not include its own plotting capabilities. However, it is possible to
use a variety of free \pyt packages for visualisation.
Two types will be demonstrated in this cookbook;
\mpl\footnote{\url{http://matplotlib.sourceforge.net/}} and
\verb|VTK|\footnote{\url{http://www.vtk.org/}}.
The \mpl package is a component of SciPy\footnote{\url{http://www.scipy.org}}
and is good for basic graphs and plots.
For more complex visualisation tasks, in particular two and three dimensional
problems we recommend the use of more advanced tools. For instance, \mayavi
\footnote{\url{http://code.enthought.com/projects/mayavi/}}
which is based upon the \verb|VTK| toolkit. The usage of \verb|VTK| based
visualisation is discussed in Chapter~\ref{Sec:2DHD} which focuses on a two
dimensional PDE.

For our simple granite block problem, we have two plotting tasks. Firstly, we
are interested in showing the
behaviour of the total energy over time and secondly, how the temperature
distribution within the block is developing over time.
Let us start with the first task.

The idea is to create a record of the time marks and the corresponding total
energies observed.
\pyt provides the concept of lists for this. Before
the time loop is opened we create empty lists for the time marks \verb|t_list|
and the total energies \verb|E_list|.
After the new temperature has been calculated by solving the PDE we append the
new time marker and the total energy value for that time
to the corresponding list using the \verb|append| method. With these
modifications our script looks as follows:
\begin{python}
t_list=[]
E_list=[]
# ... start iteration:
while t<tend:
      t+=h
      mypde.setValue(Y=qH+rhocp/h*T) # set variable PDE coefficients
      T=mypde.getSolution() #get the PDE solution
      totE=integrate(rhocp*T)
      t_list.append(t)   # add current time mark to record
      E_list.append(totE) # add current total energy to record
\end{python}
To plot $t$ over $totE$ we use \mpl a module contained within \pylab which needs
to be loaded before use;
\begin{python}
import pylab as pl # plotting package.
\end{python}
Here we are not using \verb|from pylab import *| in order to avoid name
clashes for function names within \esc.

The following statements are added to the script after the time loop has been
completed;
\begin{python}
pl.plot(t_list,E_list)
pl.title("Total Energy")
pl.axis([0,max(t_list),0,max(E_list)*1.1])
pl.savefig("totE.png")
\end{python}
The first statement hands over the time marks and corresponding total energies
to the plotter.
The second statement sets the title for the plot. The third statement
sets the axis ranges. In most cases these are set appropriately by the plotter.

The last statement generates the plot and writes the result into the file
\verb|totE.png| which can be displayed by (almost) any image viewer.
As expected the total energy is constant over time, see
\reffig{fig:onedheatout1}.

\begin{figure}[ht]
\begin{center}
\includegraphics[width=4in]{figures/ttblockspyplot150}
\caption{Example 1b: Total Energy in the Blocks over Time (in seconds)}
\label{fig:onedheatout1}
\end{center}
\end{figure}
\clearpage

\subsection{Plotting the Temperature Distribution}
\label{sec: plot T}
\sslist{example01c.py}
For plotting the spatial distribution of the temperature we need to modify the
strategy we have used for the total energy.
Instead of producing a final plot at the end we will generate a
picture at each time step which can be browsed as a slide show or composed into
a movie.
The first problem we encounter is that if we produce an image at each time step
we need to make sure that the images previously generated are not overwritten.

To develop an incrementing file name we can use the following convention. It is
convenient to put all image files showing the same variable - in our case the
temperature distribution - into a separate directory.
As part of the \verb|os| module\footnote{The \texttt{os} module provides
a powerful interface to interact with the operating system, see
\url{http://docs.python.org/library/os.html}.} \pyt
provides the \verb|os.path.join| command to build file and directory names in a
platform independent way. Assuming that
\verb|save_path| is the name of the directory we want to put the results in the
command is;
\begin{python}
import os
os.path.join(save_path, "tempT%03d.png"%i )
\end{python}
where \verb|i| is the time step counter.
There are two arguments to the \verb|join| command. The \verb|save_path|
variable is a predefined string pointing to the directory we want to save our
data, for example a single sub-folder called \verb|data| would be defined by;
\begin{verbatim}
save_path = "data"
\end{verbatim}
while a sub-folder of \verb|data| called \verb|example01| would be defined by;
\begin{verbatim}
save_path = os.path.join("data","example01")
\end{verbatim}
The second argument of \verb|join| contains a string which is the file
name or subdirectory name. We can use the operator \verb|%| to use the value of
\verb|i| as part of our filename. The sub-string \verb|%03d| indicates that we
want to substitute a value into the name;
\begin{itemize}
 \item \verb 0  means that small numbers should have leading zeroes;
 \item \verb 3  means that numbers should be written using at least 3 digits;
and
 \item \verb d  means that the value to substitute will be a decimal integer.
\end{itemize}

To actually substitute the value of \verb|i| into the name write \verb|%i| after
the string.
When done correctly, the output files from this command will be placed in the
directory defined by \verb save_path  as;
\begin{verbatim}
blockspyplot001.png
blockspyplot002.png
blockspyplot003.png
...
\end{verbatim}
and so on.

A sub-folder check/constructor is available in \esc. The command;
\begin{verbatim}
mkDir(save_path)
\end{verbatim}
will check for the existence of \verb save_path  and if missing, create the
required directories.

We start by modifying our solution script.
Prior to the \verb|while| loop we need to extract our finite solution
points to a data object that is compatible with \mpl. First we create the node
coordinates of the sample points used to represent
the temperature as a \pyt list of tuples or a \numpy array as requested by the
plotting function.
We need to convert the array \verb|x| previously set as
\verb|Solution(blocks).getX()| into a \pyt list
and then to a \numpy array. The $x_{0}$ component is then extracted via
an array slice to the variable \verb|plx|;
\begin{python}
import numpy as np # array package.
#convert solution points for plotting
plx = x.toListOfTuples()
plx = np.array(plx) # convert to tuple to numpy array
plx = plx[:,0] # extract x locations
\end{python}

\begin{figure}
\begin{center}
\includegraphics[width=4in]{figures/blockspyplot001}
\includegraphics[width=4in]{figures/blockspyplot050}
\includegraphics[width=4in]{figures/blockspyplot200}
\caption{Example 1c: Temperature ($T$) distribution in the blocks at time steps
$1$, $50$ and $200$}
\label{fig:onedheatout}
\end{center}
\end{figure}
\clearpage

We use the same techniques provided by \mpl as we have used to plot the total
energy over time.
For each time step we generate a plot of the temperature distribution and save
each to a file.
The following is appended to the end of the \verb|while| loop and creates one
figure of the temperature distribution. We start by converting the solution to a
tuple and then plotting this against our \textit{x coordinates} \verb|plx| we
have generated before. We add a title to the diagram before it is rendered into
a file.
Finally, the figure is saved to a \verb|*.png| file and cleared for the
following iteration.
\begin{python}
# ... start iteration:
while t<tend:
      i+=1
      t+=h
      mypde.setValue(Y=qH+rhocp/h*T)
      T=mypde.getSolution()
      totE=integrate(rhocp*T)
      print("time step %s at t=%e days completed. total energy = %e."%(i,t/day,totE))
      t_list.append(t)
      E_list.append(totE)

      #establish figure 1 for temperature vs x plots
      tempT = T.toListOfTuples()
      pl.figure(1) #current figure
      pl.plot(plx,tempT) #plot solution
      # add title
      pl.axis([0,mx,T1*.9,T2*1.1])
      pl.title("Temperature across blocks at time %d days"%(t/day))
      #save figure to file
      pl.savefig(os.path.join(save_path,"tempT", "blockspyplot%03d.png"%i))
      pl.clf() #clear figure
\end{python}
Some results are shown in \reffig{fig:onedheatout}.

\subsection{Making a Video}
Our saved plots from the previous section can be cast into a video using the
following command appended to the end of the script. The \verb mencoder command
is not available on every platform, so some users need to use an alternative
video encoder.
\begin{python}
# compile the *.png files to create a *.avi video that shows T change
# with time. This operation uses Linux mencoder. For other operating
# systems it is possible to use your favourite video compiler to
# convert image files to videos.

os.system("mencoder mf://"+save_path+"/tempT"+"/*.png -mf type=png:\
           w=800:h=600:fps=25 -ovc lavc -lavcopts vcodec=mpeg4 -oac copy -o \
           example01tempT.avi")
\end{python}


\documentclass{article}
\pagestyle{empty}
\usepackage{amsmath,amssymb,amsfonts}
\usepackage{graphicx}
\usepackage{multicol}
\setlength{\oddsidemargin}{0in} \setlength{\evensidemargin}{0in}
\setlength{\topmargin}{0in} \setlength{\textheight}{8.5in}
\setlength{\textwidth}{6.5in}

\makeatletter
\renewcommand*\env@matrix[1][*\c@MaxMatrixCols c]{%
	\hskip -\arraycolsep
	\let\@ifnextchar\new@ifnextchar
	\array{#1}}
\makeatother

\begin{document}
\begin{flushleft}
	\bfseries{MATH 260, Linear Systems and Matrices, Fall `14}\\
	\bfseries{Activity 10:  Introduction to Eigenvalues and Eigenvectors}\\
	%\bfseries{Honor Code:} \hspace{3.5in}\bfseries{Names:}\\
\end{flushleft}

\begin{flushleft}

\section*{Warm-up:  Matrix Multiplication}

Given the matrix
$\textbf{A}=
\begin{bmatrix}
1 & 1 \\ 4&1
\end{bmatrix}$
 and the vectors:
$\vec{v}_1=\begin{bmatrix} 2 \\ 2 \end{bmatrix}$,
$\vec{v}_2=\begin{bmatrix} 1 \\ 2 \end{bmatrix}$,
$\vec{v}_3=\begin{bmatrix} -2 \\ 0 \end{bmatrix}$,
$\vec{v}_4=\begin{bmatrix} -1 \\ -4 \end{bmatrix}$,
$\vec{v}_5=\begin{bmatrix} 1 \\ -2 \end{bmatrix}$.

\vspace{0.1in}

Find $\textbf{A}\vec{v}_i$ for $i=1,...,5$.

\vspace{2in}

\newpage

\section*{Visualizing Eigenvectors}

1) Sketch each $\vec{v}_i$ and the result of $\textbf{A}\vec{v}_i$ from the warm-up in the $xy$-plane. You should have 5 pictures when you are done. Be sure to clearly label which was your initial, and which your resultant vector.

\vspace{4in}

2) Two of the $v_i$ vectors behaved differently, which ones? Describe how they behaved differently.

\vspace{1in}

3) For the two vectors that behaved differently, you should be able to write the eigenvector equation: $\textbf{A}\vec{v}=\lambda \vec{v}$. Find $\lambda_i$ for each pair of vectors.

\vspace{.75in}

\newpage

\section*{Practice}

Let's practice finding eigenvalues and eigenvectors.

\vspace{0.1in}

4) For each matrix, take the determinant $|\textbf{A}- \lambda \textbf{I}  | $ then set the resulting polynomial equal to 0 and solve for $\lambda$. (They should all be factorable, so even the $3 \times 3$s should not be too hard to do). Once you have found ALL the eigenvalues ($\lambda$s) find at least one eigenvector for each matrix.\\

\begin{center}

$\textbf{W}=\begin{bmatrix}[rr] 1 & 4\\-4&11 \end{bmatrix}$
\hspace{0.3in}
$\textbf{G}=\begin{bmatrix}[rrr] 1 & 1 & -2\\ -1 & 2 & 1\\ 0 & 1 & -1 \end{bmatrix}$
\hspace{0.3in}
$\textbf{R}=\begin{bmatrix}[rrr] 1 & 2 & 3 \\ 0 & 4 & 5 \\ 0 & 0 & 6 \end{bmatrix}$

\end{center}

\vspace{6in}

5) Go back and look at $\textbf{R}$.  What do you notice about the eigenvalues you found for \textbf{R}?  Can you generalize this to a property of certain types of matrices?

\newpage

\section*{Some Properties of Eigenvalues}

\textit{ Note: We will find these for $2 \times 2$ matrices, but these properties generalize to any $n \times n$ matrix. }

\vspace{0.2in}

6) We find eigenvalues by solving: $|\textbf{A}- \lambda \textbf{I}  | =0 $. What happens if $\lambda = 0 $? What must be true about the matrix \textbf{A} for \textbf{A} to have eigenvalues of 0?

\vspace{1.5in}

7)a) Find $\textbf{W}^{T}$.

\vspace{1in}

b) What is the polynomial from $|\textbf{W}^{T}- \lambda \textbf{I}  | $ and how does it compare to the polynomial for $|\textbf{W}- \lambda \textbf{I}  | $?

\vspace{1in}

c) What can you say about the eigenvalues (and vectors) of $\textbf{A}$ and $\textbf{A}^{T}$?

\vspace{0.75in}

8)a) Find $\textbf{W}^{-1}$.

\vspace{1in}

b) What is the polynomial from $|\textbf{W}^{-1}- \lambda \textbf{I}  | $? Set the polynomial equal to 0, and solve for $\lambda$

\vspace{1in}

c) Look carefully, how do the eigenvalues of $\textbf{W}^{-1}$ relate to the eigenvalues of \textbf{W}?

\end{flushleft}
\end{document}

Fall 2014 - Capaldi A/Activities/Activity10_EigenPart1.tex


\documentclass{article}

\usepackage[utf8]{inputenc}
\usepackage[a4paper, total={6in, 8in}]{geometry}
\usepackage[shortlabels]{enumitem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{amsthm}
\usepackage{listings}
\usepackage{xcolor}
\usepackage{mathtools}
\usepackage{lmodern}
\DeclarePairedDelimiter\ceil{\lceil}{\rceil}
\DeclarePairedDelimiter\floor{\lfloor}{\rfloor}
\setlength{\parskip}{0.5em}

\usepackage{clrscode3e}

\title{Recursion: A Brief Introduction}
\author{Competitive Programming UTEC}

\begin{document}

\maketitle

\section{Introduction}

\subsection{Definition}

\textbf{Recursion} occurs when a thing is defined in terms of itself or its type. This definition is a bit weird and doesn't tell us much, so lets consider the following problem. We want to define a rule set for balanced brackets. How would you define that rule set? Recursion allow us to have a very elegant and simple solution: We say that a sequence $L$ of brackets is balanced if $L = L_1(L_2)$, where $L_1$ and $L_2$ are balanced brackets, or $L$ is empty. By defining balanced brackets with smaller balanced brackets we can simplify how we describe what balanced brackets are. A nice definition of recursion therefore is:

\begin{center}
	\parbox{0.7\linewidth}{Recursion (rĭ-kûr’-zhn) \textit{noun.} If you still don't get it, see \textbf{recursion}.}
\end{center}

Recursion appears in many fields of knowledge such as mathematics, linguistics and computer science. This is due to the fact that it is a very powerful tool, that allows us to abstract concepts that might be hard to define and describe them in a very simple way. In computer science when we talk about recursion we usually refer to problems that can be solved by solving smaller instances of themselves. Now you might be asking: what makes a problem \textit{smaller} or \textit{bigger}? Intuitively, we say that a problem is bigger or harder if it takes more time to solve. For example, we can say that going up 5 stairs is harder than going up 3 stairs as we know that the more stairs there are, the longer it is going to take. A more formal definition would be that a problem is said to be smaller if it is fewer iterations away from the base case. This definition will probably make more sense as we further discuss the specifics and terminology of recursion.

\subsection{Conditions for Recursion}

There are three conditions that must be fulfilled for recursion to be possible:

\subsubsection{Recursive Call}

This is probably the easiest of all the conditions. It is obvious that in order to have a recursive algorithm at some point it must call the same algorithm but with different input, in other words, it must have a \textit{recursive call}. We can have more than one recursive call, or have the recursive calls inside conditionals, it is all fair game.

\subsubsection{Base Case}

Lets consider the following algorithm:

\begin{codebox}
\Procname{$\proc{factorial}(n)$}
	\li \Return  $n * \proc{factorial}(n - 1)$
\end{codebox}

It is simple to realize that there is one huge mistake in this algorithm: \textbf{it will never stop running!} This is why we need base cases, as they tell our algorithm when to stop. Formally a base case is a special behaviour inside the recursive algorithm that activates when it receives a specific parameter:

\begin{codebox}
\Procname{$\proc{factorial}(n)$}
\li \If $n = 0$
	\li \Then
		\Return 1
	\End
\li \Return  $n * \proc{factorial}(n - 1)$
\end{codebox}

In this example the base case occurs when $n = 0$ and the function returns $1$. In general the base case can be anything that doesn't use recursion. In other words we must calculate the answer for the base case ``manually'' using an iterative approach. It is important to note that just as there can be more than one recursive call, there can also be more than one base case.

\subsubsection{Convergence}

This is probably the least intuitive of the three conditions, but it is still very simple to understand. Lets consider the following recursive algorithm:

\begin{codebox}
\Procname{$\proc{factorial}(n)$}
\li \If $n = 0$
	\li \Then
		\Return 1
	\End
\li \Return $n * \proc{factorial}(n - 2)$
\end{codebox}

At first sight, it looks like this algorithm has no problems as there is a recursive call and a base case; however, there is a very important detail that has been overlooked. Lets say we call $\proc{factoria}(3)$, this would call $\proc{factorial}(1)$, which would call $\proc{factorial}(-1)$, which would call $\proc{factorial}(-3)$, and so on. Even though we had a base case, our algorithm \textbf{never reached it}, meaning it will be stuck in an infinite loop. This is not good. This is why \textit{convergence} is important, as it ensures that regardless of the parameters we use to call the algorithm, we should reach a base case after a finite number of steps. A corrected version of the algorithm above should consider two base cases, when $n$ reaches $0$ and when $n$ reaches $1$:

\begin{codebox}
\Procname{$\proc{factorial}(n)$}
\li \If $n \leq 1$
	\li \Then
		\Return 1
	\End
\li \Return $n * \proc{factorial}(n - 2)$
\end{codebox}

\section{The Recursion Tree}

Lets consider the following algrithm for finding the $n$-th term of the Fibonacci sequence:

\begin{codebox}
\Procname{$\proc{fibonacci}(n)$}
\li \If $n \leq 1$
	\li \Then
		\Return n
	\End
\li \Return $\proc{fibonacci}(n - 1) + \proc{fibonacci}(n - 2)$
\end{codebox}

What we are going to do now is build the \textit{recursion tree} for this algorithm. This is a graphical representation of how the recursive calls behave and interact, and are very usefull to anlayze the algorithms behaviour. In this case, for $n = 4$ the tree would look like this:

\begin{center}
	\includegraphics[width=0.8\linewidth]{images/fibtree}
\end{center}

Every node in this tree represents a call to the function $\proc{fibonacci}$, and the children of a node represents the recursive calls it make. The nodes that have no children are called leaf nodes, and in recursion trees they represent a base case. The first node is called the \textit{root} and it represents the first call to the algorithm.

Just by looking at this tree try to answer the following questions: Approximately how many nodes the tree will have for $n = 5$? What about for a general values of $n$?

\section{Complexity}

\subsection{Recurrence Relations}

Before we can jump into the algorithmic analysis we need to make a brief stop in the realm of discrete mathematics to understand recurrence relations. A \textit{difference equation} or \textit{recurrence relation} is an equation that tells us how different terms of a sequence relate. Lets consider the equation:

$$a_n = 2 a_{n - 1}, a_0 = 1$$

It is simple to see that this recurrence generates the sequence: $1, 2, 4, 8, 16, \dots 2^n \dots$ As you might have realized, this means that $a_n = 2^n$. This can be formally proved using \textit{mathematical induction}, but right now the intuition of why this is true is more than enough.

This process of turining a recurrence into a sequence defined only in terms of $n$ is usually called \textit{solving} the recurrence, we are esentially finding a recursion-free expression for the sequence. This is very usefull as for some large value of $n$ we don't need to solve for all the smaller values, we can just evaluate the expression. Another technique for solving recurrences is building a recursion tree and adding up to the solution. Some of this equations, like the example above, are very intuitive and simple to solve, while others are much more difficult and require advanced techniques.

\subsection{Time as a Recurrence}

When dealing with iterative algorithms, calculating their time complexity was usually a very trivial task, we only needed to count the number of instructions that were going to be executed. This changes bit with recursion as it might be harder to tell how many times a given instruction will be executed, or how many times the recursive function will be called. For this reason, it is fitting that in order to analyze the time complexity of a recursive algorithm we use a recursive function. In general we can express the time complexity of a recursive algorithm as:

$$T(n) = \sum T(n_i) + T'(n)$$

Where $n_i$ is the parameter used to call the $i$-th recursive call ans $T'$ is the complexity of all non-recursive steps. Lets consider the previous code for finding factorials. We can see that in that case there is only one recursive call and a multiplication. This means that we can express the complexity of that code as:

$$T(n) = T(n - 1) + O(1)$$

This is a very straight forward recurrence that solves to $T(n) = O(n)$. Now lets do something a bit harder, lets try to determine the complexity of the algorithm for finding Fibonacci numbers. It is simple to realize that the complexity can be expressed as:

$$T(n) = T(n - 1) + T(n - 2) + O(1)$$

This recurrence is definitely trickier, so we must find another way of solving it. Lets remember that when we are using \textit{Big Oh} notation, we only want to find an estimate upper bound for the time complexity, therefore a good idea is to start by looking at the recursion tree and guessing. As in almost every step the number of nodes doubles, it is logical to guess that $T(n) = O(2^n)$. However, how can we prove this? A simple and straight forward way of doing it is by substituting our guess and checking:

$$T(n) = 2^{n - 1} + 2^{n - 2} + O(1)$$
$$T(n) \leq 2 * 2^{n - 1} + O(1)$$
$$T(n) \leq 2^n + O(1)$$
$$T(n) = O(2^n)$$

Even though this is not the most formal proof, it is enough to get an idea on how fast our solution will run. Later on, you will learn more advanced techniques for solving recurrences and estimating complexities.

Intuitively we can see that the more recursive calls we have, the bigger our time complexity will be. Therefore we must attempt to always minimize the number of recursive calls. We should also try to minimize the size of the smaller problems we target. However, this might be hard to achieve.

\subsection{Memory}

One important aspect to take into consideration when using recursion is that we are going to implicitly use memory of the stack. This happens because in every recursive call we need to store the current state of the algorithm in order to jump to the next function call. The auxiliary memory we will use in our algorithm will therefore be proportional to the height of our recursion tree, that is, the maximum distance between a leaf node and the root.

If we make too many recursive calls, this can lead to a stack overflow, in other words, we can run out of memory. This is one of the things that we must take into consideration when using recursion, as it can lead to our solution failing when dealing with bigger inputs.

\section{Strategy and Correctness}

Even though the problems that can be solved using recursion are very different, the solution for most of them follows a very similar pattern. First we find the solution for all the smaller problems we need, then we merge this solutions to find the general solution to the problem. Because of the versatility of recursion, lots of paradigms use it heavily.

Therefore the correctness of our algorithm depends on two things:
\begin{enumerate}
	\item \textbf{Base Case:} All of our base cases must give a correct result to our answer.
	\item \textbf{Merge:} The way in which we combine smaller solutions ensure that the general solution is also correct.
\end{enumerate}

One of the key advantages of this is that we can now give a lot more importance to the semantic meaning of our algorithms. This is to say that if we can describe what our algorithm does in words, whenever we use recursion in our solution we can assume that the result this yields is correct. For this reason recursion is a very abstraction heavy strategy that requires some practice in order to really get the most of this technique.

\end{document}


\chapter{{\tt Camera} Module}\label{ch:camera-module}

Cameras are the interface between images and the real world, and as
such, their importance in computer vision cannot be understated.  In
fact, some would say that computer vision algorithms are distinguished
by the fact that they endeavor to associate the processed pixel data
with objects in the real world for the purposed of measurement,
tracking, or display.  This is achieved by modeling the geometric and
physical properties of the device that was used to capture the
original image.  This is the purpose of the camera module.

The camera module includes built-in models for generic pinhole and
line-scan imagers and a set of generic functions for linearizing
(removing lens distortion) and epipolar rectifying (e.g. for stereo)
when these operations are relevant.  These classes and functions can
be imported into your code by including {\tt <vw/Camera.h>}.

Because you will likely encounter new camera geometries not supported
by the built-in classes, the camera module is designed to be
extensible.  You can provide your own camera model by inheriting
from and adopting the interface of the {\tt CameraModel} abstract base
class, which is defined in the header file {\tt <vw/Camera/CameraModel.h>}.

Finally, the camera module provides a basic set of tools for working
with images from real-world camera systems: bayer pattern filtering
and EXIF parsing.  We will cover all of these features in more detail,
but we begin this chapter by establishing some terminology while
exploring the most common camera geometry in use today: the pinhole
camera model.

\section{The Pinhole Camera Model}
The pinhole camera model describes the geometry found in nearly all
commercial digital camera systems today.  It is characterized by a
lens assembly that focuses light onto a two dimensional array of
pixels (usually a sensor with light sensitive circuits such as a CCD
or CMOS device).  We will use the pinhole model to establish some
terminology that will be used throughout the rest of this chapter.  Be
warned that the model we are about to develop is simplistic; many of
the non-ideal characteristics of a real-world optical system
(e.g. lens distortion) are not modeled in this simple example.  Refer
to the CAHVOR model in Section \ref{sec:built-in-cameras} if you
require a pinhole camera model that more accurately models lens
distortion.

\subsection{Perspective Projection}

Figure \ref{fig:pinhole-camera-diagram} shows the geometry of a basic
pinhole camera.  The light gray area represents the 2D array of
pixels, and it is referred to as the {\em image plane}.  The origin of
the 3D coordinate system is the point $C$, which is the center of
projection or {\em camera center} of the imager.  When a 3D point $O$
is imaged by the camera, it appears at the pixel located where segment
$\overline{OC}$ intersects the image plane at point $(u,v)$.  A line
segment $\overline{OC}$ that is perpendicular to the image plane
intersects this plane at the {\em principal point}, $(p_u, p_v)$.

\begin{figure}[tbp]
\begin{center}
  \includegraphics[width=6in]{images/camera_module_pinhole.pdf}
 \end{center}
  \caption{The basic pinhole camera model.}
  \label{fig:pinhole-camera-diagram}
\end{figure}

All of the points imaged by the camera appear on a line that passes
through $C$.  If the coordinates of ${\bf O}$ are $(x,y,z)$, then the
position of the point on the imager can be determined by projecting it
onto the plane $ z = +f$:
\begin{eqnarray}
\label{eqn:forward-projection-1}
u &=& \frac{f}{\sigma} \left(\frac{x}{z}\right) - p_u \\
\label{eqn:forward-projection-2}
v &=& \frac{f}{\sigma} \left(\frac{-y}{z}\right) - p_v
\end{eqnarray}

Here, $f$ is the focal length of the imager in meters, $\sigma$ is the
size of a pixel in {\em m/pixel}, and $(p_u, p_v)$ are the offset in
pixels of the principal point (this offset moves the origin of the
image from the principal point to the upper left hand corner, which is
the ``origin'' usually adopted when indexing images).

Equations \ref{eqn:forward-projection-1} and
\ref{eqn:forward-projection-2} constitute the {\em forward projection}
portion of the camera model; this is analogous to the process of
``capturing'' an image with a real camera.  Our model should tell us
exactly what what pixel location to look at if you wanted to see the
point $O$ in the image.

Notice how some information is lost during forward projection.  Any
point along $\overline{OC}$ will be imaged to the same point $(u,v)$
on the image plane, so if we were to start with a point $P=(u,v)$ on
the image plane, and we wanted to find the original 3D point $O$, the
best we could do would be to say that it appears somewhere along the
ray $\overrightarrow{CP}$. The
origin and direction of the ray can be computed as follows:

\begin{eqnarray}
\label{eqn:reverse-projection-1}
\overrightarrow{CP}_{origin} & = & C \\
\label{eqn:reverse-projection-2}
\overrightarrow{CP}_{direction} & = & \frac{(u + p_u, -(v + p_v), f)} {||(u + p_u, -(v + p_v), f)||_2}
\end{eqnarray}

This operation, which we call {\em back projection}, can still
provide useful information that can be used in a full 3D
reconstruction despite the ambiguity in the actual position of $O$.
Imagine that you have two cameras that have imaged the same point $O$
from two different viewpoints at pixel locations $P_1$ and $P_2$ in
their respective image planes.  Using simple geometry, you can
reconstruct the position of $O$ by computing the intersection of the
two rays emanating from each camera center through $P_1$ and $P_2$.
This is the technique commonly referred to as stereo reconstruction,
and it is one of the many ways that you can make use of the
information provided by back projection.

\section{The Camera Model Base Class}

As we have seen, a camera model provides a means for forward
projection (``imaging'' 3D points onto a 2D array of pixels) and back
projection (finding the ray along which a 3D points must lie given a
2D pixel where it was imaged).  All camera models in the Vision
Workbench derived from the CameraModel abstract base class, which
enforces this basic interface.

Forward projection of a 3D point is handled by the
\verb#point_to_pixel()# method.
\begin{verbatim}
  CameraModel* camera_model = new MyDerivedCameraModelClass;
  Vector3 world_coordinates;
  Vector2 pixel_coordinates = camera_model.point_to_pixel(world_coordinates);
\end{verbatim}

%% hutz: From my comprehension, the following paragraph makes
%%       a very incorrect statement on C++ virtual methods.
%%       Can somebody correct me if I'm wrong?
% Remember that in C++, you will need to maintain a pointer to the
% derived camera model class in order to ensure that the virtual
% inheritance mechanism calls the method from the derived class rather
% than the base class.

The back projection operation is split into two separate API calls.
The \verb#camera_center()# method returns the origin of the ray, and
the \verb#pixel_to_vector()# method returns its direction.  Remember
that any of the points that lie along this ray would have been imaged
at $(u,v)$, so this pixel-to-ray operation leaves some ambiguity about
the true location of the point $O$.
\begin{verbatim}
  CameraModel* camera_model;
  Vector3 ray_origin = camera_model.camera_center(pixel_coordinates);
  Vector3 ray_direction = camera_model.pixel_to_vector(pixel_coordinates);
\end{verbatim}
\begin{center}\fbox{\parbox{7in}{
{\bf Camera Coordinate Systems}\\ \\ Vision Workbench camera model
classes take and return coordinates that are {\em not} homogeneous.
That is, coordinates do not need to augmented with an additional
homogeneous scaling element before being passed to camera module
routines (e.g. a 2D vector $(325, 206)$ in Cartesian coordinates is
often represented as $(325, 206, 1)$ in homogeneous coordinates).
Homogeneous coordinates have certain advantages in projective geometry
(e.g. they allow a translation of the coordinates to be encoded as a
matrix multiplication), however we have chosen not to adopt this
convention.}}
\end{center}

\section{Built-in Camera Models}
\label{sec:built-in-cameras}
The Vision Workbench comes with several ``built-in'' camera models.
These classes satisfy the needs of most common applications, and they
can also serve as a design reference for your own camera model
classes.  Each class models a specific geometry and, to varying
extents, the non-ideal characteristics of the camera system such as
lens distortion.

The list of built-in models are summarized in Table
\ref{tab:camera-models}.  The following sections describes the two
basic classes of built-in camera model: those that model pinhole
cameras (where the imager is a 2D array of pixels), and those that
model line-scan cameras (where the imager is a 1D line of pixels).

\begin{table}[tdp]
\begin{center}
\begin{tabular}{|l|l|l|l|}
\hline
{\em Camera Model} & {\em Header File} & {\em Imager Type} & {\em Details}\\
\hline CAHV         & {\tt CAHVModel.h} & Pinhole     & Basic pinhole camera model \\
CAHVOR       & {\tt CAHVORModel.h} & Pinhole     & Models lens distortion\\
Line-scan     & {\tt LinescanCameraModel.h} & Line-scan & Generic Line-scan Model \\
Linear Push-broom    & {\tt LinearPushbroomModel.h} & Line-scan & Assumes linear flight path \\
Orbiting Push-broom & {\tt OrbitingPushbroomModel.h} & Line-scan & Models curvature of orbit \\
\hline
\end{tabular}
\end{center}
\label{tab:camera-models}
\caption{Built-in camera models can be found in {\tt vw/Camera/} }
\end{table}

\subsection{Pinhole Cameras}

The {\em CAHV camera model} has been widely used in NASA planetary
mission for rover navigation and scientific camera systems
\cite{yakimovsky78}.  It is a basic pinhole camera model that does not
model lens distortion or other optical aberrations.  The CAHV model is
so named because the camera intrinsic and extrinsic parameters are
jointly parameterized by four 3-dimensional vectors: C,A,H, and V.
This compact representation leads to a very efficient forward
projection operation, which is the strength of the CAHV model.
Forward projection of a real world point $O$ can be computed using

\begin{eqnarray}
u & = & \frac{(O-C) \cdot H}{(O-C) \cdot A}\\
v & = & \frac{(O-C) \cdot V}{(O-C) \cdot A}
\end{eqnarray}

The user has two choices when initializing a CAHV camera model.
First, they can construct the object by directly supplying four
3-vectors to the constructor.

\begin{verbatim}
  Vector3 C,A,H,V;
  CameraModel* cam = new CAHVModel(C,A,H,V);
\end{verbatim}

Alternatively, users seeking to use the CAHV class as a general purpose pinhole
camera model may find it easier to use the more verbose constructor
wherein the camera extrinsic and intrinsics are explicitly supplied.

\begin{verbatim}
  double focal_length;
  Vector2 pixel_size;
  double principal_point_h, principal_point_v;
  Vector3 camera_center, pointing_vector;
  Vector3 horizontal_vector, vertical_vector; // Defines image plane orientation

  CameraModel* cam = new CAHVModel(focal_length, pixel_size, principal_point_h,
                                   principal_point_v, camera_center,
                                   pointing_vector, horizontal_vector,
                                   vertical_vector);
\end{verbatim}

The {\em CAHVOR model} is an expanded camera model with two additional
3-vectors (O and R) that describe lens distortion introduced by the
camera lens.

Refer the Doxygen-generated API documentation for more information
about constructing CAHV and CAHVOR camera models.

\subsection{Line-scan Cameras}

Line-scan imagers capture images using a sensor containing a
1-dimensional array of pixels.  The image is formed by capturing
successive scan-lines as the camera platform is rotated or moved.  For
example, a flat-bed scanner or photocopier is a familiar example of
such a system.  The sensor is swept in the so-called {\em along-track}
direction along the document, composing the final image by
concatenating several thousand adjacent 1-dimensional images taken at
evenly spaced positions.

Line-scan sensors are fairly uncommon in commercial camera systems, but
they appear frequently on satellites that capture photographs of
terrain from orbit.  The orbital motion of the satellite is used in
much the same way as the motion of the sensor in the photocopier; the
{\em across-track} dimension of the image corresponds to the
projection of 3D points through the lens onto the sensor, and the
along-track dimension of the image corresponds to successive scan lines
taken at different times as the satellite moves.

\begin{figure}[tbp]
\begin{center}
  \includegraphics[width=6in]{images/linescan_geometry.pdf}
 \end{center}
  \caption{Geometry of the Line-scan Camera Model.}
  \label{fig:linescan-geometry}
\end{figure}

The geometry of the line-scan imager is subtly different from the
geometry of the pinhole camera.  See Figure
\ref{fig:linescan-geometry}.  Although there is still a center of
projection created by the camera's optics (and points are still imaged
using a perspective projection in the across-track direction), this
point moves as the camera moves, and as a result, the along-track
position of a pixel in a line-scan image is purely a function of the
position and orientation of the camera; both a function of time.  The
orientation of the image (in the sense that $u$ indexes the columns of
an image and $v$ indexes its rows) must be chosen consistent with
Figure \ref{fig:linescan-geometry} when working with
\verb#LinescanModel# and its relatives.

In the special case where the motion of the line-scan sensor is linear
and its orientation is fixed, the projection of the points onto the
image in the along-track direction is orthographic.  These assumptions
are the basis for the {\em Linear Push-broom Model}, which can be found
in the header file \verb#<vw/Camera/LinearPushbroomModel.h>#.  If you
are interested in understanding this model in detail, we recommend you
read the excellent paper by Gupta and Hartly \cite{gupta97}.

If you must relax the assumption about a linear flight path somewhat
to allow sensor pose to vary and the camera motion to lie along a
curve (as is common with orbiting camera systems), the {\em Orbiting
  Push-broom Model} is an appropriate choice.  In the Orbiting
Push-broom model, the user supplies a series of evenly spaced samples
of position and orientation and specifies the time interval (in
seconds) between samples.  A sparse set of samples is sufficient for
this model: interpolation occurs for points in between the supplied
positions and orientations.

\section{Tools for Working With Camera Images}

This section describes several tools that simplify the process of
working with image captured by real cameras.

\subsection{Inverse Bayer Pattern Filtering}

Most imaging sensors are inherently grayscale capture devices.  In
order to capture color, some imagers have a hardware color filter
placed in front of the pixels on the CCD.  This is called a
{\em Bayer filter}.  The Vision Workbench provides the
\verb#inverse_bayer_filter()# function (found in the header file
\verb#<vw/Camera/BayerFilter.h>#) which interprets the raw, grayscale
pixel values from the sensor and produces a color image by
interpreting the Bayer filter effect.

\subsection{Exif Exposure Data}

Digital cameras store data about the settings used to take a picture
in the image file according to the EXIF standard \cite{exif}. EXIF
data is stored using the Image File Directory system described in the
TIFF 6.0 standard.  EXIF tags such as {\tt FNumber} and
{\tt Exposure Time} can be useful for radiometrically calibrating your
camera images.  Unfortunately the standard is redundant and often
poorly supported by camera manufacturers (for example, many hide the
ISO setting in the maker note instead of storing it in the
ISOSpeedRatings tag), so we cannot guarantee support for every camera.

The Camera module includes the {\tt ExifView} class (defined in
\verb#<vw/Camera/Exif.h>#) for extracting this data from images.  To
create this class, you supply the filename of an image on disk.
Currently, JPEG and TIFF images are supported.  ExifData and ExifView
were based on {\tt jhead}, an EXIF JPEG header and thumbnail manipulator
program in the public domain \cite{jhead}.

\begin{verbatim}
  // Reliably get F number.
  ExifView view;
  if (view.load_exif(``img.jpg'')) {
    double f = view.get_f_number();
    // ...
  }
\end{verbatim}

\begin{thebibliography}{1}

\bibitem{exif} ``Exchangeable image file format for digital still cameras: Exif Version 2.2'',
(Japan Electronics and Information Technology Industries Association, 2002),
http://www.exif.org/specifications.html.

\bibitem{gupta97} Gupta, Rajiv and Hartley, Richard. ``Linear Pushbroom Cameras''.  IEEE
 Transactions on Pattern Analysis and Machine Intelligence. Vol.19 No. 9. September 1997

\bibitem{jhead} Wandel, Matthias, ``Exif Jpeg header and thumbnail manipulator program,'' 2006,
http://www.sentex.net/~mwandel/jhead/.

\bibitem{yakimovsky78}  Yakimovsky, Y. and Cunningham R., ``A System for Extracting
  Three-Dimensional Measurements from a Stereo Pair of TV Cameras ''
  Computer Graphics and Image Processing 7, pp. 195-210. (1978)

\end{thebibliography}


\documentclass[a4paper]{scrartcl}
\usepackage{amssymb, amsmath} % needed for math
\usepackage[utf8]{inputenc} % this is needed for umlauts
\usepackage[ngerman]{babel} % this is needed for umlauts
\usepackage[T1]{fontenc}    % this is needed for correct output of umlauts in pdf
\usepackage[margin=2.5cm]{geometry} %layout
\usepackage{hyperref}       % links within text
\usepackage{ntheorem}
\usepackage[german]{cleveref}
\newtheorem{theorem}{Satz}
\newtheorem{definition}{Defintion}

\begin{document}
\section{Minimal distance constant function}\label{sec:minimal-distance}
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nulla
quam elit, vestibulum nec facilisis at, condimentum id enim. Sed
iaculis lacinia quam, vel accumsan eros tempor in. Integer ipsum

\begin{theorem}[Tata]\label{thm:bla-blup}
\begin{enumerate}
\item Bla bla bla.
\item Bla bla bla.
\item Bla bla bla.
\end{enumerate}
\end{theorem}

metus, accumsan sit amet commodo a, egestas vitae sem. Mauris ut
orci ut dolor viverra convallis nec a erat. Aenean consequat elit
vel eros fermentum vestibulum id at ipsum. In vitae orci mauris, et
rhoncus odio. Pellentesque habitant morbi tristique senectus et netus
et malesuada fames ac turpis egestas.

\begin{definition}\label{def:aha}
ti ta to
\end{definition}

\section{bla bla}
asdf adsfaa  asdfasd fasdf sdfsdrurtzhfg tdfutu  fsdfsdfger thz ergte
 fasd fsad fasdf asdfa sdfasdf asdssdfwer wewe asdf asdf asdfa asasdf
dasdfs.

As was shown in \cref{sec:minimal-distance} you can ...
Bla in \cref{thm:bla-blup} and in \cref{def:aha}
\end{document}


%%
% The BIThesis Template for Bachelor Graduation Thesis
%
% 北京理工大学毕业设计（论文）第二章节 —— 使用 XeLaTeX 编译
%
% Copyright 2020-2022 BITNP
%
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, either version 1.3
% of this license or (at your option) any later version.
% The latest version of this license is in
%   http://www.latex-project.org/lppl.txt
% and version 1.3 or later is part of all distributions of LaTeX
% version 2005/12/01 or later.
%
% This work has the LPPL maintenance status `maintained'.
%
% The Current Maintainer of this work is Feng Kaiyu.
%%

\chapter{另一个章节}

\section{代码片段}

\begin{lstlisting}[language=Python, caption={Python Code}, label={lst:pythonfile}]
import numpy as np

def incmatrix(genl1,genl2):
    m = len(genl1)
    n = len(genl2)
    M = None #to become the incidence matrix
    VT = np.zeros((n*m,1), int)  #dummy variable

    #compute the bitwise xor matrix
    M1 = bitxormatrix(genl1)
    M2 = np.triu(bitxormatrix(genl2),1)

    for i in range(m-1):
        for j in range(i+1, m):
            [r,c] = np.where(M2 == M1[i,j])
            for k in range(len(r)):
                VT[(i)*n + r[k]] = 1;
                VT[(i)*n + c[k]] = 1;
                VT[(j)*n + r[k]] = 1;
                VT[(j)*n + c[k]] = 1;

                if M is None:
                    M = np.copy(VT)
                else:
                    M = np.concatenate((M, VT), 1)

                VT = np.zeros((n*m,1), int)

    return M
\end{lstlisting}


\chapter{LPE}

\section{Introduction}
The techniques that are described in the following chapters must be applied to a \emph{linear process equation}, or LPE for short.

\section{Requirements}

An LPE must satisfy the following requirements:

\begin{itemize}

\item Given are the definition of a single process \emph{and} its instantiation.
The instantiation must be a closed expression, and otherwise satisfy the usual requirements of \txs{} of process instantiations.
There are no requirements for the channel parameters and data parameters beyond the usual requirements of \txs{} of process definitions.

\item The body of the process consists of one or more \emph{summands}.
In this context, a summand must contain exactly the following, in the given order:

\begin{itemize}

\item One or more \emph{channel communications}; that is, channel references followed by the variables that are used to communicate over those channels.
For example, \inlinecode{OUTPUT ? x ? y}, or simply \inlinecode{OUTPUT}.

Channel communications are combined with \inlinecode{|}.
To give another example, \inlinecode{INPUT ? x | OUTPUT ? y}.

The variables that are used to communicate over a channel must be \emph{fresh}.

\item A guard, yielding a boolean value.
The guard is not always explicitly written if it is semantically equivalent to \inlinecode{true}.

\item A sequence operator, \inlinecode{>->}.

\item The expression for deadlock (\inlinecode{STOP}) \emph{or} a recursive process instantiation.
The instantiated process must use the process definition given by the LPE, which satisfies the requirements of a \txs{} process signature.
This includes channel parameters: these must be assigned their current values of the instantiating process.
There are no requirements for the values assigned to the data parameters beyond the usual requirements of \txs{} (such as type compatibility).

\end{itemize}

\end{itemize}

\section{Example}

The following code snippet gives a valid example of an LPE:

\begin{lstlisting}
//Process definition:
PROCDEF example[A :: Int, B](state, curr, prev :: Int)
  = A ? i [[state==0]] >-> example[A, B](2, i, prev)
  + A ? i [[state==1 && i!=prev]] >-> example[A, B](2, i, prev)
  + A ? i [[state==2 && i==curr]] >-> example[A, B](1, curr, curr)
  + B >-> STOP
  ;

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

The process only accepts input sequences in which every number is repeated exactly once.
The process terminates non-deterministically.


%% SECTION HEADER /////////////////////////////////////////////////////////////////////////////////////
\section{2D Spectral Modelling}
\label{sec:2Dmodel}

%% SECTION CONTENT ////////////////////////////////////////////////////////////////////////////////////

According to the first-order shear deformation theory~\cite{reissner1945effect, mindlin1951influence}, the displacement field is expressed as:
\begin{eqnarray}
	\left \{ \begin{array}{c}
		\textbf{u}^e(\xi,\eta) \\
		\textbf{v}^e(\xi,\eta) \\
		\textbf{w}^e(\xi,\eta)
	\end{array} \right\} =
	\left \{ \begin{array}{c}
		\textbf{u}_0^e(\xi,\eta) + z\boldsymbol{\varphi}_x^e(\xi,\eta)\\
		\textbf{v}_0^e(\xi,\eta) + z\boldsymbol{\varphi}_y^e(\xi,\eta)\\
		\textbf{w}_0^e(\xi,\eta) \\
	\end{array} \right\},
\end{eqnarray}
where \(\textbf{u}_0^e\), \(\textbf{v}_0^e\) and \(\textbf{w}_0^e\) are nodal displacements, \(\boldsymbol{\varphi}_x^e\), \(\boldsymbol{\varphi}_y^e\) are the rotations of the normal to the mid-plane with respect to the axes \textit{x} and \textit{y}, respectively. They are defined as:
\begin{eqnarray}
	\left \{\begin{array}{c}
		\textbf{u}_0^e(\xi,\eta) \\
		\textbf{v}_0^e(\xi,\eta) \\
		\textbf{w}_0^e(\xi,\eta) \\
		\boldsymbol{\varphi}_x^e(\xi,\eta) \\
		\boldsymbol{\varphi}_y^e(\xi,\eta)
	\end{array} \right\}
	= \textbf{N}^e(\xi,\eta)\widehat{\textbf{d}}^e
	= \sum_{n=1}^q\sum_{m=1}^p\textbf{N}_m^e(\xi)\textbf{N}_n^e(\eta)
	\left \{ \begin{array}{c}
		\widehat{\textbf{u}}_0^e \\
		\widehat{\textbf{v}}_0^e \\
		\widehat{\textbf{w}}_0^e \\
		\widehat{\boldsymbol{\varphi}}_x^e \\
		\widehat{\boldsymbol{\varphi}}_y^e
	\end{array} \right \},
\end{eqnarray}
where $\widehat{\textbf{d}}^e$ is a nodal displacements vector of the element $e$.

The nodal bending strain--displacement relations are given in the form:
\begin{eqnarray}
	\boldsymbol{\epsilon}_b^e =
	\textbf{B}_b^e\widehat{\textbf{d}}^e =
	\left [
	\begin{array}{ccccc}
		\frac{\partial N^e}{\partial x} & 0 & 0 & 0 & 0\\
		0 & \frac{\partial N^e}{\partial y} & 0 & 0 & 0\\
		\frac{\partial N^e}{\partial y} & \frac{\partial N^e}{\partial x} & 0 & 0 & 0\\
		0 & 0 & 0 & -\frac{\partial N^e}{\partial x} & 0\\
		0 & 0 & 0 & 0 & -\frac{\partial N^e}{\partial y}\\
		0 & 0 & 0 & -\frac{\partial N^e}{\partial y} & -\frac{\partial N^e}{\partial x}
	\end{array} \right]
	\left \{ \begin{array}{c}
		\widehat{\textbf{u}}_0^e \\
		\widehat{\textbf{v}}_0^e \\
		\widehat{\textbf{w}}_0^e \\
		\widehat{\boldsymbol{\varphi}}_x^e \\
		\widehat{\boldsymbol{\varphi}}_y^e
	\end{array} \right\}.
\end{eqnarray}

The nodal shear strain--displacement relations are given in the form:
\begin{eqnarray}
	\boldsymbol{\epsilon}_s^e =
	\textbf{B}_s^e\widehat{\textbf{d}}^e =
	\left [
	\begin{array}{ccccc}
		0 & 0 & \frac{\partial N^e}{\partial y} & -1 & 0\\
		0 & 0 & \frac{\partial N^e}{\partial y} & 0 & -1
	\end{array} \right]
	\left \{ \begin{array}{c}
		\widehat{\textbf{u}}_0^e \\
		\widehat{\textbf{v}}_0^e \\
		\widehat{\textbf{w}}_0^e \\
		\boldsymbol{\varphi}_x^e \\
		\boldsymbol{\varphi}_y^e
	\end{array} \right\}.
\end{eqnarray}

The mass and stiffness matrices for \ac{2d} elements are defined as:
\begin{eqnarray}
	\textbf{M}_{dd}^e & = &
	\left [
	\begin{array}{cc}
		\textbf{M}^e & 0\\
		0 & \textbf{J}^e
	\end{array}
	\right] =
	\int_{\Omega_e}\textbf{N}^T\rho
	\left [
	\begin{array}{ccccc}
		h & 0 & 0 & 0 & 0 \\
		& h & 0 & 0 & 0 \\
		&  & h & 0 & 0\\
		&  &  & \frac{h^3}{12} & 0\\
		Sym. &  &  &  & \frac{h^3}{12}
	\end{array} \right]
	\textbf{N} \diff\Omega_e,\\
	\textbf{K}_{dd}^e & = & \int_{\Omega_e}{\textbf{B}_b^e}^T
	\left[
	\begin{array}{cc}
		\textbf{A} & \textbf{B}\\
		\textbf{B} & \textbf{D}
	\end{array} \right]
	\textbf{B}_b^e \diff \Omega_e+\int_{\Omega_e}{\textbf{B}_s^e}^T\hat{\textbf{A}}\textbf{B}_s^e\diff \Omega_e,
\end{eqnarray}
where \(h=h_t+h_b\) is the element thickness, while \(h_{t(b)}\) is the distance between mid-plane and top(bottom) surface of the element, and \(\Omega_e\) is the element area:
\begin{eqnarray}
	\textbf{A} & = & \textbf{c}_{ij}\,(h_t-h_b),\qquad i,j=1,2,6\nonumber\\
	\textbf{B} & = & 1/2\, \textbf{c}_{ij}\,(h_t^2-h_b^2),\qquad i,j=1,2,6\nonumber\\
	\textbf{D} & = & 1/3\, \textbf{c}_{ij}\,(h_t^3-h_b^3),\qquad i,j=1,2,6\nonumber\\
	\hat{\textbf{A}} & = & 5/4\, \textbf{c}_{ij}\,\left[h_t-h_b-4/3\left(h_t^3-h_b^3\right)/h^2\right],\qquad i,j=4,5.
\end{eqnarray}


\chapter{Logistic Regression models}
\label{ch:Models}

The Logistic Regression models obtained in the results of this work is shown in tables \ref{tab:model1} and \ref{tab:model2}. To clarify, $\pi(x)$ indicates the probability that a new instance $x$ belongs to the default class, which, in this case, is a student passing the course.

\begin{table}[htb]
\centering
\begin{tabular}{cc} \hline
\textbf{Week} & \textbf{Model} \\ \hline
1 & $logit[\pi(x)] = -2.1+0.14*pp_1+0.2*pv_1$ \\ \hline
2 & $logit[\pi(x)] =-3.31+0.1*pp_1+0.16*pp_2+0.06*pv_1+0.22*pv_2$ \\ \hline
3 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-3.5+0.07*pp_1+0.1*pp_2+0.13*pp_3+0.04*pv_1$\\$ +0.08*pv_2+0.19*pv_3$\end{tabular} \\ \hline
4 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-4.4+0.06*pp_1+0.08*pp_2+0.09*pp_3+0.17*pp_4$\\$ +0.02*pv_1+0.01*pv_2+0.08*pv_3+0.25*pv_4$\end{tabular} \\ \hline
5 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-4.3+0.05*pp_1+0.05*pp_2+0.06*pp_3+0.1*pp_4$\\$ +0.16*pp_5+0.03*pv_1+0.02*pv_2+0.05*pv_3+0.1*pv_4+0.17*pv_5$\end{tabular} \\ \hline
6 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-4.63+0.04*pp_1+0.04*pp_2+0.05*pp_3+0.08*pp_4$\\$ +0.12*pp_5+0.14*pp_6+0.02*pv_1+0.01*pv_2$\\$ +0.03*pv_3+0.07*pv_4+0.11*pv_5+0.11*pv_6$\end{tabular} \\ \hline
7 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-4.75+0.04*pp_1+0.03*pp_2+0.04*pp_3+0.06*pp_4$\\$ +0.09*pp_5+0.1*pp_6+0.14*pp_7+0.02*pv_1$\\$ +0.01*pv_2+0.03*pv_3+0.06*pv_4+0.08*pv_5+0.05*pv_6+0.12*pv_7$\end{tabular} \\ \hline
8 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.14+0.06*pp_1+0.02*pp_2+0.04*pp_3+0.04*pp_4$\\$ +0.07*pp_5+0.09*pp_6+0.11*pp_7+0.11*pp_8$\\$ +0.01*pv_1+0.01*pv_2+0.02*pv_3+0.06*pv_4$\\$ +0.06*pv_5-0.03*pv_6+0.03*pv_7+0.24*pv_8$\end{tabular} \\ \hline
9 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.29+0.05*pp_1+0.02*pp_2+0.04*pp_3$\\$ +0.04*pp_4+0.07*pp_5+0.07*pp_6+0.09*pp_7+0.08*pp_8$\\$ +0.1*pp_9+0.0*pv_1+0.01*pv_2+0.0*pv_3+0.06*pv_4$\\$ +0.05*pv_5-0.03*pv_6-0.01*pv_7+0.11*pv_8+0.23*pv_9$\end{tabular} \\ \hline
10 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.36+0.05*pp_1+0.01*pp_2+0.03*pp_3$\\$ +0.04*pp_4+0.06*pp_5+0.06*pp_6+0.08*pp_7+0.07*pp_8$\\$ +0.08*pp_9+0.06*pp_{10}+0.0*pv_1+0.02*pv_2$\\$ -0.01*pv_3+0.05*pv_4+0.05*pv_5$\\$ -0.03*pv_6-0.02*pv_7+0.08*pv_8+0.11*pv_9+0.21*pv_{10}$\end{tabular} \\ \hline
11 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.49+0.06*pp_1+0.01*pp_2+0.03*pp_3$\\$ +0.04*pp_4+0.07*pp_5+0.05*pp_6+0.08*pp_7+0.05*pp_8$\\$ +0.07*pp_9+0.03*pp_{10}+0.08*pp_{11}-0.0*pv_1$\\$ +0.01*pv_2-0.01*pv_3+0.05*pv_4+0.04*pv_5-0.03*pv_6$\\$ -0.02*pv_7+0.06*pv_8+0.06*pv_9+0.11*pv_{10}+0.25*pv_{11}$\end{tabular} \\ \hline
12 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.42+0.06*pp_1+0.01*pp_2+0.02*pp_3$\\$ +0.03*pp_4+0.07*pp_5+0.05*pp_6+0.09*pp_7+0.05*pp_8$\\$ +0.06*pp_9+0.01*pp_{10}+0.05*pp_{11}+0.08*pp_{12}$\\$ -0.01*pv_1+0.01*pv_2-0.01*pv_3+0.06*pv_4$\\$ +0.04*pv_5-0.04*pv_6-0.05*pv_7+0.04*pv_8$\\$ +0.05*pv_9+0.07*pv_{10}+0.15*pv_{11}+0.22*pv_{12}$\end{tabular} \\ \hline
\end{tabular}
\caption{Logistic Regression models (weeks 1-12)}
\label{tab:model1}
\end{table}

\begin{table}[htb]
\centering
\resizebox{12cm}{!}{%
\begin{tabular}{cc} \hline
\textbf{Week} & \textbf{Model} \\ \hline
13 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.25+0.04*pp_1+0.01*pp_2+0.01*pp_3$\\$ +0.02*pp_4+0.06*pp_5+0.04*pp_6+0.06*pp_7+0.04*pp_8$\\$ +0.05*pp_9+0.01*pp_{10}+0.04*pp_{11}+0.05*pp_{12}$\\$ +0.1*pp_{13}+0.0*pv_1+0.01*pv_2+0.0*pv_3+0.04*pv_4$\\$ +0.03*pv_5-0.02*pv_6-0.01*pv_7+0.03*pv_8+0.04*pv_9$\\$ +0.06*pv_{10}+0.09*pv_{11}+0.09*pv_{12}+0.14*pv_{13}$\end{tabular} \\ \hline
14 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.31+0.04*pp_1+0.02*pp_2+0.01*pp_3$\\$ +0.03*pp_4+0.06*pp_5+0.04*pp_6+0.05*pp_7+0.04*pp_8$\\$ +0.04*pp_9-0.0*pp_{10}+0.02*pp_{11}+0.03*pp_{12}$\\$ +0.07*pp_{13}+0.12*pp_{14}+0.0*pv_1+0.01*pv_2$\\$ +0.0*pv_3+0.03*pv_4+0.04*pv_5-0.02*pv_6$\\$ -0.02*pv_7+0.03*pv_8+0.04*pv_9+0.05*pv_{10}$\\$ +0.08*pv_{11}+0.07*pv_{12}+0.08*pv_{13}+0.12*pv_{14}$\end{tabular} \\ \hline
15 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.47+0.04*pp_1+0.01*pp_2+0.01*pp_3$\\$ +0.03*pp_4+0.06*pp_5+0.03*pp_6+0.06*pp_7+0.04*pp_8$\\$ +0.04*pp_9-0.01*pp_{10}+0.01*pp_{11}+0.02*pp_{12}$\\$ +0.05*pp_{13}+0.09*pp_{14}+0.09*pp_{15}+0.01*pv_1$\\$ +0.0*pv_2+0.0*pv_3+0.04*pv_4+0.03*pv_5$\\$ -0.02*pv_6-0.02*pv_7+0.02*pv_8+0.04*pv_9$\\$ +0.05*pv_{10}+0.07*pv_{11}+0.05*pv_{12}$\\$ +0.05*pv_{13}+0.08*pv_{14}+0.12*pv_{15}$\end{tabular} \\ \hline
16 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.82+0.05*pp_1+0.01*pp_2+0.01*pp_3$\\$ +0.04*pp_4+0.07*pp_5+0.04*pp_6+0.06*pp_7+0.05*pp_8$\\$ +0.04*pp_9-0.02*pp_{10}+0.0*pp_{11}+0.0*pp_{12}$\\$ +0.04*pp_{13}+0.08*pp_{14}+0.08*pp_{15}+0.07*pp_{16}$\\$ +0.01*pv_1+0.0*pv_2+0.0*pv_3$\\$ +0.06*pv_4+0.05*pv_5-0.05*pv_6$\\$ -0.05*pv_7+0.01*pv_8+0.06*pv_9+0.06*pv_{10}$\\$ +0.09*pv_{11}+0.05*pv_{12}+0.03*pv_{13}+0.05*pv_{14}$\\$ +0.11*pv_{15}+0.11*pv_{16}$\end{tabular} \\ \hline
17 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-5.56+0.04*pp_1+0.01*pp_2+0.01*pp_3$\\$ +0.03*pp_4+0.05*pp_5+0.03*pp_6+0.05*pp_7+0.04*pp_8$\\$ +0.04*pp_9-0.02*pp_{10}+0.01*pp_{11}+0.0*pp_{12}$\\$ +0.03*pp_{13}+0.06*pp_{14}+0.06*pp_{15}+0.04*pp_{16}$\\$ +0.1*pp_{17}+0.01*pv_1+0.01*pv_2$\\$ +0.0*pv_3+0.04*pv_4+0.04*pv_5-0.02*pv_6$\\$ -0.02*pv_7+0.02*pv_8+0.04*pv_9+0.05*pv_{10}$\\$ +0.07*pv_{11}+0.05*pv_{12}+0.04*pv_{13}+0.04*pv_{14}$\\$ +0.07*pv_{15}+0.06*pv_{16}+0.08*pv_{17}$\end{tabular} \\ \hline
18 & \begin{tabular}[c]{@{}c@{}}$logit[\pi(x)] =-4.62+0.02*pp_1+0.01*pp_2+0.01*pp_3$\\$ +0.02*pp_4+0.03*pp_5+0.02*pp_6+0.03*pp_7+0.03*pp_8$\\$ +0.03*pp_9+0.01*pp_{10}+0.02*pp_{11}+0.02*pp_{12}$\\$ +0.03*pp_{13}+0.04*pp_{14}+0.04*pp_{15}+0.04*pp_{16}$\\$ +0.05*pp_{17}+0.06*pp_{18}+0.01*pv_1+0.01*pv_2$\\$ +0.01*pv_3+0.02*pv_4+0.02*pv_5+0.01*pv_6$\\$ +0.01*pv_7+0.02*pv_8+0.03*pv_9+0.03*pv_{10}$\\$ +0.04*pv_{11}+0.03*pv_{12}+0.03*pv_{13}+0.03*pv_{14}$\\$ +0.04*pv_{15}+0.04*pv_{16}+0.04*pv_{17}+0.05*pv_{18}$\end{tabular}\\ \hline
\end{tabular}%
}
\caption{Logistic Regression models (weeks 13-18)}
\label{tab:model2}
\end{table}