We now enhance our heat equation example from Section \ref{sec:HeatEq_1}.
Below is an outline of how we will proceed.  Each of these sections contains an
accompanying tutorial code that builds upon the previous example.
\begin{itemize}

\item In Section \ref{Sec:Boundary Conditions} we develop the
  capability to handle other (non-periodic) boundary condition types.

\item In Section \ref{Sec:Refinement} we develop the capability to
  have multiple levels of refinement using a fixed, multilevel grid
  structure.

\item In Section \ref{Sec:AMR} we develop the capability to adaptively
  change the multilevel grid structure.

\item In Section \ref{Sec:Linear Solvers} we develop the capability to
  solve the equation implicitly, using the linear solver libraries.

\end{itemize}

\section{Boundary Conditions}\label{Sec:Boundary Conditions}
In order to understand how to implement boundary conditions, we shall
first describe the general principles behind working with boundary
conditions.  The {\tt BoxLib/Tutorials/HeatEquation\_EX2\_F/} tutorial
continues our heat equation example, but now with some non-periodic
boundary condition support.  The boundary condition modules in {\tt
  BoxLib/Src/F\_BaseLib/define\_bc\_tower.f90} and {\tt
  multifab\_physbc.f90} can be used as a springboard for developing
your own customized boundary conditions.

\subsection{General Principles}
The basic idea is that every grid has knowledge of the
boundary condition type at the low and high side edge in each direction.
The ``physical'' boundary condition types supported by default are {\tt INLET}, {\tt OUTLET},
{\tt SYMMETRY}, {\tt SLIP\_WALL}, {\tt NO\_SLIP\_WALL}, and {\tt PERIODIC}.
There is also an {\tt INTERIOR} boundary condition type, which
will be explained below.  We use an integer mapping that is
contained in {\tt BoxLib/Src/F\_BaseLib/bc.f90}:
\begin{lstlisting}[backgroundcolor=\color{light-green}]
integer, parameter, public :: PERIODIC     = -1
integer, parameter, public :: INTERIOR     =  0

integer, parameter, public :: INLET        = 11
integer, parameter, public :: OUTLET       = 12
integer, parameter, public :: SYMMETRY     = 13
integer, parameter, public ::    SLIP_WALL = 14
integer, parameter, public :: NO_SLIP_WALL = 15
\end{lstlisting}

{\bf Examples:}
\begin{itemize}
\item Consider grid 1 in Figure \ref{fig:bc_example1}.  The low-x
  boundary condition is {\tt INLET}, and the high-y boundary condition
  is {\tt NO\_SLIP\_WALL}.  The high-x and low-y boundary conditions
  are {\tt INTERIOR}, which means that the ghost cells share the same
  physical space as cells in the valid region of another grid.  Note
  that for grids 6, 7, 10, and 11, the boundary condition type for
  every side is {\tt INTERIOR}.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}[tb]
\centering
\includegraphics[width=4in]{./F_AdvancedTopics/bc_example1}
\caption{\label{fig:bc_example1}Two-dimensional example with 16 -
  4$^2$grids with {\tt INLET}, {\tt OUTLET}, and {\tt NO\_SLIP\_WALL}
  boundary conditions.  The numbers refer to the grid number.}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\item Figure \ref{fig:bc_example2} demonstrates a problem with
  periodicity in the x-direction.  In this case, the low-x boundary
  condition for grid 1 is {\tt PERIODIC}.  Note there are some
  similarities between {\tt PERIODIC} and {\tt INTERIOR} boundary
  conditions when it comes to filling ghost cells in that ghost cell
  values are simply copied in from the valid region of another grid.
  In fact, one can think of {\tt PERIODIC} as just a special type of
  {\tt INTERIOR} boundary condition.  For the other boundary
  conditions types, the user can write custom boundary conditions
  routines to fill ghost cells, which can involve setting ghost cell
  values directly, or using interior points and/or physical boundary
  conditions in some stencil operation.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}[tb]
\centering
\includegraphics[width=4in]{./F_AdvancedTopics/bc_example2}
\caption{\label{fig:bc_example2}Two-dimensional example with 16 - 4$^2$grids with
{\tt PERIODIC} and {\tt NO\_SLIP\_WALL} boundary conditions.
The numbers refer to the grid number.}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\item Now, consider an example with refined grids.  Figure
  \ref{fig:bc_example3} contains three grids at the next level of
  refinement.  In this case, for grid 1, all of the boundary condition
  types are {\tt INTERIOR}, even though the neighboring valid region
  data is at a coarser level of refinement.  For grid 2, the low-y
  boundary condition is {\tt NO\_SLIP\_WALL}, and the other three
  walls are {\tt INTERIOR}.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}[tb]
\centering
\includegraphics[width=4in]{./F_AdvancedTopics/bc_example3}
\caption{\label{fig:bc_example3}Two-dimensional example with 3 grids at a finer
resolution than the base grid.}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{itemize}

\subsection{Implementation}
Typically, we read in integer values from the inputs file for {\tt
  bc\_x\_lo}, {\tt bc\_x\_hi}, {\tt bc\_y\_lo}, etc., that correspond
to the physical boundary condition types.  We then build a {\tt
  bc\_tower} object which is an array of {\tt bc\_level} objects, one
for each level of refinement.  The {\tt bc\_level} contains several
integer array data structures, as can be seen in {\tt
  BoxLib/Src/F\_BaseLib/define\_bc\_tower.f90}:
\begin{lstlisting}[backgroundcolor=\color{light-green}]
type bc_level

   ! 1st index is the grid number (grid "0" corresponds to the prob domain)
   ! 2nd index is the direction (1=x, 2=y, 3=z)
   ! 3rd index is the side (1=lo, 2=hi)
   ! 4th index is the variable (only assuming 1 variable here)
   integer, pointer :: phys_bc_level_array(:,:,:) => Null()
   integer, pointer ::  adv_bc_level_array(:,:,:,:) => Null()
   integer, pointer ::  ell_bc_level_array(:,:,:,:) => Null()

end type bc_level
\end{lstlisting}
Each level has a {\tt phys\_bc\_level\_array(0:ngrids,dim,2)} array,
where {\tt ngrids} is the number of grids on that level, {\tt dim} is
the dimensionality of the simulation, and the third index refers to
the lower or upper edge of the grid in that coordinate direction.
This stores the {\it physical description} of the boundary type ({\tt
  INLET}, {\tt OUTLET}, etc.), which is independent of the variables
that live on the grid.  The {\tt phys\_bc\_level\_array(0,:,:)} refers
to the entire domain.  If an edge of a grid is not a physical
boundary, then it is set to a default value, typically {\tt INTERIOR}.
These boundary condition types are used to interpret the actual method
to fill the ghost cells for each variable, as described in {\tt
  adv\_bc\_level\_array} and {\tt ell\_bc\_level\_array}.

Whereas {\tt phys\_bc\_level\_array} provides a physical description
of the type of boundary, the array {\tt adv\_bc\_level\_array}
describes the action to be taken (e.g. reflect, extrapolate, etc.) for
each variable when filling physical ghost cells on domain boundaries.
The prefix ``{\tt adv\_}'' is somewhat of a misnomer, as this data
structure was originally intended to tell advection (or hyperbolic)
solvers how to fill ghost cells, but now is generally used to fill
physical domain boundary ghost cells in any instance where the user
needs to set them.  The form of this array is {\tt
  adv\_bc\_level\_array(0:ngrids,dim,2,nvar)} where the additional
component, nvar, allows for different state variable that lives on a
grid to have different boundary condition actions associated with it.
For example, you could have {\tt nvar=1} correspond to the x-velocity,
{\tt nvar=2} correspond to density, and {\tt nvar=3} correspond to
pressure.  In the {\tt BoxLib/Tutorials/HeatEquation\_EX2\_F/}
tutorial, there is only one variable, $\phi$, so obviously {\tt
  nvar=1} shall correspond to $\phi$.  When we build the {\tt
  adv\_bc\_level\_array}, we first set all values to {\tt INTERIOR},
and then overwrite any physical domain boundary condition types, as
given in {\tt phys\_bc\_level\_array}.  The {\tt
  adv\_bc\_level\_array} types supported by default are (as listed in
{\tt BoxLib/Src/F\_BaseLib/bc.f90}):
\begin{lstlisting}[backgroundcolor=\color{light-green}]
integer, parameter, public :: INTERIOR     =  0

integer, parameter, public :: REFLECT_ODD  =  20
integer, parameter, public :: REFLECT_EVEN =  21
integer, parameter, public :: FOEXTRAP     =  22
integer, parameter, public :: EXT_DIR      =  23
integer, parameter, public :: HOEXTRAP     =  24
\end{lstlisting}

To manually fill ghost cells, we call {\tt multifab\_physbc}, passing
in the state multifab along with the {\tt adv\_bc\_level\_array}.  The
subroutines {\tt physbc\_1d/2d/3d} in {\tt
  BoxLib/Src/F\_BaseLib/multifab\_physbc.f90}, indicate how to fill
ghost cells.  For example,
\begin{lstlisting}[backgroundcolor=\color{light-green}]
  subroutine multifab_physbc(s,start_scomp,start_bccomp,ncomp, &
                             the_bc_level,time_in,dx_in, &
                             prob_lo_in,prob_hi_in)

    integer        , intent(in   )           :: start_scomp,start_bccomp
    integer        , intent(in   )           :: ncomp
    type(multifab) , intent(inout)           :: s
    type(bc_level) , intent(in   )           :: the_bc_level
    real(kind=dp_t), intent(in   ), optional :: time_in,dx_in(:)
    real(kind=dp_t), intent(in   ), optional :: prob_lo_in(:),prob_hi_in(:)

    ! Local
    integer                  :: lo(get_dim(s)),hi(get_dim(s))
    integer                  :: i,ng,dm,scomp,bccomp
    real(kind=dp_t)          :: time,dx(get_dim(s))
    real(kind=dp_t)          :: prob_lo(get_dim(s)),prob_hi(get_dim(s))
    real(kind=dp_t), pointer :: sp(:,:,:,:)

    ! set optional arguments
    time    = 0.d0
    dx      = 0.d0
    prob_lo = 0.d0
    prob_hi = 0.d0
    if (present(time_in))       time = time_in
    if (present(dx_in))           dx = dx_in
    if (present(prob_lo_in)) prob_lo = prob_lo_in
    if (present(prob_hi_in)) prob_hi = prob_hi_in

    ng = nghost(s)
    dm = get_dim(s)

    do i=1,nfabs(s)
       sp => dataptr(s,i)
       lo = lwb(get_box(s,i))
       hi = upb(get_box(s,i))
       select case (dm)
       case (2)
          do scomp=start_scomp,start_scomp+ncomp-1
             bccomp = start_bccomp + scomp - start_scomp
             call physbc_2d(sp(:,:,1,scomp), lo, hi, ng, &
                          the_bc_level%adv_bc_level_array(i,:,:,bccomp), &
                          time, dx, prob_lo, prob_hi)
          end do
...

  subroutine physbc_2d(s,lo,hi,ng,bc,time,dx,prob_lo,prob_hi)

    use bl_constants_module
    use bc_module

    integer        , intent(in   ) :: lo(:),hi(:),ng
    real(kind=dp_t), intent(inout) :: s(lo(1)-ng:,lo(2)-ng:)
    integer        , intent(in   ) :: bc(:,:)
    real(kind=dp_t), intent(in   ) :: time,dx(:),prob_lo(:),prob_hi(:)

    ! Local variables
    integer :: i,j

    !!!!!!!!!!!!!
    ! LO-X SIDE
    !!!!!!!!!!!!!

    if (bc(1,1) .eq. EXT_DIR) then
       ! set all ghost cell values to a prescribed dirichlet
       ! value; in this example, we have chosen 1
       do j = lo(2)-ng, hi(2)+ng
          s(lo(1)-ng:lo(1)-1,j) = 1.d0
       end do
    else if (bc(1,1) .eq. FOEXTRAP) then
       ! set all ghost cell values to first interior value
       do j = lo(2)-ng, hi(2)+ng
          s(lo(1)-ng:lo(1)-1,j) = s(lo(1),j)
       end do
