\section{Conclusions and Future Work}
In this paper we proposed the first compilation of MAPF under the sum-of-costs assumption to ASP. We proposed a number of variants of the approach. In its first, basic form, the encoding is quadratic on the number of agents, just like existing approaches to ASP (e.g. \nbcite{ErdemKOS13}; \nbcite{GebserKKS14}), and like the encoding of MDD-SAT \cite{SurynekFSB16}, a state of the art SAT-based solver. We also propose an encoding that is linear on the number of agents, and show how we can benefit by running Dijkstra's algorithm during preprocessing time to generate a more compact encoding.

In our empirical evaluation on square grids, we observed that the linear encoding substantially outperforms the quadratic encoding. In general our approach outperforms the search-based and SAT-based state-of-the-art solvers we compared with as the number of agents increases. This suggests that ASP is a competitive approach for solving highly congested MAPF instances.

An important drawback of our approach, which only becomes apparent as larger grids are used, is grounding time. A potential (yet not elegant) line of improvement is to perform grounding manually.

Another potential line of future work is the integration of our approach to other algorithms like Windowed Hierarchical Cooperative A* \cite{Silver05}, since it is more efficient to generate shorter (though suboptimal) solutions on larger maps.


\subsubsection{\stid{3.06} PETSc-TAO} \label{subsubsect:petsc}
\paragraph{Overview}

Algebraic solvers (generally nonlinear solvers that use sparse linear solvers) and integrators form the
core computation of many numerical simulations. No scalable ``black box'' sparse solvers or integrators
work for all applications, nor are there single implementations that work well for all problem sizes.
Hence, algebraic solver and integrator packages provide a wide variety of algorithms and implementations
that can be customized for the application and range of problem sizes. PETSc/TAO~\cite{petsc:homepage,petsc-man}
is a widely used numerical library for the scalable solution of linear, nonlinear, and variational systems,
for integration of ODE/DAE systems and computation of their adjoints, and for numerical optimization.
This project focuses on three topics: (1) partially matrix-free scalable solvers to efficiently use
many-core and GPU-based systems; (2) reduced synchronization algorithms that can scale to larger
concurrency than solvers with synchronization points; and (3) performance and data structure
optimizations for all the core data structures to better utilize many-core and GPU-based
systems as well as provide scalability to the exascale systems.

The availability of systems with over 100 times the processing power of today's machines compels the utilization
of these systems not just for a single ``forward solve'' (as discussed above), but rather within a tight loop
of optimization, sensitivity analysis (SA), and uncertain quantification (UQ). This requires the implementation
of a new scalable library for managing a dynamic hierarchical collection of running scalable simulations, where
the simulations directly feed results into the optimization, SA, and UQ solvers.  This library, which we call
libEnsemble, directs the multiple concurrent ``function evaluations'' through the tight coupling and
feedback. This work consist of two parts: (1) the development of libEnsemble; and (2) the development
of application-relevant algorithms to utilize libEnsemble.

\paragraph{Key Challenges}

A key challenge for scaling the PETSc/TAO numerical libraries to Exascale systems is that traditional
``sparse-matrix-based'' techniques for linear, nonlinear, and ODE solvers, as well as optimization
algorithms, are memory-bandwidth limited.  Another difficulty is that any synchronizations
required across all compute units---for example, an inner product or a norm---can
dramatically affect the scaling of the solvers.  Another challenge is the need to
support the variety of accelerators that will be available on the exascale systems
and the programming models that application teams use for performance
portability.

Running an ensemble of simulations requires a coordination layer that handles load balancing and
allows the collection of running simulations to grow and shrink based on feedback. Thus, our
libEnsemble library must be able to dynamically start simulations with different parameters,
resume simulations to obtain more accurate results, prune running simulations that the solvers
determine can no longer provide useful information, monitor the progress of the simulations,
and stop failed or hung simulations, and collect data from the individual simulations both
while they are running and at the end.

\paragraph{Solution Strategy}

To address the scalability of the numerical libraries, we implemented new solvers and data
structures including: pipeline Krylov methods that delay the use of the results of inner
products and norms, allowing overlapping of the reductions and other computation; partially
matrix-free solvers using high-order methods that have high floating-point-to-memory-access
ratios and good potential to use many-core and GPU-based systems; and in-node optimizations
of sparse matrix-matrix products needed by algebraic multigrid to better utilize many-core
systems.

Our strategy for coordinating ensemble computations has been to develop libEnsemble
to satisfy our needs.  This library should not be confused with workflow-based
scripting systems; rather it is a library that, through the tight coupling and
feedback, directs the multiple concurrent ``function evaluations'' needed by
optimization, SA, and UQ solvers.

\paragraph{Accelerator Strategy}

Our overall strategy for accelerator support in PETSc/TAO is based on flexibility and a separation
of concerns by wrapping the data pointers from the user programming language and programming
model inside of PETSc Vector and Matrix vector objects.  This approach allows us to focus
our effort on the kernels, such as vector, matrix-vector, matrix-matrix, and other fused
computational kernels, while the developer can focus on their application.  We provide
multiple backends and support AMD, Intel, and NVIDIA accelerators.  Thus, we support
the tools that the application developers are using, while obtaining performance in
the numerical libraries and kernels.  The architecture can be found in
Figure~\ref{fig:petsc-tao-fig}.

