\documentclass[12pt]{article}
\usepackage{graphicx}
\usepackage{float}
\usepackage{amsmath}
\usepackage{scrextend}
\addtolength{\textwidth}{1in}
\addtolength{\textheight}{1in}
\addtolength{\evensidemargin}{0.5in}
\addtolength{\oddsidemargin}{-0.5in}
\addtolength{\topmargin}{-0.5in}
\title{gl-billiards}
\author{Dan Lapp\\Taras Mychaskiw\\COSC 3P98 Project}
\date{January 8th, 2014}

\begin{document}
\maketitle
    \begin{abstract}
    \end{abstract}

    \thispagestyle{empty}
    \tableofcontents
    %\cleardoublepage
    %\newpage
    \thispagestyle{empty}
    \mbox{}
    \clearpage
    \setcounter{page}{1}

    \section{Physics Engine}

        \subsection{Taking a Shot}
        Once a ball is hit by the cue, there are two ways energy is transferred to the ball. First, and more noticeable of the two
        is the transfer of linear momentum. This sends the ball moving around the table in straight lines. Second is the transfer
        of angular momentum, which applies spin to the ball. Spin can cause the ball to stop in it's tracks after a collision,
        bounce off cushions in strange (but predictable) ways and to any pool player, is just as if not more important an aspect
        to the game as the linear momentum.
            \subsubsection{Linear Momentum}
            To simplify the shot making process, the pool cue is assuming to act like a spring. That is, the further you pull
            the cue away from the cue you are going to hit, the more powerful your shot will be. Spring motion can be described
            using Hooke's Law,
            \begin{equation}
                \vec F = -k \vec x
                \label{equ:hookes_law}
            \end{equation}
            where, $\vec F$ is the force, $\vec x$ is how much the spring is stretched and $k$ is the spring constant, which
            describes basically how powerful (springy) the spring is.
            \\
            Hooke's Law is equivalent to Newton's Second Law, which states
            \begin{equation}
                \vec F = m \vec a
                \label{equ:newton}
            \end{equation}
            where, $\vec F$ is the force, $m$ is the mass of the object and $\vec a$ is the acceleration of the object. Setting
            Equation~\ref{equ:hookes_law} equal to Equation~\ref{equ:newton} gives
            \begin{eqnarray}
                -k \vec x &=& m \vec a \nonumber \\
                -k \vec x &=& m \frac{\Delta \vec v}{\Delta t} \nonumber \\
                \Delta \vec v &=& \frac{-k \Delta t}{m}\vec x  \nonumber
            \end{eqnarray}
            where $\vec v$ is the velocity of the object, and $t$ is the time. For pool, the initial velocity of the ball being struck is
            always zero, so we can simplify the above equation to
            \begin{equation}
                \vec v = \frac{-k t}{m}\vec x
                \label{equ:shot_velocity}
            \end{equation}
            where $\vec x$ is the distance between the ball and the tip of the cue, $m$ is the mass of the ball, $t$ is how much time the
            cue is in contact with the ball and $k$ is the spring constant of the cue. The values for $t$ and $k$ needed to be experimentally
            found though trial and error, essentially trying values until what happened in the simulation closely represented real life. The
            values for $t$ and $k$ were found to be $0.1$s and $10$N/m.
            %\end{Linear Velocity}

            \subsubsection{Angular Momentum}
            Angular momentum transfer is more complex. The starting point for this section is also Newton's Second Law, but written
            in a form more usable to the problem at hand.
            \begin{equation}
                \vec \tau = I \vec \alpha
                \label{equ:newton_rotation}
            \end{equation}
            where $\vec \tau$ is the torque applied to the object around it's center of rotation, $I$ is the moment of inertia of the
            object and $\vec \alpha$ is the angular acceleration of the object.
            \\
            Torque is always given by the equation,
            \begin{equation}
                \vec \tau = \vec r \times \vec F
                \label{equ:torque}
            \end{equation}
            where $\vec F$ is the force being applied, $\vec r$ is the vector between where the force is being applied and the center
            of rotation of the object, and $\times$ is the vector cross product.
            \\
            An important note is the inertia for a solid sphere is given by,
            \begin{equation}
                I_{sphere} = \frac{2}{5} m R^2
                \label{equ:inertia_sphere}
            \end{equation}
            where $R$ is the radius and $m$ is the mass of the sphere.
            \\
            Setting Equation~\ref{equ:newton_rotation} equal to Equation~\ref{equ:torque}, subbing in Equation~\ref{equ:inertia_sphere}
            for $I$ and Equation~\ref{equ:hookes_law} for $\vec F$, and solving gives,
            \begin{eqnarray}
                \vec r \times -k \vec x &=& \frac{2}{5} m R^2 \frac{\Delta \vec \omega}{\Delta t} \nonumber \\
                \Delta \vec \omega &=& \frac{5}{2} \left(\frac{\Delta t}{m R^2}\right) (\vec r \times -k \vec x) \nonumber
            \end{eqnarray}
            where $\vec \omega$ is the angular velocity of the ball, and $t$ $t$ is how much time the cue is in contact with the ball (the same $t$
            as in the previous section). Again, for pool, when the ball is struck it is entirely at rest, so the initial angular velocity is zero.
            The above equation then simplifies to
            \begin{equation}
                \vec \omega = \frac{5}{2} \left(\frac{\Delta t}{m R^2}\right) (\vec r \times -k \vec x)
                \label{equ:shot_angular}
            \end{equation}
            where $\vec x$ is the distance between the ball and the tip of the cue, $m$ is the mass of the ball, $R$ is the radius of the ball,
            $t$ is how much time the cue is in contact with the ball, $k$ is the spring constant of the cue and finally $\vec r$ is the vector
            between the center of the ball and where the cue strikes the ball.
            %\end{Angular Velocity}
        %\end{Taking a Shot}

        \subsection{Event System}
        For the purposes of this program, an event is a ball-ball collision, or a ball banking off of the cushion. The way gl-billiards works
        is each time the screen is redisplayed, some physics updater function is called with a parameter $dt$, which is how much time has passed
        since the last frame. The engine simulates the pool game up until a time $dt$ has passed. For example, if $1$s was passed, then it would
        simulate $1$s of play before returning, then the screen would be updated as if $1$s had passed.
        \\
        So, the engine determines which events occur within time $dt$. Event detection then becomes \textit{when} do events happen instead
        of \textit{if} they happened. The entire update function works as follows:\\
        \texttt{
            update($dt$)                                                        \\
            \begin{addmargin}[1em]{0em}
            find earliest event that occurs within time $dt$, call it $event$   \\
            if no such event                                                    \\
                \begin{addmargin}[1em]{0em}
                roll balls until $dt$                                           \\
                \end{addmargin}
            otherwise                                                           \\
                \begin{addmargin}[1em]{0em}
                roll balls until $event$ occurs                                 \\
                handle $event$                                                  \\
                $dt$ <-- $dt$ - $event$.$getTime()$                             \\
                call update($dt$) again                                         \\
                \end{addmargin}
            \end{addmargin}
        }
        In this manner, all events that happen within $dt$ and handled automatically before the frame updates and the balls slow
        down due to friction. Note that "roll balls" simply means each ball moves at it's speed for some amount of time. Pocketing
        detection needs to be done there, as it is not a standard event. That is, if a ball is pocketed, it cannot possible participate
        in any events in time $dt$, since it would bank off the cushion or collide with another ball first. \\
        After $update(dt)$ is finished, each ball gets affected by friction and slows down slightly. Friction takes the form of a
        slight decrease in the velocity of the ball.
        %\end{Event System}

        \subsection{Event Detection}
            \subsubsection{Ball-Ball Collision Detection}
            A ball-ball collision will occur when the centers of the balls are two radii apart. In gl-billiards, the trajectory
            of each ball is simplified to be a straight line per frame since friction is only applied at the end of each frame.
            Thus, the trajectory of each ball becomes,
            \begin{equation}
                \vec r = \vec r_0 + \vec v t
                \label{equ:position}
            \end{equation}
            where $\vec r$ is the position of the ball, $\vec r_0$ is the starting position, $\vec v$ is the velocity of the ball and
            $t$ is the amount of time elapsed. Then, for each possible collision to occur, the program needs to find at what times the
            distance from one ball to the other is equal to twice the radius of the ball. Mathematically, this becomes
            \begin{eqnarray}
                | \vec r_1 - \vec r_2 | &=& 2 R   \nonumber   \\
                \sqrt{ (\vec r_1 - \vec r_2) \cdot (\vec r_1 - \vec r_2) } &=& 2 R  \nonumber
            \end{eqnarray}
            where $R$ is the radius of a ball. Squaring both sides, and subbing in Equation~\ref{equ:position} for both
            $\vec r_1$ and $\vec r_2$ (using $\vec{dr_0} = \vec r_{0_1} - \vec r_{0_2}$ and $\vec{dv} = \vec v_1 - \vec v_2$),
            \begin{eqnarray}
                (\vec{dr_0} \cdot \vec{dr_0}) + (\vec{dr_0} \cdot \vec{dv}) t + (\vec{dv} \cdot \vec{dv}) t^2 &=& 4 R^2
                \label{equ:collision_time}
            \end{eqnarray}
            This is a quadratic equation for $t$ which can be solved easily. If there are real roots to the equation, then
            a collision occurs, and it occurs at the minimal possible $t$ value which is a solution to Equation~\ref{equ:collision_time}.
            %\end{Ball-Ball Collision Detection}

            \subsubsection{Ball-Wall Collision Detection}
            Ball-wall collision detection is similar to ball-ball, except the ball is a distance one radius away from the wall when it collides.
            Since the wall doesn't move, a different strategy had to be employed to detect when a ball-wall collision occurs. In this case,
            both the and wall positions are described using parametric equations.
            \begin{eqnarray}
                \vec r = \vec r_0 + (dt~\vec v) T_b         \label{equ:ball_parametric} \\
                \vec w = \vec s + (\vec f - \vec s) T_w     \label{equ:wall_parametric}
            \end{eqnarray}
            Where, $\vec r$ is the position of the ball, $\vec r_0$ is the initial position of the ball, $\vec v$ is the velocity of the ball,
            $dt$ is the amount of time that will pass this frame; $\vec w$ is a point on the wall, $\vec s$ is one endpoint on the wall, and $\vec f$
            is the other endpoint of the wall. $T_b$ and $T_w$ are the parametric variables, and range between $0$ and $1$. \\
            To determine when the ball hits the wall, where the ball hits must be determined first. The center of the ball hits the wall when
            $\vec r = \vec w$, thus the ball actually collides with the wall when $\vec r - R \vec n = \vec w$, where $\vec n$ is the normal
            vector to the wall. For simplicity below, we will ignore this offset value, as it is a fairly simple transformation. So, the collision
            occurs when
            \begin{eqnarray}
                r_{0_x} + (dt~v_x) T_b = s_x + (f_x - s_x) T_w  \nonumber \\
                r_{0_y} + (dt~v_y) T_b = s_y + (f_y - s_y) T_w  \nonumber \\
            \end{eqnarray}
            Solving for $T_b$ and $T_w$ gives
            \begin{eqnarray}
                T_b &=& \frac{(f_x - s_x)\cdot(s_y - r_{0_y}) - (f_y - s_y)\cdot(s_y - r_{0_y})}{(dt~v_y)\cdot(f_x - s_x) - (dt~v_x)\cdot(f_y - s_y)} \nonumber \\
                T_w &=& \frac{(dt~v_x)\cdot(s_y - r_{0_y}) - (dt~v_y)\cdot(s_y - r_{0_y})}{(dt~v_y)\cdot(f_x - s_x) - (dt~v_x)\cdot(f_y - s_y)} \nonumber \\
            \end{eqnarray}
            If both $T_b$ and $T_w$ are between $0$ and $1$, then a ball-wall collision occurs. The point at which can be found by subbing in $T_b$ or $T_w$
            into Equations~\ref{equ:ball_parametric} or \ref{equ:wall_parametric} respectfully. Then the amount of time passed can be solved for using Equations~\ref{equ:position}.
            %\end{Ball-Wall Collision Detection}
        %\end{Event Detection}

        \subsection{Event Handling and Velocity Updates}
            \subsubsection{Ball-Ball Collisions}
            %\end{Ball-Ball Collisions}

            \subsubsection{Ball-Wall Collisions}
            %\end{Ball-Wall Collisions}

            \subsubsection{Friction}
            %\end{Friction}
        %\end{Event Handling and Velocity Updates}

    %\end{Physics}