...
\end{lstlisting}

Note that the optional arguments allow for the use of space and/or
time-dependent boundary conditions.

{\tt ell\_bc\_level\_array} is the analog to {\tt
  adv\_bc\_level\_array} for the linear solvers in \BoxLib.  These
will be described in Section \ref{Sec:Linear Solvers}.

\section{Multiple Levels of Refinement}\label{Sec:Refinement}
In the {\tt BoxLib/Tutorials/HeatEquation\_EX3\_F/} tutorial, we have
expanded our example to the cases of multiple levels of refinement,
with the grids fixed in space.  In this example we advance all the
grids with the same time step, and perform synchronization operations
between levels.\\

The big change for this tutorial is that we use a "multilevel layout"
{\tt ml\_layout} rather than a {\tt layout}, and also {\tt multifab
  phi} and {\tt dx} are now {\tt nlevs} sized arrays.  After
initializing or updating $\phi$, we must fill all ghost cell and
synchronize the solution between levels.  After we make the fluxes, we
must synchronize the fluxes to maintain conservation.\\

There are three key subroutines for filling ghost cells and
synchronizing data in multilevel applications.  Each of these involves
a coarse level and a fine level:
\begin{itemize}

\item {\tt ml\_cc\_restriction} sets coarse cell-centered values equal
  to the average of the fine cells covering it.

\item {\tt ml\_edge\_restriction} sets coarse edge-centered values
  (such as fluxes) equal to the average of the fine edges covering it.

\item {\tt multifab\_fill\_ghost\_cells} fills fine ghost cells using
  interpolation from the underlying coarse data.  Note that this
  operation does not affect ghost cells that would be filled by {\tt
    multifab\_fill\_boundary} or {\tt multifab\_physbc}.

\end{itemize}

\section{Adaptive Mesh Refinement}\label{Sec:AMR}
Now fully implemented in {\tt BoxLib/Tutorials/HeatEquation\_EX4\_F/}.
The basic idea is to ``tag'' the cells you with to refine in {\tt
  BoxLib/Src/F\_BaseLim\b/tag\_boxes.f90}.  To write your own
customized tagging criteria, copy {\tt tag\_boxes.f90} into your local
directory and modify it, since this copy will take precedence over the
version in the \BoxLib~source.

There are several new
parameters that can be set via an inputs file:
\begin{itemize}
\item {\tt amr\_buf\_width}: radius (in cells) of tagged cells in
  addition to those already tagged due to the criteria in {\tt
    tag\_boxes.f90}.
\item {\tt cluster\_minwidth}: any newly created grids must be at
  least this many cells in each direction.
\item {\tt cluster\_blocking\_factor}: any newly created grids must
  have an integer multiple of this many cells in each direction.
\item {\tt cluster\_min\_eff}: This is a real number between 0 and 1
  that controls how tightly the newly created grids match the tagged
  cells.  As this value approaches 1, you will have more, smaller
  grids.  Another way to think of this is that during the grid
  creation process, at least 100$\times${\tt cluster\_min\_eff}
  percent of the cells in each grid at which the grid creation occurs
  must be tagged cells.
\item {\tt regrid\_int}: frequency, in time steps, on when to regrid
  the simulation.
\end{itemize}
It is worth playing around with the inputs files to see what effect
these parameters have on the grid structure.

\section{Linear Solvers}\label{Sec:Linear Solvers}
The tutorial code {\tt BoxLib/Tutorials/HeatEquation\_EX5\_F/}
contains an implicit version of the heat equation example.  Fortran90
\BoxLib\ contains a ``cell-centered'' multigrid solver that solves
linear systems of the form:
\begin{equation}
(\alpha\mathcal{I} - \nabla\cdot\beta\nabla)\phi = \text{RHS},
\end{equation}
where $\alpha, \phi$, and RHS are cell-centered \MultiFab~s, and
$\beta$ is an array of \MultiFab~s that are nodal in exactly one
direction (i.e., one face-centered \MultiFab for each spatial
direction).  The Laplacian-like term in the left-hand-side can be
discretized in several ways.  The simplest discretization option is
similar to a 5-point (7-point in 3D) Laplacian:
\begin{eqnarray}
\nabla\cdot\beta\nabla\phi_{ij} &=&
\frac{1}{\Delta x} \left[\beta_{i+\myhalf,j}\frac{\phi_{i+1,j} - \phi_{ij}}{\Delta x} - \beta_{i-\myhalf,j}\frac{\phi_{ij} - \phi_{i-1,j}}{\Delta x}\right]\nonumber\\
&&+ \frac{1}{\Delta y} \left[\beta_{i,j+\myhalf}\frac{\phi_{i,j+1} - \phi_{ij}}{\Delta y} - \beta_{i,j-\myhalf}\frac{\phi_{ij} - \phi_{i,j-1}}{\Delta y}\right].
\end{eqnarray}
A fully implicit discretization of the heat equation,
\begin{equation}
\frac{\phi^{n+1} - \phi^n}{\Delta t} = \left[\nabla\cdot(\nabla\phi)\right]^{n+1},
\end{equation}
is equivalent to
\begin{equation}
(\mathcal{I} - \Delta t\nabla\cdot\nabla)\phi^{n+1} = \phi^n.
\end{equation}
Thus, we will set $\alpha=1$, each $\beta=\Delta t$, and RHS = $\phi^n$.

\section{Subcycling in Time}\label{Sec:Subcycling}
In {\tt BoxLib/Tutorials/AMR\_Adv\_Diff\_F} we have expanded the
explicit version of the heat equation example in
{\tt BoxLib/Tutorials/HeatEquation\_EX4\_F/} to include an example of
subcycling in time.  In the previous examples, which did not use
subcycling in time, each level was advanced with the same time step,
which was determined by imposing the CFL criterion at the finest
level.  In the example in {\tt BoxLib/Tutorials/AMR\_Adv\_Diff\_F},
we use both temporal and spatial refinement;
$\Delta t$ decreases as $\Delta x$ decreases so
that each level is running at a different time step.  For explicit
solution of advection or hyperbolic equations, $\Delta t / \Delta x$
is constant across levels; for explicit solution of parabolic equations,
$\Delta t / \Delta x^2$ is held constant.  This strategy
requires fewer steps to be taken at all but the finest levels relative
to the non-subcycling algorithm, but requires a more sophisticated
synchronization algorithm between levels.  Overall, the use of
subycling for explicit methods usually reduces runtime despite the
synchronization overhead.

With subycling in time, the advance of each level is called
recursively from coarsest to finest,  with interlevel synchronization
as shown in Figure~\ref{fig:subcycling_algorithm}.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{figure}[tb]
\centering
\includegraphics{./F_AdvancedTopics/subcycling_algorithm}
\caption{\label{fig:subcycling_algorithm} Subcycling algorithm with 3 levels of refinement.
        $num\_substeps=2$ is assumed here for clarity. }
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%During the single global time step, the algorithm performs
%${(num\_substeps)}^{\ell-1}$ steps at each level $\ell$ according to
%the predefined sequence presented in
%Figure~\ref{fig:subcycling_algorithm}. The main rule is that coarser
%levels are always updated before the finer ones.
To advance the solution at level $\ell,$ where we assume $0 < \ell < \ell_{max},$
the following steps are taken:
\begin{itemize}
\item Ghost cells at level $\ell$ are filled, either
using interpolation from level $\ell-1$, physical boundary conditions, or
copying from other grids at level $\ell$.
\item Face-based fluxes are computed at level $\ell$ and used to update the solution at level $\ell$.
\item Fluxes are stored in order to correct cells on the coarse side of any
coarse-fine interface.   Level $\ell$ and (the temporal and spatial average of)
level $\ell+1$ fluxes will be stored and used to correct level $\ell$ cells
adjacent to the interface of levels $\ell$ and $\ell+1.$   Similarly, both
$\ell-1$ fluxes and (the temporal and spatial average of) level $\ell$ fluxes
will be stored and used to correct level $\ell-1$ cells
adjacent to the interface of levels $\ell-1$ and $\ell.$
\item This procedure is called recursively $num\_substeps$ times for level $\ell+1.$
\item The solution at level $\ell+1$ is averaged down onto level $\ell$.
\end{itemize}


\documentclass[main.tex]{subfiles}
\begin{document}

\subsection{Gauge symmetries in QED}

\marginpar{Tuesday\\ 2020-4-7, \\ compiled \\ \today}

Last time we wrote the Lagrangian of QED:
%
\begin{align}
\mathscr{L}_{QED} = - \frac{1}{4} F^{\mu \nu } F_{\mu \nu }
+ \overline{\psi} \qty(i \gamma^{\mu } \DD_{\mu } -m) \psi
\,,
\end{align}
%
where \(\DD_{\mu } = \partial_{\mu } + i e A_{\mu }\).

This possesses several symmetries: Lorentz (actually, Poincaré) invariance, \(P\) (parity), \(C\) (charge conjugation), \(T\) (time inversion).

We are also interested in the \emph{internal} symmetries of this Lagrangian: all the aforementioned symmetries were spacetime ones.

We know that \(\overline{\psi} = \psi ^\dag \gamma^{0}\), so if we transform \(\psi \to e^{i \theta } \psi \) the Lagrangian is unchanged, since we also have \(\overline{\psi} \to e^{-i \theta } \overline{\psi} \).
Here, we are taking a \emph{constant} phase angle \(\theta \): it comes out of the derivative unchanged.
This is called a \(U(1)\) \textbf{global} symmetry, since it is the same everywhere in space and since a phase is the same as a \(1 \times 1 \) unitary matrix.

The following section differs from the notes.
Let us ignore the interactions of electrons with the EM fields in QED.
Our world is made of electrons, and we want to describe these free propagating electrons.
We take the Lagrangian
%
\begin{align}
\mathscr{L}_{\text{Dirac}} = \overline{\psi} \qty(i \gamma^{\mu } \partial_{\mu }  -m) \psi
\,,
\end{align}
%
which still has the symmetry \(\psi \to e^{i \alpha } \psi \).

Is this invariant also with respect to a \emph{local} \(U(1)\) symmetry? This looks like \(\psi (x) \to e^{i \alpha (x)} \psi (x)\), where \(\alpha (x)\) is a continuous spacetime scalar function.

This is a ``promotion'' of the symmetry: why? It seems like a global symmetry is a more general thing\dots However, the global symmetry is a special case of the local one.

This local symmetry is called a \(U(1)\) \emph{gauge} symmetry.
Properly speaking, the global symmetry is also a gauge one but it is commonly called just a global symmetry.

Substituting in, we get
%
\begin{align}
e^{-i \alpha (x)} \overline{\psi} \qty[i \partial_{\mu } \gamma^{\mu } - m] e^{i \alpha (x)} \psi
&=
\overline{\psi} \qty[i \partial_{\mu } \gamma^{\mu } - m] \psi
 + \overline{\psi} \psi i \gamma^{\mu }\partial_{\mu } \alpha
\,,
\end{align}
%
so we see that the Lagrangian is \emph{not} invariant under this gauge symmetry in general.

If we want the symmetry to hold, we need to introduce a \emph{compensating} field to cancel out the term.

The answer is that the thing to add is a vector field \(A_{\mu }\).
Then, if we transform
%
\begin{align}
A_{\mu } \to A_{\mu } - \frac{1}{e} \partial_{\mu } \alpha
\,
\end{align}
%
this compensates the change, as long as the vector is coupled to the fermion with a term \(\overline{\psi} e \gamma^{\mu } A_{\mu } \psi \) in the Lagrangian.
This is a profound result: if we wanted to describe a world with only electrons, and we want to have this electron be symmetric with respect to the \(U(1)\) gauge symmetry \(e \to e^{i \alpha (x)} e\) then we \emph{must} have a vector coupled to it.

Then, we should also insert a term describing the propagation of the free vector \(A_{\mu }\), the kinetic term \(\propto F^{\mu \nu } F_{\mu \nu }\).