\begin{figure}
\centering
\includegraphics[trim = 0in .2in 1.7in .2in, clip, width=0.9\textwidth]{projects/2.3.3-MathLibs/2.3.3.06-PETSc-TAO/petsc_arch}
\caption{The PETSc/TAO architecture enables users to utilize a variety of programming
models for GPUs independently of PETSc's internal programming model.}
\label{fig:petsc-tao-fig}
\end{figure}

\begin{figure}
\centering
\includegraphics[trim = 1in 3.6in 1in 2in, clip, width=0.9\textwidth]{projects/2.3.3-MathLibs/2.3.3.06-PETSc-TAO/petsc_perf}
\caption{Solve time for a 3D Laplacian with second-order elements.  Larger grids are generated by uniform refinement.  Runs are configured with six resource sets on each Summit node, each with one GPU and 4 MPI processes.}
\label{fig:petsc-tao-perf}
\end{figure}

Our primary performance portability layer is based on Kokkos and KokkosKernels, which supports
vector, matrix, and matrix-matrix operations.  We also have full support for a native CUDA
backend and partial support for a native HIP and OpenCL backends.  Figure~\ref{fig:petsc-tao-perf}
demonstrates performance portability via a scaling study with PETSc/TAO’s built-in algebraic multigrid
(AMG) solver, PCGAMG, using cuSPARSE and Kokkos (with KokkosKernels) back-ends on our most
mature device, CUDA, where we obtain competitive performance.  The slower performance of
KokkosKernels is due to computing a transpose for matrix transpose multiply, which is
not yet natively supported in KokkosKernels.

The PETSc/TAO library has been compiled for Spock and Crusher and preliminary results have
been obtained using the accelerators and performance optimizations are being made.

The libEnsemble tools are based on python and makes calls to user-defined functions.
The user-defined functions can use the accelerators on the compute nodes during their
evaluation.

\paragraph{Recent Progress}

In the past year, we have released PETSc/TAO 3.16 (available at \url{http://www.mcs.anl.gov/petsc}), which
features enhanced GPU support.  We have full support for a Kokkos plus KokkosKernels backend for
performance portability that includes vector, matrix, and matrix-matrix operations and full
support for a native CUDA backend.  We have partial support for a native HIP and OpenCL
backends.  We have been updating and profiling the GAMG solver, the native algebraic
multigrid solver in PETSc, to use the enhanced GPU support.  Numerical results on
this work is available in \cite{mills2021toward}.  We have also been updating
our scalable communication layers, PetscSF, which allows us to use GPU-aware
MPI, thus allowing direct communication of data between Summit GPUs, bypassing
the previously needed step of first copying the data to the CPU memory.  Numerical
results on this work is available in \cite{zhang2021petscsf}.

We have also released libEnsemble 0.7.2 (available at \url{https://github.com/Libensemble/libensemble}).
This release includes new generator functions and examples, improved testing across available platforms,
and a new tutorial.  A paper documenting libEnsemble and providing use cases is available
in \cite{hudson2021libensemble}.

\paragraph{Next Steps}

Our next efforts are:
\begin{enumerate}
  \item \textbf{Application readiness}:
  We will complete a status review of our applications for the early access hardware.  We will
  complete software quality initiatives related to the build system, architecture specific spack
  recipes, and spack smoke tests for build and accelerator usage validation.
  \item \textbf{PETSc/TAO + Kokkos + KokkosKernels release}:
  We will release a version of PETSc/TAO with full Kokkos and KokkosKernels integration.  We will
  provide a tutorial on these features, characterize the performance, and suggest optimizations
  and best practices.
  We will also make improvements to the PETSc/TAO GAMG solver and provide updated performance results.
  \item \textbf{libEnsemble + Balsam2 release}:
  We will release a version of libEnsemble with full Balsam2 support and updated API.
  We will follow continuous integration best practices and continue testing on pre-exascale DOE systems.
  \item \textbf{PETSc/TAO + Optimized communication layer release}:
  We will release a version of PETSc/TAO with an optimized communication layer for the early access systems.
  This version will include support for AMGx on NVIDEA GPUs and a batch LU factorization and solver.
  We will optimize some numerical methods (such as methods in DMNetwork and numerical optimization methods)
  to use the communication layer and better utilize the accelerators.
  We will provide initial benchmark results for GAMG and AMGx.
\end{enumerate}


\documentclass{llncs}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{comment}
\usepackage{hyperref}
\usepackage{longtable}
\usepackage{stmaryrd}
\newcommand{\interp}[1]{\llbracket #1 \rrbracket}
\newcommand{\maps}{\colon}
\renewcommand{\:}{\colon}
\newcommand{\FinSet}{\mathrm{FinSet}}
\newcommand{\Set}{\mathrm{Set}}
\newcommand{\Cat}{\mathrm{Cat}}
\newcommand{\Calc}{\mathrm{Calc}}
\newcommand{\Mon}{\mathrm{Mon}}
\newcommand{\BoolAlg}{\mathrm{BoolAlg}}
\renewcommand{\Form}{\mathrm{Form}}
\newcommand{\leftu}{\mathrm{left}}
\newcommand{\rightu}{\mathrm{right}}
\newcommand{\send}{\mathrm{send}}
\newcommand{\recv}{\mathrm{recv}}
\newcommand{\comm}{\mathrm{comm}}
\renewcommand{\quote}[1]{``#1"}
\newcommand{\deref}[1]{\mathrm{eval}(#1)}
\newcommand{\op}{\mathrm{op}}
\newcommand{\NN}{\mathbb{N}}
\newcommand{\pic}{$\pi$-calculus}

\makeatletter
\gdef\tshortstack{\@ifnextchar[\@tshortstack{\@tshortstack[c]}}
\gdef\@tshortstack[#1]{%
  \leavevmode
  \vtop\bgroup
    \baselineskip-\p@\lineskip 3\p@
    \let\mb@l\hss\let\mb@r\hss
    \expandafter\let\csname mb@#1\endcsname\relax
    \let\\\@stackcr
    \@ishortstack}
\makeatother

\title{Logic, resource, and reflection}
\author{
L.G. Meredith\inst{2}\\
\and
Michael Stay\inst{1}\\
}
\institute{
  {Pyrofex Corp.}\\
  \email{\fontsize{8}{8}\selectfont stay@pyrofex.net}\\
  \and
  {RChain Cooperative}\\
  \email{\fontsize{8}{8}\selectfont lgreg.meredith@rchain.coop}
}
\begin{document}
\maketitle
\begin{abstract}
\noindent
  We present an algorithm for deriving a spatial-behavioral type
  system and term assignment from a formal presentation of a
  interactive computational calculus. This turns out to identify a
  species of category which we offer an axiomatic characterization of
  interaction categories.
\end{abstract}

\section{Introduction and motivation}

In groundbreaking work, Abramsky, Gay, and Nagarajan put forward the
idea of interaction categories to give a categorical framework for
interactive models of computing. Indeed, interactive models of
computation are relatively new and offer distinct insights because
they include the computational environment as part of the
computation. Examples include the {\pic}, in fact, all the mobile
process calculi, as well as the lambda calculus. However, interaction
categories fail to say axiomatically what interaction is.

We put forward a simple, intuitive axiomatic characterization of
interaction and use this to derive not only a logic but a proof theory
and term assignment algorithm for all systems satisfying these
axioms. The resulting structure identifies a species of category and
we offer this as an axiomatic characterization of interaction
categories.

\subsection{Intuitions}

The key idea in this construction is to use both the evaluation
context of Meredith and Stay, and computational reflection, similar to
what is found in Meredith and Radestock, to build a proof theory with
a cut elimination that corresponds exactly with the notion of
computation embodied in any interactive rewrite system.

The requirement that the rewrite system is interactive means the left
hand side of every rewrite rule will necessarily be a term
constructor, say $\mathsf{K}$, taking at least two terms. That is, when
viewed as a piece of syntax it is at least a tuple of terms. Then, by
controlling evaluation with an evaluation context we can force a
distinction between a tensor and a cut, where the cut forms the redex
with an evaluation context supplied, and the tensor is denied the
evaluation context, effectively rendering it a data structure. Of
course, the data is inaccessible until there is a means to unpack it,
and a par term is constructed as the principal means to extract the
data from the tensor.

The use of the term constructor that forms a redex as a data structure
is the essential use of reflection. The lack of a reduction context
gives us the ability to suspend computation. Having suspended it, we
reify computation as data, and use par to unpack the data making up
the computation. Completing the circle, the tensor-par cut rule
constitutes the means to reflect computational data back into actual
computations.

It turns out that denying the evaluation context is not the only way
to suspend computation. We can also form contexts. In this case, we
only admit 1-holed contexts, ranged over by $\chi$. With contexts we can
define a notion of rely-guarantee, two notions actually (indicated by
the operations $(- \rhd -)$, and $(- \lhd -)$), as a redex term constructor
might not be commutative. .

\begin{eqnarray*}
\tau \rhd_{\mathsf{K}} \tau’ & \triangleq & \{ u \quad | \quad \exists t. u = \mathsf{!}\mathsf{K}[]r(t, []),\forall u’ : \tau. (\exists \rho : u@u’ \rightarrow v) \Rightarrow v:\tau’ \} \\
\tau’ \lhd_{\mathsf{K}} \tau & \triangleq & \{ t \quad | \quad \exists u. t = \mathsf{K}[]l([], u)\mathsf{!},\forall t’ : \tau. (\exists \rho: t@t’ \rightarrow v) \Rightarrow v : \tau’ \}
\end{eqnarray*}

In the sequel we drop the subscript on the triangles if it’s understood from
context. We use the notation $\chi @ t$ to mean the term formed by
substituting $t$ for hole in $\chi$. Thus, $\mathsf{K}(t, [])@u = \mathsf{K}(t, [])[u/[]] = \mathsf{K}(t,u)$ and similarly, $\mathsf{K}([], u)@t = \mathsf{K}([], u)[t/[]] = \mathsf{K}(t,u)$

To give some examples, the comm rule of rho-calculus is given by

\begin{equation*}
  \mathsf{for}( y \leftarrow x )P \quad | \quad x\mathsf{!}(Q) \rightarrow P\{ @Q/y \}
\end{equation*}

In this case K is parallel composition, and the revised, resource
constrained comm rule, looks like

\begin{equation*}
  R | \mathsf{for}( y \leftarrow x )P \quad | \quad x\mathsf{!}(Q) \rightarrow P\{ @Q/y \}
\end{equation*}

In the lambda calculus, $\beta$-reduction is given by

\begin{equation*}
  (\lambda x.M)N \rightarrow M\{ N/x \}
\end{equation*}

$\mathsf{K}$ is application, and the revised, resource constrained $\beta$-reduction is given by

\begin{equation*}
  R((\lambda x.M)N) \rightarrow M\{ N/x \}
\end{equation*}

In what follows we will focus on calculi that don’t employ binding
operators and so-called nominal phenomena. This is not to say that we
can’t handle nominal phenomena, just that the content is already
complex enough and we want to focus on the core ideas.

\subsection{Related work}

\section{Conclusion and future work}

\bibliographystyle{amsplain}
\bibliography{ladl}
\end{document}


\section{Techniques for Channel Sounding}
\label{sec_sounding_techniques}

Methods and systems for evaluating \ac{MU-MIMO} transmissions have evolved over the years as the \ac{WURC} platform matured as has our understanding of the logistical and signal processing complexities of large-scale \ac{MU-MIMO} beamforming on an \ac{SDR} platform.

In this section, we present the methods and systems used for the channel sounding experiments presented in this chapter, building from narrowband \ac{MU-MIMO} channel estimation for \textit{static} \acp{STA} all the way to a wideband, real-time channel sounding systems supporting completely \textit{mobile} \acp{STA}.

%\subsection{Mobile Signal Strength Mapping (Wardriving)}
%\label{sec_wardrive_technique}
	%
	%\rgnote{Hacked Atheros driver and frequency translation wardriving method: GPS puck and tagged packet receptions -- no channel estimates are available from the hardware, though}

%#################################################
\subsection{Static Single-Carrier Sounding}
\label{sec_static_miso_mubf}

	One of the primary reasons to develop the WARPLab platform integrations in Section~\ref{sec_warplab} was to be able to plan and execute multi-user channel sounding experiments with over-the-air multi-user beamforming in real-world scenarios.

	Consider a 4x2 system performing a downlink transmission where we wish to estimate the downlink beamformed \ac{SINR} from a 4-radio \ac{AP} to two \acp{STA}.
	Ideally, the linear pre-coder would eliminate interference from each spatial stream to each unintended receiver; however, we know that channel estimation errors and receiver spatial separation potentially increase the inter-user interference and would like to measure this effect in real environments.

	We employ a WARPLab-based MU-MIMO framework that is based on directly estimating the channel \ac{SINR} in its constituent terms and then computing the Shannon capacity to estimate the achievable rate of a transmission system.
	This is accomplished by a single-carrier measurement technique adapted from \cite{aryafar2010design} and shown in Fig.~\ref{fig_exTrans}.
	Here, the transmitter \ac{AP} beamforms sections of the transmission packet independently to accurately measure the SINR at the \acp{STA}.

\begin{figure}[ht]
\centering
  	\includegraphics[width=6in]{figs/exTrans}
   	\caption{Example RSSI Measurement used in achievable capacity calculation.
	\label{fig_exTrans}}
\end{figure}

	In the depicted 4x2 transmission example, the transmitter first sends an 802.11 \ac{STF} and \ac{LTF} preamble for gain control and timing synchronization (blue) and then performs a MU-MIMO transmission to both users (red).
	In the following two sections (green, purple), the transmitter sequentially zeroes out the data stream to each receiver individually in order to measure noise and interference at each receiver during the \ac{MU-MIMO} transmission.
	In the example 4x2 case, this becomes a single-user beamformed transmission, however in the 4x3 or 4x4 case, two or three receivers would be beamformed to during this measurement.

	Thus, the difference between the full MU-MIMO transmission containing both signal, noise, and interference at each receiver (red) and the transmission containing just interference and noise at the zeroed-out receiver (green or purple) is each transmitter's SINR.
	From there, we can compute aggregate Shannon Capacity as $C=log_2(1+\text{SINR})$.

	This method is quite effective to obtain an estimate for the multi-user interference in a downlink \ac{MU-MIMO} transmission, however it does have one drawback aside from the time required for cycling through different transmission modes.% and obtaining a statistically significant number of samples to estimate \ac{RSSI}.
	Since it directly measures channel noise power during a silent period, it is possible that the noise power estimation is amplified since it measures both channel noise and receiver noise simultaneously.
	Most of the time, the interference term will dominate noise floor in \ac{SINR} and this would not matter, but in highly-separable channels, it is possible that the channel noise will be smaller than the receiver thermal noise and this method will underestimate the channel quality.

%#################################################
\subsection{Static 802.11 Channel Sounding}
\label{sec_static_miso_chan_est}

	While the single-carrier system is useful for performing narrowband experiments, 802.11af is a wideband protocol utilizing channel bandwidths up to 32~MHz wide \cite{flores2013ieee80211af}.
	In addition, UHF channels have reported empirical indoor 0.9 coherence bandwidth between 6-16~MHz \cite{varela2001rms} and empirical outdoor urban/suburban 0.5 coherence bandwidth on the order of 0.5-2~MHz \cite{bajwa1985large}.
	Additional experimental results have indicated very small resolution channel estimation on the order of 19.5~kHz may be relevant for signal processing in \ac{TVWS} systems \cite{zhang2016watch}.
	All together, this means that we wish to obtain channel state information and perform beamforming at a small granularity across the wide 802.11af channel bandwidths to be sure to capture UHF channel dynamics.

	%Luckily, our implementation of a real-time 802.11af-like stack implements a real-time layer-2 wireless bridge utilizing an 802.11a/g AP and STA design with a completely open network stack.
	To perform wideband channel sounding to multiple user \acp{STA}, the real-time capabilities of the 802.11 reference design are leveraged to provide fine-grained continuous channel estimates from multiple transmitting antennas in order to directly measure the \ac{MU-MIMO} channel capacity instantaneously and over a long period of time.

	The legacy 802.11 design calculates and stores channel state information as required by its OFDM channel equalizers, however, this information is generally discarded after packet reception.
	The channel estimation extracted from each received 802.11 PLCP header \cite{std11ac} provides a complete \ac{CSI} estimation matrix that can be used as a single-antenna sounding event.
	We modify the physical layer of the WARP 802.11 Reference Design \cite{warp80211} to treat each of a series of transmitted PLCP headers as separate ``packets'' for the purpose of \ac{CSI} measurement from multiple transmitting antennas.

	Our custom sounding ``packet'' is a brief 802.11g-like signal containing PLCP header for packet detection, AGC convergence, and symbol timing extraction.
	The payload is just long enough to provide error detection bits and identifying information about the transmitter so that the transmitting antenna can be identified.
	Due to the small size of this sounding packet, it is not compliant with the requirement that 802.11 packets contain an 802.11 and link-layer header.
	Therefore, we modify the MAC software to pass all packets regardless of valid header or fields to the Ethernet interface for processing.

	\begin{figure}[htb]
\centering
  \includegraphics[width=2.7in]{figs/ryan_sounding_example}
    \caption{Short timing packets are sent from each of the \ac{WURC} array antennas in rapid succession consisting of an 802.11 PLCP preamble and a short, 14-byte payload.}\label{fig:sounding}
\end{figure}

	We construct this special sounding packet in MATLAB and preconfigure the \ac{WURC} array, running our WARPLab modification, to transmit these packets continuously staggered in time as shown in Figure \ref{fig:sounding}.
	Tests show that WARPLab continuous-transmit mode remains synchronous over long periods of time if the boards are clock synchronized.
	We provide sufficient spacing between sounding packets to allow the 802.11 PHY to process the previous packet and reset, and we find that the WARPLab buffer size of 32768 samples over 819.2~$\mu s$ is sufficient to capture channel variation even at higher frequencies.

We combine this structure with a set of multiple listening nodes that process these channel sounding packets and can then store them for later retrieval.
A ten-minute packet trace for a single antenna can run over 1 GB in size, so substantial buffering and disk I/O speed is required for the recording nodes.

%#################################################
\subsection{Static 802.11 MU-MIMO Beamforming}
\label{sec_static_beamforming}

	We wish to perform the same type of multi-user beamformed channel estimation as in Section~\ref{sec_static_miso_mubf}, except modified for wideband channel sounding.

	A fundamental tradeoff of \ac{SDR} equipment is that one generally sacrifices processing speed for the sake of flexibility, which becomes a problem when performing closed-loop beamforming operations where performance can be severely degraded by processing delays and transmission latency.
	For this reason, very few published papers have attempted to perform actual over-the-air beamformed transmissions, opting instead to post-process and \emph{estimate} beamforming performance from channels estimated in both uplink and downlink directions.

	Our approach to solving the processing delay in \ac{SDR} equipment is to take advantage of the higher coherence time of low-frequency channels and perform over-the-air experiments on selected UHF (470-698~MHz) channels, where the processing latency becomes much less significant.
	We will show in Chapter~\ref{sec_environment_chapter} that this approach is suitable to the longer channel coherence times and reduced sensitivity to user mobility.

	To this end, we implement a beamforming and channel-sounding framework based around the 802.11af WiFi standard, in order to compare against 2.4/5~GHz implementations of 802.11ac since the physical \ac{OFDM} layers of 802.11ac VHT 40~MHz and 802.11af TVHT 5~MHz are identical aside from the radio sampling rate \cite{std11af,std11ac} \cite{guerra2018toolbox}.

	Standards-compliant piloted phase correction is implemented to compensate for sample timing drift during the payload, necessary to yield accurate measurements of received \ac{EVM}.
	Two copies of the cyclicly-shifted L-STF provide ample time to account for AGC settling and the WARPLab trigger jitter.
	Timing recovery and carrier-frequency offset correction operates on the L-LTF field, while we utilize the TVHT-LTF symbols with the 802.11af spatial spreading matrix for channel estimation.

%\rgnote{This is where the development work for Uri's experimental paper goes. I basically implemented MATLAB's 802.11ac toolbox on WARP/WURC before it was a toolbox. As a personal, note, this was a significant development contribution, but I ended up not using it for any experimental study. Based on what I learned building the system and attempting to implement implicit calibration, I decided to move on to a complete system redesign (IRIS and ``Argos''). However, this work was used in currently submitted CSI security work that was led by Uri and also Naren.}

%#########
\subsubsection{Multi-Stream Noise and Channel Estimate}
\label{sec_static_mubf_chan_est}

	Our analysis requires updated \ac{CSI} for each downlink beamformed packet as well as \ac{CSI} noise variance.
	To provide these measurement metrics, we take two approaches depending on the transmission direction and number of streams.

% WURCLab multi-stream bemformed channel sounding with ground truth
\begin{figure}[ht]
\centering
\includegraphics[width=1\linewidth]{./figs/packet_format.pdf}
\caption{Multi-stream beamformed packet format implements the 802.11af TVHT 5~MHz PHY, utilizing the TVHT-LTF for multi-stream channel sounding.}
\label{fig:packet_format}
\end{figure}

	On the multi-stream downlink beamformed packet, we send an extra \textit{non-beamformed} TVHT-LTF (blue) immediately following the beamformed TVHT-LTF (green) as shown in the timing diagram in Figure~\ref{fig:packet_format}.

		In the case where power is allocated equally across receivers, each transmit antenna has the same transmit power budget, and the channel is \emph{i.i.d.} Rayleigh, the per-user expected beamformed \ac{SINR} can be expressed \cite{anandpuma} as
\begin{equation} \label{eq_expected_bf_sinr}
\mathcal{E}\{ SINR\} = 10\cdot \log_{10}\bigg( \frac{M-K+1}{K}\frac{(P/N_O)}{M} \bigg).
\end{equation}
	This approximation, valid for environments with rich multipath, provides a power scaling factor for the non-beamformed \ac{LTF} fields that allows a receiver that has performed \ac{AGC} on the beamformed \ac{STF} (orange) in Figure~\ref{fig:packet_format} to also resolve non-beamformed signals.

	When scaled according to the expected degradation in beamformed \ac{SNR} compared to broadcast \ac{SNR} \cite{anandpuma} to avoid \ac{AGC} clipping, this extra TVHT-LTF provides an estimate of the multi-user wireless channel \emph{at the exact moment} that the beamformed packet is sent.

	On the single-stream uplink channel, we assume that the wireless channel is constant for the WARPLab buffer, then we can apply the noise variance estimation technique developed in \cite{ren2009snr} to estimate the packet noise variance \ac{SNR}.
	The same estimator may be used for the individual zero-forced streams of the multi-stream downlink packet.

	The end-to-end latency of a sound-precode-transmit operation on our \ac{WURC} array using WARPLab 7.4 ranges from 71~ms for a $4\times 1$ transmission to 173~ms for a $4\times 4$.
	This approach of operating on UHF channels is validated in that we are consistently able to achieve less than 5\% receive \ac{EVM} at 16-QAM in an office environment with $4\times 2$ \ac{MU-MIMO}, provided the \acp{STA} are static.

	%The MATLAB library developed for this is released open-source for use on WARPv3 or WARPv3 platforms \cite{guerra2018toolbox}.

%#################################################
\subsection{Mobile Measurement System: Rapid Implicit Sounding}
\label{sec_mobile_chan_est}

 Channel sounding of mobile devices has always presented a challenge for \ac{SDR} systems, which require extensive computational resources, power sources, and  synchronization to operate as a stand-alone mobile device.
 For that reason, our early multi-user UHF research focused solely on fixed devices \cite{anand2014case} and avoided investigations of channels with nodal mobility.

	As \ac{MU-MIMO} channel sounding techniques advanced, we once again leveraged the modular and compartmentalized design of \ac{WURC} and our driver libraries to port another \ac{SDR} framework to our platform in order to perform \emph{mobile} multi-user wide-band channel measurements.

 In order to sound the multi-user environment rapidly between a \ac{MU-MIMO} \ac{AP} and multiple mobile \acp{STA}, we ported the published Argos \ac{MU-MIMO} control channel \cite{shepard2015faros} to inter-operate with our new $8\times 8$ MIMO WURC array (Section~\ref{sec_wurc_8x8}) by integrating custom HDL and embedded C libraries for the WARPv3 platform.
 The robust wireless synchronization scheme utilizing long correlatable signal sequences in Argos allows us to operate mobile \acp{STA} remotely, using a low-rate wireless side channel (the wireless bridge in Fig.~\ref{fig:wurc_argos_hw} for \ac{STA} initialization and control messages, while sample-level synchronization and implicit channel sounding occurs over the UHF channel.
 More details about the design of Argos are available in \cite{shepard2015faros}; we configure the system to allow us to sound the uplink channel of a set of mobile/static \acp{STA} every 2.5 to 5~ms.

	In order to increase the number of antennas available at the \ac{AP}, we share reference clocks between two $4\times4$ WURC \acp{AP} as discussed in Section~\ref{sec_wurc_4x4} to create a single $8\times8$ \ac{WURC} \ac{AP}.
	This significantly shortened clocking topology introduces no measurable decrease in signal or triggering error and has been validated over hours of operation. %, thus achieving our original design goals and providing new measurement capabilities in UHF bands.

	By starting from relatively simple narrowband channel sounding and building to wideband channel estimation as beamforming hardware and software support evolved, we developed a real-time multi-user and frequency-agile channel sounding system that allowed for true nodal mobility and could capture channel dynamics in small, millisecond packet timescales.


\subsection{Imperative programming with linear arrays}
\label{sec:imper-progr}

The API for mutable linear arrays (shown in \cref{sig:array})
aims to safely handle manual allocation and
deallocation of arrays that may contain affine elements.
One would first use @create n v@ to create
an (unrestricted) array of size @n@ initialized with value
@v@. This value must be unrestricted as it is duplicated to
initialize all array elements. Using the @map@ function we
can transform the unrestricted elements into linear (affine)
ones. This array can be processed further using @map@ (or @set@ if
affine). The @get@ function is only applicable if the element type
is unrestricted as one element is duplicated. The @length@
function is always applicable. To @free@ an array the elements must be
affine.

To manage the different kinds of accessing the array we distinguish between constructors, destructors,
observers, and mutators.
Constructors and destructors like @create@ and @free@ manipulate the whole
array. %As with channels in \cref{sec:session-linearity},
The constructor
@create@ yields a linear resource which is consumed by @free@.
During the lifetime of the array resource @a@, we can split
off \emph{shared borrows} @&a@ that provide a read-only
view or \emph{exclusive borrows} @&!a@ for read-write views.
Observer functions such as @length@ and @get@ expect an shared borrow
argument, mutator functions such a @set@ expect
a exclusive borrow.

Each borrow is tied to a region whose lifetime is properly
contained in the lifetime of the resource.
In a region, we can split off as many shared borrows of a resource as
we like, but we can take only one exclusive borrow. In a
subsidiary region, we can take shared borrows of any
borrow or we can take an exclusive borrow of an exclusive borrow from an
enclosing region. Borrows are confined to their regions. Inside the region,
shared borrows are unrestricted (@un@) whereas exclusive
borrows are affine (@aff@).

The code in \cref{ex:array} demonstrates a use of the API to create an
array of Fibonacci numbers as the programmer would write it. After
creation of the array, the presence of a borrow in the for loop
prevents access to the ``raw'' resource inside the loop's
body. \cref{ex:array:get} of the example contains two shared borrows
in the same expression, which forms a region by itself. These borrows
are split off the exclusive borrow used in \cref{ex:array:set}, which
belongs to the next enclosing region corresponding to the loop body.
The whole array can be returned in \cref{ex:array:return} because  the
borrows are no longer in scope.

\begin{figure}[tp]
  \centering
  \begin{subfigure}[t]{1\linewidth}
\begin{lstlisting}
module type ARRAY = sig
  type ('a : 'k) t : lin
  val create : ('a : un) => int -> 'a -> 'a t
  val free : ('a : aff) => 'a t -> unit
  val length : &('a t) -> int
  val get : ('a : un) => &('a t) * int -> 'a
  val set : ('a : aff) => &!('a t) * int * 'a -> unit
  val map : (&'a -> 'b) -> &('a t) -> 'b t
end

module Array : ARRAY
\end{lstlisting}
    \vspace{-15pt}
    \caption{Signature}
    \label{sig:array}
  \end{subfigure}

  \begin{subfigure}[t]{1\linewidth}
\begin{lstlisting}
let mk_fib_array n =
  let a = create n 1 in
  for i = 2 to n - 1 do
    let x = get (&a, i-1) + get (&a, i-2) in(*@\label{ex:array:get}*)
    set (&!a, i, x)(*@\label{ex:array:set}*)
  done;
  a(*@\label{ex:array:return}*)
# mk_fib_array : int -> int Array.t
\end{lstlisting}
    \vspace{-10pt}
    \caption{Example of use}
    \label{ex:array}
\begin{lstlisting}[firstnumber=2]
  let a = create n 1 in
  for i = 2 to n - 1 do {|
    let x = {| get &a (i-1) + get &a (i-2) |} in(*@\label{ex:array:region:get}*)
    set &!a i x
  |} done;
\end{lstlisting}
    \vspace{-10pt}
    \caption{Excerpt of \cref{ex:array} with explicit regions}
    \label{ex:array:region}
  \end{subfigure}
  \vspace{-5pt}
  \caption{Linear arrays}
  \label{ex:array}
\end{figure}

\cref{ex:array:region} uses braces @{| ... |}@ to make the
regions of the example in \cref{ex:array} explicit.  One
region consists of the header expression of the @let@ in
\cref{ex:array:region:get}. It is contained in another region that
comprises the body of the @for@ loop. \lang guarantees that borrows
never escape the smallest enclosing region. It employs a system of
\emph{indexed kinds} like @aff_r@ and @un_r@ where
$r$ is a positive integer that corresponds to the lexical nesting
depth of regions. For instance, the type of @&!a@ in
\cref{ex:array:set} has kind @aff_1@ whereas the type of
@&a@ in \cref{ex:array:region:get} has kind
@un_2@ and the typing of the inner region is such that types with
kind indexes greater than or equal to $2$ cannot escape.
In the example, borrows cannot escape  because they are consumed
immediately by @get@ and @set@.

Region annotations are automatically inserted using
syntactic cues such as borrows and binders (see
\cref{regionannot}).  Users may manually insert regions to further restrict the range of a
borrow. In practice, region annotations are
rarely needed with common programming idioms.
% All regions for the examples in this section have been inferred.

% \begin{figure}
%   \centering
%   % \begin{subfigure}{0.6\linewidth}
% \begin{lstlisting}
% let mk_fib_array n =
%   let a = create n 1 in
%   for i = 2 to n - 1 do {|
%     let x = {| get &a (i-1) + get &a (i-2) |} in(*@\label{ex:array:region:get}*)
%     set &!a i x
%   |}
%   done;
%   a(*@\label{ex:array:return}*)
% # mk_fib_array : int -> int Array.t
% \end{lstlisting}
%     \caption{Example from \cref{ex:array} with explicit regions}
%     \label{ex:array:region}
%   % \end{subfigure}
% \end{figure}

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


\chapter{Methodology}
\section{Feature Set}
HFO's high-level features set returns many features that is not relevant for our problem, such as opening angle to opponent's goal or pass opening angle to a teammate. We decided to remove those variables for the models understand more easier what to do. Another change was in the normalization of the features. The original environment returned normalized features in relation due to the half field problem. Once our problem is more comprehensive and the agents are in the same space and the features are strict, We maintained the without normalization.

Let $T$ denote the number of teammates in game and $O$ the
number of opponents. There are a total of $10 + 3T + 2O + 1$ high-level
features in our environment.

\begin{enumerate}[noitemsep]
\setcounter{enumi}{-1}
\item{\textbf{X position} - The agent’s x-position on the field.}
\item{\textbf{Y position} - The agent’s y-position on the field.}
\item{\textbf{Orientation} - The global direction that the agent is facing.}
\item{\textbf{Ball X} - The ball's x-position on the field.}
\item{\textbf{Ball Y} - The ball's y-position on the field.}
\item{\textbf{Able to Kick} - Boolean indicating if the agent can kick the ball.}
\item{\textbf{Goal Center Proximity} - Agent's proximity to the center of the goal.}
\item{\textbf{Goal Center Angle} - Angle from the agent to the center of the goal.}
\item{\textbf{Proximity to Opponent} - If an opponent is present,
  proximity to the closest opponent. Invalid if there are no
  opponents.}
\item [$T$] {\textbf{Proximity from Teammate i to Opponent} - For each
  teammate i: the proximity from the teammate to the closest
  opponent. This feature is invalid if there are no opponents or if
  teammates are present but not detected.}
\item [$2T$] {\textbf{X, Y of Teammates} - For each teammate: the x-position, y-position.}
\item [$2O$] {\textbf{X, Y of Opponents} - For each opponent: the x-position, y-position.}
\item [$+1$] {\textbf{Interceptable} - Whether the agent can intercept the ball or
 not.}
\end{enumerate}

\section{Actions}
Based on \cite{cyrus}, We chose four actions:
\begin{enumerate}
    \item Move: Performs the basic move, going to the position according to the formation file.
    \item Go to ball: Performs an interception move, tackling the opponent when it can.
    \item Defend Goal: Goes to the circumcenter position of the triangle goalie position, right or left goal post position and attacker position.
    \item Block: Performs \cite{marlik2011}'s Marlik Block.
\end{enumerate}

Evaluating Reinforcement Learning on Robocup Soccer Simulation 2D/proposal/methodology.tex


\section{Object Detection}
\label{sec:ObjectDetection}

Since the topic of this thesis concerns the task of \emph{visual} object tracking, an indispensable step in the processing pipeline will unquestionably be object detection. Holistically, there are \emph{fast} object detectors, \egtext{}, \gls{yolo}~\cite{redmon2016yolo} (\sectiontext{}~\ref{ssec:YouLookOnlyOnce}) or \gls{ssd}~\cite{liu2016ssd}. We use the term \emph{fast} to denote that the detector can operate on high \gls{fps}. This comes at a cost of relatively lower accuracy, though, as compared to \emph{slower} but more accurate approaches based on \glspl{rpn}, such as various versions of \gls{fasterrcnn} (\sectiontext{}~\ref{ssec:FasterRCNN}).

Object detection is a very difficult task because the number of objects is unknown in advance, which means that the number of outputs of the model is variable. Numerous attempts have been proposed to evade this inherent shortage of standard neural networks. An obvious solution is to only produce a constant number of \glspl{bbox}, as utilized by \gls{ssd} and \gls{yolo}. But methods based on \glspl{rpn} try to circumvent the obstacle of having to predict only a fixed set of \glspl{bbox}. Other differences between object detectors stem from the architecture itself, whether the training is an end-to-end pipeline or the model consists of various parts. Fully convolutional architectures are also becoming more prevalent~\cite{tian2019fcos}.

% ##############################################################################
\subsection{Non-Maximum Suppression}
\label{ssec:NonMaximumSuppression}

Object detectors have profited from the end-to-end learning paradigm in which features, object proposals, and the classifier become part of one model~\cite{hosang2017learningnms}. A proposal is nothing but a region containing a potential object of interest. However, the number of proposals may grow considerably, outnumbering the real count of present objects. Moreover, these proposals may have a large overlapping region as measured by \gls{iou} (\sectiontext{}~\ref{eq:IntersectionOverUnion}), rendering most of them useless in terms of conveying new information. To filter such proposals, the \gls{nms} algorithm is used (\figtext{}~\ref{fig:NonMaximumSuppression}). The objective is to iteratively select only proposals the \gls{iou} of which is below a specific threshold. Let $\mset{B} = \cbrackets{\vect{b}_1, \vect{b}_2, \dots, \vect{b}_n}$ be a set of $n$ region proposals described by $n$ \glspl{bbox}. Scores for each detection are contained in a set $\mset{S} = \cbrackets{s_1, s_2, \dots, s_n}$, where $s_i$ denotes a detection score for the $i$-th box, $\vect{b_i}$. Let $\lambda$, such that $0 \leq \lambda < 1$, denote the threshold for the maximum allowed portion of the overlap between regions. $\mset{B}_{nms}$ is the set of filtered proposal instances from the set $\mset{B}$ produced using \gls{nms} (\algtext{}~\ref{alg:NonMaximumSuppression}).

\begin{algorithm}[t]
    \caption{Non-Maximum Suppression}
    \label{alg:NonMaximumSuppression}
    \begin{algorithmic}[1]
        \Function{NMS}{$\mset{B}$, $\mset{S}$, $\lambda$}

        \State $\mset{B}_{nms}$ $\gets$ $\emptyset$
        \Comment{initialize the output (filtered) set of region proposals}

        \While {$\mset{B} \neq \emptyset$}
        \Comment{loop until all the proposals are processed}

        \State $m \gets \underset{i \in \cbrackets{1, 2, \dots, \msetsize{S}}}{\argmax{}} \mset{S}$
        \Comment{find an index of a proposal with the highest score}

        \State $\mset{B} \gets \mset{B} - \vect{b}_m$, $\mset{S} \gets \mset{S} - s_m$
        \Comment{remove the proposal}

        \State $\mset{B}_{nms} \gets \mset{B}_{nms} \cup \vect{b}_m$
        \Comment{save the proposal with the highest score}

        \For{$i \gets 1$ to $\msetsize{B}$}
        \Comment{iterate through remaining proposals}

        \If{\Call{iou}{$\vect{b}_m$, $\vect{b}_i$} $\geq \lambda$}
        \Comment{\gls{iou} (\eqtext{}~\ref{eq:IntersectionOverUnion}) exceeds the threshold}

        \State $\mset{B} \gets \mset{B} - \vect{b}_i$, $\mset{S} \gets \mset{S} - s_i$
        \Comment{remove the proposal}
        \EndIf
        \EndFor
        \EndWhile

        \State \Return $\mset{B}_{nms}$
        \EndFunction
    \end{algorithmic}
\end{algorithm}

% ------------------------------------------------------------------------------
\begin{figure}[t]
    \centerline{\includegraphics[width=0.6\linewidth]{figures/theoretical_foundations/non_maximum_suppression.pdf}}
    \caption[\gls{nms} visualization]{An illustration of a potential effect of the \gls{nms} algorithm on \glspl{bbox}. Multiple proposals (left) are filtered so that only the ones with the highest detection score (right) remain while satisfying the condition that the overlap does not exceed a specific threshold.}
    \label{fig:NonMaximumSuppression}
\end{figure}
% ------------------------------------------------------------------------------

% ##############################################################################
\subsection{YOLO}
\label{ssec:YouLookOnlyOnce}

\gls{yolo} is a very popular single-stage object detector thanks to its ability to run in real-time and yet be sufficiently accurate. Its speed is primarily a consequence that \emph{it looks only once} at a given input image. Compared to \gls{rpn}-based approaches, the authors of \gls{yolo} devised a \gls{cnn} model capable of performing extraction of region proposals as well as classification in a single run~\cite{redmon2016yolo}. Besides, the backbone \gls{cnn} model processes an entire image during the training and test time, allowing an implicit inclusion of contextual information about classes together with their visual representation. During the testing phase, the \gls{nms} algorithm is employed to filter predictions to make sure that each object instance is detected just once. Since the initial introduction of this approach, multiple updates have been brought forward~\cite{redmon2017yolo9000, redmon2018yolov3, wang2020yolov4, wong2019yolonano}.

% ##############################################################################
\subsection{Faster R-CNN}
\label{ssec:FasterRCNN}

\gls{fasterrcnn}~\cite{ren2017fasterrcnn} is the most prominent \emph{two-stage} object detector. The first stage consists of generating region proposals using the \gls{rpn}~\cite{huang2017speedacctradeoff}. This set of class-agnostic, rectangular \glspl{bbox} is produced from an input of arbitrary size (\figtext{}~\ref{fig:FasterRCNNPipeline}). Regarding the second stage, the proposed regions (usually $300$) serve as a basis for subsequent cropping of features from the same intermediate feature maps that are then fed to the remaining feature extractor to predict the class. Based on this class prediction, the proposed box is further refined. Despite the endeavor to diminish unnecessary computations, there is still a part of the computation that has to be executed once per each proposed region, so the performance depends on the number of regions generated by the \gls{rpn}.

% ------------------------------------------------------------------------------
\begin{figure}[t]
    \centerline{\includegraphics[width=\linewidth]{figures/theoretical_foundations/fastercnn_diagram.pdf}}
    \caption[\gls{fasterrcnn}]{A conceptual processing diagram of the \gls{fasterrcnn} model.}
    \label{fig:FasterRCNNPipeline}
\end{figure}
% ------------------------------------------------------------------------------


% Lecture for ph2a Caltech 2017: Vibrations and Waves
\documentclass[pdf,handout, hideothersubsections]{beamer}
\usepackage{beamerthemeshadow}
\mode<presentation>
  {
    \usefonttheme{structuresmallcapsserif}
    \usetheme{CambridgeUS}
    \usecolortheme{seahorse}
    %\useinnertheme{circles}
%    \useoutertheme{tree}
  }

\usepackage{svg}
\usepackage{xmpmulti}
\usepackage{mathtools}
%\usepackage{enumitem}
\usepackage{hyperref}
\hypersetup{
    pdffitwindow=true,     % window fit to page when opened
    colorlinks=true,       % false: boxed links; true: colored links
    linkcolor=orange,      % color of internal links
    citecolor=green,       % color of links to bibliography
    filecolor=magenta,     % color of file links
    urlcolor=blue,         % color of external links
    pdfstartview={Fit}
}

% Fonts/encoding
\renewcommand{\UrlFont}{\tiny}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
%\usepackage[sc,medium,raggedright]{titlesec}
\usepackage{newtxmath}
%\usepackage{libertine}
\usepackage[osf]{ebgaramond}

\graphicspath{{Figures/}}

\begin{document}
\title{Normal Modes}
\author{Caltech: ph2a}
\date{12 - Oct - 2017}

\frame{\titlepage}

\frame{\frametitle{Table of contents}\tableofcontents}

\setbeamerfont{footnote}{size=\tiny}

\section{Previous Summary}
\begin{frame}
\frametitle{Last Time:}
\begin{itemize}
\item Coupled oscillators have multiple free vibration frequencies/modes.
\item These free oscillation frequencies are called eigenfrequencies.
\item The oscillation functions are the eigenfunctions.
\item Linear algebra can be used to solve for these functions.
\end{itemize}
\end{frame}

\begin{frame}
\frametitle{Properties of Modes in Coupled Osc.}
\begin{enumerate}
\pause
\item $\omega_{1,i}=\omega_{2,i}=\omega_i$~(for the i$^{th}$ mode)
\pause
\item $A_{1,i}, A_{2,i} \ne f(t)$; i.e. amplitudes are constant
\pause
\item A's are constant, so the relative phases of the modes are
  constant.
\pause
\item \underline{Stable}: w/o friction the oscillations go on
  forever. There is no mixing of energy \emph{between} eigenmodes
\pause
\item \textbf{Complete}: Any free oscillation can be decomposed into a sum of
  normal modes.

\end{enumerate}
\end{frame}

\section{Coupled Oscillator}
\begin{frame}
\frametitle{Coupled Oscillators: Overview}
\pause
\begin{enumerate}
\item For free vibrations, $m \ddot{x} + b \dot{x} + k x = 0$.
\pause
\item In a coupled systems, there can be several springs and several
  masses with many inter-connections.
\pause
\item Can be used for analysis of many kinds of linear systems.
\pause
\item Matrix methods are very handy in solving systems of coupled
  differential equations: linear algebra is useful for solving systems
  of linear equations.
\end{enumerate}
\end{frame}

\subsection{Examples}
\begin{frame}
\frametitle{Examples}

\begin{itemize}
\item 2 masses, 3 springs (Airtrack Demo) \\
\url{https://www.myphysicslab.com/springs/double-spring-en.html} \\
\url{http://www.falstad.com/coupled/}
%\pause
\item 2 Pendula coupled by a weak spring
%\pause
\item Double Pendulum (python demo) \\
\url{https://www.myphysicslab.com/pendulum/double-pendulum-en.html}

\end{itemize}

\end{frame}

\subsection{Equations of Motion}

\begin{frame}
\frametitle{Summary of the EigenMode analysis:}
\begin{enumerate}
\item Make a diagram of the system. Draw the forces.
\pause
\item Write down the differential eqs. for the forces (e.g.
$\ddot{x} = -\frac{k}{m} x$)
\pause
\item Write down the initial guess for the solutions,
  e.g. $\tilde{x}_k = \tilde{A}_k e^{i \omega t}$
\pause
\item Plug guesses into diff. eqs. Re-arrange so it `looks easy' to put
  into matrix form.
\pause
\item Write as a matrix equation (with $N = $ number of modes): \\
($N \times N$ matrix) $\times$ ($N \times 1$ column vector) = 0
\pause
\item Set the determinant of the $N \times N$ matrix = zero to find
  the eigenvalues (solve for the possible values of $\omega$)
\pause
\item Plug the eigenvalues back into the matrix equation to solve for
  the complex amplitudes, $\tilde{A}_k$
\end{enumerate}
\end{frame}

\begin{frame}
\frametitle{Two Masses + Three Springs}
\begin{columns}

  \begin{column}{0.5\textwidth}
\pause
    \includegraphics[width=0.85\textwidth]{2masses3springs.jpg}
\begin{itemize}
\item $k_1 = k_2 = k_3 = k$
\item $m_1 = m_2 = m$
\end{itemize}
  \end{column}

  \begin{column}{0.5\textwidth}
    \pause
    Forces on Mass 1:
    \begin{equation}
      F_1 = m \ddot{x_1} = -k x_1 + k (x_2 - x_1)
    \end{equation}
    \pause
    Forces on Mass 2:
    \begin{equation}
      F_2 = m \ddot{x_2} = -k x_2 - k (x_2 - x_1)
    \end{equation}
    \pause
    2 Eqs \& 2 Unknowns:
    \begin{align}
      m \ddot{x_1} + 2 k x_1 - k x_2 &= 0 \\
      m \ddot{x_2} + 2 k x_2 - k x_1 &= 0
    \end{align}
  \end{column}

\end{columns}
\end{frame}

\begin{frame}
\frametitle{Two Masses + Three Springs}
    \pause
\begin{enumerate}
\item For SHO, we guessed $\tilde{x} = A e^{i (\omega t + \phi_0)}$
\pause
\item For CHO, we use $\tilde{x_1} = A_1 e^{i \omega t}$ and
  $\tilde{x_2} = A_2 e^{i \omega t}$; assuming $A_1$ and $A_2$ are complex.
\pause
\item Plugging into Eqs. 3 \& 4, we get: \\
\begin{align*}
\Big[ -\omega^2 A_1 + 2 \frac{k}{m}A_1 - \frac{k}{m}A_2 \Big] e^{i
  \omega t} &= 0 \\
\Big[ -\omega^2 A_2 + 2 \frac{k}{m}A_2 - \frac{k}{m}A_1 \Big] e^{i
  \omega t} &= 0
\end{align*}
\pause
\item Divide both sides by $e^{i \omega t}$ and using $\omega_0^2 =
  k/m$, we get:
\pause
\begin{align*}
\Big[ -\omega^2 A_1 + 2 \omega_0^2 A_1 - \omega_0^2 A_2 \Big] &= 0 \\
\Big[ -\omega^2 A_2 + 2 \omega_0^2 A_2 - \omega_0^2 A_1 \Big] &= 0
\end{align*}

\end{enumerate}
\end{frame}

\section{Eigenfrequencies}
\begin{frame}
\frametitle{Matrix Methods: Eigenvalues}
\pause
Rewrite in matrix form to allow using linear algebra: \\
\[
\begin{bmatrix}
-\omega^2 + 2 \omega_0^2 & -\omega_0^2 \\
-\omega_0^2 & -\omega^2 + 2 \omega_0^2
\end{bmatrix}
\begin{bmatrix}
A_1 \\
A_2
\end{bmatrix}
=
\begin{bmatrix}
0 \\
0
\end{bmatrix}
\]
\pause
which we can write as
\[
M_{j k}
\begin{bmatrix}
A_1 \\
A_2
\end{bmatrix}
=
\begin{bmatrix}
0 \\
0
\end{bmatrix}
\]
\pause
Multiplying through by the inverse matrix, $M_{jk}^{-1}$, we get
\[
M_{jk}^{-1} M_{j k}
\begin{bmatrix}
A_1 \\
A_2
\end{bmatrix}
=
M_{jk}^{-1}
\begin{bmatrix}
0 \\
0
\end{bmatrix}
\]
\pause
which just means $A_1 = 0$ and $A_2 = 0$, which is the trivial
solution of no motion of the oscillators.
\pause
The only cases in which
this is not true, are the ones for which \textcolor{blue}{the matrix inverse,
$M_{jk}^{-1}$, \emph{does not exist}}.

\end{frame}

\begin{frame}
From linear algebra, we remember that the non-invertible matrices have
a determinant equal to zero:
\[
\begin{vmatrix}
-\omega^2 + 2 \omega_0^2 & -\omega_0^2 \\
-\omega_0^2 & -\omega^2 + 2 \omega_0^2
\end{vmatrix}
= 0
\]
\pause
which gives us the following quadratic equation:
\pause
$(-\omega^2 + 2 \omega_0^2)^2 -\omega_0^4 = 0$ \\
\pause
and solving for $\omega$, we have
\centering
\pause
$\omega^2 = 2 \omega_0^2 \pm \omega_0^2$ \\
\pause
so $\omega = (\omega_0, \sqrt{3} \omega_0)$

\end{frame}

\section{Eigenmodes}
\begin{frame}
\frametitle{Eigen (Normal) Modes}
\pause
Plugging the eigenfrequencies back into our equations, we get:
\pause
\begin{align}
\omega = \omega_0 :  -\omega_0^2 A_1 + 2 \omega_0^2 A_1 - \omega_0^2 A_2 &=
0 \implies A_1 = A_2\\
\omega = \sqrt{3} \omega_0 :  -\omega_0^2 A_1 - 3 \omega_0^2 A_2 + 2 \omega_0^2 A_2 &=
0 \implies A_1 = - A_2
\end{align}
\pause
These are the \emph{symmetric} and \emph{anti-symmetric} solutions,
respectively:

\begin{block}{Symmetric Mode:}
$ \tilde{x}_1 = \tilde{C}_+ e^{i \omega_0 t}, \tilde{x}_2 = \tilde{C}_+
e^{i \omega_0 t}$
\end{block}
\begin{alertblock}{Anti-Symmetric:}
$\tilde{x}_1 = \tilde{C}_- e^{i \sqrt{3} \omega_0 t},
\tilde{x}_2 = -\tilde{C}_- e^{i \sqrt{3} \omega_0 t}$
\end{alertblock}

\end{frame}

\section{Torsionally Coupled Pendula}
\begin{frame}
\frametitle{Example: Weakly Coupled Pendula}

\begin{columns}
  \begin{column}{0.3\textwidth}
    \includegraphics[width=4cm]{TorsionCoupled.png}
  \end{column}
  \pause

\begingroup
\footnotesize
  \begin{column}{0.7\textwidth}
Two pendula pivot about an axis, $A$, and are constrained to rotate in
a plane perpendicular to that axis. The pivot points are fixed. The
pendula are coupled by a weak torsional spring that obey's Hooke's law
with a torsional spring constant, $\kappa$.:
\begin{equation*}
\tau = \kappa (\theta_1 - \theta_2)
\end{equation*}
\pause

\begin{enumerate}
\item (2.5 pts) Write the coupled diff. eq. describing the motion of
  the pendula for $\theta_n << 1$.

\item (2.5 pts) Find the two eigenfreqencies.

\item (2.5 pts) Find the two eigenfunctions. The overall complex
  amplitude for each eigenfunction should remain undetermined.

\item (2.5 pts) Determine the time evolution of each pendulum with the
  initial conditions $\theta_1(0) = 0$ and $\theta_2(0) = A$, and both
  starting with zero velocity. Sketch the functions for at least 2
  cycles. Assume that $\kappa = \frac{1}{8} m g L$.

\end{enumerate}

\end{column}
\endgroup
\end{columns}
\end{frame}

\begingroup
\footnotesize
\begin{frame}
\frametitle{Part 1}
\begin{columns}[T]

  \begin{column}{0.3\textwidth}
     \includegraphics[width=\textwidth]{Simple_pendulum_generalized_coordinates.pdf}

  \end{column}
\pause
  \begin{column}{0.7\textwidth}
  \begin{enumerate}
  \item Motion of pendulum is \emph{rotational}, not translational, so instead of $F = m a$, use $\tau = I \ddot{\theta}$, where $\tau$ is the torque, and $\theta$ is the angle of the pendulum wire. \\
    \pause
  \item
    \begin{align*}
      I \ddot{\theta}_1 &= \vec{r} \times \vec{F} \\
      m L^2 \ddot{\theta}_1 &= -m g L \sin{\theta_1} \\
      m L^2 \ddot{\theta}_1 &\simeq -m g L \theta_1
    \end{align*}
   \pause
   \item And we also add our weak torsional spring's torque:
\begin{align}
 m L^2 \ddot{\theta}_1 &= -m g L \theta_1 - \kappa (\theta_1 -
                         \theta_2) \label{eq:tor1}\\
 m L^2 \ddot{\theta}_2 &= -m g L \theta_2 + \kappa (\theta_1 -
     \theta_2) \label{eq:tor2}
\end{align}
Using the same logic for the second pendulum, while being careful
about the sign of the coupling torque.

  \end{enumerate}

  \end{column}

\end{columns}

\end{frame}
\endgroup

\begingroup
\footnotesize
\begin{frame}
\frametitle{Part 2}
\begin{enumerate}
\item Use the usual initial guesses: $\tilde{\theta}_k = \tilde{A}_k
  e^{i \omega t}$
\item Plugging in to \eqref{eq:tor1}, and \eqref{eq:tor2}, and dividing by $e^{i \omega t}$, we get:
\begin{align}
 -m L^2 \omega^2 A_1 &= -m g L A_1 - \kappa (A_1 - A_2) \\
 -m L^2 \omega^2 A_2 &= -m g L A_2 + \kappa (A_1 - A_2)
\end{align}
\item Dividing by $m L^2$ and regrouping:
\begin{align}
 \omega^2 A_1 - \omega_0^2 A_1 + \frac{\kappa}{m L^2} (A_1 - A_2) &= 0 \\
 \omega^2 A_2 - \omega_0^2 A_1 - \frac{\kappa}{m L^2} (A_1 - A_2) &= 0
\end{align}

\end{enumerate}
\end{frame}
\endgroup

\begingroup
\footnotesize
\begin{frame}
\frametitle{Part 2b}

Now we can write it as a matrix equation (setting $ \frac{\kappa}{m
  L^2} = \omega_T^2$ :
\[
\begin{bmatrix}
\omega^2 - \omega_0^2 + \omega_T^2 & -\omega_T^2 \\
-\omega_0^2 - \omega_T^2 & \omega^2 + \omega_T^2
\end{bmatrix}
\begin{bmatrix}
A_1 \\
A_2
\end{bmatrix}
=
\begin{bmatrix}
0 \\
0
\end{bmatrix}
\]
\pause
Setting the determinant equal to zero:
\begin{align}
(\omega^2 + \omega_T^2)(\omega^2 - \omega_0^2 + \omega_T^2) -
  (-\omega_T^2)(-\omega_0^2 - \omega_T^2) = 0
\end{align}
we can algebraically solve for $\omega$ in terms of $\omega_0$ and $\omega_T$.
\end{frame}
\endgroup

\begin{frame}
\frametitle{Part 3}
Plug the eigenfrequencies back into Eqs 11 \& 12 to solve for the
(complex) values of $A_1$ and $A_2$.

\end{frame}

\begin{frame}
\frametitle{Part 4: Initial Conditions}
Solve for the relative phases and amplitudes of $A_n$ by using the
initial conditions on $\theta_n(0)$ and $\dot{\theta_n}(0)$

\end{frame}

% \section{Beats}
% \begin{frame}
%  \frametitle{Beats: Examples}

% \end{frame}

% \section{Summary}
% \begin{frame}
% \frametitle{Modes in Coupled Oscillators}
% \begin{enumerate}
% \pause
% \item $\omega_{1,i}=\omega_{2,i}=\omega_i$~(for the i$^{th}$ mode)
% \pause
% \item $A_{1,i}, A_{2,i} \ne f(t)$; i.e. amplitudes are constant
% \pause
% \item A's are constant, so the relative phases of the modes are
%   constant
% \pause
% \item \underline{Stable}: w/o friction the oscillations go on forever
% \pause
% \item \textbf{Complete}: Any motion can be decomposed into a sum of
%   normal modes.

% \end{enumerate}
% \end{frame}

\end{document}