\end{document}


Monadic AAM begins with recognizing that the abstract semantics from
section~\ref{section:AAMByExample:AbstractSemantics} look suspiciously monadic.
%
In this section we will rewrite the exact same function but in monadic style.
%
After the exercise, the monad will be generalized in
section~\ref{section:MonadicAAM:Generalizing} and this generalization will be
exploited in section~\ref{section:MonadicAAM:Optimizations}.

\subsubsection{Nondeterminism}
\input{sections/04MonadicAAM/00MonadicStyle/00Nondeterminism/Z.tex}

\subsubsection{State}
\input{sections/04MonadicAAM/00MonadicStyle/01State/Z.tex}


% Created 2020-09-29 ter 18:34
% Intended LaTeX compiler: pdflatex
\documentclass[11pt]{article}
\usepackage[utf8]{inputenc}
\usepackage{lmodern}
\usepackage[T1]{fontenc}
\usepackage[top=3cm, bottom=2cm, left=3cm, right=2cm]{geometry}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{amssymb}
\usepackage{amsmath}
\usepackage[theorems, skins]{tcolorbox}
\usepackage[style=abnt,noslsn,extrayear,uniquename=init,giveninits,justify,sccite,
scbib,repeattitles,doi=false,isbn=false,url=false,maxcitenames=2,
natbib=true,backend=biber]{biblatex}
\usepackage{url}
\usepackage[cache=false]{minted}
\usepackage[linktocpage,pdfstartview=FitH,colorlinks,
linkcolor=blue,anchorcolor=blue,
citecolor=blue,filecolor=blue,menucolor=blue,urlcolor=blue]{hyperref}
\usepackage{attachfile}
\usepackage{setspace}
\usepackage{tikz}
\author{Gabriel Petrini}
\date{October 1st, 2020}
\title{Estimating Dynamic Models Without Solving Value Functions}
\begin{document}

\maketitle
\tableofcontents

\bibliography{References}

\section*{\cite{hotzMiller1993}}
\label{sec:org9c92db5}

Dynamic discrete choice models are complicated to estimate because of the future value terms. \citet{hotzMiller1993} show:

\begin{itemize}
\item Differences in conditional value functions \(v_j-v_{j'}\) can be mapped into \uline{conditional choice probabilities} ( \(p_j\)'s )
\item We can pull the \(p_j\)'s from the data in a first stage
\item \textbf{Empirical example:} optimal stopping with respect to couples' fertility
\end{itemize}

\subsection*{Difference in \(v\)'s and logit errors}
\label{sec:orgc62eac5}

Consider an individual who faces two choices where the errors are T1EV. The probability of choice 1 is:
\begin{align*}
p_1&=\frac{\exp(v_1)}{\exp(v_0)+\exp(v_1)}
\end{align*}

The ratio of \(p_1/p_0\) is then:
\begin{align*}
\frac{p_1}{p_0}&=\frac{\exp(v_1)}{\exp(v_0)} = \exp(v_1 - v_0)
\end{align*}
implying that:
\begin{align*}
\ln(p_1/p_0)&=v_1-v_0
\end{align*}

\subsection*{General structure}
\label{sec:org916f1e4}

The inversion theorem of Hotz and Miller says that there exists a mapping, \(\psi\), from the conditional choice probabilities, the \(p\)'s, into the differences in the conditional valuation functions, \(v_j-v_k\):
\begin{align*}
V_{t+1}&=v_{0t+1}+\mathbb{E}\max\{\epsilon_{0t+1},v_{1t+1}+\epsilon_{1t+1}-v_{0t+1},...,\\
&\phantom{\text{----}}v_{{J}t+1}+\epsilon_{{J}t+1}-v_{0t+1}\}\\
V_{t+1}&=v_{0t+1}+\mathbb{E}\max\{\epsilon_{0t+1},\psi_0^1(p_{t+1})+\epsilon_{1t+1},...,\psi_0^{{J}}(p_{t+1})+\epsilon_{{J}t+1}\}
\end{align*}

The \(p\)'s can be taken from the data.  However:

\begin{enumerate}
\item We need the mapping, \(\psi\),
\item We need to be able to calculate the expectations of the \(\epsilon\)'s
\item We need to do something with the \(v_0\)'s
\end{enumerate}
\end{document}


\chapter{Literature Review}

\section{Tensegrity Structures}
It is possible to design free-standing structures with axially loaded compression elements in a well crafted network of tensional elements.
Such an arrangement is called a tensegrity structure (tensile integrity).
Each element of the structure experiences either pure axial compression or pure tension \cite{BuckminsterFuller1975}\cite{Snelson1965}.
The absence of bending or shear forces allows for highly efficient use of materials,
resulting in lightweight, yet robust systems.

Because the struts are not directly connected,
tensegrities have the unique property that externally applied forces distribute through the structure via multiple load paths.
This creates a soft structure, for a soft robot, out of inherently rigid materials.
Since there are no rigid connections within the structure, there are also no lever arms to magnify forces.
The result is a global level of robustness and tolerance to forces applied from any direction.

%Tensegrity structures are composed of axially loaded compression elements encompassed within a network of tensional elements, and thus each
%element experiences either pure linear compression or pure tension.  As a result, individual elements can be extremely lightweight as there are no
%bending or shear forces that must be resisted.  Because the struts are not directly connected, a unique property of tensegrity structures is how externally applied forces distribute through the structure
%via multiple load paths, creating a system level robustness and tolerance to forces applied from any direction.
%Because there are no rigid connections within the structure, there are also no lever arms to magnify forces.  Instead, all experienced forces act linearly on each structural element.  Combined with the ability to diffuse forces globally,
This makes tensegrity robots inherently compliant and extremely well suited for physical interactions with complex and poorly modeled natural environments.
Active motion in tensegrity robots can be performed by changing cable lengths in parallel,
enabling the use of many small actuators that work together, rather than individual heavy actuators which work in series.
There are also many indications that tensegrity properties are prevalent throughout biological systems,
and the morphology of the SUPERball that we are studying,
especially when carrying a payload,
ends up bearing a striking resemblance to the nucleated tensegrity model of cell structure~\cite{Wang2009}\cite{Wang2001}.

\section{Prior Work in Tensegrity Robotics Design}
An important advantage of tensegrity structures with respect to general pin-jointed structures is their increased mass-efficiency due to a high fraction of tensile members.
Tensile members are generally more mass-efficient as they do not need to resist buckling.
A further advantage from a robotics perspective is that forces diffuse in a tensegrity.
There are no lever arms and torques do not accumulate at the joints as in a classic serial manipulator.
Forces distribute through multiple load paths, thus increasing robustness and tolerance to mechanical failure.

%advantages
%applications
The static properties of tensegrities have been thoroughly studied and some basic analysis is discussed in section \ref{modeling}.
On the other hand, few examples are known of truly dynamic motion of these structures.
Early examples of kinematic motion include the work at EPFL's IMAC laboratory~\cite{Fest2004}.
Skelton and Sultan introduced algorithms for the positioning of tensegrity based telescopes and the dynamic control of a tensegrity flight simulator platform~\cite{sultan2000tensegrity}.
Although there were some early efforts at MIT's CSAIL lab, it wasn't until the work of Paul and Lipson at Cornell University that the concept of tensegrity robotics became widespread~\cite{Paul2006a}.
Paul and Lipson were the first to study the properties of dynamic tensegrity structures in hardware and simulation.
A few years later Fivat and Lipson designed the IcoTens, a small actuated tensegrity icosahedron robot, but did not publish results.
In recent years, the BIER lab at the University of Virginia has been studying Central Pattern Generator based control for tensegrity based fish tails,
which is closely related to the control architectures proposed for SUPERball~\cite{Caluwaerts2013rsif,Bliss2012}.
Mirats-Tur has presented design and controls work on various other tensegrity morphologies that have been tethered or fixed to the ground~\cite{GraellsRovira2009,miratstur2011athree-dof}.
At Union College, Rieffel and colleagues are following an interesting line of work by considering vibration based actuation for small tensegrities~\cite{khazanov2014developing}.
Related work was presented by B\"ohm and Zimmermann, who demonstrated controlled locomotion of vibration driven tensegrity robots with a single actuator~\cite{bohm2013vibration}.
Finally, Shibata, Hirai and colleagues have developed pneumatically actuated rolling tensegrity structures~\cite{Shibata2009}.
%goal

Building upon these works, the \SB{} project seeks to push forward the tensegrity robotics field and develop truly untethered, highly dynamic and compliant robots exploiting the aforementioned advantages.

\section{Tensegrity Robotics for Space Exploration}
%NASA is supporting research into tensegrity robotics to create robots with many of the same qualities that benefit biological systems.
The high strength-to-weight ratio of tensegrity structures is very attractive due to the impact of mass on mission launch costs.
Large tensegrity structures have been shown to be deployable from small compact configurations which enable them to fit into space constrained launch fairings.
While the above qualities have inspired studies of deployable antennae and other large space structures~\cite{Tibert2002},
it is in the realm of planetary exploration that we see the most significant role for many of the unique force distribution qualities of tensegrity robots.
The NIAC project currently funding this research~\cite{NIACfinalreport} specifically studies landing and surface mobility of tensegrities,
exploiting the controllable compliance and force distribution properties which make for reliable and robust environmental interactions.

The main goal is to develop tensegrity probes with an actively controllable tensile network
 to enable compact stowage for launch, followed by deployment in preparation for landing.
Due to their natural compliance and
structural force distribution properties, tensegrity probes can safely absorb
significant impact forces, enabling high speed Entry, Descent, and Landing
(EDL) scenarios where the probe itself acts much like an airbag.  However,
unlike an airbag which must be discarded after a single use, the tensegrity
probe can actively control its shape to provide compliant rolling mobility
while still maintaining the ability to safely absorb impact shocks that might
occur during exploration.  This combination of functions from a single
structure enables compact and lightweight planetary exploration missions
with the capabilities of traditional wheeled rovers, but with a mass and
cost similar or less than a stationary probe.

Therefore, a large fraction of the overall weight (as measured at atmospheric entry) of a tensegrity mission can be used for the scientific payload
due to the dual use of the structure as a lander and a rover.
This allows for cheaper missions and enable new forms of surface exploration that utilize the natural tolerance to impacts of tensegrities~\cite{Vytas_IPPW_2013}.

% Because  of  the  limited  research  into  actuated  tensegrity
% robotics,   many   design   aspects   have   yet   to   be   carefully
% studied. To date, the majority of constructed tensegrity robots
% have  been  simple  prototypes  using  servo  motors,  limited
% sensing,  and  are  often  tethered  for  power  and  control  [5].
% Others have had fewer limbs than the SUPER ball, or have
% been  secured  to  the  ground  as  opposed  to  free-standing
% [6][7]. Some related approaches utilize tensegrity as part of a
% larger, more complicated system, but not as the primary loco-
% motion method [8]. Others have created designs that do not
% use direct cable actuation, as in the SUPER ball, but instead
% have  more  limited  forms  of  locomotion  through  vibration
% [9][10]. Finally, the most similar designs to the SUPER ball
% have not been engineered to specific design requirements nor
% have  the  advanced  sensing  framework  needed  for  controls
% testing [11]
%
% The  high  strength-to-weight  ratio  of  tensegrity  structures
% is very attractive due to the impact of mass on mission launch
% costs.  Large  tensegrity  structures  have  been  shown  to  be
% deployable from small compact configurations which enable
% them to fit into space constrained launch fairings. While the
% above qualities have inspired studies of deployable antennae
% and  other  large  space  structures  [12],  it  is  in  the  realm
% of  planetary  exploration  that  we  see  the  most  significant
% role  for  many  of  the  unique  force  distribution  qualities  of
% tensegrity  robots.  A  recent  NIAC  project  [13]  specifically
% studies  landing  and  surface  mobility  of  tensegrities,  ex-
% ploiting  the  controllable  compliance  and  force  distribution
% properties which make for reliable and robust environmental
% interactions.
% The   main   goal   is   to   develop   tensegrity   probes   with
% an  actively  controllable  tensile  network  to  enable  compact
% stowage  for  launch,  followed  by  deployment  in  preparation
% for  landing.  Due  to  their  natural  compliance  and  structural
% force  distribution  properties,  tensegrity  probes  can  safely
% absorb significant impact forces, enabling high speed Entry,
% Descent, and Landing (EDL) scenarios where the probe itself
% acts  much  like  an  airbag.  However,  unlike  an  airbag  which
% must  be  discarded  after  a  single  use,  the  tensegrity  probe
% can  actively  control  its  shape  to  provide  compliant  rolling
% mobility  while  still  maintaining  the  ability  to  safely  absorb
% impact  shocks  that  might  occur  during  exploration.  This
% combination  of  functions  from  a  single  structure  enables
% compact and lightweight planetary exploration missions with
% the capabilities of traditional wheeled rovers, but with a mass
% and cost similar or less than a stationary probe.
%
% Therefore, a large fraction of the overall weight (as mea-
% sured  at  atmospheric  entry)  of  a  tensegrity  mission  can  be
% used  for  the  scientific  payload  due  to  the  dual  use  of  the
% structure  as  a  lander  and  a  rover.  This  allows  for  cheaper
% missions  and  enable  new  forms  of  surface  exploration  that
% utilize the natural tolerance to impacts of tensegrities [14].
%
% Buckminster Fuller [1] and the artist Kenneth Snelson [2]
% initially  explored  tensegrity  structures  in  the  1960s.  Until
% the  mid-1990s  the  majority  of  tensegrity  related  research
% was  concerned  with  form-finding  [15]  and  design  analysis
% of  static  structure  [16][17].  More  recently,  active  control
% efforts  for  tensegrities  began  to  emerge  [18],  as  well  as
% descriptions  of  the  dynamics  of  tensegrity  structures  taking
% the connectivity pattern into account [17].
% The tensegrity principle allows for compliance and multi-
% path load distribution, which is ideal for physical interaction
% with  the  environment.  However,  these  aspects  also  present
% significant  challenges  to  traditional  control  approaches.  A
% recent  review  [19]  shows  that  there  are  still  many  open
% problems in actively controlling tensegrities, especially when
% interacting  with  an  environment  during  locomotion  or  ma-
% nipulation  tasks.  Though  work  has  been  done  to  control  a
% tensegrity  to  change  into  a  specified  shape  [20],  practical
% determination  of  the  desired  shape  itself  is  an  ongoing
% challenge.  Recently,  locomotion  of  icosahedral  tensegrity
% robots  through  body  deformation  was  demonstrated  [21].
% Other work has addressed collision between rigid tensegrity
% elements during control generation [22][23].
% The  approach  taken  by  the  NASA  Dynamic  Tensegrity
% Robotics  Lab  builds  on  this  by  developing  body  defor-
% mation  control  algorithms  based  on  central  pattern  gen-
% erators  [24][25],  distributed  learning,  reservoir  computing,
% and  genetic  algorithms  [26],  instead  of  traditional  linear
% and  nonlinear  systems  approaches.  To  date,  our  approach
% has  shown  promising  results  at  productively  harnessing  the
% potential  of  complex,  compliant,  and  nonlinear  tensegrity
% structures.

% \section{Motivation an Goal}


% !TeX root = ../solution.tex

\hypertarget{he22.06}{%
\chapter{[HE22.06] Fibonacci Rabbits}\label{he22.06}}

\begin{marginfigure}
	\includegraphics[width=49mm]{level3/challenge6.jpg}
\end{marginfigure}
\subsection{Intro}
Everyone loves rabbits!

\noindent\url{http://46.101.107.117:2201}

\noindent
Note: The service is restarted every hour at x:00.

\section{Solution}\label{hv21.06-solution}

Looking at the source code of the page, we see a list of images to be
displayed:

\noindent\begin{fullwidth}
{\footnotesize\begin{verbatim}

Petal

Harley

Rosie

Petunia

Mortimer

Henry

Miffy

E.B.

Baxter

Archie

Murphy

Doc

Hopper

Fluffy

Daffodil

Buttons

Freddie

Roger

Bucky

Oliver

Olive

Bugs

Flower

Chester

Bubbles

Coco

Clover

\end{verbatim}
}
\end{fullwidth}

\noindent
The file names have an numbering that follows the Fibonacci series, so ordering
them by the number shows that the file \verb+rabbit-196418.jpg+ is missing.
Have a look at it\\
\noindent\verb+he2022{th1z_41nT_4_r4bB1T!}+

\begin{marginfigure}
	\includegraphics[width=50mm]{level3/rabbit-196418.jpg}
\end{marginfigure}


\documentclass{report}

\usepackage{tikz}
\usepackage{graphicx}
\usepackage{amsmath}
\usepackage{palatino}
\usepackage{siunitx}
\usepackage{hyperref}
\usepackage{listings}

% tables
\usepackage{booktabs}
\usepackage{tabularx}

% begin tikz
\usepackage{tikz}
\usetikzlibrary{graphs,graphdrawing,matrix,decorations.pathreplacing}
\usegdlibrary{layered}
% end tikz

% biblio
\usepackage[style=authoryear]{biblatex}
\addbibresource{references.bib}

\input{macros.tex}

\title{Moist Convection ML}
\author{Noah D. Brenowitz}
\date{\today}
\usepackage{dsfont}
\newcommand{\1}[1]{\mathds{1}\left[#1\right]}
\begin{document}
\maketitle
\tableofcontents

\chapter*{Notation and Physical Constants}
\label{ch:notation}
\begin{table}
  \centering
  \begin{tabularx}{\textwidth}{lX}
    \toprule
    Symbol & Description\\
    \toprule
    $n$ & number of samples \\
    $m$ &  number of features\\
    $X$ & $s \times m$ data matrix of predictors\\
    $Y$ & $s \times \cdot $ data matrix of predictands\\
    \bottomrule
  \end{tabularx}

  \caption{List of common notations}
  \label{tab:constants}
\end{table}

\begin{table}
  \centering
  \begin{tabularx}{\textwidth}{lcX}
    \toprule
    Variable & Value & Description\\
    \toprule
    $c_p$ & \SI{1004}{J/K/kg} & Heat capacity of air\\
    $L_v$ & \SI{2.5e6}{J/kg} & Latent heat of vaporization\\
    \bottomrule
  \end{tabularx}

  \caption{List of physical constants}
  \label{tab:constants}
\end{table}
\chapter{Introduction}

\chapter{Training Data}

\section{System for Atmospheric Modeling}
\label{sec:sam}

The System for Atmospheric Modeling (SAM) uses a different set of prognostic
equations \autocite{Khairoutdinov2003}. These are given by

\begin{subequations}
  \label{eq:sam}
  \begin{align}
    &\totd{\bu}{t} + ( f  + \beta y) \mathbf{k}\times \bu = - \nabla \phi \\
    &\totd{w}{t} = -\nabla \phi + g B \label{eq:w-full}\\
    &\totd{h_L}{t}  = Q_{rad}  - \frac{1}{\rho_0} \pd{}{z} \left( L_c P_r + L_s P_s + L_s P_g \right)\\
    &\totd{q_T}{t} = -  \dot{q}_p^{\text{micro}} \label{eq:sam-qT}\\
    &\totd{q_p}{t} = \frac{1}{\rho_0} \pd{}{z} \left(  P_r +  P_s + P_g \right) + \dot{q}_p^{\text{micro}}\\
    &\nabla \cdot \bu + \frac{1}{\rho_0} \pd{\rho_0 w}{z}  = 0.
  \end{align}
\end{subequations}
I have neglected the sub-grid-scale flux terms in the formulation above since
they are not relevant to the problem considered in this report. The temperature
and humidity variables introduced in the previous section have been replaced
here by
\begin{description}
\item[Liquid/ice water static energy] $h_L = c_p T +gz - L_c (q_c + q_r) - L_s
  (q_i + q_s + q_g)$,
\item[Total nonprecipitating water] $q_T = q_v + q_c + q_i$, and
\item[Total precipitating water] $q_p = q_r + q_s + q_g$.
\end{description}
Note that $h_L$ is only an appropriate variable when hydrostatic balance or
anelastic equations are satisfied. Otherwise, potential temperature should be
used. There are a number of diagnostic equations which can be solved to
determine the temperature, and all the mixing ratios for the different species
of precipitating and non-precipitating water. Perhaps most importantly, the
water vapor is assumed to be at or below an approximate saturation value so that
\[q_v = \min(q_T, q_{sat}(p_0, T)),\]
where
\[ q_{sat} = q_{sw} (1-\omega_i) + \omega_i q_{si}\]
is a convex combination of the saturation mixing ratios of vapor with respect to
ice and liquid water.

A consequence of this diagnostic relation is that the latent
heating term due to condensation is not explicitly calculated. Instead, SAM
models the microphysical processes which govern the conversion from condensate
($\text{cloud water} + \text{cloud ice}$) to precipitation ($\text{rain} +
\text{snow} + \text{grauppel}$). These processes are given by
\[
  \dot{q}_p^{\text{micro}} = \text{accretion} - \text{evaporation} + \text{autoconversion}.
\]
A nice paper by \textcite{hernandez-duenas_minimal_2013} contains a more thorough
discussion of a similar set of microphysical equations, which can be helpful for
gaining intuition. Additional details about the diagnostic relations linking the
water species and the prognostic variables $q_T$, $h_L$, and $q_p$ are available
in Appendix \ref{sec:diag-q} and in the original SAM paper by \textcite{Khairoutdinov2003}.

This formulation is convenient for numerical modeling purposes, but
moist-convective processes are often understood as a coupling between dry
dynamics and moist variables because the bouyancy is related primarily to
temperature, rather than moist static energy.
For instance, the circulation due to the monsoons and MJO can be understood
roughly as the response to a imposed heating pattern \autocite{Gill1980}, and
the multiscale theories of Biello and Majda rely upon asympotic analysis of the
latent heating.

\section{Near-global Model Configuration}
\label{sec:model-config}

We configure the model in the same way as \textcite{Bretherton2015}.

The size of the domain is (5120, 2560) grid points with a grid size of
\SI{4}{\km}, which in physical units is \SI{20480}{\km} by \SI{12800}{\km}.
We define the central 2560 kilometers in the y-direction as the tropics.
This is 16 coarse grained grid boxes out of total of 64, which is [24, 40) in
0-indexed notation.

\begin{figure}[ht]
  \centering
  \includegraphics{images/cld.png}
  \caption{\label{fig:cld}Snapshot of the cloud cover fraction field from the NGAqua simulation.}
\end{figure}

% \begin{tikzpicture}[scale=.5]
%   \draw (0,0) rectangle (20.480, 12.800);
%   \draw[step=.160] (0,0) grid (20.480, 12.800);
% \end{tikzpicture}

\section{Data Availability}

The coarse-grained NGAqua data is available on the olympus file server in the UW Atmospheric Sciences department as well as in a google cloud storage bucket:
\verb|nbren12-largedata/data/id/726a6fd3430d51d5a2af277fb1ace0c464b1dc48|

\section{Model Outputs}

The model outputs a collection of three dimensional and two dimensional fields
at a sampling interval of three hours.
Because the model uses an Arakawa C-Grid, some of the variables are staggered
while others are centered.
Figure \ref{fig:arakawa-c-grid} provides an illustration of this.

\begin{figure}
  \centering

  \begin{tikzpicture}[scale=2]

    \draw (-1, 0) -- (3,0);
    \draw (0, -1) -- (0,3);
    \draw (2, -1) -- (2,3);
    \draw (-1, 2) -- (3,2);

    \node at (1,1) {$q_v$, $q_p$, $q_n$, $\phi$, $s_l$};
    \node[fill=white] at (1,0) {$u_{i}$};
    \node[fill=white] at (1,2) {$u_{i+1}$};
    \node[fill=white] at (2,1) {$v_{i+1}$};
    \node[fill=white] at (0,1) {$v_{i}$};
  \end{tikzpicture}

  \caption{Arakawa C-Grid.
    The velocities are represented on the faces, while the scalar quantities are
    cell-centered.
    This plot only shows the horizontal grid, but the vertical velocity $w$ is
    staggered in the vertical direction.}
  \label{fig:arakawa-c-grid}
\end{figure}

\section{Coarse-graining and Destaggering}
\label{sec:post-processing}

The main post processing steps are

\begin{enumerate}
\item Coarse-graining, and
\item computing the apparent heat and moisture source due to convection.
\end{enumerate}

The coarse graining procedure is relatively straightforward.
SAM outputs the data on a grid with a \SI{4}{\km} resolution.
We can describe this coarse-graining mathematically.
Let $f(x,y,z,t)$ be some three dimensional field outputed by the atmospheric
model.
Then, divide the domain into coarse grained grid boxes $C_{i,j}$ which represent the
typical GCM grid box. These grid boxes are defined by

\[
  C_{i,j} = \{(x,y):   j \Delta x \leq x < (j+1) \Delta x
  \quad \cap\quad j \Delta y \leq y < (j+1) \Delta y \},
\]
where $\Delta x$ and $\Delta y$ are the size of the GCM grid box (e.g.
\SI{160}{\km}). Averaging over these grid boxes gives the coarse-grained field
\[
  \overline{f}_{i,j} = \int_{C_{ij}} f dA.
\]

\begin{figure}
  \centering
  \begin{tikzpicture}
    \draw (0,0) rectangle (6,6);
    \draw[step=1.5mm] (0,0) grid (6,6);
    \draw[decorate,decoration={brace,amplitude=10pt,mirror,raise=4pt}] (0,0) -- (6,0);
    \node at (3,-.7cm) {$\Delta x = \SI{160}{\km}$};
  \end{tikzpicture}
  \caption{Coarse-graining procedure. The coarse-grained grid boxes have a
    length of \SI{160}{km} and contains $40^2$ fine scale grid boxes.}
  \label{fig:coarse-grain}
\end{figure}

Figure \ref{fig:preprocess} contains a flow chart describing the preprocessing pipeline.

\begin{figure}
  \centering
  \begin{tikzpicture}[ every node/.style={draw} ]
    \graph[layered layout]{

      Input data -> Destagger $u$ and $v$ -> a/ Coarse grain all variables;
      Input data -> a; a -> w/Destagger coarse grained $\overline{w}$; {a, w} ->
      Reshape data and fit models!

    };
  \end{tikzpicture}

  \caption{Preprocessing pipeline flowchart}
  \label{fig:preprocess}
\end{figure}
\section{Apparent Heating and Moistening}
\label{sec:q1q2}

In SAM, the conserved variables are the liquid-ice static energy and the total non-precipitating water. The liquid static energy is given in temperature units by
\[ s_l = T + \frac{g}{c_p} z - L_c(q_n + q_p),\]
where $q_n$ is the total cloud condensate, $q_p$ is precipitation, and $L_c$ is the latent heat of condensation. This definition is an approximation which neglects the presence of the frozen phase of water. The total water non-precipitating water is just given by
$q_t = q_v + q_n.$

Then, for our purposes, the apparent heat source is given by
\[Q_1 = \partial_t {\bar{s}_l} + \overline{ \mathbf{v} }\cdot \overline{\nabla} \bar{s}_l, \]
and the apparent drying is given by
\[Q_2 = - \frac{L_c}{c_p} \left[\partial_t {\bar{q}_t} +\overline{ \mathbf{v} } \cdot \overline{\nabla} \bar{q}_t\right].\]
The factor $-\frac{L_c}{c_p}$ is used to ensure that this quantity also has units K/day. Comparing to the original prognostic equations for SAM shows that $Q_1$ contains the source term  $Q_r$ to the temperature equation which represents radiative transfer, which is usually a cooling tendency. For the purposes of cumulus parametrization, it might be possible to assume this is known from other sources (e.g. a radiative transfer code such as RRTMG). Therefore, we will also define the convective component of the apparent heating as $Q_{1c} = Q_1 - Q_r$.

All the differential operators in these two expression represent a finite
differencing taken on the coarse grid, and we will use centered differences to
compute these. Specifically, the formulas for the advection terms are given
by
\renewcommand{\bf}{\bar{f}_{i,j}}

% \[(A_f)_{i,j} = \left( \bar{f}_{i+1,j,k} - \bar{f}_{i-1,j,k} \right) \frac{\bar{u}_{i,j,k}}{2 \Delta x}
%               + \left( \bar{f}_{i,j+1,k} - \bar{f}_{i,j-1,k} \right) \frac{\bar{v}_{i,j,k}}{2 \Delta y}
%               + \left(  \bar{f}_{i,j,k+1} - \bar{f}_{i,j,k-1} \right) \frac{\bar{v}_{i,j,k}}{z_{k+1} - z_{k-1}}
%             \]

\begin{align}
  (A_f)_{i,j,k} = &\left( \bar{f}_{i+1,j,k} - \bar{f}_{i-1,j,k} \right) \frac{\bar{u}_{i,j,k}}{2 \Delta x}\\
              +&\left( \bar{f}_{i,j+1,k} - \bar{f}_{i,j-1,k} \right) \frac{\bar{v}_{i,j,k}}{2 \Delta y}\nonumber\\
              +& \left(  \bar{f}_{i,j,k+1} - \bar{f}_{i,j,k-1} \right) \frac{\bar{w}_{i,j,k}}{z_{k+1} - z_{k-1}}.\nonumber
\end{align}
We have taken advantage of the constant horizontal grid spacing and the
collocation of all the coarse grained variables.

The numerical estimates of $Q_1$ and $Q_2$ depend on these simple expressions.
The apparent heating is given by
\begin{equation}
  \label{eq:q1-num}
  Q_1^{n+1/2} = \frac{\bar{s_l}^{n+1} - \bar{s_l}^{n} }{\Delta t}
            +  A^{n}_{s_l} .
\end{equation}
where the spatial index $i,j,k$ has been dropped. Similarly, the apparent
drying is given by
\begin{equation}
  \label{eq:q2-num}
  -\frac{c_p}{L_v} Q_2^{n+1/2} = \frac{\bar{q_T}^{n+1} - \bar{q_T}^{n} }{\Delta t}
            +  A^{n}_{q_T} .
\end{equation}
The factor $\frac{c_p}{L_v}$ ensures that $Q_2$ has units of temperature over
time, just like $Q_1$. These and other important physical quantities are
described in \autoref{tab:constants}.

\section{Reshaping data}

Most machine learning algorithms require two dimensional matrices as inputs, but
the SAM produces four-dimensional datasets of humidity, temperature, and other
atmopsheric variables.
To reshape this multivariate three-dimensional data into a single vector for
machine learning, we must define which dimensions of data are physically
relevant.
We call these ``feature dimensions'' and the remaining non-relevant dimensions
``sample dimensions''. The columns of the two-dimnsional data matrix $X$ will
correspond to samples taken along the sample dimensions, and the rows will
correspond to data taken from the feature dimensions.

Because the time-scale of deep atmopsheric convection is so fast, the inputs for
the convection scheme should be non-local in the vertical direction, so the only
feature dimension is $z$.
The remaining dimensions of the data---$x$, $y$, and time---are the sample
dimensions.
Therefore, given a single field of the data $f[x,y,z,t]$, then a particular sample vector
\[
  \mathbf{f}[x,y,t] =
    \begin{bmatrix}
      f[x,y,1,t] \\
      f[x,y,2,t] \\
      \vdots\\
      f[x,y,n_z,t]
    \end{bmatrix}
\]
is defined for each horizontal location and time point. Then, we can tabulate
all these vectors in a two dimensional array given by
\newcommand{\fb}{\mathbf{f}}
\[
  X_f =
  \begin{bmatrix}
    \fb[1,1,1], \fb[2,1,1], \ldots,\fb[x,y+1,t], \fb[x+1,y+1,t],\ldots,\fb[n_x, n_y,
    n_t]
  \end{bmatrix}
\]

In addition to being 4 dimensional, the data are multivariate, and contains
multiple atmopspheric fields, with different physical units. For most of our
analysis, we use $q_T$ and $s_L$ to predict the amount of latent heating due to
convection. To handle the multivariate case, we simply stack the data matrices
for each variable vertically, so that the full data matrix $X_{\{s_l, q_T\}}$ is given by
\[
  X_{\{s_l, q_T\}}=\begin{bmatrix}
    X_{s_l}\\
    X_{q_T}
  \end{bmatrix}.
\]
We define data matrices for more than two variables.

Finally, we must introduce the temporal shifting operator, which we will use to
create models for the dynamics. When time is the only sample dimension, this
operator is trivial, but having multiple sample dimensions complicates matters.
In any case, the time shifting  operator $L$ is defined by
\[
  LX =
  \begin{bmatrix}
    \mathbf{x}[1,1,2],\ldots,\mathbf{x}[x, y, t+1], \ldots, \mathbf{x}[n_x, n_y, t]
  \end{bmatrix}.
\]
Because we use this operator extensively below, we will adopt the notation that $X' =
LX$, so that $X'$ are the data shifted forward by one time sample.

\chapter{Methods}

\section{Machine Learning for dynamical systems}

The ultimate goal of this work is to estimate or simulate the unknown source
terms. Essentially we need an effective way to draw samples
from
\[ \rho(x_{t+\Delta t}, t + \Delta t |x_{[s < t]}).\] There are two clear problems here.
First, this probability distribution depends on the whole time course of
$x$ leading up to time $t$.
Ideally we want to create a Markov description of the data, a task which is
known as \emph{embedding}.
Supposing $z_t$ is a suitable embedding of $x_t$---Takens''' delay embedding is a natural choice---the conditional pdf becomes
\[\rho(z_{t+\Delta t}, t+ \Delta t| z_t, t),\]
and we must characterize this conditional density.
We also might prefer to use the infinitesmimal generator
\[L_z = \lim_{\Delta t \rightarrow 0} \frac{\rho(z_{t+\Delta t}, t+ \Delta t| z_t,
    t) - \delta(z_{t+\Delta t} - z_t) }{\Delta t}.\]

There are also a series of functions $f_i$ which we trust capture some aspect of
the dynamics.
For example, we should trust the dynamical core, turbulence, and radiation
schemes, and not attempt to \emph{learn} a GCM from scratch.
But the functions $f_i$ are not specified in the pdf at all, and we might not
even know them with perfect accuracy. We can include them in the statistical
model as follows
\[\rho(z_{t+\Delta t}, t+ \Delta t| z_t, y_i, t) p(y_i|z_t, t) \]
where $y_i = f_i(z_t) + \epsilon_i$.

\section{Maximum Covariance Analysis}
\label{sec:mca}

Maximum Covariance Analysis (MCA) finds the modes which maximize the cross
covariance between an input matrix $X$ and output matrix $Y$.
If the mean of $X$ and $Y$ along the columns vanishes, then the covariance
matrix is given by
\[C=X'Y.\]
Then, we take an SVD of this matrix to get
\[C=U\Sigma V'.\] We will call the columns of $U$ the input \emph{loadings}, and
the columns of $V$ the output loadings.
The loading vectors each orthornmal bases of the input and output features
spaces.
By projecting the data onto these loadings, we obtain the input and output
\emph{scores}, which are respectively defined by $S_x = X U''''''$ and $S_y=YV'$.

For our analysis, we consider the case where $X$ is the matrix of
horizontal-temporal samples of profiles of $q_T$ and $s_L$, and $Y$ contains
samples of $Q_{1c}$ and $Q_2$. In other words, there are $2\cdot n_z$ columns of
$X$ and $Y$ corresponding. Moreover, the columns of $X$ and $Y$ are weighted by
the square root of the corresponding layer mass. The behavior of the NGAqua
dataset appears to reduce to a two mode structure, and we show the behavior of
these two modes in Figures \ref{fig:mca-loadings} and \ref{fig:mca-ts}.

\begin{figure}
  \centering
  \includegraphics[height=5in]{images/mca_modes.pdf}
  \caption{Loadings for first two MCA modes.}
  \label{fig:mca-loadings}
\end{figure}
\begin{figure}
  \centering
  \includegraphics[width=\textwidth]{images/mca_ts.png}
  \caption{Time series of first MCA mode scores for a single location at the
    equator.
    Input scores (top) and output scores (bottom).
    The sign and amplitude of these modes is given by the raw output of the
    scheme, and does not correspond to the plots in \autoref{fig:mca-loadings}.}
  \label{fig:mca-ts}
\end{figure}

\section{Linear models}

\begin{figure}[ht]
  \centering
  \includegraphics[width=\textwidth]{images/lrf_lm.png}
  \caption{\label{fig:lrf-lm}Linear response matrix for linear regression
    pipeline.
    The full outputs are regressed onto the columns of $X$ with a variance
    larger than .001.
    This thresholding procedure ensures that the uppper atmosphere
    moistures---which vanishes---does not enter the regression analysis.}
\end{figure}

\begin{figure}[ht]
  \centering
  \includegraphics[width=\textwidth]{images/lrf_mca4.png}
  \caption{\label{fig:lrf-mca}Linear response matrix for MCA linear regression
    pipeline.
    The first step is to compute the X scores, and then the full Y outputs are
    regressed onto these scores.}
\end{figure}

\begin{figure}[ht]
  \centering
  \includegraphics[width=5in]{images/mca-regression-coef}
  \caption{\label{fig:mca-regression-coef}Regression coefficients for each
    whitened MCA mode.
    These are the resulting heating patterns if the z-score of the given mode is
    1.0.
    These patterns do not need to look like output loadings shown in
    \autoref{fig:mca-loadings}, despite their similarity.}
\end{figure}

\section{Time stepping with Neural Networks}

The data we are using are only evaulated with a coarse sampling time step of 3 hours. On the other hand, we will probably use 10-20 minute time step for the coarse resolution model. This means that the dynamical model we are trying to fit is
$$ x^i_{n+1} = \underbrace{f(f(\ldots f}_{\text{m times}}(x^i_n))) + \int_{t_n}^{t_{n+1}} g(x(t), t) dt$$
where $i$ is the horizontal spatial index, and $n$ is the time step. The number of times the function $f$ is applied is $m=\frac{\Delta t}{h}$ where $h$ is the GCMs time step, and $\Delta t$ is the sampling interval of the stored output. The integral on the right represents the approximately known terms such as advection, and $f$ represents the unknown source terms.

We solve a minimization problem to find $f$. This is given by
$$
\min_{a} \lim_{m \rightarrow \infty} \sum_{i,n} ||x^{i}_{n+1} - F^{(m)} x^i_{n} - g_n^{i}||_W^2 \quad \text{s.t.}\quad F^{(m)}(\cdot) = \underbrace{f(f(\ldots f}_{\text{m times}}(\cdot))),\ f(x) = x +  \frac{ \Delta t}{m} a(x).
$$
Intuitively, the forward operator $F^{(m)}$ is the result applying $m$ forward euler steps to the system $a$.

Let's try performing this fit. First, we need to import the appropriate models, and load the data

\subsection{Literature Review}
\label{sec:blowup-rnn}

Unfortunately, applying a function repeatedly like often causes solutions to
explode.
This issue is discussed known in recurrent neural network (RNN) community
\autocite[See Ch.
10.7]{Goodfellow2016}.
They discuss something known as Echo State Networks (ESN), which must repeatedly
confront this issue. Apparently, this blow up can be controlled in two ways.
\begin{enumerate}
\item Control the spectral radius of the Jacobian. I.e. ensure that
  \[\rho \left( \frac{\partial x^{n+1}}{\partial x^n} \right) < 1\]

\item Use squashing nonlinearities like $\tanh$, and allow larger spectral radius.
\end{enumerate}

I still need to figure out how exactly they control the spectral radius of
neural network.

The deep learning literature discusses the issue of exploding gradients as more
an issue with back-propagation of gradients than forward propagation or
predictions. However, I think the solutions are the same.

\section{Time stepping}

Want to formulate a neural network scheme which has inputs that do not depend on the time step.
The various physical processes in a climate model update the state sequentially, so that each process sees a state updated by the previous process.
Unfortunately, these processes can dramatically change the state by up to a few degrees K over a large time step, which makes the inputs for the neural networks scheme depend on the time step.
This is not much of an issue for physics based parameterizations, but machine learning schemes cannot be extrapolated to different time steps then they were trained on if their inputs depend on the time steps.
Therefore, we need to make the inputs to an ML scheme invariant to the time step, which we accomplish with the following time-stepper
\begin{align}
 x^* &= x + h g(x, t) \\
 x^{+} &= x^* + h f(x, g(x, t), t; \alpha).
\end{align}

\section{Enforcing physical constraints}

\subsection{Positive humidity}

We would like to ensure that $q> 0$ in a mass conserving way so that it doesn't alter the precipitation.
To do this, we first assume that
\[ Pq =
  \begin{cases}
    \alpha q & q >= \epsilon \\
    \epsilon & q < \epsilon
  \end{cases}.
\]
Then, choosing
\[\alpha = \frac{\langle q \rangle - \epsilon \langle \1{q < \epsilon} \rangle}{\langle \1{q \geq \epsilon} q \rangle}\]
ensures mass conservation.

\section{Mixture model}

We first train separate models on different regions in parallel, and then switch between the networks using a mixture modeling approach.
We will divide the data into 5 meridionally overallaping regions, and then train the networks on each region in isolation. These regions are
\begin{itemize}
\item Deep tropics
\item 2 Sub-tropics regions
\item 2 mid-lat regions
\end{itemize}
Because this dataset is so large, each region will still have many sampling points, but we do not join the sub-tropcs and mid-latitude regions for the northern and southern hemisphere because there could be climatological difference between these regions.
These regions are separated by distinct rainfall regimes.

The coarse-grained indices corresponding to a given latidue is given by $a \phi / \SI{160}{\km}$ which is $\frac{a\pi}{180 \cdot 160} \phi $ if $\phi$ is in degrees. Therefore the indices of the regions above are
\begin{enumerate}
\item 0,18 (so midlat)
\item 16,28 (so sub tropics)
\item 26,38 (deep tropics)
\item 36,48 (no sub tropics)
\item 46,64 (no midlat)
\end{enumerate}

\printbibliography
\appendix

\chapter{Source code}
\label{sec:source}

% \lstinputlisting[language=python]{../lib/linear_regression.py}

\end{document}

% Local Variables:
% TeX-master: t
% TeX-PDF-mode: t
% TeX-engine: luatex
% End:


\documentclass[journal,hidelinks]{IEEEtran}
\usepackage[utf8]{inputenc}
\usepackage[
  pdftitle={Final Exam},
  pdfauthor={Andrei Purcarus},
  pdfsubject={ECSE-534 -- Analog Microelectronics}
]{hyperref}
\usepackage{graphicx}
\usepackage[all]{hypcap}
\usepackage{cleveref}
\usepackage{indentfirst}
\usepackage[per-mode=symbol]{siunitx}
\usepackage{amsmath}

\title{ECSE-534 \\ Analog Microelectronics \\ Final Exam}
\author{Andrei~Purcarus,~260631911,~\IEEEmembership{McGill~University} \\ \href{mailto:andrei.purcaruscraciun@mail.mcgill.ca}{andrei.purcaruscraciun@mail.mcgill.ca}}

\begin{document}
\sloppy

\maketitle

\section{Introduction}

\IEEEPARstart{T}{his} report follows the design, simulation, and analysis of an anti-aliasing filter for a $\Delta \Sigma$ data converter using a 0.13 micron process from IBM. We used Cadence to simulate the design in said process. The filter was required to adhere to the topology shown in \Cref{fig:filter_topology} and meet the following specifications:
\begin{itemize}
  \item A DC gain of $\SI{1}{\volt\per\volt}$.
  \item A passband from DC to $\SI{100}{\kilo\hertz}$.
  \item A maximum attenuation of $\SI{0.1}{\deci\bel}$ in the passband.
  \item A maximum phase shift of $\SI{10}{\degree}$ in the passband.
  \item A minimum attenuation of $\SI{40}{\deci\bel}$ at frequencies over $\SI{15}{\mega\hertz}$.
  \item An input resistance of at least $\SI{1}{\kilo\ohm}$.
  \item An output resistance of at most $\SI{20}{\ohm}$.
  \item An output voltage swing of $\SI{0.9}{\volt}$ around an analog ground level of $\SI{0.6}{\volt}$.
  \item A maximum RMS noise level of $\SI{100}{\micro\volt}$.
\end{itemize}

The filter must meet these specifications while driving a $\SI{1}{\pico\farad}$ load capacitance that represents the input capacitance of the $\Delta \Sigma$ data converter.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{schematics/filter_topology.png}
  \caption{A schematic of the second-order anti-aliasing filter topology.}
  \label{fig:filter_topology}
\end{figure}

To meet these requirements, we first calculated the required values for the passive components of the filter. Then, we modified the operational amplifier we designed in the past assignments to meet the specifications. Next, we assembled the filter and verified that it meets the requirements. Finally, we discussed a rough sketch of the layout of the filter.

\begin{figure*}[!htb]
  \centering
  \includegraphics[width=\textwidth]{schematics/folded_cascode.png}
  \caption{A schematic of the operational amplifier designed in past assignments.}
  \label{fig:folded_cascode}
\end{figure*}

\begin{figure*}[!htb]
  \centering
  \includegraphics[width=\textwidth]{schematics/folded_cascode_2.png}
  \caption{A schematic of the modified operational amplifier made to meet the requirements.}
  \label{fig:folded_cascode_2}
\end{figure*}

\begin{figure*}[!htb]
  \centering
  \includegraphics[width=\textwidth]{schematics/filter.png}
  \caption{A schematic of the anti-aliasing filter.}
  \label{fig:filter}
\end{figure*}

\section{Filter Design}

We first translated the given specifications into restrictions on our circuit. We started by deriving the transfer function of the filter as
\begin{align}
H(s) &= \frac{-R}{1 + s R C} \frac{1}{R/2} \frac{1/2}{1 + s R C} \\
     &= \frac{-1}{(1 + s R C)^2}
\end{align}
This result tells us that the DC gain is $-1$ and the bandwidth is given by $f_{3dB} = 1 / 2 \pi R C$.

In order to gain more insight into the operation of the filter, we added a relative mismatch $\Delta$ to the components in the feedback network. We thus obtained
\begin{align}
H(s) &= \frac{-R (1 + \Delta_R)}{1 + s R C (1 + \Delta_R) (1 + \Delta_C)} \frac{1}{R/2} \frac{1/2}{1 + s R C} \\
     &\approx \frac{-R (1 + \Delta_R)}{1 + s R C (1 + \Delta_R + \Delta_C)} \frac{1}{R/2} \frac{1/2}{1 + s R C}
\end{align}
This result tells us that the DC gain can be approximated as $-(1 + \Delta_R)$ and that there are two poles formed, one at $f_1 = 1 / 2 \pi R C$ and the other at $f_2 = 1 / 2 \pi R C (1 + \Delta_R + \Delta_C)$.

The given DC gain requirement means that the feedback resistors in the circuit must match well. In addition, the DC gain of the operational amplifier must be high, say at least $\SI{60}{\deci\bel}$.

The given attenuation requirements mean that we must have $f_{3dB} \gg \SI{100}{\kilo\hertz}$ and $f_{3db} \ll \SI{15}{\mega\hertz}$. Since a second order filter has a roll-off of about $\SI{40}{\deci\bel}$ per decade, this translates approximately to $f_{3db} < \SI{1.5}{\mega\hertz}$.

The given input resistance requirement means that $R > \SI{1}{\kilo\hertz}$. The given output resistance requirement means that we must have $2 R_{out} < \SI{20}{\ohm}$ for the operational amplifier, where $R_{out}$ is the output resistance of the amplifier in the unity gain configuration.

The given voltage swing requirements translate directly into equivalent requirements for the operational amplifier.

The given noise requirement must be separated between two sources: the thermal noise generated by the feedback network and the noise generated by the amplifier. We therefore allocate an RMS noise budget of $\SI{50}{\micro\volt}$ to each.

The RMS thermal noise generated by the feedback network can be approximated as
\begin{align}
v_{n,rms} = \sqrt{\frac{kT}{C} + \frac{kT}{4C}}
\end{align}
Therefore, we have
\begin{align}
v_{n,rms} &< \SI{50}{\micro\volt} \\
\sqrt{\frac{kT}{C} + \frac{kT}{4C}} &< \SI{50}{\micro\volt} \\
C &> \SI{2}{\pico\farad}
\end{align}

The noise generated by the amplifier is harder to quantify. However, since the feedback gain of our circuit is $1 / 2$, the output spectral noise density of the amplifier in this circuit will be equivalent to the input-referred spectral noise density measured in open loop simulation times $2$. Thus, we require an input-referred RMS noise level of at most $\SI{50}{\micro\volt} / \sqrt{2} = \SI{35}{\micro\volt}$.

Therefore, the requirements for the feedback network are
\begin{equation}
R > \SI{1}{\kilo\ohm}
\end{equation}
\begin{equation}
C > \SI{2}{\pico\farad}
\end{equation}
\begin{equation}
\SI{100}{\kilo\hertz} \ll \frac{1}{2 \pi R C} < \SI{1.5}{\mega\hertz}
\end{equation}

To minimize the size of the capacitors used, we chose to use $C = \SI{3}{\pico\farad}$. Then, to allow for at least a $\SI{20}{\percent}$ margin on the upper bandwidth, we chose to use $f_{3dB} = \SI{1}{\mega\hertz}$, and thus $R = \SI{53}{\kilo\ohm}$.

\section{Operational Amplifier Design}

From the previous section, the main requirements for the operational amplifier are a DC gain of at least $\SI{60}{\deci\bel}$, a maximum output resistance of $\SI{10}{\ohm}$ in the unity gain configuration, and an input-referred RMS noise level of at most $\SI{35}{\micro\volt}$ over the given bandwidth. In addition, we require that the unity gain frequency of the amplifier should be at least 10 times our chosen filter bandwidth, at $\SI{10}{\mega\hertz}$.

To meet these specifications, we reused the operational amplifier designed in the past assignments. A schematic is shown in \Cref{fig:folded_cascode}. This amplifier has a DC gain of $\SI{73}{\deci\bel}$, a unity gain bandwidth of $\SI{40}{\mega\hertz}$, an output resistance in the unity gain configuration of $\SI{12.9}{\ohm}$, and a total input-referred RMS noise of $\SI{65}{\micro\volt}$ between $\SI{1}{\hertz}$ and $\SI{100}{\kilo\hertz}$.

These results show that the amplifier does not meet the specifications for noise and output resistance. In order to modify the amplifier to meet the specifications, we performed a series of transformations on our initial circuit.

A noise analysis in Cadence indicated that the main contributors to the noise level were transistors $T_0$, $T_1$, $T_3$, and $T_4$, with a total contribution of $\SI{92.68}{\percent}$. Since flicker noise is inversely proportional to transistor area, we needed to scale the widths of these transistors upward. We achieved this by scaling the widths of $T_0$, $T_1$, $T_3$, and $T_4$ by a factor of $4$, and then scaling the width of $T_2$ to provide sufficient current to $T_0$ and $T_1$ to avoid disturbing the operating point of the other transistors in the circuit. This transistor ended up being scaled by a factor of $5$.
In addition, to meet the output resistance specification, we needed to scale the current in the output branch upward. We achieved this by scaling the widths of both $T_7$ and $T_{16}$ by a factor of $2$.
This also had the effect of scaling our bandwidth upward, so we scaled $C_c$ to $\SI{0.72}{\pico\farad}$ and $R_c$ to $\SI{3.3}{\kilo\ohm}$ to compensate.
The resulting amplifier is shown in \Cref{fig:folded_cascode_2}.

We then measured the amplifier's characteristics to confirm that it now met the specifications. The amplifier now had a DC gain of $\SI{77}{\deci\bel}$, a unity gain bandwidth of $\SI{53}{\mega\hertz}$, an output resistance in the unity gain configuration of $\SI{4.1}{\ohm}$, and a total input-referred RMS noise of $\SI{32}{\micro\volt}$ between $\SI{1}{\hertz}$ and $\SI{100}{\kilo\hertz}$. The first two poles were also moved to $\SI{8}{\kilo\hertz}$ and $\SI{102}{\mega\hertz}$, and the first zero was moved to $\SI{124}{\mega\hertz}$, which are very close to the values they initially had. In addition, we verified that the amplifier was still stable, with a phase margin of $\SI{57}{\degree}$.

\section{Putting It All Together}

We next assembled the circuit together as previously described. The result is shown in \Cref{fig:filter}. Note that we split the resistors into units of size $R/4$ in order to better match them in layout, and we split the capacitors into units of size $C$ for the same reason. After some testing, we also changed the value of $R$ to $\SI{40}{\kilo\ohm}$ in order to fully meet the specifications.

To test the performance of the filter, we used the circuit shown in \Cref{fig:filter_tb}, which has a load capacitance of $\SI{1}{\pico\farad}$.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{schematics/filter_tb.png}
  \caption{A schematic of the test-bench used to measure the AC and transient performance of the filter.}
  \label{fig:filter_tb}
\end{figure}

We first measured the transient performance of the filter by using a $\SI{0.9}{\volt}$ peak-peak, $\SI{10}{\kilo\hertz}$ sine wave centered around $\SI{0.6}{\volt}$ as an input. The resulting input and output are shown in \Cref{fig:filter_tran}. This figure shows that the output signal has no significant distortion even at full range. In fact, we can compute the total harmonic distortion as only $\SI{0.040}{\percent}$, which shows that the circuit meets the voltage swing requirement of the $\Delta \Sigma$ converter.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{results/filter_tran.png}
  \caption{Transient response of the filter for a $\SI{0.9}{\volt}$ peak-peak, $\SI{10}{\kilo\hertz}$ sine wave centered around $\SI{0.6}{\volt}$. The input waveform is shown in brown and the output waveform is shown in red.}
  \label{fig:filter_tran}
\end{figure}

We then measured the AC performance of the filter by using small signal analysis. The results are shown in \Cref{fig:filter_ac}. These results show that we have a DC gain of $\SI{0.99953}{\volt\per\volt}$, an attenuation of $\SI{0.053}{\deci\bel}$ and a phase shift of $\SI{8.83}{\degree}$ at $\SI{100}{\kilo\hertz}$, and an attenuation of $\SI{41.5}{\deci\bel}$ at $\SI{15}{\mega\hertz}$. Therefore, the filter meets all the AC requirements.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{results/filter_ac.png}
  \caption{AC response of the filter. The plot on the left shows the gain in $\SI{}{\deci\bel}$ and the plot on the right shows the phase in $\SI{}{\degree}$.}
  \label{fig:filter_ac}
\end{figure}

We next measured the noise properties of the filter. After running an AC noise analysis and integrating the results from $\SI{1}{\hertz}$ to $\SI{100}{\kilo\hertz}$, we obtained the results shown in \Cref{fig:filter_noise}. This figure clearly shows that we have a total RMS output noise of $\SI{66}{\micro\volt}$, which meets the specified maximum noise level for the input to the $\Delta \Sigma$ converter.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{results/filter_noise.png}
  \caption{Noise results for the filter over the bandwidth from $\SI{1}{\hertz}$ to $\SI{100}{\kilo\hertz}$.}
  \label{fig:filter_noise}
\end{figure}

Then, we measured the output resistance of the filter using the circuit shown in \Cref{fig:filter_tb_2}. With the load resistance set to $\SI{20}{\ohm}$ and the input set to $\SI{1}{\volt}$, we measured a small signal output voltage of $\SI{0.6984}{\volt}$. Using a simple voltage divider equation, we found that the output resistance of the filter was therefore $\SI{8.62}{\ohm}$, which is smaller than the maximum output resistance requirement.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{schematics/filter_tb_2.png}
  \caption{A schematic of the test-bench used to measure the output resistance of the filter.}
  \label{fig:filter_tb_2}
\end{figure}

Finally, we measured the input resistance of the filter using the circuit shown in \Cref{fig:filter_tb_3}. With the signal resistance set to $\SI{40}{\kilo\ohm}$ and the input set to $\SI{1}{\volt}$, we measured a small signal output voltage of $\SI{0.49962}{\volt}$. Using a simple voltage divider equation, we found that the input resistance of the filter was therefore $\SI{39.98}{\kilo\ohm}$, which greatly exceeds the specification.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{schematics/filter_tb_3.png}
  \caption{A schematic of the test-bench used to measure the input resistance of the filter.}
  \label{fig:filter_tb_3}
\end{figure}

\section{Layout}

Next, we planned out a rough sketch of the layout for the filter. As shown in \Cref{fig:folded_cascode_2}, we made all transistors multiples of a unit size, which reduces the error when trying to match them. We used a combination of the number of fingers to increase the length of a transistor and the multiplicity to increase the width of a transistor, thus ensuring that transistors can be made into rectangular shapes that are not too long and not too wide.

In addition, we made sure that all transistors that need to be matched have a multiplicity of at least $2$, which allows us to use a common centroid geometry to eliminate the effect of the first order component of the process gradient in producing matching error. An example of this is shown in \Cref{fig:layout_diff_pair}. In this figure, $T_0$ and $T_1$ are placed such that their centroids coincide. In addition, this figure shows the addition of dummy structures to the boundaries of the pair, which ensures that all transistors have a similar environment and thus creates a better matching. The dummy transistors would typically be connected to $V_{SS}$.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{layout/diff_pair.png}
  \caption{A common centroid layout for a differential input pair with dummy structures at the boundary. Connections are not shown.}
  \label{fig:layout_diff_pair}
\end{figure}

For the passive components, matching was also critical since it controls the DC gain of the filter. In addition, mismatches can split the poles of the filter, causing ringing to occur. To ensure that these components are matched correctly, we again split them into subcomponents of unit size and used a common centroid geometry. A sketch of the layout of the resistors in the circuit is shown in \Cref{fig:layout_res}, and a sketch of the layout of the capacitors in the circuit is shown in \Cref{fig:layout_cap}.
We note here that while the matching of components is critical, the values of the components themselves are not. Since the $\Delta \Sigma$ converter oversamples at a rate of $\SI{16}{\mega\hertz}$ and the signal bandwidth is only $\SI{100}{\kilo\hertz}$, the resulting pole at around $\SI{1}{\mega\hertz}$ can vary by $\SI{\pm 20}{\percent}$ while still producing little passband attenuation and sufficient stopband attenuation.

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{layout/res.png}
  \caption{A common centroid layout for the resistors in the filter. Connections are not shown.}
  \label{fig:layout_res}
\end{figure}

\begin{figure}[!htb]
  \centering
  \includegraphics[width=\columnwidth]{layout/cap.png}
  \caption{A common centroid layout for the capacitors in the filter. Connections are not shown.}
  \label{fig:layout_cap}
\end{figure}

\section{Conclusions}

In conclusion, we designed an anti-aliasing filter capable of acting as a preprocessor for the $\Delta \Sigma$ converter specified in the examination question. This filter meets all of the specifications. In addition, we provided a sketch of the approach we would use to lay out such a filter.

\bibliographystyle{IEEEtran}
\bibliography{IEEEabrv,references}

\end{document}


\subsection{Enumeration types}
\label{subsec:library_of_transformations:type_level_transformations:enumeration_types}

\begin{figure}[H]
    \centering
    \begin{subfigure}{0.25\textwidth}
        \centering
        \includegraphics{images/05_library_of_transformations/02_type_level_transformations/04_enumeration_types/enum_type.pdf}
        \caption{$Tm_{Enum}$ with \\$name = .\type{Example}$ and \\$values = \{ \type{OPTION\_A},$\\$ \type{OPTION\_B}, \type{OPTION\_C} \}$}
        \label{fig:library_of_transformations:type_level_transformations:enumeration_types:visualisation:ecore}
    \end{subfigure}
    \\
    \begin{subfigure}{0.65\textwidth}
        \centering
        \input{images/05_library_of_transformations/02_type_level_transformations/04_enumeration_types/enum_as_node_types.tikz}
        \caption{$TG_{EnumNodes}$ with $name = .\type{Example}$ and\\$values = \{ \type{OPTION\_A}, \type{OPTION\_B}, \type{OPTION\_C} \}$}
        \label{fig:library_of_transformations:type_level_transformations:enumeration_types:visualisation:groove_nodes}
    \end{subfigure}
    \begin{subfigure}{0.25\textwidth}
        \centering
        \input{images/05_library_of_transformations/02_type_level_transformations/04_enumeration_types/enum_as_flags.tikz}
        \caption{$TG_{EnumFlags}$ with \\$name = .\type{Example}$ and \\$values = \{ \type{OPTION\_A},$\\$ \type{OPTION\_B}, \type{OPTION\_C} \}$}
        \label{fig:library_of_transformations:type_level_transformations:enumeration_types:visualisation:groove_flags}
    \end{subfigure}
    \caption{Visualisations of the transformations of enumeration types}
    \label{fig:library_of_transformations:type_level_transformations:enumeration_types:visualisation}
\end{figure}

This section will define the transformation of an enumeration type. Within this transformation, a new enumeration type is introduced, including its possible values. The Ecore type model that introduces such a subclass is defined as follows:

\begin{defin}[Type model $Tm_{Enum}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum}
Let $Tm_{Enum}$ be the type model containing a enumeration type with identifier $name$. The values of this enumeration type are defined as part of sequence $values$. $Tm_{Enum}$ is defined as:
\begin{align*}
Class =\ &\{\} \\
Enum =\ &\{name\} \\
UserDataType =\ &\{\} \\
Field =\ &\{\} \\
\mathrm{FieldSig} =\ &\{\} \\
EnumValue =\ &\{ (name, v) \mid v \in values \} \\
Inh =\ &\{\} \\
Prop =\ &\{\} \\
Constant =\ &\{\} \\
\mathrm{ConstType} =\ &\{\}
\end{align*}
\isabellelref{tmod_enum}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{defin}

\begin{thm}[Correctness of $Tm_{Enum}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum_correct}
$Tm_{Subclass}$ (\cref{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum}) is a consistent type model in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}.
\isabellelref{tmod_enum_correct}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

A visual representation of $Tm_{Enum}$ with $.\type{Example}$ as identifier for the new enumeration type and $\type{OPTION\_A}$, $\type{OPTION\_B}$ and $\type{OPTION\_C}$ as its values can be seen in \cref{fig:library_of_transformations:type_level_transformations:enumeration_types:visualisation:ecore}. The correctness proof of $Tm_{Enum}$ is trivial, and therefore not included here. The proof can be found as part of the Isabelle validated proofs.

In order to make composing transformation functions possible, $Tm_{Enum}$ should be compatible with the type model it is combined with.

\begin{thm}[Correctness of $\mathrm{combine}(Tm, Tm_{Enum})$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum_combine_correct}
Assume a type model $Tm$ that is consistent in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}. Then $Tm$ is compatible with $Tm_{Enum}$ (in the sense of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:compatibility}) if:
\begin{itemize}
    \item The identifier of the enumeration type in $Tm_{Enum}$ is not yet an identifier for a class, enumeration type or user-defined data type in $Tm$;
    \item The identifier of the enumeration type in $Tm_{Enum}$ is not in the namespace of any class, enumeration type or user-defined data type in $Tm$;
    \item None of the identifiers in any class, enumeration type or user-defined data type in $Tm$ is in the namespace of the enumeration type in $Tm_{Enum}$.
\end{itemize}
\isabellelref{tmod_enum_combine_correct}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

\begin{proof}
Use \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_models:tmod_combine_merge_correct}. It is possible to show that all assumptions hold. Now we have shown that $\mathrm{combine}(Tm, Tm_{Enum})$ is consistent in the sense of \cref{defin:formalisations:ecore_formalisation:type_models:type_model_consistency}.
\end{proof}

The definitions and theorems for a regular subclass within Ecore are now complete.

\subsubsection{Encoding as node type}

A possible encoding for enumeration types in Ecore is using node types in GROOVE. In this case, the enumeration type itself is transformed into an abstract node type. Each value of the enumeration type is converted to its own node type, extending the abstract node type. The encoding corresponding to $Tm_{Enum}$ can then be represented as $TG_{EnumNodes}$, defined in the following definition:

\begin{defin}[Type graph $TG_{EnumNodes}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_node_types}
Let $TG_{EnumNodes}$ be a type graph containing multiple node types. The first node type encodes the enumeration type $name$. The other node types encode the $values$ of enumeration type $name$. $TG_{EnumNodes}$ is defined as:
\begin{align*}
NT =\ &\{\mathrm{ns\_\!to\_\!list}(name)\} \cup \{ \mathrm{ns\_\!to\_\!list}(name) \append \langle v \rangle \mid v \in values \} \\
ET =\ &\{\} \\
\!\!\sqsubseteq\ =\ &\{(\mathrm{ns\_\!to\_\!list}(name), \mathrm{ns\_\!to\_\!list}(name))\}\ \cup \\&
\{(\mathrm{ns\_\!to\_\!list}(name) \append \langle v \rangle, \mathrm{ns\_\!to\_\!list}(name) \append \langle v \rangle) \mid v \in values \}\ \cup \\&
\{(\mathrm{ns\_\!to\_\!list}(name) \append \langle v \rangle, \mathrm{ns\_\!to\_\!list}(name)) \mid v \in values \} \\
abs =\ &\{\mathrm{ns\_\!to\_\!list}(name)\} \\
\mathrm{mult} =\ &\{\} \\
contains =\ &\{\}
\end{align*}
\isabellelref{tg_enum_as_node_types}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{defin}

\begin{thm}[Correctness of $TG_{EnumNodes}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_node_types_correct}
$TG_{EnumNodes}$ (\cref{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_node_types}) is a valid type graph in the sense of \cref{defin:formalisations:groove_formalisation:type_graphs:type_graph_validity}.
\isabellelref{tg_enum_as_node_types_correct}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

A visual representation of $TG_{EnumNodes}$ with $.\type{Example}$ as identifier for the encoded enumeration type and $\type{OPTION\_A}$, $\type{OPTION\_B}$ and $\type{OPTION\_C}$ as its values can be seen in \cref{fig:library_of_transformations:type_level_transformations:enumeration_types:visualisation:groove_nodes}. Please note that in this visualisation, the sequences are concatenated using the dollar sign $\$$. The correctness proof of $TG_{EnumNodes}$ is trivial, and therefore not included here. The proof can be found as part of the Isabelle validated proofs.

In order to make composing transformation functions possible, $TG_{EnumNodes}$ should be compatible with the type graph it is combined with.

\begin{thm}[Correctness of $\mathrm{combine}(TG, TG_{EnumNodes})$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_node_types_combine_correct}
Assume a type graph $TG$ that is valid in the sense of \cref{defin:formalisations:groove_formalisation:type_graphs:type_graph_validity}. Then $TG$ is compatible with $TG_{EnumNodes}$ (in the sense of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_graphs:compatibility}) if:
\begin{itemize}
    \item There are no shared node types between $TG_{EnumNodes}$ and $TG$.
\end{itemize}
\isabellelref{tg_enum_as_node_types_combine_correct}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

\begin{proof}
Use \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_graphs:tg_combine_merge_correct}. It is possible to show that all assumptions hold. Now we have shown that $\mathrm{combine}(TG, TG_{EnumNodes})$ is valid in the sense of \cref{defin:formalisations:groove_formalisation:type_graphs:type_graph_validity}.
\end{proof}

The next definitions define the transformation function from $Tm_{Enum}$ to $TG_{EnumNodes}$:

\begin{defin}[Transformation function $f_{EnumNodes}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum_to_tg_enum_as_node_types}
The transformation function $f_{EnumNodes}(Tm)$ is defined as:
\begin{align*}
NT =\ &\{\mathrm{ns\_\!to\_\!list}(e) \mid e \in Enum_{Tm}\} \cup \{\mathrm{ns\_\!to\_\!list}(e) \append \langle v \rangle \mid (e, v) \in EnumValue_{Tm}\} \\
ET =\ &\{\} \\
\!\!\sqsubseteq\ =\ &\{(\mathrm{ns\_\!to\_\!list}(e_1), \mathrm{ns\_\!to\_\!list}(e_2)) \mid e_1 \in Enum_{Tm} \land e_2 \in Enum_{Tm} \}\ \cup \\&
\{(\mathrm{ns\_\!to\_\!list}(i) \append \langle j \rangle, \mathrm{ns\_\!to\_\!list}(i) \append \langle j \rangle) \mid (i, j) \in EnumValue_{Tm} \}\ \cup \\&
\{(\mathrm{ns\_\!to\_\!list}(i) \append \langle j \rangle, \mathrm{ns\_\!to\_\!list}(e)) \mid (i, j) \in EnumValue_{Tm} \land e \in Enum_{Tm} \} \\
abs =\ &\{\} \\
\mathrm{mult} =\ &\{\} \\
contains =\ &\{\}
\end{align*}
\isabellelref{tmod_enum_to_tg_enum_as_node_types}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{defin}

\begin{thm}[Correctness of $f_{EnumNodes}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum_to_tg_enum_as_node_types_func}
$f_{EnumNodes}(Tm)$ (\cref{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum_to_tg_enum_as_node_types}) is a valid transformation function in the sense of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_transformation_functions:transformation_function_type_model_type_graph} transforming $Tm_{Enum}$ into $TG_{EnumNodes}$.
\isabellelref{tmod_enum_to_tg_enum_as_node_types_func}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

The proof of the correctness of $f_{EnumNodes}$ will not be included here. Instead, it can be found in the validated Isabelle theories.

Finally, to complete the transformation, the transformation function that transforms $TG_{EnumNodes}$ into $Tm_{Enum}$ is defined:

\begin{defin}[Transformation function $f'_{EnumNodes}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_node_types_to_tmod_enum}
The transformation function $f'_{EnumNodes}(TG, name)$ is defined as:
\begin{align*}
Class =\ &\{\} \\
Enum =\ &\{\mathrm{list\_\!to\_\!ns}(n) \mid n \in NT_{TG} \land n = \mathrm{id\_\!to\_\!name}(name)\} \\
UserDataType =\ &\{\} \\
Field =\ &\{\} \\
\mathrm{FieldSig} =\ &\{\} \\
EnumValue =\ &\{(\mathrm{list\_\!to\_\!ns}(e), v) \mid e \append \langle v \rangle \in NT_{TG} \land e \append \langle v \rangle \neq \mathrm{id\_\!to\_\!name}(name) \} \\
Inh =\ &\{\} \\
Prop =\ &\{\} \\
Constant =\ &\{\} \\
\mathrm{ConstType} =\ &\{\}
\end{align*}
\isabellelref{tg_enum_as_node_types_to_tmod_enum}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{defin}

\begin{thm}[Correctness of $f'_{EnumNodes}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_node_types_to_tmod_enum_func}
$f'_{EnumNodes}(TG, name)$ (\cref{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_node_types_to_tmod_enum}) is a valid transformation function in the sense of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_transformation_functions:transformation_function_type_graph_type_model} transforming $TG_{EnumNodes}$ into $Tm_{Enum}$.
\isabellelref{tg_enum_as_node_types_to_tmod_enum_func}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

Once more, the correctness proof is not included here but can be found in the validated Isabelle proofs of this thesis.

\subsubsection{Encoding as flags}

Another possible encoding for enumeration types in Ecore is using flags in GROOVE. In this case, the enumeration type itself is transformed into a regular node type. Each value of the enumeration type is converted to a flag on this node type. The encoding corresponding to $Tm_{Enum}$ can then be represented as $TG_{EnumFlags}$, defined in the following definition:

\begin{defin}[Type graph $TG_{EnumFlags}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_flags}
Let $TG_{EnumFlags}$ be a type graph containing a single node type which encodes the enumeration type $name$. The flags on the node type of $name$ encode the different $values$. $TG_{EnumFlags}$ is defined as:
\begin{align*}
NT =\ &\{\mathrm{ns\_\!to\_\!list}(name)\} \\
ET =\ &\{ (\mathrm{ns\_\!to\_\!list}(name), \langle v \rangle, \mathrm{ns\_\!to\_\!list}(name)) \mid v \in values \}\\
\!\!\sqsubseteq\ =\ &\{(\mathrm{ns\_\!to\_\!list}(name), \mathrm{ns\_\!to\_\!list}(name))\} \\
abs =\ &\{\} \\
\mathrm{mult}(e) =\ &\begin{cases}
    (0..1, 0..1) &\mathrm{if}\ e \in ET_{TG_{EnumFlags}}
\end{cases}\\
contains =\ &\{\}
\end{align*}
\isabellelref{tg_enum_as_flags}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{defin}

\begin{thm}[Correctness of $TG_{EnumFlags}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_flags_correct}
$TG_{EnumFlags}$ (\cref{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_flags}) is a valid type graph in the sense of \cref{defin:formalisations:groove_formalisation:type_graphs:type_graph_validity}.
\isabellelref{tg_enum_as_flags_correct}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

A visual representation of $TG_{EnumFlags}$ with $.\type{Example}$ as identifier for the encoded enumeration type and $\type{OPTION\_A}$, $\type{OPTION\_B}$ and $\type{OPTION\_C}$ as its values can be seen in \cref{fig:library_of_transformations:type_level_transformations:enumeration_types:visualisation:groove_flags}. The correctness proof of $TG_{EnumFlags}$ is trivial, and therefore not included here. The proof can be found as part of the Isabelle validated proofs.

In order to make composing transformation functions possible, $TG_{EnumFlags}$ should be compatible with the type graph it is combined with.

\begin{thm}[Correctness of $\mathrm{combine}(TG, TG_{EnumFlags})$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_flags_combine_correct}
Assume a type graph $TG$ that is valid in the sense of \cref{defin:formalisations:groove_formalisation:type_graphs:type_graph_validity}. Then $TG$ is compatible with $TG_{EnumFlags}$ (in the sense of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_graphs:compatibility}) if:
\begin{itemize}
    \item There are no shared node types between $TG_{EnumFlags}$ and $TG$.
\end{itemize}
\isabellelref{tg_enum_as_flags_combine_correct}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

\begin{proof}
Use \cref{defin:transformation_framework:type_models_and_type_graphs:combining_type_graphs:tg_combine_merge_correct}. It is possible to show that all assumptions hold. Now we have shown that $\mathrm{combine}(TG, TG_{EnumFlags})$ is valid in the sense of \cref{defin:formalisations:groove_formalisation:type_graphs:type_graph_validity}.
\end{proof}

The next definitions define the transformation function from $Tm_{Enum}$ to $TG_{EnumFlags}$:

\begin{defin}[Transformation function $f_{EnumFlags}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum_to_tg_enum_as_flags}
The transformation function $f_{EnumFlags}(Tm)$ is defined as:
\begin{align*}
NT =\ &\{\mathrm{ns\_\!to\_\!list}(e) \mid e \in Enum_{Tm}\} \\
ET =\ &\{(\mathrm{ns\_\!to\_\!list}(e), v, \mathrm{ns\_\!to\_\!list}(e)) \mid (e, v) \in EnumValue_{Tm}\} \\
\!\!\sqsubseteq\ =\ &\{(\mathrm{ns\_\!to\_\!list}(e_1), \mathrm{ns\_\!to\_\!list}(e_2)) \mid e_1 \in Enum_{Tm} \land e_2 \in Enum_{Tm} \} \\
abs =\ &\{\} \\
\mathrm{mult}(e) =\ &\begin{cases}
    (0..1, 0..1) &\mathrm{if}\ e \in \{(\mathrm{ns\_\!to\_\!list}(n), v, \mathrm{ns\_\!to\_\!list}(n)) \mid (n, v) \in EnumValue_{Tm}\}
\end{cases}\\
contains =\ &\{\}
\end{align*}
\isabellelref{tmod_enum_to_tg_enum_as_flags}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{defin}

\begin{thm}[Correctness of $f_{EnumFlags}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum_to_tg_enum_as_flags_func}
$f_{EnumFlags}(Tm)$ (\cref{defin:library_of_transformations:type_level_transformations:enumeration_types:tmod_enum_to_tg_enum_as_flags}) is a valid transformation function in the sense of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_transformation_functions:transformation_function_type_model_type_graph} transforming $Tm_{Enum}$ into $TG_{EnumFlags}$.
\isabellelref{tmod_enum_to_tg_enum_as_flags_func}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

The proof of the correctness of $f_{EnumFlags}$ will not be included here. Instead, it can be found in the validated Isabelle theories.

Finally, to complete the transformation, the transformation function that transforms $TG_{EnumFlags}$ into $Tm_{Enum}$ is defined:

\begin{defin}[Transformation function $f'_{EnumFlags}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_flags_to_tmod_enum}
The transformation function $f'_{EnumFlags}(TG)$ is defined as:
\begin{align*}
Class =\ &\{\} \\
Enum =\ &\{\mathrm{list\_\!to\_\!ns}(n) \mid n \in NT_{TG}\} \\
UserDataType =\ &\{\} \\
Field =\ &\{\} \\
\mathrm{FieldSig} =\ &\{\} \\
EnumValue =\ &\{(\mathrm{list\_\!to\_\!ns}(e), v) \mid (e, v, e) \in ET_{TG} \} \\
Inh =\ &\{\} \\
Prop =\ &\{\} \\
Constant =\ &\{\} \\
\mathrm{ConstType} =\ &\{\}
\end{align*}
\isabellelref{tg_enum_as_flags_to_tmod_enum}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{defin}

\begin{thm}[Correctness of $f'_{EnumNodes}$]
\label{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_flags_to_tmod_enum_func}
$f'_{EnumFlags}(TG)$ (\cref{defin:library_of_transformations:type_level_transformations:enumeration_types:tg_enum_as_flags_to_tmod_enum}) is a valid transformation function in the sense of \cref{defin:transformation_framework:type_models_and_type_graphs:combining_transformation_functions:transformation_function_type_graph_type_model} transforming $TG_{EnumFlags}$ into $Tm_{Enum}$.
\isabellelref{tg_enum_as_flags_to_tmod_enum_func}{Ecore-GROOVE-Mapping-Library.EnumType}
\end{thm}

Once more, the correctness proof is not included here but can be found in the validated Isabelle proofs of this thesis.