A quote: ``And she said `let there be symmetry', and there was light''.

We could have just proven that the QED Lagrangian is invariant with respect to \(U(1)\) symmetry: however, this reasoning illustrates the point that the symmetry requires the insertion of photons.

One might ask: how do you know that this is the correct symmetry?
The method is trial and error.

Could we have something which is more complicated than a spin 1 mediator? It is basically a guessing game, we see what works.

\section{QCD}

This section can also be followed from Peskin \cite[sec.\ II.11]{peskinConceptsElementaryParticle2019}.

This \(U(1)\) gauge symmetry is an abelian symmetry, but we also have non-abelian ones: we denote by \(T^{a}\) the generators of the group, their Lie algebra is defined by
%
\begin{align}
\qty[T^{a}, T^{b}] = if^{abc} T^{c}
\,.
\end{align}

The \emph{structure coefficients} \(f^{abc}\) are manifestly antisymmetric in their first two indices. It can also be shown that they are fully antisymmetric. If the group is abelian, we have \(f^{abc}\) identically, but this need not be the case.

To say that these are generators means that any infinitesimal transformation can be written as
%
\begin{align}
\Phi \to \qty(1 + i \alpha^{a} t^{a}_{R}) \Phi
\,,
\end{align}
%
where \(\alpha^{a}\) are the parameters of the infinitesimal transformation, while \(t^{a}_{R}\) are Hermitian matrices of dimension \(d_R\) which make up the representation of the group. There are \(d_G\) of them, where \(d_G\) is the dimension of the group.

The finite unitary transformation mapping \(\Phi \to U(\alpha ) \Phi \) can be recovered from here by
%
\begin{align}
U(\alpha ) = e^{i \alpha^{a} t^{a}_{R}}
\,.
\end{align}

We will be interested in Lie groups \(SU(n)\) with \(N\geq 2\), which are \(N \times N\) unitary matrices with determinant \(1\).

For example, recall that \(SU(2)\) has a 2-to-1 correspondence with \(SO(3)\). \(SU(2)\) describes the rotation of spinors, the generators of their rotation are \(\sigma^{i} / 2\).

Last time we discussed the annihilation  of \(e^{+} e^{-}\) into hadrons: we can get protons and neutrons, pions, kaons\dots

However we can simplify by discussing only the creation of quarks.

When we compute the cross sections, our calculation seems to be wrong by a factor 3. If we multiply it by 3 we get the correct result.
So there are three types of quarks: we categorize them by ``color'', even though it has nothing to do with colors.

We associated QED  with \(U(1)\): is there a group corresponding to Quantum Chromo Dynamics?
Can we do this with the weak interaction as well?

Since there are three quarks, we are drawn to represent them as triplets.
Since we know that unitary matrices are nice, we try \(SU(3)\).
We call this symmetry \(SU(3)_{\text{color}}\).

We start by giving some general results for \(N\)-dimensional groups \(SU(N)\): we normalize their representation by imposing
%
\begin{align}
\Tr \qty[t^{a}_{N} t^{b}_{N}] = \frac{1}{2} \delta^{ab}
\,,
\end{align}
%
where \(t^{a}_{N}\) are the Hermitian generators of an \(N\)-dimensional unitary representation. If we generalize to an \(R\)-dimensional representation, we will have
%
\begin{align}
\Tr \qty[t^{a}_{G} t^{b}_{G}] = C(R) \delta^{ab}
\,,
\end{align}
%
where \(C(R)\) is some constant depending only on the dimension of the representation.

A special representation we can choose is the \textbf{adjoint} representation, which is the one under which the generators of the Lie algebra transform; it is defined by:
%
\begin{align} \label{eq:adjoint-representation-definition}
\qty(t^{a}_{G})^{bc} \overset{\text{def}}{=} i f^{abc}
\,.
\end{align}

By making use of the Jacobi identities we can show that this is indeed a valid representation of the group, its dimension is that of the group and we have:
%
\begin{align}
\Tr \qty[t^{a}_{G} t^{b}_{G}] = f^{acd} f^{bcd} = C(G) \delta^{ab}
\,,
\end{align}
%
where the constant \(C(G)\) is just the dimension \(N\) for the adjoint representation.
For \(SU(N)\) the dimension is \(N^2 - 1\): the representation consists of \(N^2-1\) matrices, each \(N \times N\).

\subsection{Non-abelian gauge theory: Yang-Mills}

Consider the Lagrangian
%
\begin{align}
\mathscr{L} = \overline{\psi} i \gamma^{\mu } \partial_{\mu }  \psi
\,.
\end{align}

This can describe an electron. Now, let us add an index \(j\) in the group \(G\), according to which the particle transforms in the \(R\)-dimensional (in our case \(R=3\)) representation:
\begin{align}
\mathscr{L} = \overline{\psi}_{j} i \gamma^{\mu } \partial_{\mu } \psi_{j}
\,.
\end{align}

Under the local action of a group \(G\) the particle transforms like
%
\begin{align}
\psi_{j} (x) \overset{G}{\to}
\psi^{'}_{j} (x)
= \qty(1 + i \alpha^{a}(x) t^{a}_{R})_{jk} \psi_{k}
\,,
\end{align}
%
where \(a\) is an index going from 1 to \(N^2-1\).

We have the same problem we had with \(U(1)_{\text{em}}\): we need to cancel the term coming from the derivative of \(\alpha (x)\), with a one-index object.
The variation in the Lagrangian is
%
\begin{align}
\delta \mathscr{L} = \overline{\psi}_{j} i \gamma^{\mu } \qty(i \partial_{\mu } \alpha^{a} (x) t^{a}_{R, jk}) \psi_{k}
\,.
\end{align}

The solution is the same: we introduce a coupling to the derivative, which takes the form
%
\begin{align}
\DD_{\mu } \to \partial_{\mu } - i g A_{\mu }^{a} t^{a}_{R}
\,,
\end{align}
%
where \(g\) is the strength of the interaction, which is also written as \(g_{s}\) in the case of the strong force.
The index \(a\) goes from \(1\) to \(N^2-1 = 8\): we must introduce a vector field \(A\) for each \emph{generator} of the required symmetry.

The beautiful thing is the fact that starting only from the symmetry requirement we can get a full theory.

We now attribute actual \emph{existence} to these quantum fields: they are interaction bosons.
They must transform like
%
\begin{align}
A^{a}_{\mu }(x) &\to  A^{a}_{\mu } (x) + \frac{1}{g} \partial_{\mu } \alpha^{a} (x) + \overbrace{A^{b}_{\mu } f^{abc} \alpha^{c} (x)}^{\text{new nonabelian term}}
 \\
&=  A^{a}_{\mu } (x) + \frac{1}{g} \DD_{\mu } \alpha^{a}(x)
\,.
\end{align}

This is derived making use of the adjoint representation definition \eqref{eq:adjoint-representation-definition}: we are equating
%
\begin{align}
A^{b}_{\mu } f^{abc} \alpha^{c} &= -i A^{b}_{\mu } t^{b}_{R} \alpha^{a}  \\
A^{b}_{\mu } f^{abc} \alpha^{c} &= -i A^{b}_{\mu } (i f^{bca}) \alpha^{c} \\
A^{b}_{\mu } f^{abc} \alpha^{c} &= + A^{b}_{\mu } f^{abc} \alpha^{c}
\marginnote{We can do cyclic permutations of the indices of \(f^{abc}\).}
\,.
\end{align}

If we assign physical reality to these fields we must give them kinetic terms in the Lagrangian, which will then be
%
\boxalign{
\begin{align}
\mathscr{L} =
- \frac{1}{4} F^{\mu \nu a} F^{a}_{\mu \nu } + \overline{\psi}
\qty(i \gamma^{\mu } \DD_{\mu }-m) \psi
\,,
\end{align}}
%
which looks the same as the QED Lagrangian, but we must be careful: what is \(F_{\mu \nu }^{a}\)?
We might think it is
%
\begin{align}
F^{a}_{\mu \nu } = 2 \partial_{[\mu } A^{a}_{\nu ]}
\,,
\end{align}
%
but this is not enough: inside the covariant derivative in \(\DD_{\mu } \alpha \) in the transformation law we also have \(A_{\mu }\), so we get an additional term, and the final formula looks like
%
\begin{align}
F^{a}_{\mu \nu } = 2 \partial_{[\mu } A^{a}_{\nu ]} + g f^{abc} A^{b}_{\mu } A^{c}_{\nu }
\,.
\end{align}

This corresponds to the fact that, while there is no photon-photon interaction since \(U(1)\) is abelian,  \(SU(3)\) is not: so, we do have gluon-gluon interaction.
Notice that this expression has abelian symmetries as a special case: the term \(fAA\) is antisymmetric in the two bosons, so if they commute it vanishes.
The square of this field strength is then both Lorentz and gauge invariant.

This field strength can be interpreted as the Riemann tensor of the Lie group manifold:
%
\begin{align}
\qty[\DD_\mu , \DD_\nu] = -ig F^{a}_{\mu \nu } t^{a}_{R}
\,.
\end{align}

This is crucial in very high energy situations, such as in the early universe. The dynamics of the field are now more complicated than the ones we find in electrodynamics due to the nonlinear terms.

The wavefunction \(\psi\) which appears in the Lagrangian will transform in some \(d\)-di\-men\-sio\-nal representation of \(G = SU(3)_c\).
It will have indices like \(\psi_{\alpha , i}\): \(\alpha \) is a four-dimensional spinorial index, while \(i\) is a three-dimensional color index.

The strong-interaction coupling constant \(g_s \) is dimensionless, we also define the parameter
%
\begin{align}
\alpha_{s} = \frac{g_s^2}{4 \pi }
\,.
\end{align}

The coupling term of the gluons with the fields can be made explicit as
%
\begin{align}
\overline{\psi}_{\alpha, i} \gamma^{\mu }_{\alpha \beta } A^{a}_{\mu } \qty(t^{a})_{ij} \psi_{\beta, j}
\,,
\end{align}
%
where \(\mu \) is a Lorentz index, \(i\) and \(j\) are color indices, while \(\alpha \) and \(\beta \) are spinorial indices.

\end{document}


\section{Method}
\label{sec:method}

In this section we describe how we calculate full 3D velocities for stars in
the Kepler field.
Around 1 in 3 Kepler targets have an RV from either Gaia, LAMOST, or APOGEE.
For these \nrv\ stars we calculated 3D velocities using the {\tt coordinates}
library of {\tt astropy} \citep{astropy2013, astropy2018}.
This library performs a series of matrix rotations and translations to convert
stellar positions and velocities in equatorial
% , or International Celestial Reference System (ICRS)
coordinates into positions and velocities in Galactocentric coordinates.
It converts positions, proper motions, parallaxes/distances, and RVs into \x,
\y, \z, \vx, \vy, \vz.
We adopted a Solar position of $r_\odot = 8.122$ kpc \citep{gravity2018} and
$z_\odot = 20.8$ pc \citep{bennet2019}, and a Solar velocity of $v\odot =
(12.9, 245.6, 7.78)$ \kms \citep{drimmel2018}.
For stars {\it without} RVs, we inferred their velocities by marginalizing
over their RVs using the method described below.

% It has been demonstrated that the dispersion in vertical velocity, \vz, of a
% population of stars increases with the age of that population,
% \citep[\eg][]{stromberg1946, wielen1977, nordstrom2004, holmberg2007,
% holmberg2009, aumer2009, casagrande2011, ting2019, yu2018}.
% Most AVRs are calibrated using velocities in Galactocentric coordinates, \vx,
% \vy\ and \vz, which can only be calculated with full 6-D position and velocity
% information, \ie\ proper motions, position and radial velocity.
% In \citet{angus2020} we explored rotational evolution using velocity
% dispersion as an age proxy, however we used velocity in the direction of
% Galactic latitude, \vb, instead of \vz.
% This is because \vb\ can be calculated without an RV measurement but is a
% close approximation to \vz\ for \kepler\ stars due to the orientation of the
% Kepler field.
% The \kepler\ field lies at low Galactic latitudes, ($\sim 5-20$\degrees), so
% the ${\bf z}$-direction is similar to the ${\bf b}$-direction for \kepler\
% stars.
% However, even at such low latitudes, kinematic ages calculated with \vb\
% instead of \vz\ are likely to be systematically larger because of mixing
% between \vz, \vx\ and \vy.
% A direct measurement or precise estimate of \vz\ is necessary to calculate
% accurate kinematic ages.

\subsection{Inferring 3D velocities (marginalizing over missing RV
measurements)}
\label{sec:inference}

% Three-dimensional velocities in galactocentric coordinates: \vx, \vy, and \vz\
% can only be directly computed via a transformation from 3D velocities in
% another coordinate system, like the equatorial coordinates provided by \gaia:
% \mura, \mudec, and RV.
% For stars with no measured RV in \gaia\ DR2, \vx, vy, and \vz\ can still be
% inferred from positions and proper motions alone, by marginalizing over
% missing RV measurements.
For each star in our sample without an RV measurement, we inferred \vx, \vy,
and \vz\ from the 3D positions -- RA (\ra), dec (\dec), and parallax
(\parallax), and 2D proper motions (\mura\ and \mudec) provided in the \gaia\
EDR3 catalog \citep{gaia_edr3}.
We also simultaneously inferred distance (instead of using inverse-parallax)
to model velocities \citep[see \eg][]{bailer-jones2015, bailer-jones2018}.

Using Bayes rule, the posterior probability of the velocity parameters given
the Gaia data can be written:
\begin{equation}
    p({\bf v_{xyz}}, D | \mu_{\alpha}, \mu_{\delta}, \alpha, \delta, \pi) =
    p(\mu_{\alpha}, \mu_{\delta}, \alpha, \delta, \pi | {\bf v_{xyz}}, D)
    p({\bf v_{xyz}}) p(D),
\end{equation}
where $D$ is distance and ${\bf v_{xyz}}$ is the 3D vector of velocities.
To evaluate the likelihood function, our model predicts observable data from
model parameters, \ie\ it converts \vx, \vy\, \vz\ and $D$ to \pmra, \pmdec\
and \parallax.
In the first step of the model evaluation, cartesian coordinates, \x, \y, and
\z\, are calculated from \ra, \dec, and $D$ by applying a series of matrix
rotations, and a translation to account for the Solar position.
The cartesian Galactocentric velocity parameters, \vx, \vy, and \vz, are then
converted to equatorial coordinates, \pmra\ and \pmdec\ via another rotation.
The posterior PDFs of the parameters \vx, \vy, \vz, and $\ln(D)$ are sampled
by evaluating this model over a range of parameter values which are chosen by
via the No U-Turns Sampler (NUTS) algorithm in {\tt PyMC3}.
At each set of model parameters the likelihood is calculated via a Gaussian
likelihood function, and multiplied by a prior (described below) to produce
the posterior probability: the probability of those model parameters given the
data.

For computational efficiency, we used {\tt PyMC3} to sample the posterior PDFs
of stellar velocities \citep{pymc3}.
This required that we rewrite the {\tt astropy} coordinate transformation code
using {\tt numpy} and {\tt Theano} \citep{numpy, theano}.
The series of rotations and translations required to convert from equatorial
to Galactocentric coordinates is described in the astropy
documentation\footnote{
    https://docs.astropy.org/en/stable/coordinates/galactocentric.html }
\citep{astropy2018}.
For each star in the \kepler\ field, we explored the posteriors of the four
parameters, \vx, \vy, \vz, and $\ln(D)$ using the {\it PyMC3} No U-Turn
Sampler (NUTS) algorithm, and the {\tt exoplanet} \python\ library
\citep{exoplanet}.
We tuned the {\it PyMC3} sampler for 1500 steps, with a target acceptance
fraction of 0.9, then ran four chains of 1000 steps for a total of 4000 steps.
This resulted in a $\hat{r}$-statistic (the ratio of intra-chain to
inter-chain variance) of around unity, indicating convergence.
Using PyMC3 made this inference procedure exceptionally fast -- taking just a
few seconds per star on a laptop.

\subsection{The prior}
\label{sec:prior}

As mentioned previously, the positioning of the \kepler\ field at low Galactic
latitude allows \vz\ to be well-constrained from proper motion measurements
alone.
This also happens to be the case for \vx, because the direction of the
\kepler\ field is almost aligned with the \y-axis of the Galactocentric
coordinate system and is almost perpendicular to both the \x\ and \z-axes (see
figure \ref{fig:kepler_field}).
For this reason, the \y-direction is similar to the radial direction for
observers near the Sun, so \vy\ will be poorly constrained for \kepler\ stars
without RV measurements.
On the other hand, \vx\ and \vz\ are almost perpendicular to the radial
direction and can be precisely inferred with proper motions alone.
\begin{figure}[ht!]
\caption{
\x, \y\ and \z\ positions of stars observed by \kepler, showing the
    orientation of the \kepler\ field.
The Sun's position is indicated with a Solar symbol.
The direction of the field is almost aligned with the \y-axis and almost
    perpendicular to the \x\ and \z-axes, which is why \vx\ and \vz\ can be
    tightly constrained for \kepler\ stars without RVs, but \vy\ cannot.
}
  \centering
    \includegraphics[width=.7\textwidth]{kepler_field}
\label{fig:kepler_field}
\end{figure}

We constructed a multivariate Gaussian prior PDF over distance and 3D velocity
using the Kepler targets {\it which have RV measurements}.
We calculated the means and covariances of the \vx, \vy, \vz\ and $\ln(D)$
distributions of stars with measured RVs and then used these means and
covariances to construct a multivariate Gaussian prior over the velocity and
distance parameters for stars {\it without} RVs.
Velocity and distance outliers greater than 3-$\sigma$ were removed before
calculating the means and covariances of the distributions.
The distance and velocity distributions of Kepler targets with RVs are
displayed in figure \ref{fig:prior_distributions_2D}.
These are the distributions we used to construct the prior.
The 1- and 2-$\sigma$ contours of the multivariate Gaussian prior is shown in
each panel in red.
This figure shows that Gaussian functions only approximately reproduce
the true velocity distributions, and do not capture the substructure.
We could have chosen a more complex prior that would fit these data better,
for example, a mixture of Gaussians, which would capture the moving groups in
the Solar neighborhood.
This may result in slightly more accurate inferred velocities.
However, since our goal is kinematic age dating, we only need to resolve the
vertical velocity component to a sufficient precision that will accurately
allow for calculations of vertical velocity dispersions, so the minor gain in
precision will not have a large affect on the end results.
In addition, since this prior is constructed using stars with RVs, which may
have a slightly different velocity distribution to stars without RVs, we opted
for the more uninformative, simple Gaussian prior.

\begin{figure}[ht!]
\caption{
The velocity and distance distributions for stars with RV measurements,
    used to construct a multivariate Gaussian prior over velocity and
    distance parameters for stars {\it without} RVs.
The 1- and 2-D distributions of the data are shown in black and the prior is
    indicated in red.
}
  \centering
    \includegraphics[width=.8\textwidth]{prior_distributions_2D}
\label{fig:prior_distributions_2D}
\end{figure}

Our goal was to infer the velocities of stars {\it without} RV measurements
using a prior calculated from stars {\it with} RV measurements.
However, stars with and without RVs are likely to be quite different
populations, determined by the Gaia, LAMOST and APOGEE selection functions.
In particular, stars without RV measurements are more likely to be fainter,
less luminous, cooler and potentially older.
Figure \ref{fig:CMD} shows the populations of stars with and without RVs on
the CMD -- stars with RVs are more likely to be upper-main-sequence and red
giant stars, and stars without RVs are more likely to be mid and lower
main-sequence dwarfs.
% Lower-mass stars are, on average, older, and have larger velocity dispersions,
% plus stars in different locations in the Galaxy have different orbital
% velocities.
For this reason, a prior based on the velocity distributions of stars {\it
with} RVs will not necessarily reflect the velocities of those without.
We could have opted to construct a prior that depends on CMD position,
however, in practice, this would require making a number of arbitrary choices,
so we instead opted for a simpler approach.
In addition, we find that the \vx\ and \vz\ velocities we infer are not
strongly influenced by the prior, as described below.
% However, given that \vx\ and \vz\ are strongly informed by proper motion
% measurements, and therefore likely to be relatively prior-insensitive, the
% prior may not significantly impact our final vertical velocities.

We tested the influence of the prior on the velocities we inferred.
One of the main features of the RV selection functions is brightness: Gaia DR2
RVs are only available for stars brighter than around 14th magnitude, and
LAMOST DR5 and APOGEE DR16 RVs for stars brighter than around 16th magnitude.
For this reason, we tested priors based on stellar populations with different
apparent magnitudes.
Three priors were tested: one calculated from the velocity distributions of
the brightest half of the RV sample (\gaia\ $G$-band apparent magnitude $<$
13), one from the faintest half ($G$ $>$ 13), and one from {\it all} stars
with RVs.
Figure \ref{fig:prior_distributions} shows the distributions of the faint
(blue) and bright (orange) halves of the RV sample as kernel density estimates
(KDEs).
The distributions are different because bright stars are typically more
massive, younger, more evolved, and/or closer to the Sun on average than faint
stars.
As a result, these stars occupy slightly different Galactic orbits.
The multivariate Gaussian, fit to these distributions, which was used as a
prior PDF, is shown as single-dimension projections in figure
\ref{fig:prior_distributions}.
The Gaussian fit to the bright and faint star distributions are shown as
dashed orange and blue lines, respectively.
The Gaussian fit to {\it all} the data, both bright and faint, is shown as a
black solid line.
The means of the faint and bright distributions differ by 6 \kms, 5 \kms, 1
\kms\ and 0.21 kpc, for \vx\, \vy, \vz\ and $\ln(D)$, respectively.
The \vx, \vy, and distance distributions of the bright stars are slightly
non-Gaussian -- more so than the faint stars.
This highlights the inadequacy of using a Gaussian distribution as the prior
-- a Gaussian is only an approximation of the underlying distribution of stars
in our sample.
As a result of this approximation, inferred velocities that are strongly
prior-dependent -- (\ie\ especially those in the \y-direction) may inherit
some inaccuracies from the Gaussian prior, which is not a perfect
representation of the underlying data.
However, given that the populations of stars with and without RV measurements
are different, it may be inappropriate to use a more complex, more
informative prior anyway.

\begin{figure}[ht!]
\caption{
    Velocity and distance distributions of faint (blue) and bright (orange)
    stars with RVs, shown as KDEs.
    Gaussian fits to these distributions are shown as dashed lines in
    corresponding colors.
    The solid black line shows the Gaussian fit to all data (bright and faint
    combined) and is the prior we ended up using in our model.
    This figure highlights the differences between the velocities and
    distances of bright and faint stars (with RVs) in our sample.
}
  \centering
    \includegraphics[width=1\textwidth]{prior_distributions}
\label{fig:prior_distributions}
\end{figure}
We inferred the velocities of 1000 stars chosen at random from the
RV Kepler sample using each of these three priors and compared the
inferred velocity distributions.
If the inferred velocities were highly prior-dependent, the resulting
distributions, obtained from different priors, would look very different.
The results of this test are shown in figure \ref{fig:prior_comparison}.
From left to right, the three panels show the distributions of inferred \vx,
\vy, \vz, and log-distance.
The blue dashed line shows a KDE representing the distributions of velocities
inferred using the prior calculated from the faint half of the RV sample.
Similarly, the solid orange line shows the distribution of inferred velocities
using the prior calculated from the bright half of the RV sample, and the
solid black line shows the results of the prior calculated from {\it all}
stars with measured RVs.
In all but the \vy\ panel (second from the left), the blue, orange,
and black lines lie on top of each other, indicating that different priors do
not significantly influence the resulting velocities.

The median values of the \vy\ distributions resulting from the faint and
bright priors differ by around 4 \kms.
This is similar to the difference in means of the faint and bright populations
(5 \kms, as quoted above).
The inferred \vx\ and \vz\ distributions differ by 2 \kms\ and 0.3 \kms,
respectively.
Regardless of the prior choice, the \vx\ and \vz\ distributions are similar
because velocities in the \x\ and \z-directions are not strongly prior
dependent: they are tightly constrained with proper motion measurements alone.
However, the distribution of inferred \vy\ velocities {\it does} depend on the
prior.
This is because the \y-direction is close to the radial direction for \kepler\
stars (see figure \ref{fig:kepler_field}), and \vy\ cannot be tightly
constrained without an RV measurement.
The distributions of stellar distances are almost identical, irrespective of
the prior.
This is because distance is very tightly constrained by Gaia parallax and is
relatively insensitive to the prior.
% It is therefore highly dependent on the prior.
\begin{figure}[ht!]
\caption{
The distributions of velocity and distance parameters, inferred using three
    different priors.
The orange line is a KDE that represents the distribution of parameters
    inferred with a Gaussian prior, estimated from the bright half of the RV
    sample ($G < $ 13).
The blue dashed line shows the results from a prior estimated from the faint
    half of the RV sample ($G > 13$)).
The black line shows the results from a prior calculated from all stars with
    RV measurements and is the prior we adopt in our final analysis.
    This figure shows that all parameters except \vy\ are relatively
    insensitive to the three priors that were tested.
    }
  \centering
    \includegraphics[width=1\textwidth]{prior_comparison}
\label{fig:prior_comparison}
\end{figure}

% Fainter stars have smaller y-velocities than brighter stars because they are,
% on average, further from the Sun

Although this test was performed on stars with RV measurements, which are
brighter overall than the sample of stars without RVs (\eg\ figure
\ref{fig:rv_histogram}), figure \ref{fig:prior_comparison} nevertheless
indicates that \vx\ and \vz\ are not strongly prior-dependent.
Since this work is chiefly motivated by kinematic age-dating, which mostly
requires vertical velocities (\vz), we are satisfied with these results.
% The difference in the dispersions of \vz\ velocities, calculated with the
% three different priors tested above was smaller than 0.5 \kms.
We conclude that the \vx\ and \vz\ velocities we infer are relatively
insensitive to prior choice, and we adopt a prior calculated from the
distributions of all stars with RV measurements (black Gaussians in figure
\ref{fig:prior_distributions}).
The \vy\ velocities are more strongly prior dependent and should be used with
caution.

{\bf
A better prior for the velocity distribution would be a phase-space
distribution function that takes into account asymmetric drift and other
nontrivial aspects of the local velocity distribution.
However, priors of this form would require a model for the phase-space
distribution function, $f(x,y,z,v_x,v_y,v_z)$, which would require a
hierarchical model that takes into account covariances between the spatial and
kinematic properties of stars \citep[\eg][]{trick2016, hagen2019,
anguiano2020}.
We consider this to be outside of the scope of this work, and instead argue
that our assumed isotropic velocity prior is a conservative choice because it
does not impose any covariant structure between velocity components or
dependencies on Galactic position.
However, in general, to extend this Kepler-field-specific analysis to other
populations of stars in different parts of the Galaxy, alternative priors will
have to be constructed.
We leave this for a future exercise.
}

Figure \ref{fig:posterior} shows the posterior PDF over velocity and distance
parameters for a randomly selected Kepler target with an RV measurement, KIC
\kicstar.
The blue lines in each panel indicate star's velocities, directly calculated
using the RV measurement, and the distributions indicate the probability
density of the parameters inferred {\it without} the RV measurement.
The velocity parameters are correlated because the lack of RV introduces a
slight degeneracy: the star's proper motion can be equally well described with
a range of different velocities.
The star's posterior PDF is particularly elongated in \vy, which is the
velocity most similar to RV.
The star's distance is not tightly correlated with its velocity parameters
because it is precisely determined by parallax.
\begin{figure}[ht!]
\caption{
The posterior PDF over parameters \vx, \vy, \vz\ and $\ln$(distance) for a
    Kepler target chosen at random: KIC \kicstar.
    {\bf
    Blue lines show the location of the star's `true' parameters, based on a
    calculation that includes the RV measurement.
    }
This figure shows that the velocity parameters are correlated and the star's
    posterior is elongated in \vy.
    }
  \centering
    \includegraphics[width=.7\textwidth]{posterior}
\label{fig:posterior}
\end{figure}


\documentclass[letter,12pt]{article}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%	\usepackage{graphicx}
%	\usepackage{amsmath}
%	\usepackage{array}
%	\usepackage{amssymb}
%	\usepackage{setspace}
%	%\usepackage[margin=1.5cm,vmargin={0pt,1cm},nohead]{geometry}
%	\usepackage[margin=1in,vmargin={1in,1in}]{geometry}
%	% Package that has the symbol for ``:=''
%	\usepackage{txfonts}
%	% Create fancy headers and footers for this document
%	\usepackage{fancyhdr}
%	%\usepackage{cite}
%	% The ``cite'' package causes the hyperlinks for the in-text references/citations to fail. I believe it is because this package overrides the default package for referencing. Hence, only use the ``cite'' package with the IEEE format.
%	% Package for ``turnstile'' binary relations, where letters are defined above and below symbols
%	\usepackage{turnstile}
%	\usepackage{extarrows}
%	% Package that provides the cross symbol
%	\usepackage{ifsym}
%	\usepackage{marvosym}
%	% Commands for using the package for hyperlinks -
%	\usepackage[pdftex,
%		pdftitle={Graphics and Color with LaTeX},
%		pdfauthor={Patrick W Daly},
%		pdfsubject={Importing images and use of color in LaTeX},
%		pdfkeywords={LaTeX, graphics, color},
%		pdfpagemode=UseOutlines,bookmarks, bookmarksopen,
%		pdfstartview=FitH, colorlinks, linkcolor=blue, citecolor=blue, urlcolor=red,
%	]{hyperref}
%	\hypersetup{colorlinks, linkcolor=blue}
%	% Concatenate references
%	\usepackage{cite}

%	% Package for tyepsetting algorithms and heuristics
%	\usepackage{listings}
%	\lstset{language=[GNU]C++}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%	Additional packages
\input{/data/others/grappanotes/others/preamble}
%	AMS theorem package
\usepackage{amsthm}

% definition of new \LaTeX command for the citation: \cite{Cimatti08} and \cite{Barrett09}
% This allows mathematical/logic symbols to be typeset with the font ``Zapf Chancery'' in ``\LaTeX\ math mode''. To typeset symbols in such font, try: \mathpzc{ABCdef123}
\DeclareMathAlphabet{\mathpzc}{OT1}{pzc}{m}{it}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Start of document
\begin{document}
\title{Scribed Notes for Week 2: September 17, 2013}
\date{\today}
\author{Zhiyang Ong
	\thanks{Email correspondence to: \href{mailto:ongz@acm.org}{ongz@acm.org}}
}
\maketitle

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Declaration}
\label{sec:declaration}

I did this assignment on my own without any collaborators. The mathematical programming package that I have used is \cite{Makhorin2012}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Finding the Perfect Diet}
\label{sec:findingperfectdiet}

Q1.1) and Q1.2): See printouts. \\

Q1.3) The minimal cost from CPLEX is 92.5, and the minimal cost from GLPK is about 80.69. Since GLPK yields a lower cost that CPLEX, it gives a better solution to the linear programming problem.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Finding the Optimal Volume Mix of Two Types of Liquid}
\label{sec:optimalliquidmix}

Q2.1) Mathematical formulation for finding the optimal volume mix of two types of liquid. \\

Let $x_{1}$ and $x_{2}$ represent the volume of liquid types 1 and 2 in cm$^{3}$. \\

Objective function:

maximize $F(x) = \$2/{\rm cm}^{3} \times x_{1} + \$3/{\rm cm}^{3} \times x_{2} $ \\

Decision variables:

$\underline{x}_{\varepsilon} s$ \\

Subject to these constraints:

$x_{1} + x_{2} \leq 2000 $ (since 2 $l = 2000$ cm$^{3}$)

$1 g/cm^{3} \times x_{1} + 2 g/cm^{3} \times x_{2} \leq 3000 $ (since 3 kg $ = 3000$ g)

$x_{1} \geq 0$

$x_{2} \geq 0$
\ \\
\ \\
Here, I define density $\rho$ = $\frac{{\rm mass}\ m}{{\rm volume}\ v}$. \\

$\therefore m = \frac{\rho}{v}$

Q2.2) See printout.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Nonlinear Programming}
\label{sec:nonlinearprogramming}

Q3) Attachment

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Traveling Salesperson Problem}
\label{sec:tspquestion}

%For the asymmetric traveling salesperson problem (TSP), the distance, $d$, between any pair of cities $i$ and $j$ is not equivalent. That is, $d(i,j) \neq d(j,i)$).

%The number of tours for asymmetric TSP is: $(n-1)!$ \cite[\S6.1.1, pp. 224]{Punnen2007}. Therefore, the cardinality for $N_{2}(t)$ is: $\frac{1}{2}(n-2)!$ % $\frac{1}{2}(n-2)!$

Q4.1) The cardinality for $N_{2}(t)$ is: n. \\
\ \\
Q4.2) $N_{2}(t) = \{ t: t \in T \& t can be obtained by removing 2 edges from the tour and then replacing them with 2 edges \}$

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{\linespread{1}
\bibliographystyle{plain}
\bibliography{/data/research/antipastobibtex/references}
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}


% !TeX spellcheck = <none>
\documentclass[./\jobname.tex]{subfiles}

\begin{document}
\definecolor{light-gray}{gray}{0.9}

\chapter{Task Description}

This project is about constructing and building a 3-axis robot. The robot is equipped with two cameras and a red laser-pointer. The user can take a green laser-pointer to direct the robot into a different position. In order to avoid permanent sight-damage, the robot should avoid shining the laser into faces of surrounding humans. The following list contains the main working steps:

\begin{itemize}
	\item design and construct the 3-axis robot
	\item manufacture and assemble the robot parts
	\item develop the backwards kinematic
	\item implement the backwards kinematic in C and compile to DLL
	\item find green laser point in 3D stereo image with OpenCV in Python
	\item drive the red laser point of the robot to the green laser point of the human
	\item planned but optional:
	\begin{itemize}
		\item plan path from current position to green laser position
		\item implement controller to correct deviance between red and green laser point
		\item avoid human faces along the way
	\end{itemize}

\end{itemize}

\chapter{Design}

The robot consists of 3 Dynamixel MX-64AT motors, 2 Microsoft HD 3000 lifecam and a laser module DB635-1-3-FA(14x45)-ADJ from Picotronic. Aluminium frames are attached to the motors to build the framework of the robot. The cameras and laser-pointer are connected with aluminium brackets to the robot. The design of the robot and its components is established with SolidWords. The whole robot is mounted on aluminium profiles to improve the handling and to store of the electrical hardware. Beside the cables, a power supply for the motors and laser pointer, an emergency stop button and communication components for the motors are required. The cameras are directly connected to the laptop or computer via the USB ports. This means that the laptop requires 3 USB sockets. A connection via a USB-Hub failed as the OpenCV library could not find the cameras. \\
The table \ref{tab:camera_before_after} shows how the cameras were modified in order to properly attach them to the robot tool. \\
The table \ref{tab:3d_rander} displays a 3D render of the completely assembled robot.\\
Finally, the finished robot can be seen in figure \ref{fig:final_assemgly}

\begin{table}[H]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\begin{tabular}{c c}
			\includegraphics[width=0.6\textwidth]{img/foto/camera_with_stand.jpg}
			\includegraphics[width=0.49\textwidth]{img/foto/camera_without_stand.jpg}
		\end{tabular}
	}
	\unterschrift{comparison of the cameras before and after modification}{}{}
	\label{tab:camera_before_after}
\end{table}

\begin{table}[H]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\begin{tabular}{c c}
			\includegraphics[width=0.75\textwidth]{../img/pdf/robot_3d_side.pdf}
			\includegraphics[width=1\textwidth]{../img/pdf/robot_3d_front.pdf}
		\end{tabular}
	}
	\unterschrift{3D render of the assembled robot in SolidWorks}{}{}
	\label{tab:3d_rander}
\end{table}

\begin{figure}[H]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\includegraphics[width=0.8\textwidth]{img/foto/final_robot_photo.jpg}
	}
	\unterschrift{final assembly of the robot}{}{}
	\label{fig:final_assemgly}
\end{figure}

\chapter{Calculation}
This chapter describes the mathematical formulations that are needed to control the robot. This includes the backwards kinematics as well as the formulas for setting $\theta_{0,1,2}$.

\section{Backwards Kinematic}

The following figure \ref{fig:robot_coord} shows the coordinate systems that are used to get the link parameters shown in table \ref{tab:link_params} below. The link parameters are established using the Deviant Hartenberg convention mentioned in \cite[p. 70- 79]{Craig2018}.

With the knowledge of the link parameters, the transformation matrices are generated in the next step. The full matrix can be seen in equation \ref{eq:transformationmatrix}

\begin{figure}[H]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\includegraphics[width=0.4\textwidth]{img/pdf/robot_axis_coord.pdf}
	}
	\unterschrift{robot axis coordinate systems used to calculate the link parameters}{}{}
	\label{fig:robot_coord}
\end{figure}

\begin{table}[H]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\begin{tabular}{|c|c|c|c|c|}
			\hline
			$i$ & $\alpha_{i-1}$ & $a_{i-1}$ & $d_i$ & $\theta_{i-1}$\\
			\hline
			1 & 0 & 0 & 100 & $\theta_0$\\
			2 & -90 & 50 & 0 & $\theta_1 - 90$\\
			3 & 0 & 100 & 0 & $\theta_2 + 180$\\
			F & 90 & 0 & 68 & $0$ \\
			\hline
		\end{tabular}
	}
	\unterschrift{table of link parameters}{}{}
	\label{tab:link_params}
\end{table}

\begin{equation}
\label{eq:transformationmatrix}
\begin{split}
& T =  \\
& \begin{bmatrix}
-c0c1s2 -c0c2s1 & -s0 & c0c1c2 - c0s1s2 & a2c0 + dF (c0c1c2 - c0s1s2) + a3c0s1 \\
-c1s0s2 -c2s0s1 &  c0 & c1c2s0 - s0s1s2 & a2s0 + dF (c1c2s0 - s0s1s2) + a3s0s1 \\
s1s2 - c1c2     &   0 & -c1s2 - c2s1 & d1 + a3c1 + dF(-c1s2 - c2s1) \\
0               &   0 & 0 & 1 \\
\end{bmatrix}\\
\end{split}
\end{equation}

\subsection{Implementation}
For controlling the robot, several functions are written in C and compiled to a DLL. The functions are built on the Dynamixel library \cite{Robotis2019}. The DLL provides the following methods:
\begin{itemize}
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|int robot_start();|} \\
	Sets up the communication with the robot by returning the port number. This number must be provided in every other function. Further this function sets up the main parameters of every motor like the velocity limits.
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|void robot_stop(int port_num);|} \\
	Stops the robot by driving to the home position and freeing the device with the port number.
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|void robot_home(int port_num);|} \\
	Separate function for driving the robot to the home position.
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|int robot_drive(float z, float alpha, float beta, int port_num);|} \\
	Tells the robot to drive to a specific position specified by $\alpha$, $\beta$ and z. The motion towards this position is not planned.
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|int robot_reached_target(float z, float alpha, float beta, \ \ \ \ \ int port_num);|} \\
	This function checks if the robot is at the specified $\alpha$, $\beta$ and z position and returns 1 if it reached the target (otherwise 0).
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|void robot_set_theta(float theta0, float theta1, float theta2, \ \ \ \ \ int port_num);|} \\
	Instead of specifying a global position, this function allows to set the axis angle $\theta$ by its own.
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|float robot_get_theta0(int port_num);|} \\
	Returns the angle $\theta_0$ that the robot is at that time.
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|float robot_get_theta1(int port_num);|} \\
	Returns the angle $\theta_1$ that the robot is at that time.
	\item \colorbox{light-gray}{\lstinline[basicstyle=\ttfamily\color{black}]|float robot_get_theta2(int port_num);|} \\
	Returns the angle $\theta_2$ that the robot is at that time.
\end{itemize}
The functions \textit{robot\textunderscore drive} as well as the function \textit{robot\textunderscore set\textunderscore theta} are non-blocking. This means that the function returns, before the robot reached the target. Blocking functions can be easily created outside the DLL by simply polling the functions \textit{robot\textunderscore reached\textunderscore target} or \textit{robot\textunderscore get\textunderscore theta}.

\section{Goal Robot Configuration}
\label{sec:calc_robot_config}

The laser point on the wall can be described by only to 2 DOF, vertical and horizontal coordinates. To track the laser point, the robot has to change 2 DOF likewise. Even though the robot has 3 rotation axis, it only satisfy 2 DOF, because $theta_1$ and $theta_2$ directly depend to each other. Therefore, one of these angles can be set to any arbitrary angle. In this case $theta_1$ is constantly set to 0°. With the 2 cameras and the knowledge of the transformation matrices of the robot, the vertical and horizontal coordinates of the laser point are received and transformed into 3D coordinates of the robot base coordinate system.

As a result, the rotation angle of the motors can be calculated. $\theta_0$ is a simple geometric problem and can be easily calculated with trigonometric functions (see figure \ref{fig:3d_point_base}). The equation \ref{eq:theta_2} for $\theta_2$ is slightly more advanced. Additionally, the length and height of the robot components have to be taken in consideration.

\begin{figure}[H]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\includegraphics[width=0.8\textwidth]{img/pdf/robot_3d_point_base.pdf}
	}
	\unterschrift{camera calibration app flowchart}{}{}
	\label{fig:3d_point_base}
\end{figure}

\begin{equation}
\label{eq:theta_0}
\theta_0 = arctan \left( \frac{Y_0}{X_0} \right)
\end{equation}

\begin{equation}
\label{eq:theta_2}
\theta_2 = -1 \cdot arctan \left( \frac{ Z_0 - 100 - 100 cos(\theta_1)}{\sqrt{X_{0}^{2} + Y_{0}^{2}} - 50 - 100 sin(\theta_1)} \right)
\end{equation}

\chapter{Stereo Vision}

The idea of this project is to drive directly to the correct point, without using a closed loop controller of any sort. This is done by measuring the 3D point with a stereo camera and calculating back to the desired robot configuration (as shown in \ref{sec:calc_robot_config}). In order to measure the correct point, the cameras need to be calibrated. Further, a reliable method for finding the laser-point is needed. All vision related tasks are done with \cite{2014opencv}

\section{Camera Calibration}
At first a camera calibration application is written, that allows to take images, calculate the two single camera matrices and estimates the translation and rotation between the two cameras. The flowchart in figure \ref{fig:cam_cal_app_flowchart} shows the main outline of the camera calibration app.

Three quality measures are deployed to verify that the matrices are correct:
\begin{itemize}
	\item measuring a known 3D structure with the calibrated stereo camera tool
	\item using the same pictures of the chessboard in MATLAB and comparing the calculated matrices
	\item plausibility check for the translation vector and the rotation matrix between the cameras
\end{itemize}

Besides the camera calibration towards each other, the main camera (left) must also be calibrated to the TCP. This is called the hand-eye calibration. The following matrix \ref{eq:HE} shows the hand-eye calibration. Although there are more complex methods to generate this transformation matrix, it can also be measured from the real tool. The figure \ref{fig:hand_eye_coord} shows the rotation between the TCP coordinate system and the camera coordinate system.

\begin{equation}
\label{eq:HE}
HE =
\begin{bmatrix}
0.0  & 1.0 & 0.0 & -28.5 \\
-1.0 & 0.0 & 0.0 & 45.0 \\
0.0  & 0.0 & 1.0 & 28.0 \\
0.0  & 0.0 & 0.0 & 1.0 \\
\end{bmatrix}
\end{equation}

\begin{figure}[h]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\includegraphics[width=0.4\textwidth]{img/png/hand_eye_coord.png}
	}
	\unterschrift{hand-eye coordinate system transformation}{}{}
	\label{fig:hand_eye_coord}
\end{figure}

\begin{figure}[h]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\includegraphics[width=0.6\textwidth]{img/pdf/camera_calibration_app_flowchart.pdf}
	}
	\unterschrift{camera calibration app flowchart}{}{}
	\label{fig:cam_cal_app_flowchart}
\end{figure}

\section{Laser Point Detection}
The second part is about detecting the laser point in an image. To make the task simpler, the laser point may only be projected onto a white flip board chart. \\
Two methods for detecting the laser point are tested.

\subsection{Method 1: HSV Threshold}
As lasers are monochromatic one could think about looking for a certain colour. The idea is to define a threshold in HSV-colour space and only look at the pixels that are within this band. By applying a dilation function to the binary image, the weakly connected pixels are morphed together and form blobs. Then the function \textit{findCountours} is deployed to detect the connected areas of white pixels. Finally, the first (biggest) area contour is taken and the centre of mass is calculated. This is the 2D point in one image. \\
This method did not work very well. Some problems have been identified:
\begin{itemize}
	\item Taking the biggest area is not very sensible. More constraints could be helpful like: size threshold, convexity or previous point.
	\item As the automatic mode of the camera is not deactivated the colour of the laser point might change with different lighting scenarios.
	\item The definition of the colour threshold is not trivial: Either too many pixels or too few are taken. Especially with a colourful surrounding this trade-off is hard to control.
\end{itemize}

\subsection{Method 2: Template Matching}

The second method uses template matching to find the green laser point. The process outline as follows: a template slides over the image and at every pixel they are compared. The comparison results a scalar value which are then stacked together to create something like a `heat-map'. The larger the scalar is at an index, the better is the correspondence between the image and the template. \\
There are many different methods for comparing two images defined in OpenCV. The utilize method was found to work best for this sort of object detection. The formula is shown in equation \ref{eq:template_matching}. \\
The templates are created before every run. In order to make that process as user-friendly as possible, a GUI based configuration app is created. The templates can be seen in the table \ref{tab:laser_template_comp}. \\
The main characteristics of this method are:
\begin{itemize}
	\item This method works much better with different lighting scenarios than the HSV-threshold.
	\item Motion blurring results in an unstable detection of the laser point. Thus, fast movements with the robot and by hand should be avoided.
	\item Whenever there is no green laser point in the image, the red laser is detected as green, since this is now the best match.
	\item This method only works with the background (e.g. white flip board) specified in the template.
\end{itemize}

\begin{equation}
R(x,y) = \frac{\sum_{x',y'} (T'(x',y') \cdot I'(x + x', y + y'))}{\sqrt{\sum_{x',y'} T'(x',y')^{2} \cdot \sum_{x',y'} I'(x + x', y + y')^{2}}}
\label{eq:template_matching}
\end{equation}

\begin{table}[h]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\begin{tabular}{c c}
			\includegraphics[width=0.295\textwidth]{img/png/green_laser_template.png}
			\includegraphics[width=0.3\textwidth]{img/png/red_laser_template.png}
		\end{tabular}
	}
	\unterschrift{laser point template as created by the configuration app}{}{}
	\label{tab:laser_template_comp}
\end{table}

\chapter{Main App}
This chapter describes the algorithmic steps taken in the main application as seen in the flowchart \ref{fig:main_app_flowchart}. The action \textit{transform 3D point to robot base} consists of multiple steps itself:

\begin{itemize}
	\item Multiply the 3D point with the hand-eye calibration to transform the point into the TCP frame, as seen in \ref{eq:HE}
	\item Transform the point to the robot base coordinate system by multiplying with the backwards kinematic in \ref{eq:transformationmatrix}.
\end{itemize}

\begin{figure}[h]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\includegraphics[width=0.5\textwidth]{img/pdf/main_app_flowchart.pdf}
	}
	\unterschrift{camera calibration app flowchart}{}{}
	\label{fig:main_app_flowchart}
\end{figure}

\chapter{Conclusion}

We find, that template matching method is better suited to detect small objects in a constantly changing image rather than searching the images for a specific colour.

The resting distance between green and red laser point, as seen in figure \ref{fig:resting_offset} results from the offset of the laser pointer to the robot tool centre. That can be easily adjusted with a new bracket. To avoid any systematic errors, the laser pointer has to be mounted colinear with the z-axis of the robot tool.

Another current problem is the high energy consumption of the laser pointer. Within a half an hour, the intensity of the laser pointer dropped significantly. In the next step, a more appropriate power supply should be installed.

An additional option could be to specify $theta_1$ as a variable instead of a constant and find a more advanced system of equations.

\begin{figure}[H]
	\centering
	\noindent\adjustbox{max width=\linewidth}{
		\includegraphics[width=0.5\textwidth]{img/foto/resting_ofset.png}
	}
	\unterschrift{resting offset between laser points}{}{}
	\label{fig:resting_offset}
\end{figure}

\end{document}


\chapter{Hyperparameters}
\label{chap:hyperparameters}

Here I present the hyperparameters used for experiments in the following chapter. I run a rough hyperparameter search to use reasonably good enough parameters, and the algorithm does not diverge. As the goal of this thesis is to evaluate the execution time of the algorithm rather than its quality or performance, these parameters may not be optimal for the given problem at hand. I recommend the available literature for a more appropriate hyperparameter selection.

\begin{table}[ht]
    \centering
    \begin{tabular}{|l|c|}
        \hline
        \textbf{Parameter} & \textbf{Value} \\
        \hline
        Selection & Tournament \\
        \quad Number of parents & $2$ \\
        Crossover & Uniform \\
        \quad Probability to inherit gene from 1st parent & $40\%$ \\
        \quad Offspring & $80\%$ \\
        \hline
        Replace mutation & \\
        \quad Mutation rate & $20\%$ \\
        \quad Position clipping & no \\
        Normal mutation & \\
        \quad Mutation rate & $20\%$ \\
        \quad Standard deviation & $0.005$ \\
        \quad Position clipping & no \\
        Cauchy mutation & \\
        \quad Mutation rate & $20\%$ \\
        \quad Scale & $0.003$ \\
        \quad Position clipping & yes \\
        Adaptive step mutation & \\
        \quad Starting deviation & $0.01$ \\
        \quad Deviation increase & $1.3$ \\
        \quad Deviation decrease & $0.2$ \\
        \quad Fraction of better to increase deviation & $30\%$ \\
        \quad Minimum deviation & $0.00001$ \\
        \quad Maximum deviation & $1.0$ \\
        \quad Position clipping & no \\
        \hline
    \end{tabular}
    \caption{Hyperparameters of mutation experiments}
    \label{tab:esmutationhyperparmarameters}
\end{table}

\begin{table}[ht]
    \centering
    \begin{tabular}{|l|c|}
        \hline
        \textbf{Parameter} & \textbf{Value} \\
        \hline
        Selection & Tournament \\
        \quad Number of parents & $2$ \\
        Crossover & One--point \\
        \quad Mutated individuals & $40\%$ \\
        Mutation & Bit--Flip \\
        \quad Mutated individuals & $60\%$ \\
        \quad Mutation probability & $0.1\%$ \\
        \hline
    \end{tabular}
    \caption{\acrlong*{acc:ga} hyperparameters}
    \label{tab:gahyperparameters}
\end{table}

\begin{table}[ht]
    \centering
    \begin{tabular}{|l|c|}
        \hline
        \textbf{Parameter} & \textbf{Value} \\
        \hline
        Selection & Tournament \\
        \quad Number of parents & $2$ \\
        Mutation & Normal \\
        \quad Mutation rate & $20\%$ \\
        \quad Standard deviation & $0.005$ \\
        \hline
        Uniform crossover & \\
        \quad Offspring & $80\%$ \\
        \quad Probability to inherit gene from 1st parent & $40\%$ \\
        One--point crossover & \\
        \quad Offsprign & $80\%$ \\
        Two--point crossover & \\
        \quad Offsprign & $80\%$ \\
        Arithmetic crossover & \\
        \quad Offsprign & $40\%$ \\
        Blend crossover & \\
        \quad Offsprign & $70\%$ \\
        \quad $\alpha$ & $0.5$ \\
        \hline
    \end{tabular}
    \caption{Hyperparameters of crossover experiments}
    \label{tab:escrossoverhyperparmarameters}
\end{table}

\begin{table}[ht]
    \centering
    \begin{tabular}{|l|c|}
        \hline
        \textbf{Parameter} & \textbf{Value} \\
        \hline
        Selection & Tournament \\
        \quad Number of parents & $2$ \\
        Crossover & Uniform \\
        \quad Probability to inherit gene from 1st parent & $40\%$ \\
        Mutation & Normal \\
        \quad Mutation rate & $20\%$ \\
        \quad Standard deviation & $0.005$ \\
        \hline
        Standard mutation & \\
        \quad Offspring & $80\%$ \\
        Plus schema & \\
        \quad Offspring & $150\%$ \\
        Comma schema & \\
        \quad Offspring & $200\%$ \\
        \hline
    \end{tabular}
    \caption{Hyperparameters of crossover schemes experiments}
    \label{tab:esschemehyperparmarameters}
\end{table}

\begin{table}[ht]
    \centering
    \begin{tabular}{|l r|c|}
        \hline
        \multicolumn{2}{|l|}{\textbf{Parameter}} & \textbf{Value} \\
        \hline
        Cognitive acceleration coefficient & $c_l$ & 1.5 \\
        Social acceleration coefficient  & $c_g$ & 1.5 \\
        Inertia weight & $\omega$ & 0.8 \\
        Velocity clip value & & 2 \\
        \hline \hline
        \textbf{Neighborhood} & & \textbf{Relative size} \\
        \hline
        Circle & & 0.26 \\
        Grid & & \\
        \quad Linear & & 0.02 \\
        \quad Compact & & 0.05 \\
        \quad Diamond & & 0.06 \\
        Nearest neighbors & & 0.13 \\
        Random & & \\
        \quad PSO2006 & & 0.13 \\
        \quad PSO2011 & & 0.2 \\
        \hline
    \end{tabular}
    \caption{\acrlong*{acc:pso} hyperparameters}
    \label{tab:psohyperparameters}
\end{table}


\documentclass{article}

\usepackage[T1]{fontenc}
\usepackage[osf]{libertine}
\usepackage[scaled=0.8]{beramono}
\usepackage[margin=1.5in]{geometry}
\usepackage{url}
\usepackage{booktabs}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{nicefrac}
\usepackage{microtype}
\usepackage{subcaption}
\usepackage{bm}

\usepackage{amsthm}
\newtheorem{defn}{Definition}

\usepackage{sectsty}
\sectionfont{\large}
\subsectionfont{\normalsize}

\usepackage{titlesec}
\titlespacing{\section}{0pt}{10pt plus 2pt minus 2pt}{0pt plus 2pt minus 0pt}
\titlespacing{\subsection}{0pt}{5pt plus 2pt minus 2pt}{0pt plus 2pt minus 0pt}

\usepackage{pgfplots}
\pgfplotsset{
  compat=newest,
  plot coordinates/math parser=false,
  tick label style={font=\footnotesize, /pgf/number format/fixed},
  label style={font=\small},
  legend style={font=\small},
  every axis/.append style={
    tick align=outside,
    clip mode=individual,
    scaled ticks=false,
    thick,
    tick style={semithick, black}
  }
}

\pgfkeys{/pgf/number format/.cd, set thousands separator={\,}}

\usepgfplotslibrary{external}
\tikzexternalize[prefix=tikz/]

\newlength\figurewidth
\newlength\figureheight

\setlength{\figurewidth}{12cm}
\setlength{\figureheight}{6cm}

\newlength\squarefigurewidth
\newlength\squarefigureheight

\setlength{\squarefigurewidth}{4cm}
\setlength{\squarefigureheight}{4cm}

\newlength\smallsquarefigurewidth
\newlength\smallsquarefigureheight

\setlength{\smallsquarefigurewidth}{3.25cm}
\setlength{\smallsquarefigureheight}{3.25cm}

\newlength\smallfigurewidth
\newlength\smallfigureheight

\setlength{\smallfigurewidth}{6.25cm}
\setlength{\smallfigureheight}{4cm}

\setlength{\parindent}{0pt}
\setlength{\parskip}{1ex}

\newcommand{\acro}[1]{\textsc{\MakeLowercase{#1}}}
\newcommand{\given}{\mid}
\newcommand{\mc}[1]{\mathcal{#1}}
\newcommand{\data}{\mc{D}}
\newcommand{\intd}[1]{\,\mathrm{d}{#1}}
\newcommand{\inv}{^{-1}}
\newcommand{\trans}{^\top}
\newcommand{\mat}[1]{\bm{\mathrm{#1}}}
\renewcommand{\vec}[1]{\bm{\mathrm{#1}}}
\newcommand{\R}{\mathbb{R}}
\renewcommand{\epsilon}{\varepsilon}
\newcommand{\Exp}{\mathbb{E}}

\DeclareMathOperator{\var}{var}
\DeclareMathOperator{\cov}{cov}
\DeclareMathOperator{\diag}{diag}
\DeclareMathOperator*{\argmin}{arg\,min}
\DeclareMathOperator*{\argmax}{arg\,max}

\begin{document}

\section*{Gaussian Process Classification}

Just as we could use the kernel trick to extend Bayesian linear
regression to Gaussian processes for general-purpose nonlinear
regression, we may also extend Bayesian linear classification in the
same way.  In Gaussian process classification, we assume there is a
latent function $f\colon \mc{X} \to \R$ that is commensurate with the
probability of a positive observation; higher latent function values
correspond to higher probabilities of positive observations.  In
Bayesian linear classification, we assumed a parametric (linear) form
for this latent function:
\[
  f(\vec{x}) = \vec{x}\trans \vec{w}.
\]
In Gaussian process classification, rather than choosing a parametric
form for $f$, we instead place a Gaussian process prior on $f$:
\[
  p(f) = \mc{GP}(f; \mu, K).
\]
Note that a Gaussian prior on the weight vector $\vec{w}$ above
induces a Gaussian process prior on $f$ with mean function
\[
  \mu(\vec{x}) = \vec{x}\trans \vec{\mu}
\]
and covariance function
\[
  K(\vec{x}, \vec{x}') = \vec{x}\trans \mat{\Sigma} \vec{x},
\]
where $p(\vec{w}) = \mc{N}(\vec{w}; \vec{\mu}, \mat{\Sigma})$. The
Gaussian process formalism allows us to model arbitrary nonlinear
classification boundaries by using any desired mean and covariance
function for $f$.

\subsection*{Likelihood}

Suppose we have made binary observations at a set of values $\mat{X}$,
and define $\vec{f} = f(\mat{X})$ to be the associated set of latent
function values.  As in Bayesian linear classification, we assume
the following likelihood for a given binary observation $y_i$
associated with $\vec{x}_i$:
\[
  p(y_i = 1 \given f_i)
  =
  \sigma(f_i),
\]
where $\sigma\colon \R \to (0, 1)$ is a monotonically increasing
sigmoid function such as the logisitic function or the standard normal
\acro{CDF}.  We again assume the observations are conditionally
independent given the latent function values:
\[
  p(\vec{y} \given \vec{f})
  =
  \prod p(y_i \given f_i).
\]

\subsection*{Inference}

Given our prior $p(f) = \mc{GP}(f; \mu, K)$ and a set of observations
$\data = (\mat{X}, \vec{y})$, we wish to find the posterior
distribution of the latent function values $\vec{f} = f(\mat{X})$.
Note that if we had a Gaussian posterior $\vec{f}$, this would induce
a Gaussian process posterior for the function $f$ given $\data$.
The posterior is
\[
  p(\vec{f} \given \data)
  =
  \frac{1}{Z}
  p(\vec{f} \given \mat{X})
  p(\vec{y} \given \vec{f})
  =
  \mc{N}\bigl(\vec{f}; \mu(\mat{X}), K(\mat{X}, \mat{X})\bigr)
  \prod_i p(y_i \given f_i).
\]
Unfortunately, the sigmoid likelihood coupled with the Gaussian prior
do not couple to form a tractable posterior.  Instead, we must
approximate this posterior in some way.  Previously we described the
Laplace approximation, which approximates the unnormalized log
posterior with a second-order Taylor expansion, resulting in a
Gaussian approximate posterior centered at the posterior mode
\[
  \hat{\vec{f}} = \argmax_{\vec{f}} p(\vec{f} \given \data).
\]

Here we will consider two more general-purpose approximation
techniques for approximating intractable posterior distributions.
These techniques are useful when the likelihood factorizes into
one-dimensional terms, as in \acro{GP} classification.

\section*{Assumed Density Filtering}

Consider a posterior distribution of the form
\[
  p(\vec{\theta} \given \data)
  =
  \frac{1}{Z}
  p_0(\vec{\theta})
  \prod_{i = 1}^N
  t_i(\vec{\theta}),
\]
where the $t_i$ are typically likelihood terms, for example our $p(y_i
\given f_i)$ above.  We assume the prior $p_0(\vec{\theta})$ has been
chosen to be some nice form, for example a Gaussian, and we will use
the Gaussian case to illustrate the idea below.

In \emph{assumed density filtering} (\acro{ADF}), we assume that the
posterior has the same form as the prior $p_0$, and we seek an
approximating distribution
\[
  q(\vec{\theta}) \approx p(\vec{\theta} \given \data)
\]
from the same family as $p_0$ that approximates the true posterior
``as well as possible.''

Mechanically, ensuring that our approximate distribution $q$ remains
in the same family as $p_0$ is achieved by selecting an (unnormalized)
member $\tilde{t}_i$ from the likelihood conjugate to the prior for
each of the likelihood terms $t_i$.  The result is
\[
  q(\vec{\theta})
  =
  p_0(\vec{\theta})
  \prod_{i = 1}^N \tilde{Z}_i \tilde{t}_i(\vec{\theta}; \tilde{\vec{\theta}}_i),
\]
and this product will belong to the desired family by conjugacy.  Here
the constants $\tilde{Z}_i$ and the local parameter vectors
$\{\tilde{\vec{\theta}}_i\}$ are free parameters, called \emph{site
  parameters}, we may choose for each of the approximating
distributions $\tilde{t}_i$ to try to improve the fit of the
approximating distribution.

For example, the Gaussian distribution is self-conjugate, so the
\acro{ADF} approximation will in this case take the form
\[
  q(\vec{\theta})
  =
  p_0(\vec{\theta})
  \prod_{i=1}^N t_i(\vec{\theta})
  \approx
  \mc{N}(\vec{\theta}; \vec{\mu}, \mat{\Sigma})
  \prod_{i=1}^N
  \tilde{Z}_i
  \mc{N}(\vec{\theta}; \tilde{\vec{\mu}}_i, \tilde{\mat{\Sigma}}_i),
\]
where the site parameters are the constants $\{\tilde{Z}_i\}$ (chosen
so that the approximation normalizes) as well as the local mean
vectors $\{\tilde{\vec{\mu}}_i\}$ and covariance matrices
$\tilde{\mat{\Sigma}}_i$.

Note that in the \acro{GP} classification case, the likelihood terms
in the product are in fact one dimensional, because the likelihood for
$y_i$ only depends on $f_i$:
\[
  q(\vec{f})
  =
  \mc{N}(\vec{f}; \vec{\mu}, \mat{\Sigma})
  \prod_{i=1}^N
  \tilde{Z}_i
  \mc{N}(f_i; \tilde{\mu}_i, \tilde{\sigma}^2_i).
\]

Consider just the first two terms in this product:
\[
  p(\vec{\theta} \given \data_1)
  \propto
  p_0(\vec{\theta})
  t_1(\vec{\theta}).
\]
This product will not have the same nice form of the prior, but has
only been warped ``slightly'' away from the prior via a single
likelihood term.  In many cases, this distribution will be at least
partially manageable.  Perhaps there will not be a nice closed
expression, but we might still be able to compute the normalizing
constant or the moments of the posterior.

In assumed density filtering, we will approximate this product with a
member of the desired family:
\[
  q_1(\vec{\theta})
  =
  \tilde{Z}_1
  p_0(\vec{\theta})
  \tilde{t}_1(\vec{\theta}; \tilde{\vec{\theta}}_1)
  \approx
  p(\vec{\theta} \given \data_1)
  \propto
  p_0(\vec{\theta})
  t_1(\vec{\theta}).
\]
This approximation is done by matching the moments between the
approximation $q_1(\vec{\theta})$ and the true posterior
$p(\vec{\theta} \given \data_1)$.

For example, consider $p_0(\vec{\theta}) = \mc{N}(\vec{\theta};
\vec{\mu}, \mat{\Sigma})$.  We select the site parameters
\[
  \tilde{Z}_1^{-1}
  \qquad
  \tilde{\vec{\mu}}_1 \qquad
  \tilde{\mat{\Sigma}}_1
\]
such that
\begin{align*}
  \int q_1(\vec{\theta}) \intd{\vec{\theta}} &= 1 \\
  \mathbb{E}\bigl[q_1(\vec{\theta})\bigr] &= \mspace{14.5mu} \mathbb{E}\bigl[ p(\vec{\theta} \given \data_1) \bigr] \\
  \cov\bigl[q_1(\vec{\theta})\bigr] &= \cov\bigl[ p(\vec{\theta} \given \data_1) \bigr].
\end{align*}
Now the approximate distribution is in the desired density family
(Gaussians) and matches the true posterior up to the second moment.

Now consider the first three terms of the product:
\[
  p(\vec{\theta} \given \data_1, \data_2)
  \propto
  p_0(\vec{\theta})
  t_1(\vec{\theta})
  t_2(\vec{\theta})
  \propto
  p(\vec{\theta} \given \data_1)
  t_2(\vec{\theta}).
\]
The idea in assumed density filtering is to substitute in our
approximation $q_1(\vec{\theta})$, giving:
\[
  p(\vec{\theta} \given \data_1, \data_2)
  \stackrel{\propto}{\sim}
  q_1(\vec{\theta})
  t_2(\vec{\theta}).
\]
Now we are in the same situation we were in before!  We have a nice
``prior'' distribution $q_1$ multiplied by a single likelihood term
$t_2$.  We proceed as before, replacing the true likelihood term $t_2$
with an approximate (conjugate) term $\tilde{Z}_2
\tilde{t}_2(\vec{\theta}; \tilde{\vec{\theta}}_2)$, where we again
choose the site parameters $(\tilde{Z}_2, \tilde{\vec{\theta}}_2)$ to
match the moments between our new approximation
\[
  q_2(\vec{\theta})
  =
  \tilde{Z}_2
  q_1(\vec{\theta})
  \tilde{t}_2(\vec{\theta}; \tilde{\vec{\theta}}_2)
  =
  \tilde{Z}_1
  \tilde{Z}_2
  p_0(\vec{\theta})
  \tilde{t}_1(\vec{\theta}; \tilde{\vec{\theta}}_1)
  \tilde{t}_2(\vec{\theta}; \tilde{\vec{\theta}}_2).
\]
and the ``less-approximate'' posterior
$q_1(\vec{\theta})t_2(\vec{\theta})$.  We proceed in this fashion
until we have processed all the local likelihood terms, resulting
in the final approximation
\[
  q(\vec{\theta})
  =
  p_0(\vec{\theta})
  \prod_{i = 1}^N \tilde{Z}_i \tilde{t}_i(\vec{\theta}; \tilde{\vec{\theta}}_i).
\]

\section*{Expectation Propagation}

One thing to note about assumed density filtering is that our final
approximation is dependent on the sequence in which we process the
likelihood terms $\{t_i\}$.  Note that we are always matching the
moments between
\[
  q_{i-1}(\vec{\theta})t_i(\vec{\theta}),
\]
the approximation using data up to the $i$th term as well as the true
$i$th likelihood term, and the new approximation
\[
  q_i(\vec{\theta})
  =
  \tilde{Z}_i
  q_{i-1}(\vec\theta)
  \tilde{t}_i(\vec{\theta}; \tilde{\vec{\theta}}_i).
\]
This moment matching at time $i$ therefore never considers data that
appears in future terms.  For this reason, we might accumulate errors
and/or wish to later ``revisit'' a particular term and update the site
parameters $(\tilde{Z}_i, \tilde{\vec{\theta}}_i)$ in light of future
data.  This idea leads to \emph{expectation propagation,} a refinement
of assumed density filtering that can address some of these issues.

The idea is simple.  Once we have processed each of the likelihood
terms, resulting in the approximation above
\[
  q(\vec{\theta})
  =
  p_0(\vec{\theta})
  \prod_{i = 1}^N \tilde{Z}_i \tilde{t}_i(\vec{\theta}; \tilde{\vec{\theta}}_i),
\]
we repeatedly revisit each term and update its site parameters.  The
mechanism for doing so is quite simple.  First, we select a site $1
\leq i \leq N$ to update, then form the so-called \emph{cavity
  distribution,} which is our approximation using all but the $i$th
term in the product:
\[
  q_{-i}(\vec{\theta})
  =
  p_0(\vec{\theta})
  \prod_{j \neq i} \tilde{Z}_j \tilde{t}_j(\vec{\theta}; \tilde{\vec{\theta}}_j),
\]
where we have divided by the old site term $\tilde{Z}_i
\tilde{t}_i(\vec{\theta}; \tilde{\vec{\theta}}_i)$.  Now we replace
the removed site term with the true likelihood term $t_i$, forming the
\emph{tilted distribution}
\[
  q_{-i}(\vec{\theta})
  t_i(\vec{\theta}).
\]
Finally, we select new site parameters to (re)match the moments
between the tilted distribution and our new approximation:
\[
  q_{\text{new}}(\vec{\theta})
  =
  \tilde{Z}_i
  q_{-i}(\vec{\theta})
  \tilde{t}_i(\vec{\theta}; \tilde{\vec{\theta}}_i).
\]
We proceed continually updating site parameters in this manner until
we reach convergence (i.e., none of the site parameters changes very
much) or we expend a chosen computational budget.

\subsection*{Theoretical motivation}

We conclude with one brief note about the theoretical motivation
behind the moment matching used in assumed density filtering and
expectation propagation.  The Kullback--Leibler (\acro{KL}) divergence
(also called \emph{relative entropy}) is a notion of ``distance''
between probability distributions, defined by
\[
d_{\text{\acro{KL}}}\bigl(p(\vec{\theta}) \parallel q(\vec{\theta})\bigr)
  =
  \int
  p(\vec{\theta})
  \log
  \frac{p(\vec{\theta})}{q(\vec{\theta})}
  \intd{\vec{\theta}}.
\]
Notice that \acro{KL} divergence is not a true distance, as it is not
symmetric, but it does satisfy $d_{\text{\acro{KL}}}(p \parallel q)
\geq 0$ with $d_{\text{\acro{KL}}}(p \parallel q) = 0$ if and only if
$p(\vec{\theta}) = q(\vec{\theta})$ almost everywhere.

A well-known result is that the \acro{KL} divergence between an
arbitrary probability distribution $p(\vec{\theta})$ and a
multivariate Gaussian distribution $q(\vec{\theta})$ (in the direction
$d_{\text{\acro{KL}}}(p \parallel q)$) is minimized when $q$ is chosen
to match the moments of $p$.  Therefore, in the case of Gaussian
approximations, these methods can be seen as iteratively building up
an approximate posterior in the desired family by minimizing the
\acro{KL} divergence at every step.

Minimizing \acro{KL} divergence in ``the other direction,''
$d_{\text{\acro{KL}}}(q \parallel p)$, gives rise to another family of
approximation techniques known as \emph{variational Bayesian
  inference.}

\end{document}