text:
\documentclass[notitlepage,12pt]{article}

\usepackage{fullpage}
\usepackage{color}
\usepackage{graphicx}
\usepackage{multirow}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{booktabs}
\usepackage{hyperref}
\usepackage{xspace}
\usepackage{arydshln,leftidx,mathtools}
\usepackage{verbatim}
\usepackage{listings}
\usepackage[super]{nth}
\usepackage{eucal}

%---------Code listings----------

\definecolor{codegreen}{rgb}{0,0.6,0}
\definecolor{codegray}{rgb}{0.5,0.5,0.5}
\definecolor{codepurple}{rgb}{0.58,0,0.82}
\definecolor{backcolour}{rgb}{0.95,0.95,0.92}

\lstdefinestyle{mystyle}{
    backgroundcolor=\color{backcolour},
    commentstyle=\color{codegreen},
    keywordstyle=\color{magenta},
    numberstyle=\tiny\color{codegray},
    stringstyle=\color{codepurple},
    basicstyle=\footnotesize,
    breakatwhitespace=false,
    breaklines=true,
    captionpos=b,
    keepspaces=true,
    numbers=left,
    numbersep=5pt,
    showspaces=false,
    showstringspaces=false,
    showtabs=false,
    tabsize=2,
    xleftmargin=.25in,
    xrightmargin=.25in
}

\lstset{style=mystyle}

%---------Commands-------------

\setcounter{section}{0}
\newcommand{\runDM}{\texttt{runDM}\xspace}

\newcommand\scalemath[2]{\scalebox{#1}{\mbox{\ensuremath{\displaystyle #2}}}}
\newcommand{\ourpaper}{\href{http://arxiv.org/abs/1605.04917}{arXiv:1605.04917}\xspace}

%--------Document--------------

\begin{document}

\title{runDM v1.0 - Manual \\ \vspace{0.5cm}\normalsize \textit{With runDMC, It's Tricky. With runDM, it's not.}}

\date{\vspace{-1cm}\nth{18} May 2016}

\maketitle

\tableofcontents

\section{Overview}

The \runDM code is a tool for calculating the running of the couplings of Dark Matter (DM) to the Standard Model (SM) in simplified models with vector mediators. By specifying the mass of the mediator and the couplings of the mediator to SM fields at high energy, the code can be used to calculate the couplings at low energy, taking into account the mixing of all dimension-6 operators. The code can also be used to extract the operator coefficients relevant for direct detection, namely low energy couplings to up, down and strange quarks and to protons and neutrons. Further details about the physics behind the code can be found in Appendix B of \ourpaper.

At present, the code is available in two languages: \textit{Mathematica} and \textit{Python}. For installation instructions and example code in each language, skip straight to Sec.~\ref{sec:implementations}. Example files/notebooks for all versions of the code (along with the code itself) are available at: \href{https://github.com/bradkav/runDM/}{https://github.com/bradkav/runDM/}. If you are interested in an implementation in another language, please get in touch and we'll do what we can to add it. Unless you want the code in Fortran, in which case you have to buy me beer first. Please contact Bradley Kavanagh (\href{mailto:bradkav@gmail.com?subject=runDM v.10}{bradkav@gmail.com}) for any questions, problems, bugs and suggestions.

If you make use of \runDM in your work, please cite it as:

\begin{quote}
F. D'Eramo, B. J. Kavanagh \& P. Panci (2016). \textit{runDM} (Version X.X) [Computer software]. Available at https://github.com/bradkav/runDM/\,,
\end{quote}
making sure to include the correct version number. Please also cite the associated papers:

\begin{quote}

 A. Crivellin, F. D'Eramo \& M. Procura, \textit{New Constraints on Dark Matter Effective Theories from Standard Model Loops}, Phys.\ Rev.\ Lett.\  {\bf 112} (2014) 191304 [arXiv:1402.1173 [hep-ph]].

F. D'Eramo \& M. Procura, \textit{Connecting Dark Matter UV Complete Models to Direct Detection Rates via Effective Field Theory}, JHEP {\bf 1504} (2015) 054 [arXiv:1411.3342 [hep-ph]]\,,
\end{quote}

\begin{quote}
F. D'Eramo, B. J. Kavanagh \& P. Panci, \textit{You can hide but you have to run: direct detection with vector mediators}, (2016) [arXiv:1605.04917]\,.
\end{quote}

\section{General framework}

This section describes the general framework of \runDM, describing the general usage, inputs and outputs of \runDM, as well as pseudocode for how to use the most important functions. For implementation-specific information, please see Sec.~\ref{sec:implementations}.

The core of \runDM is the function \texttt{runCouplings}($\mathbf{c}$, $E_1$, $E_2$). This function accepts as input a vector of couplings $\mathbf{c}$, specified at some energy $E_1$. It returns a different vector of couplings, evaluated at some other energy $E_2$, taking into account RG evolution between the two energy scales. Full details about the numerical implementation can be found in Appendix~B of \ourpaper. Here, we simply outline which coupling values are required as input and output.

The input vector  $\mathbf{c}$ has 16 elements, the coefficients of the dimension-6 DM-SM operators of the form: $\mathcal{O}_{\mathrm{DM},\mu} \, \mathcal{O}_\mathrm{SM}^\mu/m_V^2$, where $m_V$ is the mass of the vector mediator. The structure of the DM operator does not affect the running of the coefficients and may take the following forms for fermionic DM $\chi$:

\begin{equation}
\mathcal{O}_{\mathrm{DM},\mu} = \overline{\chi}\gamma_\mu \chi\,, \,\overline{\chi} \gamma_\mu \gamma^5 \chi\,,
\end{equation}
and for complex scalar DM $\phi$:
\begin{equation}
\mathcal{O}_{\mathrm{DM},\mu} = \phi^\dagger \overleftrightarrow{\partial}_\mu \phi\, , \, \partial_\mu (\phi^\dagger \phi)\,.\end{equation}

The SM operators which appear at dimension-6, defined above the electroweak symmetry breaking (EWSB) scale, are:
\begin{alignat}{2}
\mathcal{O}_{q^{(i)}}^\mu &= \overline{q}^{(i)}_L \gamma^\mu q^{(i)}_L \,, \qquad \mathcal{O}_{l^{(i)}}^\mu   &= \overline{l}^{(i)}_L \gamma^\mu l^{(i)}_L\,, \nonumber \\
\mathcal{O}_{u^{(i)}}^\mu &= \overline{u}^{(i)}_R \gamma^\mu u^{(i)}_R\,, \qquad \mathcal{O}_{e^{(i)}}^\mu &= \overline{e}^{(i)}_R \gamma^\mu e^{(i)}_R \,, \\
\mathcal{O}_{d^{(i)}}^\mu &= \overline{d}^{(i)}_R \gamma^\mu d^{(i)}_R\,, \qquad\mathcal{O}_H^\mu &= i H^\dagger \overleftrightarrow{D}_\mu H\,, \nonumber
\end{alignat}
where the $(i)$ superscript labels the generation number. The vector of couplings $\mathcal{c}$ which \runDM accepts as input is then defined as
\begin{equation}
\scalemath{0.9}{\mathbf{c} = \left(\!\begin{array}{cccccccccccccccc}
c_{ q}^{(1)} & c_{u}^{(1)} & c_{ d}^{(1)}\,&\, c_{ l}^{(1)} & c_{ e}^{(1)} \,&\,
c_{ q}^{(2)} & c_{ u}^{(2)} & c_{ d}^{(2)} \,&\, c_{ l}^{(2)} & c_{ e}^{(2)} \,&\,
c_{ q}^{(3)} & c_{ u}^{(3)} & c_{ d}^{(3)} \,&\, c_{ l}^{(3)} & c_{ e}^{(3)} \,&\,
c_{ \!H} \end{array}\!\right)}\,.
\label{eq:cdef}
\end{equation}
A number of functions are available to initialise these coupling vectors - see Sec.~\ref{sec:init}.

If the energy $E_2$ at which to evaluate the couplings is above the EWSB scale (i.e.~$E_2 > m_Z$), the output of \texttt{runCouplings} will be a vector of couplings as in Eq.~\ref{eq:cdef}, evaluated after RG evolution. However, if $E_2$ is below the EWSB scale (i.e.~$E_2 <m_Z$), then \texttt{runCouplings} will return the vector $\mathcal{C}$, which are the couplings to the SM operators after EWSB. These operators are

\begin{alignat}{2}
\mathcal{O}_{Vu^{(i)}}^\mu &= \overline{u}^{(i)} \gamma^\mu u^{(i)}\,, \qquad \mathcal{O}_{Au^{(i)}}^\mu &= \overline{u}^{(i)} \gamma^\mu \gamma^5 u^{(i)}\,, \nonumber \\
\mathcal{O}_{Vd^{(i)}}^\mu &= \overline{d}^{(i)} \gamma^\mu d^{(i)}\,, \qquad \mathcal{O}_{Ad^{(i)}}^\mu &=  \overline{d}^{(i)} \gamma^\mu \gamma^5 d^{(i)}\,,\\
\mathcal{O}_{Ve^{(i)}}^\mu &= \overline{e}^{(i)} \gamma^\mu e^{(i)}\,, \qquad \mathcal{O}_{Ae^{(i)}}^\mu &=  \overline{e}^{(i)} \gamma^\mu \gamma^5 e^{(i)}\,, \nonumber
\end{alignat}
and the corresponding coupling vector is
\begin{align}
\scalemath{0.9}{\mathcal{C} = \left(\!\begin{array}{cccccccccccccccc}
\mathcal{C}_{ Vu}^{(1)} & \mathcal{C}_{ Vd}^{(1)} & \mathcal{C}_{ Vu}^{(2)} & \mathcal{C}_{ Vd}^{(2)} & \mathcal{C}_{ Vd}^{(3)} &
\mathcal{C}_{ Ve}^{(1)} &\mathcal{C}_{ Ve}^{(2)}  & \mathcal{C}_{ Ve}^{(3)}  & \mathcal{C}_{ Au}^{(1)} & \mathcal{C}_{ Ad}^{(1)} & \mathcal{C}_{ Au}^{(2)} & \mathcal{C}_{ Ad}^{(2)} & \mathcal{C}_{ Ad}^{(3)} &
\mathcal{C}_{ Ae}^{(1)} &\mathcal{C}_{ Ae}^{(2)}  & \mathcal{C}_{ Ae}^{(3)} \end{array}\!\right) }\,.
\label{eq:cdef2}
\end{align}

The \runDM code takes care of the matching between between $\mathbf{c}$ and $\mathcal{C}$ at the EWSB-scale. It also takes care of relative values of $E_1$ and $E_2$ compared to each other and to $m_Z$. The only possibility which is not allowed is to have $E_1 < m_Z$ and $E_2 > m_Z$. This is because the matching from the broken to the unbroken phase of the SM is not unique.

In the following subsections, we give more details on the key functions available in \runDM, including \texttt{DDCouplingQuarks} (Sec.~\ref{sec:DDCouplingsQuarks}) and \texttt{DDCouplingNR} (Sec.~\ref{sec:DDCouplingsNR}) which allow the user to directly calculate the couplings relevant at the direct detection scale.

\subsection{Initialisation}
\label{sec:init}

The input coupling vector $\mathbf{c}$ must be in the form of an array with 16 elements. To help with initialisation, \runDM includes the function \texttt{initCouplings()}, which returns such an array, filled with zeroes. The user is then free to specify each of the 16 couplings in Eq.~\ref{eq:cdef}.

Alternatively, \texttt{setBenchmark(benchmarkID)} returns a coupling vector $\mathbf{c}$ corresponding to one of a number of preset benchmarks, specified using the string \texttt{benchmarkID}. The available benchmarks are:

\begin{itemize}

\item \texttt{"Higgs"} - coupling only to the Higgs current operator:

\qquad $c_H = 1$, all other couplings zero.

\item \texttt{"UniversalVector"} - universal vector coupling to all fermions:

\qquad $c_q^{(i)} = c_u^{(i)} = c_d^{(i)} = c_l^{(i)} = c_e^{(i)} = 1$, $c_H = 0$.

\item \texttt{"UniversalAxial"} - universal axial-vector coupling to all fermions:

\qquad $-c_q^{(i)} = c_u^{(i)} = c_d^{(i)} = -c_l^{(i)} = c_e^{(i)} = 1$, $c_H = 0$.

\item \texttt{"QuarksVector"} - vector coupling to all quarks:

\qquad $c_q^{(i)} = c_u^{(i)} = c_d^{(i)} = 1$, $c_l^{(i)} = c_e^{(i)} = c_H = 0$.

\item \texttt{"QuarksAxial"} - axial-vector coupling to all quarks:

\qquad $-c_q^{(i)} = c_u^{(i)} = c_d^{(i)} = 1$, $c_l^{(i)} = c_e^{(i)} = c_H = 0$.

\item \texttt{"LeptonsVector"} - vector coupling to all leptons:

\qquad $c_l^{(i)} = c_e^{(i)} = 1$, $c_q^{(i)} = c_u^{(i)} = c_d^{(i)} = c_H = 0$.

\item \texttt{"LeptonsAxial"} - axial-vector coupling to all leptons:

\qquad $-c_l^{(i)} = c_e^{(i)} = 1$, $c_q^{(i)} = c_u^{(i)} = c_d^{(i)} = c_H = 0$.

\item \texttt{"ThirdVector"} - vector coupling to third generation fermions:

\qquad $c_q^{(3)} = c_u^{(3)} = c_d^{(3)} = c_l^{(3)} = c_e^{(3)} = 1$, all remaining couplings zero.

\item \texttt{"ThirdAxial"} - axial-vector coupling to third generation fermions:

\qquad $-c_q^{(3)} = c_u^{(3)} = c_d^{(3)} = -c_l^{(3)} = c_e^{(3)} = 1$, all remaining couplings zero.

\end{itemize}

If the value of \texttt{benchmarkID} is not recognised, \texttt{setBenchmark} simply returns a coupling vector filled with zeroes.

\subsection{runCouplings}

The function \texttt{runCouplings}($\mathbf{c}$, $E_1$, $E_2$) accepts as input a vector of couplings $\mathbf{c}$, defined at energy $E_1$ (in GeV) and returns a vector of couplings evaluated at energy $E_2$ (in GeV), taking into account the running, matching and mixing between the two energies. The energies $E_1$ and $E_2$ must be in the range $[1, 10^8]$ GeV (the evolution matrices have not been calculated outside of that range). The input vector $\mathbf{c}$ has the form of Eq.~\ref{eq:cdef}.

 If $E_2 > m_Z$, \texttt{runCouplings} returns the elements of $\mathbf{c}$, the vector of couplings above the EWSB scale defined in Eq.~\ref{eq:cdef}. Alternatively, if $E_2 < m_Z$, \texttt{runCouplings} returns the elements of $\mathbf{\mathcal{C}}$, the vector of couplings in the EFT below the EWSB scale, defined in Eq.~\ref{eq:cdef2}. Note that \texttt{runCoupling} will return an error if $E_1 < m_Z$ and $E_2 > m_Z$ - in this case the matching at the EWSB-scale is not unique.

The function \texttt{runCouplings} is \textit{vectorized}, meaning that it will accept $E_1$ and $E_2$ as arrays as well as single numbers. \texttt{runCouplings} will happily deal with one of $E_1$ and $E_2$ being an array and the other being a scalar. The output of \texttt{runCouplings} will be an array with dimensions \{Length($E_1$), 16\} or \{Length($E_2$), 16\}, depending on which of $E_1$ and $E_2$ is an array. If both $E_1$ and $E_2$ are arrays, they should have the same length and \textit{runCouplings} will return an array with dimensions \{Length($E_1$), 16\}. The function is \textit{not vectorized} in $\mathbf{c}$ - i.e. $\mathbf{c}$ should always be a 1-dimensional array with 16 elements.

\subsection{DDCouplingsQuarks}
\label{sec:DDCouplingsQuarks}

The function \texttt{DDCouplingsQuarks}($\mathbf{c}$, $E_1$) accepts as input a vector of couplings $\mathbf{c}$, defined at energy $E_1$ (in GeV). The input vector $\mathbf{c}$ has the form of Eq.~\ref{eq:cdef}. The running is performed down to the nuclear energy scale of 1 GeV and the function returns a vector of the low-energy couplings to light quarks ($u$, $d$, $s$) relevant for direct detection:

\begin{equation}
\mathcal{C}_q = \left( \mathcal{C}_V^{(u)}, \mathcal{C}_V^{(d)}, \mathcal{C}_A^{(u)}, \mathcal{C}_A^{(d)}, \mathcal{C}_A^{(s)} \right)\,.
\end{equation}

As in \texttt{runCouplings}, $E_1$ must be in the range $[1, 10^8]$ GeV. \texttt{DDCouplingQuarks} is also vectorized, so it will accept $E_1$ as a scalar or an array. It will return an array with dimensions \{Length($E_1$), 5\}.

\subsection{DDCouplingsNR}
\label{sec:DDCouplingsNR}

The function \texttt{DDCouplingsNR}($\mathbf{c}$, $E_1$, \texttt{mx}, \texttt{DMcurrent}, \texttt{N}) is an alternative to \texttt{DDCouplingsQuarks} which takes care of the embedding of the quarks in the nucleon and the matching onto non-relativistic (NR) operators.

\texttt{DDCouplingsNR} accepts as input a vector of couplings $\mathbf{c}$, defined at energy $E_1$ (in GeV). The input vector $\mathbf{c}$ has the form of Eq.~\ref{eq:cdef}. The running is performed down to the nuclear energy scale of 1 GeV. The quark level coefficients are then matched onto the nucleon-level coefficients (with \texttt{N} = `p' for protons and \texttt{N} = `n' for neutrons).\footnote{For the quark spin content of the nucleons, $\Delta_q^{(N)}$, we use the values in the lower panel of Table~II of \href{http://arxiv.org/abs/1202.1292}{arXiv:1202.1292}.} The relativistic nucleon-level coefficients are then matched onto the NR operators introduced in \href{http://arxiv.org/abs/1203.3542}{arXiv:1203.3542}, depending on the form of the DM interaction current and the value of the DM mass \texttt{mx} (in GeV). The possibilities for the variable \texttt{DMcurrent} are:

\begin{equation}
\mathcal{O}_{\mathrm{DM}, \mu} =
\begin{cases}
\phi^\dagger \overleftrightarrow{\partial}_\mu \phi & \qquad \text{\texttt{DMcurrent = `scalar'},}\\
\overline{\chi} \gamma_\mu \chi & \qquad \text{\texttt{DMcurrent = `vector'},}\\
\overline{\chi} \gamma_\mu \gamma^5 \chi & \qquad \text{\texttt{DMcurrent = `axial-vector'}.}\\
\end{cases}
\end{equation}
The function returns a vector of 12 NR operator coefficients, with definitions and numbering of the operators matching those in \href{http://arxiv.org/abs/1203.3542}{arXiv:1203.3542} and \href{http://arxiv.org/abs/1307.5955}{arXiv:1307.5955}:
\begin{equation}
\left(\mathfrak{c}_{\phi(\chi) \, 1}^{N}, \mathfrak{c}_{\phi(\chi) \, 2}^{N}, ..., \mathfrak{c}_{\phi(\chi) \, 12}^{N}\right) \,.
\end{equation}
Note that the calculation of these coefficients automatically includes a factor of $1/E_1^2$ (equivalent to $1/m_V^2$, arising from the mediator propagator). For more details, see Appendix C of \ourpaper.

Again, $E_1$ must be in the range $[1, 10^8]$ GeV. \texttt{DDCouplingNR} is also vectorized, so it will accept $E_1$ as a scalar or an array.  However, \texttt{mx}, \texttt{DMcurrent} and \texttt{N} must all be single values. The function will return an array with dimensions \{Length($E_1$), 12\}.
\section{Implementations}
\label{sec:implementations}

\subsection{Mathematica}

In order to use the \textit{mathematica} implementation of \texttt{runDM}, simply copy the \textit{mathematica} package file \texttt{mathematica/runDM.m} into the same directory as your notebook and then use \texttt{Get}:

\begin{lstlisting}[language=mathematica]
Get[NotebookDirectory[] <> "runDM.m"];
\end{lstlisting}

Below is an example code snippet for calculating (and plotting) the low energy couplings to light quarks (relevant in direct detection experiments) at the nuclear energy scale, assuming a mediator of mass $m_V$ which couples through the axial-vector current to all SM quarks:

\begin{lstlisting}[language=mathematica]
Get[NotebookDirectory[] <> "runDM.m"];

(*Set benchmark*)
chigh = setBenchmark["QuarksAxial"];

clabels = {"cVu", "cVd", "cAu", "cAd", "cAs"};

(*Calculate and plot*)
Table[Plot[{DDCouplingsQuarks[chigh, 10^lmv][[k]]}, {lmv, 0.0, 6.0},
  PlotTheme -> "Scientific",
  FrameLabel -> {"Log10[mv/GeV]", clabels[[k]]},
  PlotRangePadding -> .1, ImageSize -> 200,
  BaseStyle -> {FontSize -> 16}], {k, 5}]
\end{lstlisting}
For more detailed examples, see the notebook at \texttt{mathematica/runDM-examples.nb}. We also provide an example notebook showing how to interface \runDM with \textsc{NRopsDD v3.0}, available at \href{http://www.marcocirelli.net/NROpsDD.html}{this http URL}, in order to calculate limits from direct detection experiments for arbitrary sets of couplings. This notebook can be found at \texttt{mathematica/runDM-NRopsDD.nb}.

\subsection{Python}

In order to use the \textit{python} implementation of \runDM, you will need to have the \href{http://www.numpy.org}{\texttt{numpy}} and \href{https://www.scipy.org/index.html}{\texttt{scipy}} packages installed.  Once that's done, copy the module file \texttt{python/runDM.py} into the same directory as your python script. Make sure that the folder \texttt{python/data/} is in the same folder as the module file. Then simply import the module:

\begin{lstlisting}[language=Python]
import runDM
\end{lstlisting}

Below is an example code snippet for calculating (and plotting) the low energy couplings to light quarks (relevant in direct detection experiments) at the nuclear energy scale, assuming a mediator of mass $m_V$ which couples through the axial-vector current to all SM quarks:

\begin{lstlisting}[language=Python]
import numpy as np
from matplotlib import pyplot as pl
import runDM

#Set benchmark
c_high = runDM.setBenchmark("QuarksAxial")

#Calculate the low energy couplings
mV = np.logspace(0, 6, 1000)
c_q = runDM.DDCouplingsQuarks(c_high, mV)

#Now let's do some plotting
f, axarr = pl.subplots(5,figsize=(5,9))

clabels = ['c_V^u','c_V^d','c_A^u','c_A^d','c_A^s']

for k in range(5):
    ax = axarr[k]
    ax.semilogx(mV, c_q[:,k])
    ax.set_xlabel(r'$m_V$ [GeV]', fontsize=14.0)
    ax.set_ylabel(r'$'+clabels[k]+'$', fontsize=14.0)

pl.tight_layout()
pl.show()
\end{lstlisting}
For more detailed examples, see the script at \texttt{python/runDM-examples.py} or the ipython notebook at \texttt{python/runDM-examples.ipynb}.
\end{document}

max_stars_repo_name: LBJ-Wade/runDM

max_issues_repo_name: LBJ-Wade/runDM

max_forks_repo_name: bradkav/runDM


text:
%-------------------------
% Pyspark knowledge
% Author : Aysha M.Machingara
% License : MIT
%------------------------

\documentclass[letterpaper,11pt]{article}

\usepackage{latexsym}
\usepackage[empty]{fullpage}
\usepackage{titlesec}
\usepackage{marvosym}
\usepackage[usenames,dvipsnames]{color}
\usepackage{verbatim}
\usepackage{enumitem}
\usepackage[hidelinks]{hyperref}
\usepackage{fancyhdr}
\usepackage[english]{babel}
\usepackage{tabularx}
\input{glyphtounicode}

%----------FONT OPTIONS----------
% sans-serif
% \usepackage[sfdefault]{FiraSans}
% \usepackage[sfdefault]{roboto}
% \usepackage[sfdefault]{noto-sans}
% \usepackage[default]{sourcesanspro}

% serif
% \usepackage{CormorantGaramond}
% \usepackage{charter}

\pagestyle{fancy}
\fancyhf{} % clear all header and footer fields
\fancyfoot{}
\renewcommand{\headrulewidth}{0pt}
\renewcommand{\footrulewidth}{0pt}

% Adjust margins
\addtolength{\oddsidemargin}{-0.5in}
\addtolength{\evensidemargin}{-0.5in}
\addtolength{\textwidth}{1in}
\addtolength{\topmargin}{-.5in}
\addtolength{\textheight}{1.0in}

\urlstyle{same}

\raggedbottom
\raggedright
\setlength{\tabcolsep}{0in}

% Sections formatting
\titleformat{\section}{
  \vspace{-4pt}\scshape\raggedright\large
}{}{0em}{}[\color{black}\titlerule \vspace{-5pt}]

% Ensure that generate pdf is machine readable/ATS parsable
\pdfgentounicode=1

%-------------------------
% Custom commands
\newcommand{\resumeItem}[1]{
  \item\small{
    {#1 \vspace{-2pt}}
  }
}

\newcommand{\resumeSubheading}[4]{
  \vspace{-2pt}\item
    \begin{tabular*}{0.97\textwidth}[t]{l@{\extracolsep{\fill}}r}
      \textbf{#1} & #2 \\
      \textit{\small#3} & \textit{\small #4} \\
    \end{tabular*}\vspace{-7pt}
}

\newcommand{\resumeSubSubheading}[2]{
    \item
    \begin{tabular*}{0.97\textwidth}{l@{\extracolsep{\fill}}r}
      \textit{\small#1} & \textit{\small #2} \\
    \end{tabular*}\vspace{-7pt}
}

\newcommand{\resumeProjectHeading}[2]{
    \item
    \begin{tabular*}{0.97\textwidth}{l@{\extracolsep{\fill}}r}
      \small#1 & #2 \\
    \end{tabular*}\vspace{-7pt}
}

\newcommand{\resumeSubItem}[1]{\resumeItem{#1}\vspace{-4pt}}

\renewcommand\labelitemii{$\vcenter{\hbox{\tiny$\bullet$}}$}

\newcommand{\resumeSubHeadingListStart}{\begin{itemize}[leftmargin=0.15in, label={}]}
\newcommand{\resumeSubHeadingListEnd}{\end{itemize}}
\newcommand{\resumeItemListStart}{\begin{itemize}}
\newcommand{\resumeItemListEnd}{\end{itemize}\vspace{-5pt}}

\begin{document}

\section{Pyspark Learning}

      \resumeItemListStart
        \resumeItem{\textbf{COVID Recovery Index:} Developed COVID impact planning strategy for fortune 50 automobile insurer in the US by predicting the impact of COVID on driving at a county level with a MAPE of 10\% for 500 large US counties. Used ping data from cellphones and other socio-economic and epidemiological variables. Predicted the Unemployment rate using google trends on unemployments claims with 15\% MAPE for 35 states. Formulated metrics and built a real-time dashboard for consumption by over 100 members and presented insights to CTO}
        \resumeItem{\textbf{Advanced Automation Platform:} Built an enterprise-ready micro-service, event-driven architecture on AWS for intelligent automation of claim handling and deployed in production, reducing manual work by 42k hours/year for fortune 50 automobile insurer in the US }

        \resumeItem{\textbf{Natural Language Processing:} Deployed NLP framework for analyzing regulatory compliance documents and identified gaps with existing controls as REST API for real-time prediction, delivering \$12MM cost savings/year}

        {\textit{Technology Used}: Python, Flask, Logistic Regression, Random Forest, Gaussian MM, Latent Dirichlet Allocation, scikit-learn, spaCy (Entity Recognition) }
      \resumeItemListEnd
      \end{document}

ext: tex

max_stars_repo_name: ayshamdmgit/pyspark

max_issues_repo_name: ayshamdmgit/pyspark

max_forks_repo_name: ayshamdmgit/pyspark


text:
\documentclass[xetex, aspectratio=169,professionalfont]{beamer}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}

% for long verbatim lines
\usepackage{listings}
\lstset{basicstyle=\ttfamily,breaklines=true}

%% Title and authors
\title{\fontbold A Non-intrusive Beamer Theme Focusing on Content}
\subtitle{simple theme}
\date{\today}
\author{\underline{Adarsh}}

% Color palette
\definecolor{AlertColor}{HTML}{DA4D45}
\definecolor{MyTeal}{HTML}{00796B}
\definecolor{MyBlue}{HTML}{03A9F4}
\definecolor{MyPink}{HTML}{E91E63}
\definecolor{MyPurple}{HTML}{6A1B9A}
\definecolor{MyLime}{HTML}{CCDB39}
\definecolor{MyGreen}{HTML}{388E3C}
\definecolor{SelectColor}{HTML}{F5F5F5}
\definecolor{MyIndigo}{HTML}{3E50B4}
\definecolor{MyOrange}{HTML}{FE9700}
\definecolor{MyPeach}{HTML}{FECBBB}
\definecolor{DarkBlue}{HTML}{0287D0}
\definecolor{DarkGold}{HTML}{C69318}
% three styles light, dark and none
% light is default
\usetheme[style=light]{simple}

\begin{document}

\begin{frame}
	% \maketitle also works
\makepictitle{img/coverimage}{img/logo}{DarkGold}
\end{frame}

%% Toc in first frame - takes sections and not frames
%\begin{frame}{Table of contents}
%  \setbeamertemplate{section in toc}[sections numbered]
%  \tableofcontents[hideallsubsections]
%\end{frame}

%% Just for reference - it doesn't create a new slide
\section{Why a new theme?}
\begin{frame}
	\vspace{2\baselineskip}
	\ribbon{AlertColor}{\fontbold \Huge A New Theme}
\end{frame}

\begin{frame}[fragile]{Why are we building a new theme?}
	% examples taken from Indyk's slides
	\centering
	\alert{``We want to have a minimal presentation where only content matters.''}
	\vspace{\baselineskip}
	\begin{columns}
		\column{0.33\textwidth}
		{
			\circleimage[width=1cm]{MyGreen}{2cm}{img/smallnotebook}
			\begin{center}
				{\Large Short}\\
				Write concise sentences.
			\end{center}

		}

		\column{0.33\textwidth}
		{
			\circleimage[width=1cm]{MyLime}{2cm}{img/simplemaze}
			\begin{center}
				{\Large Simple}\\
				Do not complicate things. %\vspace*{\baselineskip}
			\end{center}

		}

		\column{0.33\textwidth}
		{
			\circleimage[width=1cm]{MyBlue}{2cm}{img/smartidea}
			\begin{center}
				{\Large Smart}\\
				Present ideas in a smart way. %\vspace*{\baselineskip}
			\end{center}

		}

	\end{columns}

\end{frame}

\begin{frame}[fragile]{What does the theme provide?}
	%\centering
	Theme in itself is quite minimal-
	\begin{itemize}
		\item Simple background
		\item Simple titles with no blocks or navigation symbols
		\item \alert{Some Cool Tools}
	\end{itemize}

\end{frame}

\section{New options}
\begin{frame}
	\vspace{2\baselineskip}
	\ribbon{MyGreen}{\fontbold \Huge Tools}
\end{frame}

\begin{frame}[fragile]{Tools, you say?}
\centering
	\alert{Content + Cool Tools = Awesome Presentation}\vspace*{\baselineskip}

		Did you see those cute circles with images?

\verb|\circleimage[width=2cm]{MyPink}{3cm}{img/awesome}| \vspace*{\baselineskip}

		\circleimage[width=2cm]{MyPink}{3cm}{img/awesome}

		You can get cool clip-arts from \url{https://openclipart.org}.

\end{frame}

\begin{frame}[fragile]{You have already seen some..}
	\centering
	\begin{itemize}
		\item title page: \verb|\makepictitle{img/coverimage}{img/logo}{DarkGold}|
		\item section heading: \verb|\ribbon{MyGreen}{\fontbold \Huge Tools}|
	\end{itemize}
	I tried to keep them flexible. For example, I can create a thin ribbon here by just typing \verb|\ribbon[minimum height=0]{MyBlue}{I am a ribbon.}|.
	\ribbon[minimum height=0]{MyBlue}{I am a ribbon.}

\end{frame}

\begin{frame}[fragile]{Images with shadows}

\begin{columns}
	\column{0.5\textwidth}
	\centering
	We can include images with hint of shadows (looks better in light theme).
\verb|\shadowimage[scale=0.5]{img/visual}|
and of course \verb|\includegraphics| works too.

	\column{0.5\textwidth}
	\centering
	\begin{figure}
		\shadowimage[scale=0.45]{img/visual}
	\end{figure}
\end{columns}

\end{frame}

\begin{frame}[fragile]{Cards}

	\centering
	We can use cards to present our ideas.
	\verb|\card{MyGreen}{MyBlue}{6cm}{img/strong}{<text>}|
	\vspace{\baselineskip}

	\begin{columns}
		\column{0.5\textwidth}
		\centering

	\card{MyGreen}{MyBlue}{6cm}{img/strong}{
		{\Large Strength} \\
		We can explain strengths here. There may be many points which we can write here.
	}

	\vspace*{0.5\baselineskip}

	\card{MyBlue}{AlertColor}{6cm}{img/weak}{
		{\Large Weakness} \\
		We can explain weakness-es here.
	}

		\column{0.5\textwidth}
		\centering

		\card{MyOrange}{MyLime}{6cm}{img/opportunity}{
		{\Large Opportunities} \\
		We can explain opportunities here.
		\vspace*{2\baselineskip}
	}

	\vspace*{0.5\baselineskip}

		\card{AlertColor}{MyGreen}{6cm}{img/threat}{
		{\Large Threats} \\
		We can explain threats here.
	}

	\end{columns}

\end{frame}

\begin{frame}[fragile]{So many cards}

	\begin{columns}
		\column{0.5\textwidth}
		\centering

			\card{MyBlue}{AlertColor}{6cm}{img/weak}{
			{\Large Card} \\
			A usual card with an image at corner.
		}
		\begin{lstlisting}[breaklines]
\card{MyBlue}{AlertColor}{6cm}{img/weak}{<text>}
\end{lstlisting}
	%	\vspace*{0.5\baselineskip}

	\simplecard{MyGreen}{6cm}{
		{\Large Simple Card} \\
		This is a simple card.
	}
	\verb|\simplecard{MyGreen}{6cm}{<text>}|

		\column{0.5\textwidth}
		\centering

		\sideimagecard{MyOrange}{6cm}{img/nature}{
			{\Large Side Image Card} \\
			This is a side image card.
		}

	\begin{lstlisting}[breaklines]
\sideimagecard{MyOrange}{6cm}{img/nature}{<text>}
\end{lstlisting}

		\imagecard{img/visual1}{6cm}{
			{\Large Image Card} \\
		This card has an image as background.
		}
		\verb|\imagecard{img/visual1}{6cm}{<text>}|

	\end{columns}

\end{frame}

\begin{frame}[fragile]{Cards can be used in many ways}

	\centering
	Here we use them to represent task flow of software development.
	\vspace{\baselineskip}

	\begin{columns}
		\column{0.25\textwidth}
		\centering

		\card{MyGreen}{DarkBlue}{3.5cm}{img/one}{
			{\Large PREPARE} \\
			We can explain strengths here. There may be many points which we can write here. We can explain strengths here. There may be many points which we can write here.
		}

		\column{0.25\textwidth}
		\centering

		\card{MyGreen}{DarkBlue}{3.5cm}{img/two}{
			{\Large DEVELOP} \\
			We can explain weaknesses here. There may be many points which we can write here. We can explain strengths here. There may be many points which we can write here.
		}

		\column{0.25\textwidth}
		\centering

		\card{MyGreen}{DarkBlue}{3.5cm}{img/three}{
			{\Large DEPLOY} \\
			We can explain opportunities here. There may be many points which we can write here. We can explain strengths here. There may be many points which we can write here.
		}

		\column{0.25\textwidth}
		\centering

		\card{MyGreen}{DarkBlue}{3.5cm}{img/four}{
			{\Large SUPPORT} \\
			We can explain threats here. There may be many points which we can write here. We can explain strengths here. There may be many points which we can write here.
		}

	\end{columns}

\end{frame}

\begin{frame}[fragile]{Fancy tables}
\begin{center}
\begin{fancytable}{Table Title}{2cm}
{
	No. & Monday   & Tuesday & Wednesday & Thursday & Friday\\
	1   & A & B & C & D & E \\
	2   & F & G & H & J & K \\
	3   & A & B & C & D & E \\
}
\end{fancytable}
\end{center}
\begin{lstlisting}
\begin{fancytable}{Table Title}{2cm}
{No. & Monday   & Tuesday & Wednesday & Thursday & Friday\\
1   & A & B & C & D & E \\
2   & F & G & H & J & K \\
3   & A & B & C & D & E \\}
\end{fancytable}
\end{lstlisting}
\end{frame}

\begin{frame}[fragile]{Fancy Tables with multi-line cells}
	\centering
	Some times some rows need more depth.
	\begin{center}
		\begin{fancytable}{Algorithm Analysis}{3cm}{
				Algorithm & Run time & Remark \\
				|[text depth=3ex]|This is a big Old algorithm & 	|[text depth=3ex]| $O(n^3)$ & 	|[text depth=3ex]|  pretty slow \\
				New algorithm & $O(n)$ & still slow \\
			}
		\end{fancytable}
	\end{center}
\begin{lstlisting}
\begin{fancytable}{Algorithm Analysis}{3cm}{
Algorithm & Run time & Remark \\
|[text depth=3ex]|This is a big Old algorithm & |[text depth=3ex]| $O(n^3)$ & |[text depth=3ex]|  pretty slow \\
New algorithm & $O(n)$ & still slow \\}
\end{fancytable}
\end{lstlisting}
\end{frame}

\begin{frame}[fragile]{Fancy Tables with selection}
	\centering
	We can select a row to highlight.
	\begin{center}
	\begin{fancytable}{Algorithm Analysis}{3cm}{
		Algorithm & Run time & Remark \\
		|[fill=SelectColor]| Our algorithm & 	|[fill=SelectColor]| $O(\log n)$ & 	|[fill=SelectColor]| fast \\
		|[text depth=3ex]|This is a big Old algorithm & 	|[text depth=3ex]| $O(n^3)$ & 	|[text depth=3ex]|  pretty slow \\
		New algorithm & $O(n)$ & still slow \\
	}
	\end{fancytable}
	\end{center}
\end{frame}

\begin{frame}[fragile]{Fancy Tables are..}
	\centering
	\alert{Even Fancier!!}
	\begin{center}
		\begin{fancytable}{Algorithm Analysis}{3cm}{
		|[]|	\checkbox{} &	Algorithm & Run time & Remark \\
		|[fill=SelectColor]|\checkumark &	|[fill=SelectColor]| Our algorithm & 	|[fill=SelectColor]| $O(\log n)$ & 	|[fill=SelectColor]| fast \\
		|[text depth=3ex]|\checkbox{} & |[text depth=3ex]|This is a big Old algorithm & 	|[text depth=3ex]| $O(n^3)$ & 	|[text depth=3ex]|  pretty slow \\
		|[]|	\checkbox{}	& New algorithm & $O(n)$ & still slow \\
			}
		\end{fancytable}
	\end{center}
\end{frame}

\begin{frame}[fragile]{We can make fancy lists}
	\begin{columns}
		\column{0.5\textwidth}
		\centering
\begin{lstlisting}
\begin{fancylist}
\item Our awesome research results
\item They can also be applied elsewhere
\item Methods are new and efficient
\item It does have some drawbacks. But every method does.Drawbacks are norm in this field and that is alright.
\end{fancylist}
\end{lstlisting}

		\column{0.5\textwidth}
		\centering
			\begin{fancylist}
			\item Our awesome research results
			\item They can also be applied elsewhere
			\item Methods are new and efficient
			\item It does have some drawbacks. But every method does. Drawbacks are norm in this field and that is alright.
		\end{fancylist}
	\end{columns}
\end{frame}

\begin{frame}[fragile]{Fancy lists with fancy options...}
	\begin{columns}
		\column{0.5\textwidth}
		\centering
\begin{lstlisting}
\begin{fancylist}[color=MyOrange] ...
\end{lstlisting}
\vspace{\baselineskip}
		\begin{fancylist}[color=MyOrange]
	\item Our awesome research results
	\item They can also be applied elsewhere
	\item Methods are new and efficient
	\item It does have some drawbacks. But every method does.
	\end{fancylist}

		\column{0.5\textwidth}
		\centering
\begin{lstlisting}
\begin{fancylist}[color=AlertColor, shape=ring]...
\end{lstlisting}

		\begin{fancylist}[color=AlertColor, shape=ring]
			\item Our awesome research results
			\item They can also be applied elsewhere
			\item Methods are new and efficient
			\item It does have some drawbacks. But every method does.
		\end{fancylist}
	\end{columns}
\end{frame}

\begin{frame}[fragile]{Fancy lists with fancy options...}
	\begin{columns}
		\column{0.5\textwidth}
		\centering
\begin{lstlisting}
\begin{fancylist}[color=MyBlue, shape=square]...
\end{lstlisting}

		\begin{fancylist}[color=MyBlue, shape=square]
			\item Our awesome research results
			\item They can also be applied elsewhere
			\item Methods are new and efficient
			\item It does have some drawbacks. But every method does.
		\end{fancylist}

		\column{0.5\textwidth}
		\centering
\begin{lstlisting}
\begin{fancylist}[shape=hollowsquare]...
\end{lstlisting}
		\begin{fancylist}[shape=hollowsquare]
			\item Our awesome research results
			\item They can also be applied elsewhere
			\item Methods are new and efficient
			\item It does have some drawbacks. But every method does.
		\end{fancylist}
	\end{columns}
\end{frame}

\begin{frame}[fragile]{Colorful side headings}
	\fancybox{Definition}{
		Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley.
	}

	\fancybox[MyPink]{Some Important Points}{
		So here we go:
		\begin{enumerate}
			\item First point
			\item Second point
			\item Third Point
		\end{enumerate}
	And here we stop.
	}
\end{frame}

\begin{frame}
	\mainresult{Our Main Result}{
		Sometimes we want to dedicate one slide to show our result. This whole slide just shows our result, so that viewers can see it for a while and soak it. It should look beautiful.
		}
\end{frame}

\begin{frame}
	\mainresult[MyBlue]{Our Main Result In Blue}{
		Of course we can change background color for this slide. We can make it blue for example and it still looks beautiful. We are focused -- viewers are focused -- Happiness. We can make it look like a profound quote. \\
		\hfill \footnotesize{- Some wise man}
	}
\end{frame}

\begin{frame}
\vspace{2\baselineskip}
\ribbon{MyOrange}{\fontbold \Huge How Does It Work?}
\end{frame}

\begin{frame}
\centering
\begin{columns}
	\column{0.5\textwidth}
	I give you a minimal theme with no clutter. If you use it wisely then only sky is the limit.
	Unleash your {\Huge \alert{CREATIVITY}}.
	\column{0.5\textwidth}
	\begin{figure}
		\includegraphics[width=4cm]{img/think}
	\end{figure}
\end{columns}

\end{frame}

\begin{frame}[fragile]{How do I use it?}
	Include this in your preamble.
\begin{verbatim}
\usetheme[style=light]{simple}
\end{verbatim}

It comes in	three styles --
\begin{itemize}
	\item Dark Style - \verb|\usetheme[style=dark]{simple} |
	\item \alert{Light Style (Default)}  - \verb|\usetheme[style=light]{simple} |
	\item No style - \verb|\usetheme[style=none]{simple} |
\end{itemize}

And works like any other theme...

\begin{block}{Block}
works like a block.
\end{block}

Equations render just fine --
\begin{equation}
A^x + B^y = ?
\end{equation}
and so on so forth.
\end{frame}

\begin{frame}[fragile]{Can I make changes?}
\begin{center}
	\alert{Yes. You can change whatever you want.}
\end{center}

\fancybox[MyBlue]{What about Fonts?}{
	I have provided all the used fonts in Fonts directory. As far as I know these are open-source fonts.
}

You can also go to \verb|beamerinnerthemesimple.sty| and change fonts to the ones you like.

Define a bold and italic font:
\begin{verbatim}
\newfontfamily\fontbold{<Your Bold Font Here>}
\newfontfamily\fontitalic{<Your Italic Font Here>}
\end{verbatim}
Define a font for big quotation marks:
\begin{verbatim}
\newfontfamily\quotefont{<Your Font For Quotation Mark Here>}
\end{verbatim}
\end{frame}

\begin{frame}
	\vspace{2\baselineskip}
	\ribbon{DarkGold}{\fontbold \Huge What Next?}
\end{frame}

\begin{frame}
\centering
\alert{I'd love to hear your thoughts, issues, questions and comments.}
\begin{columns}
	\column{0.5\textwidth}
	\begin{figure}
		\includegraphics[width=3cm]{img/questionguy}
	\end{figure}
	\column{0.5\textwidth}
		\begin{figure}
		\includegraphics[width=3cm]{img/questiongirl}
	\end{figure}
\end{columns}
\end{frame}

\end{document}


text:
\begin{frame}
  \frametitle{Progress chart}
  	  \begin{textblock*}{12.5cm}(0.1cm,3cm) % {block width} (coords)
 \begin{figure}[ht!] % replace 't' with 'b' to force it to
	\includegraphics[width=\textwidth]{./images/progress_chart_light.pdf}
	\caption{Workflow for the simulations proposed in this work.}
\end{figure}
		\end{textblock*}
\end{frame}

\subsection{Stage 1: Basic on-line reprocessing demonstration}

\begin{frame}
\frametitle{Stage 1 goals (complete)}
	\begin{itemize}
		\itemsep1em
		\item Review and summarize state of the art
		\item Create \textbf{high-fidelity full-core model} of the \gls{MSBR}
		in Serpent
		\item Simple SaltProc v0.1 demonstration and validation for
		once-through \gls{MSR} reprocessing \textbf{(``black box'') with
		fixed, ideal $\epsilon_e$}
		\item \textbf{Equilibrium fuel composition} search for the \gls{MSBR}
		based on ideal removals
		\item Investigate \textbf{effect of \gls{FP} removal}
	\end{itemize}

\end{frame}

\begin{frame}
\frametitle{Stage 1 results: multiplication factor dynamics}

\begin{columns}
	\column{4.3cm}
	\begin{block}{\gls{MSBR} on-line reprocessing analysis}
		\fontsize{7}{9}\selectfont
		\begin{itemize}
			\item Full-core model of the \gls{MSBR} for 60 years of operation
			\item FP removal from the salt with fixed, ideal extraction
			efficiencies
			\item $^{233}$Pa ideal removal and feed of an equal mass of
			$^{233}$U into the core
			\item Fresh fertile material feed to maintain the salt inventory
			\item Fine time resolution (3-day depletion steps)
		\end{itemize}
	\end{block}

	\column{8cm}
		\begin{figure}[ht!]
		\centering
			\includegraphics[width=\textwidth]{../figures/keff_msbr.png}
			\caption{Effective multiplication factor dynamics for the
			full-core \gls{MSBR} model (reproduced from
			Rykhlevskii \emph{et al.} \cite{rykhlevskii_modeling_2019}).}
		\end{figure}

\end{columns}
\end{frame}

\begin{frame}
\frametitle{Stage 1 results: Effect of fission products removal}

\begin{figure}[t] % replace 't' with 'b' to force it to
	\centering
	\includegraphics[width=0.8\textwidth]{../figures/keff_rem_cases.png}
	\caption{Calculated effective multiplication factor for the full-core
		\gls{MSBR} model with removal of various fission product groups over
		10 	years of operation (reproduced from Rykhlevskii \emph{et al.}
		\cite{rykhlevskii_modeling_2019}).}
\end{figure}

\end{frame}

\subsection{Stage 2: Tool demonstration and validation for \gls{TAP}}

\begin{frame}
\frametitle{Stage 2 goals (in progress)}
\begin{enumerate}
	\itemsep1em
	\item Review and summarize the \gls{TAP} reactor and \textbf{fuel
	reprocessing system design}
	\item Create \textbf{high-fidelity full-core model} of the \gls{TAP} core
	in Serpent
	\item Develop multi-component fuel reprocessing system model with
	\textbf{fixed, non-ideal removal efficiency}
	\item SaltProc demonstration for fixed removal
	efficiency and static geometry
	\item Enable switching between multiple Serpent
geometries during
	simulation to \textbf{maintain the \gls{TAP} core criticality}
	\item Perform 40-year depletion simulation using SaltProc and
	\textbf{compare} obtained results with Betzler \emph{et al.}
	\cite{betzler_assessment_2017}
\end{enumerate}

\end{frame}

\begin{frame}
\frametitle{\gls{TAP} concept high-fidelity Serpent model}
	  \begin{textblock*}{12.25cm}(0.25cm,1.8cm) % {block width} (coords)
\begin{figure}[htp!] % replace 't' with 'b' to
	\includegraphics[width=\textwidth]{./images/tap_model.png}
	\caption{An $XY$ (left) and $XZ$ (right) section of the \gls{TAP} model.
	The violet color represents zirconium hydride, and the yellow represents
	fuel salt (reproduced from Rykhlevskii \& Huff
	\cite{rykhlevskii_milestone_2019}).}
\end{figure}
	  \end{textblock*}
\end{frame}

\begin{frame}
\frametitle{Multi-component fuel reprocessing system model in SaltProc}

\begin{columns}
		\column[t]{6cm}
		\begin{itemize}
			\item Fixed, non-ideal ($<100\%$) removal efficiencies
			\item Sparger and separator located in-line
			\item Static geometry with constant moderator-to-fuel ratio
			\item 5\% and 19.79\% low-enriched uranium feed
		\end{itemize}

	\column[t]{6.5cm}
	\begin{figure}[htp!] % replace 't' with 'b' to
	\centering
			\vspace{-7mm}
		\begin{overprint}
	\onslide<1>\includegraphics[height=0.8\textheight]{../figures/demo_reprocessing_scheme.png}
	\onslide<2>\includegraphics[height=0.8\textheight]{../figures/demo_reprocessing_scheme_2.png}
		\end{overprint}
	\caption{\gls{TAP} reprocessing scheme flowchart used for demonstration of
		SaltProc \cite{rykhlevskii_milestone_2019}.}
	\end{figure}
\end{columns}
\end{frame}

\begin{frame}
\frametitle{Depletion simulation results for TAP with various feeds}
\begin{textblock*}{12.6cm}(0.1cm,2.2cm) % {block width} (coords)
	\begin{figure}[htp!] % replace 't' with 'b' to
		\begin{minipage}[b]{0.48\textwidth}
			\includegraphics[width=\linewidth]{../figures/keff_3.png}
		\end{minipage}
			\hspace{-2mm}
		\begin{minipage}[b]{0.48\textwidth}
			\includegraphics[width=\linewidth]{../figures/keff_zoomed_2.png}
		\end{minipage}
		\caption{Effective multiplication factor dynamics for full-core
		\gls{TAP} model for different fueling scenarios over a 13-year reactor
		operation (left) and for the time interval from 367 to 471 days after
		startup (right). Confidence interval $\pm\sigma=28pcm$ is shaded.}
	\end{figure}
\end{textblock*}
\end{frame}

\begin{frame}
\frametitle{Fuel salt composition evolution during the TAP operation}
\begin{textblock*}{12.25cm}(0.25cm,1.8cm) % {block width} (coords)
	\begin{figure}[htp!] % replace 't' with 'b' to
		\centering
				\vspace{-3mm}
		\includegraphics[width=0.72\textwidth]{../figures/u_pu_mass.png}
		\caption{Mass of major nuclides during 13 years of reactor operation
		with 19.79\% \gls{LEU} feed.}
	\end{figure}
\end{textblock*}
\end{frame}

%\begin{frame}
%\frametitle{SaltProc demonstration for realistic on-line reprocessing system}
%\begin{block}{Finishing Stage 2}
%	\begin{enumerate}
%		\item Implement variable core geometry capability in SaltProc
%		\item Demonstrate a key feature of
%		the \gls{TAP} reactor -
%		adjusting the moderator rod configuration - which is necessary
%		achieve 60-years lifetime.
%		\item Perform 40-year depletion simulation using SaltProc
%		and compare obtained results with Betzler \emph{et al.}
%		\cite{betzler_assessment_2017}
%	\end{enumerate}
%\end{block}
%\end{frame}

\subsection{Stage 3\&4: Variable Xe removal and gas removal system bounding}

\begin{frame}
	\frametitle{Stage 3 (in progress): SaltProc demonstration with variable
	$\epsilon_{Xe}$}
	\begin{columns}
	\column{7cm}
\begin{block}{Realistic fuel processing system model for the \gls{TAP}}
	\begin{enumerate}
		\itemsep1em
		\item Incorporate extraction efficiencies as a \textbf{function of
		many physical system design	parameters} (e.g., helium bubble size)
		\item Perform life-time long depletion simulation with \textbf{dynamic
		removal efficiency}
		\item Perform short-term (3 days) in \textbf{load-following regime}
		\item Conduct \textbf{parametric sweep of input parameters} in
		$\epsilon_{Xe}$
		equation to determine the range of key parameters
	\end{enumerate}
\end{block}
	\column{4.5cm}
	\begin{figure}[bth!] % replace 't' with 'b' to
		\centering
		\includegraphics[width=1.1\textwidth]{../figures/load_curve.png}
		\caption{Tentative load curve for short-term simulation.}
		\label{fig:load}
	\end{figure}
	\end{columns}
\end{frame}

\begin{frame}
\frametitle{Gas removal system bounding for the TAP}

\begin{block}{Stage 4: Prototype design for the xenon removal system}
	\begin{enumerate}
		\itemsep1em
		\item \textbf{Determine bounds for key design parameters} (sparger
		volume, geometry, salt and helium flow rates) by analyzing parametric
		sweep
		\item Calculate key design parameters to \textbf{minimize fuel salt
		inventory} in the system
		\item Perform \textbf{nuclear criticality safety} analysis using MCNP6
		\cite{werner_mcnp6._2018} to confirm that the selected sparger design
		is safe
	\end{enumerate}
\end{block}
\end{frame}

\subsection{Stage 5: Safety parameters evolution}

\begin{frame}
\frametitle{\gls{TAP} Safety and Operational parameters analysis}
		\begin{block}{Stage 5: Safety parameters dynamics for
		long- and short-term depletion}
	\begin{enumerate}
		\itemsep1em
		\item Finish a axially discretized core	geometry in Serpent with
		non-uniform axial density distribution to estimate the \textbf{axial
		power offset}
		\item Create a script/template for quick calculation of \textbf{all
		safety parameters for given core configuration} (geometry and fuel
		composition)
		\item Calculate safety parameters (temperature coefficients, control
		rod worth, axial power offset) at \textbf{different moment during
		operation}
		\item Repeat for short-term depletion to capture the
		\textbf{parameters dynamics for load-following operation}
	\end{enumerate}
		\end{block}
\end{frame}

\begin{frame}
\frametitle{Safety parameters calculations at start-up}

\begin{columns}
	\column{6cm}
	\begin{itemize}
		\item \textbf{Temperature coefficient} of reactivity calculated
		separately for fuel and moderator in range \textbf{800-1000K}
		\item A configuration of 25 control rods has a reactivity worth of
		\textbf{$1110\pm9.7$pcm (1.1\%) at startup}
		\item Serpent template to calculate temperature coefficients and
		control rod worth \textbf{by single run} was developed
	\end{itemize}

	\column{6.5cm}
	\begin{figure}[bth!] % replace 't' with 'b' to
	\includegraphics[width=\textwidth]{../figures/axial_offset.png}
	\caption{\gls{TAP} model divided to multiple axial layers with different
	densities of the salt to calculate axial power offset.}
	\end{figure}
\end{columns}
\end{frame}


text:
\documentclass[12pt]{book}
\usepackage{tgschola}
\usepackage{longtable}
\usepackage{booktabs}
\usepackage{hyperref}
\usepackage[utf8]{inputenc}
\usepackage[margin=1in]{geometry}
\usepackage{minted}
\usepackage{tikz}
\usetikzlibrary{shapes.geometric, arrows, positioning}

\title{The Robot Plumbing Guide}
\date{2017-10-07}
\author{The Hibike Team}
\begin{document}
\maketitle

\tableofcontents

\chapter{Introduction}
The driving principle behind PiE is running a robotics competition. This means many things:
logistics, provinding mentorship and guidance, organizing events,
providing an interface for programming the robot, and making
the robot work. Keep in mind that this guide addresses only one aspect
of the competition; plumbing is not everything. With that said, it is still a good
idea to have a plumber on hand when pipes start to leak.
\section{A Brief Overview of the Control Stack}
For our purposes, there are five elements involved in controlling the robot.
\begin{enumerate}
	\item Dawn: the main interface that students use. Takes inputs from the controller,
	    and shows data and errors to students.
    \item Ansible: the transmitter and reciever for data to and from Dawn.
	\item Runtime: the program in charge of monitoring and communication. Sends and receives data from
        Dawn (via Ansible), as well as monitoring Hibike and StateManager.
	\item StateManager: a data store. Provides a central place to store and retrive data from Hibike
	    and Runtime.
	\item Hibike: the program that communicates with sensors. Handles low-level protocol details.
\end{enumerate}
\section{A Diagram of the Stack}
\begin{center}
\begin{tikzpicture}[node distance=3.5cm, part/.style={
        rectangle,
        rounded corners,
        draw=black,
        text=black,
        fill=green!50,
        minimum size=1.5cm,
        very thick
    }, method/.style={
        rectangle,
        draw=black,
        fill=yellow!50,
    }, arrow/.style={
        very thick, <->, =>stealth
    }]
    \node (smgr) [part] {StateManager};
    \node (ansible) [part, right=of smgr] {Ansible};
    \node (dawn) [part, right=of ansible, xshift=-1cm] {Dawn};
    \node (student) [part, below=of dawn] {Student} ;
    \node (runtime) [part, below=of ansible] {Runtime};
    \node (hibike) [part, below=of smgr] {Hibike};
    \node (smrt1) [part, below=of hibike] {SD 2};
    \node (smrt2) [part, right=of smrt1] {...};
    \node (smrtmore) [part, left=of smrt1] {SD 1};
    \node (studentapi) [part, left=of smgr, xshift=1.5cm] {Student API};
    \node (studentcode) [part, below=of studentapi] {Student Code};
    \draw [arrow] (studentcode) -- (studentapi);
    \draw [arrow] (studentapi) -- node[method] {Pipe} (smgr);
    \draw [arrow] (runtime) -- (ansible);
    \draw [arrow] (student) -- node[method] {Screen \& Keyboard} (dawn);
    \draw [arrow] (dawn) -- node[method] {Wifi} (ansible);
    \draw [arrow] (smgr) -- node[method] {Pipe} (runtime);
    \draw [arrow] (smgr) -- node[method] {Queue} (hibike);
    \draw [arrow] (hibike) -- (smrt2);
    \draw [arrow] (hibike) -- node[method] {USB Serial} (smrt1);
    \draw [arrow] (hibike) -- (smrtmore);

\end{tikzpicture}
\end{center}
\chapter{Hibike}
Hibike is in charge of low-level sensor communication, and all the gory
details that are involved. It is divided into two modules:
\begin{itemize}
	\item \texttt{hibike\_message.py}

	The low-level details of the
	Hibike communications protocol. Handles things like encoding into packets and checksums.
	\item \texttt{hibike\_process.py}

	The ``supervisor'' of sensors.
	Communicates with sensors, sends data to runtime, and reacts to orders from StateManager.
\end{itemize}

Alongside these main modules, there are various testing modules:
\begin{itemize}
	\item \texttt{virtual\_device.py}

	Virtual devices, for testing Hibike's read and write capabilities.
	\item \texttt{hibike\_tester.py}

	A test module that wraps a Hibike process with a nicer interface.
\end{itemize}

\section{Design Choices and Explanations}
Hibike is packet-based and works over USB, specifically serial.

\paragraph{Why USB?}

In previous years, a custom communications protocol was used, over custom cables.
This provided the advantage of real-time communications
and configurability; however, debugging was very difficult,
and developing for smart sensors more so. The Beaglebone doesn't provide real-time guarantees
anyways, and USB provides cheap, commodity cables and well-tested software.

\paragraph{Why packets?}

Most protocols are packet-based, and serial is not a packet-based communications link.
Packets make it easy to tell when data begins and ends.

\paragraph{Why serial?}

Arduino provides a well-tested serial library, so communication with any Arduino is easy
over serial. In addition, implementing and using serial is relatively simple compared
to many other types of USB connection, such as HID (used by keyboards and mice). Some
flexibility and speed is lost as a result of this abstraction, but much more is gained
in ease of use.

\section{The Hibike Protocol}
\subsection{A Quick Introduction}
We make a few starting assumptions concerning the endpoints of communication: the device controlling a sensor is a Smart Device (SD), and a Beaglebone Black (BBB) is used as the central control board of each robot and thus is in charge of communicating with each Smart Device. These two communicate with each other via serial: the Beaglebone running pySerial and the Smart Device by using the built-in serial library. As each Smart Device communicates with the Beaglebone on its own separate port, we conveniently have no need to worry about any race conditions or other problems arising from concurrency.

Hibike abstracts every Smart Device as a set of (parameter, value) pairs.
The hibike protocol supports three ways of interacting with these parameters:
\begin{itemize}
\item Subscribing to regular updates of specific paramters
\item Polling specific parameters
\item Writing to specific parameters
\end{itemize}

Refer to Section 7 for an outline of the general behavior of the Hibike protocol.

\subsection{Message Format}

All messages have the relatively simple structure of Message ID, Payload, and Checksum as
depicted below. A more complete description of each field is given below the diagram.

\begin{center}
	\begin{tabular}{|c|c|c|c|}
	\hline
	Message ID & Payload Length & Payload & Checksum \\
	(8 Bits) & (8 Bits) & (Length Varies) & (8 Bits) \\
	\hline
	\end{tabular}
\end{center}

\begin{itemize}
	\item Message ID
	\begin{itemize}
		\item An 8-bit ID specifying the type of message.
		\item More information about this field in the following sections.
	\end{itemize}
	\item Payload Length
	\begin{itemize}
		\item An 8-bit unsigned integer, specifying the number of bytes in the payload.
	\end{itemize}
	\item Payload
	\begin{itemize}
		\item Varies depending on the type of message sent.
	\end{itemize}
	\item Checksum
	\begin{itemize}
		\item An 8-bit checksum placed at the end of every message.]
		\item The current scheme XORs every other byte in the message.
	\end{itemize}
\end{itemize}

\subsection{UID Format}
Each smart device is assigned an 88-bit UID with the following fields.

\begin{center}
	\begin{tabular}{|c|c|c|}
	\hline
	Device Type & Year & ID \\
	(16 Bits) & (8 Bits) & (64 bits) \\
	\hline
	\end{tabular}
\end{center}

\begin{itemize}
	\item Device Type
	\begin{itemize}
		\item 16-bit ID specifying the Type of a Smart Device
		\item Device types are enumerated in Section 5
	\end{itemize}
	\item Year
	\begin{itemize}
		\item 8-bit ID corresponding to the competition year that the Smart Device was manufactured for.
		\item The 2015-2016 season will correspond to 0x00
	\end{itemize}
	\item ID
  	\begin{itemize}
  		\item Randomly generated 64-bit number that will uniquely identify each Smart Device within a specific device type and year.
  		\item With 64-bit IDs, the probability of a hash collision with 1000 of 1 type of device per year is roughly 0.05\%
	\end{itemize}
\end{itemize}

\subsection{Parameters and Bitmaps}

\begin{itemize}
	\item Hibike abstracts every smart device as a set of parameters that map to values
	\item Each smart device contains some number of paramaters, which can be read/written to.
	\item Parameters can have many types. The following types are supported:
	\begin{itemize}
		\item \texttt{bool}
		\item \texttt{uint8\_t}
		\item \texttt{int8\_t}
		\item \texttt{uint16\_t}
		\item \texttt{int16\_t}
		\item \texttt{uint32\_t}
		\item \texttt{int32\_t}
		\item \texttt{uint64\_t}
		\item \texttt{int64\_t}
		\item \texttt{float}
		\item \texttt{double}
	\end{itemize} CAUTION: Arduino's doubles are only 4 bytes long (same as a float), so an
	Arduino's Double is the same as python's Float. Do not use this type
	unless your arduino is actually cranking out 8 bytes.
	\item Some paramaters are read only, some are write only, and some support both.
	\item A config file will describe the paramaters for each Device Type (name, type, permissions).
	\item Some packets encode sets of parameters in the form of bitmaps.
	\begin{center}
		\begin{tabular}{|c|c |c| c|}
		\hline
		Params & Value 0 & \ldots & Value 15 \\
		(16 bits) & (Optional and Variable) & \ldots & (Optional and Variable) \\
		\hline
		\end{tabular}
	\end{center}
	\begin{itemize}
		\item Params - 16-bit bitmap describing a set of parameters. The nth bit of
		Params, where the LSB is the 0th bit, references the nth paramater of
  		a device.
		\item Value{[}0-15{]} - DeviceWrite and DeviceData send actual values for
  		each param in Params. The value field for param n will only be present
  		if bit n in Params is set. The size and type of each value field
  		depends on param number and device type, and is described in a config
  		file.
  	\end{itemize}
\end{itemize}

\subsection{Message Types}
\begin{center}
    \begin{tabular}{|c|c|}
        \hline
        ID & Message Type \\
        \hline
        0x10 & Ping \\
        0x11 & Subscription Request \\
        0x12 & Subscription Response \\
        0x13 & Device Read \\
        0x14 & Device Write \\
        0x15 & Device Data \\
        0x16 & Device Disable \\
        0x17 & Heartbeat Request \\
        0x18 & Heartbeat Response \\
        0xFF & Error \\
        \hline
    \end{tabular}
\end{center}

\subsection{Device Types}
% This part was automatically converted from the README
\begin{longtable}[c]{@{}|l|l|l|l|l|l|l|@{}}
\toprule
ID & Sensor & Param Number & Param Name & Param Type & Read? &
Write?\tabularnewline
\midrule
\endhead
\hline
0x00 & LimitSwitch & 0 & switch0 & bool & yes & no\tabularnewline
& & 1 & switch1 & bool & yes & no\tabularnewline
& & 2 & switch2 & bool & yes & no\tabularnewline
0x01 & LineFollower & 0 & left & float & yes & no\tabularnewline
& & 1 & center & float & yes & no\tabularnewline
& & 2 & right & float & yes & no\tabularnewline
0x02 & Potentiometer & 0 & pot0 & float & yes & no\tabularnewline
& & 1 & pot1 & float & yes & no\tabularnewline
& & 2 & pot2 & float & yes & no\tabularnewline
0x03 & Encoder & 0 & rotation & int16\_t & yes & no\tabularnewline
0x04 & BatteryBuzzer & 0 & is\_unsafe & bool & yes & no\tabularnewline
& & 1 & calibrated & bool & yes & no\tabularnewline
& & 2 & v\_cell1 & float & yes & no\tabularnewline
& & 3 & v\_cell2 & float & yes & no\tabularnewline
& & 4 & v\_cell3 & float & yes & no\tabularnewline
& & 5 & v\_batt & float & yes & no\tabularnewline
& & 6 & dv\_cell2 & float & yes & no\tabularnewline
& & 7 & dv\_cell3 & float & yes & no\tabularnewline
0x05 & TeamFlag & 0 & mode & bool & yes & yes\tabularnewline
& & 1 & blue & bool & yes & yes\tabularnewline
& & 2 & yellow & bool & yes & yes\tabularnewline
& & 3 & led1 & bool & yes & yes\tabularnewline
& & 4 & led2 & bool & yes & yes\tabularnewline
& & 5 & led3 & bool & yes & yes\tabularnewline
& & 6 & led4 & bool & yes & yes\tabularnewline
0x06 & Grizzly & & & & &\tabularnewline
0x07 & ServoControl & 0 & servo0 & float & yes & yes\tabularnewline
& & 1 & servo1 & float & yes & yes\tabularnewline
0x08 & LinearActuator & & & & &\tabularnewline
0x09 & ColorSensor & & & & &\tabularnewline
0x0A & YogiBear & 0 & duty\_cycle & float & yes & yes\tabularnewline
& & 1 & pid\_pos\_setpoint & float & no & yes\tabularnewline
& & 2 & pid\_pos\_kp & float & no & yes\tabularnewline
& & 3 & pid\_pos\_ki & float & no & yes\tabularnewline
& & 4 & pid\_pos\_kd & float & no & yes\tabularnewline
& & 5 & pid\_vel\_setpoint & float & no & yes\tabularnewline
& & 6 & pid\_vel\_kp & float & no & yes\tabularnewline
& & 7 & pid\_vel\_ki & float & no & yes\tabularnewline
& & 8 & pid\_vel\_kd & float & no & yes\tabularnewline
& & 9 & current\_thresh & float & no & yes\tabularnewline
& & 10 & enc\_pos & float & yes & yes\tabularnewline
& & 11 & enc\_vel & float & yes & no\tabularnewline
& & 12 & motor\_current & float & yes & no\tabularnewline
& & 13 & deadband & float & yes & yes\tabularnewline
0x0B & RFID & 0 & id & uint8\_t & yes & no\tabularnewline
& & 1 & detect\_tag & uint8\_t & yes & no\tabularnewline
0x10 & DistanceSensor & & & & &\tabularnewline
0x11 & MetalDetector & & & & &\tabularnewline
0xFFFF & ExampleDevice & 0 & kumiko & bool & yes & yes\tabularnewline
& & 1 & hazuki & uint8\_t & yes & yes\tabularnewline
& & 2 & sapphire & int8\_t & yes & yes\tabularnewline
& & 3 & reina & uint16\_t & yes & yes\tabularnewline
& & 4 & asuka & int16\_t & yes & yes\tabularnewline
& & 5 & haruka & uint32\_t & yes & yes\tabularnewline
& & 6 & kaori & int32\_t & yes & yes\tabularnewline
& & 7 & natsuki & uint64\_t & yes & yes\tabularnewline
& & 8 & yuko & int64\_t & yes & yes\tabularnewline
& & 9 & mizore & float & yes & yes\tabularnewline
& & 10 & nozomi & double & yes & yes\tabularnewline
& & 11 & shuichi & uint8\_t & yes & no\tabularnewline
& & 12 & takuya & uint16\_t & no & yes\tabularnewline
& & 13 & riko & uint32\_t & yes & no\tabularnewline
& & 14 & aoi & uint64\_t & no & yes\tabularnewline
& & 15 & noboru & float & yes & no\tabularnewline
\bottomrule
\end{longtable}

\subsection{Error Types}
\begin{tabular}{|c|c|}
    \hline
    Status & Meaning \\
    \hline
    0xFD & Unexpected Packet Delimiter \\
    0xFE & Checksum Error \\
    0xFF & Generic Error \\
    \hline
\end{tabular}

\subsection{Message Descriptions}
\begin{enumerate}
    \item Ping: BBB pings SD for enumeration purposes.
        The SD will respond with a SubscriptionResponse packet.

        Payload format:
        \begin{center}
            \begin{tabular}{|c|c|}
                \hline
                Empty \\
                (0 bits) \\
                \hline
            \end{tabular}
        \end{center}
        Direction: BBB $\Rightarrow$ SD

    \item SubscriptionRequest: BBB requests data to be returned at a given interval.
        \begin{itemize}
            \item Params is a bitmap of paramaters being subscribed to.
            \item The SD will respond with a Sub Response packet with a delay and
                bitmap of params it will acutally send values for, which may not be
                what was requested, due to nonexistent and write-only parameters.
            \item If too many parameters are subscribed to, the Smart Device may have
                to send multiple DeviceData packets at each interval.
            \item A delay of 0 indicates that the BBB does not want to receive data.
            \item Non-zero delay with 0 Params will still subscribe to empty
                updates!!!
        \end{itemize}
        Payload format:
        \begin{center}
            \begin{tabular}{|c|c|}
                \hline
                Params & Delay \\
                (16 bits) & (16 bits) \\
                \hline
            \end{tabular}
        \end{center}
        Direction: BBB $\Rightarrow$ SD
    \item SubscriptionResponse: SD sends (essentially) an ACK packet with its UID,
        params subscribed to, and delay.

        Payload format:
        \begin{center}
            \begin{tabular}{|c|c|c|}
                \hline
                Params & Delay & UID \\
                (16 bits) & (16 bits) & (88 bits) \\
                \hline
            \end{tabular}
        \end{center}
        Direction: BBB $\Leftarrow$ SD
    \item Device Read: BBB requests some values from the SD.
        \begin{itemize}
            \item The SD should respond with DeviceData packets with values for all
                the readable params that were requested.
            \item If all the values cannot fit in one packet, multiple will be sent.
        \end{itemize}

        Payload format:
        \begin{center}
            \begin{tabular}{|c|}
                \hline
                Params \\
                (16 bits) \\
                \hline
            \end{tabular}
        \end{center}
        Direction: BBB $\Rightarrow$ SD
    \item Device Write: BBB writes attempts to write values to some parameters.
        \begin{itemize}
            \item The SD should respond with a DeviceData packet describing the
                readable params that were actually written to.
            \item The protocol currently does not support any ACK for write only
                params.
        \end{itemize}

        Payload format:
        \begin{center}
            \begin{tabular}{|c|c|c|c|}
                \hline
                Params & Value 0 & \ldots & Value 15 \\
                (16 bits) & (Optional and Variable) & \ldots & (Optional and Variable) \\
                \hline
            \end{tabular}
        \end{center}
        Direction: BBB $\Rightarrow$ SD
    \item Device Data: SD sends the values of some of its paramters.
        \begin{itemize}
            \item This can occur in response to a DeviceWrite/DeviceRead, or when the
                interval for a SubscriptionResponse occurs.
        \end{itemize}
        Payload format:
        \begin{center}
            \begin{tabular}{|c|c|c|c|}
                \hline
                Params & Value 0 & \ldots & Value 15 \\
                (16 bits) & (Optional and Variable) & \ldots & (Optional and Variable) \\
                \hline
            \end{tabular}
        \end{center}

        Direction: BBB $\Leftarrow$ SD
    \item Heart Beat Request: BBB/SD requests SD/BBB heartbeat response for
        connectivity purposes.
        \begin{itemize}
            \item This message pathway is a two way street, both BBB and SD can send
                requests and send responses to the other
            \item Upon receiving a Heart Beat Request, a Heart Beat Response message
                should be immediately sent back
            \item Payload is currently unused, but can be used for future
                functionality in keeping track of individual heartbeat requests and
                responses (for latency purposes)
        \end{itemize}
        Payload format:
        \begin{center}
            \begin{tabular}{|c|}
                \hline
                ID \\
                (8 bits) \\
                \hline
            \end{tabular}
        \end{center}
        Direction: BBB $\Leftrightarrow$ SD
    \item Heart Beat Response: Sent in response to a Heart Beat Request
        \begin{itemize}
            \item This message pathway is a two way street, both BBB and SD can
                receive requests and send responses to the other
            \item Should only be sent upon receiving a Heart Beat Request
            \item Payload is currently unused, but can be used for future
                functionality in keeping track of individual heartbeat requests and
                responses (for latency purposes)
        \end{itemize}
        Payload format:
        \begin{center}
            \begin{tabular}{|c|}
                \hline
                ID \\
                (8 bits) \\
                \hline
            \end{tabular}
        \end{center}
        Direction: BBB $\Leftrightarrow$ SD
    \item Error Packet: Sent to indicate an error occured.
        \begin{itemize}
            \item Currently only used for the BBB to log statistics.
        \end{itemize}
        Payload format:
        \begin{center}
            \begin{tabular}{|c|}
                \hline
                Error Code\\
                (8 bits) \\
                \hline
            \end{tabular}
        \end{center}
        Direction: BBB $\Leftarrow$ SD

\end{enumerate}

\section{The Hibike Process}
\texttt{hibike\_process.py} handles communication with sensors and StateManager.
Initialization and running happen in this series of steps:
\begin{enumerate}
    \item Hibike asks the operating system for a list of serial ports that match
        those used by Arduinos.
    \item It verifies that these ports are working, and opens them for communication.
    \item Hibike checks that each port contains a smart sensor by pinging it.
    \item Each device is given a reading thread, a writing thread, and a write queue.
    \item Alongside the device threads, a read batching thread and a cleanup
        thread are started. The batch thread sends all reads to StateManager
        at certain intervals. The cleanup thread removes disconnected devices.
    \item Hibike tells all devices to stop sending data. Once the devices
        respond, StateManager subscribes to each device for each of
        its parameters.
    \item Afterwards, Hibike receives and reacts to commands from StateManager.
\end{enumerate}

Hibike devices are represented as a named tuple, with read and write
threads, a serial port, a write queue, and an instance ID, which
is generated randomly when the device starts up.

\subsection{An Explanation of the Architecture}
Each part of the structure of the Hibike process has its place, and has
been designed in deliberately. If threads are used, it is usually because
of blocking I/O.

\paragraph{Reader and Writer Threads}
Reading from a serial connection using nonblocking communication means that it
is easily possible to receive an incomplete packet even if the communications
link is reliable; thus, we use blocking reads. We don't want to stop reading
from every other sensor if one is taking a while, so we use threads to
periodically switch between sensors.

\paragraph{The Write Queue}
If a device sends a heartbeat request, we want to respond quickly
without going all the way to StateManager. Thus, we have a write queue, allowing
both the main thread and the read thread to write packets.

\paragraph{The Batch Thread}
Inter-thread communication is quick, but inter-process communication is slow.
Consequentially,
Hibike threads can quickly talk to each other, but talking to StateManager, which
runs in a separate process, is quite time-consuming. Instead of
sending any device data as soon as it is read, it is easier to bundle many
reads up and send them all at once. The batch thread is responsible for this.

\paragraph{The Cleanup Thread}
When a device disconnects, its resources remain in use. The read
and write threads sit idle, and the serial port remains open. This
can cause problems if a new device appears on an existing serial port,
so it is useful to clean up the resources. At the same time, it
can take up to 30 seconds to close a serial port, which is unacceptably
long for Hibike to wait. Therefore, a separate thread is put in charge
of such things.

\paragraph{The Hotplug Thread}
In order to detect new devices, something has to scan serial ports
and check which contain smart sensors. This could be done in the
main loop, but detection can take hundreds or even thousands of
milliseconds.

\paragraph{Instance IDs}
Devices already have an associated UID, that is (hopefully) unique
to every device. Why is it necessary to have yet another
unique identifier? The answer lies with hotplugging: it is
possible for a device to disconnect and then reconnect.
In this case, it still has the same UID, so we have no way
of telling whether it has reconnected. The solution is to associate
an ID with a particular connection to the device, so that the device
will have a different instance ID if it reconnects.

\section{Smart Devices}
There are a few types of smart device, each with its own responsibility.
Smart devices are based on the Arduino platform; we are using
Arduino Pro Micros because of their relative cheapness (\$4/unit)
and power. The firmware for these devices is written in C++.

\begin{itemize}
    \item LimitSwitch

        The name of this sensor is pretty self-explanatory. It's a limit
        switch (or two, or three), that is on when pressed.
    \item LineFollower

        This is a line-following sensor, that detects the brightness of
        the floor beneath it. There are three sensors: left, middle,
        and right.
    \item BatteryBuzzer

        This device monitors the battery voltage and cell balances,
        making sure that the battery doesn't get dangerously
        imbalanced or low. It displays the cell voltages
        on an LED display, and beeps when there are problems.
        Its functionality may be supplanted in
        the future by a dedicated chip.
    \item ServoControl

        The servo controller controls the position of a servo,
        in the range [-1, 1]. The position can be read or written to.

    \item YogiBear

        This is the new motor controller, put into place after the
        repeated demise of many a Grizzly. It uses a COTS motor controller,
        and has the ability to perform PID (supposedly). If Hibike
        does not respond to heartbeats, it disables itself automatically.

    \item RFID

        This sensor is unfortunately slow; sometimes, it will not read,
        and the read must be delayed for a cycle. It is also very close
        range; usually, about 0.5in is the maximum.
\end{itemize}

\section{Hotplug}
Smart sensor hotplug has been a highly requested feature for some time now.
There are two halves to hotplug: adding new devices, and disconnecting old ones.
Both sides of the implementation are based on polling -- periodically checking
whether new devices have been connected, or old ones removed.

\subsection{Adding New Devices}
Every period of \texttt{HOTPLUG\_POLL\_INTERVAL} seconds, the hotplug thread
wakes up and goes looking for new devices. It does this using the existing
\texttt{get\_working\_serial\_ports}, excluding any ports that are already
attached to existing devices. Afterwards, it scans these serial ports for smart
sensors, and adds them to the list of devices, spinning up threads and queues
as appropriate.

\subsection{Removing Disconnected Devices}
After adding any new devices, we go on the lookout for old devices that
have been disconnected. When a device is disconnected, its read and
write threads crash, and we receive a message in \texttt{error\_queue}.
If we have only received one message from a device, we assume that the device may only
have been temporarily disconnected, and resend the message for the next iteration.
If the existing device has a different instance ID, then we assume
that the device has reconnected.
Otherwise, we tell the cleanup thread to clean the device.

\section{Testing}
Hibike provides a few options for testing protocol compatibility
and generating data. In general, there is no substitute for testing on real
hardware, but there are at least a few tests.

\subsection{Latency}
Full-stack latency testing exists in the form of the \texttt{TIMESTAMP\_UP/DOWN}
commands, which are passed from Dawn to Ansible to StateManager, to Hibike,
and back up. At the end, Dawn prints the timestamps that each level sent.

\subsection{\texttt{hibike\_tester.py}}
This module acts as a fake StateManager, spawning its own
copy of \texttt{hibike\_process}. You can use this to verify
that Hibike is sending device data to state manager, and that
it reacts appropriately to commands sent to it.
\subsection{\texttt{virtual\_device.py}}
This implements virtual devices, which communicate with Hibike
through a virtual serial port. It is meant to be used with
\texttt{spawn\_virtual\_device.py} to create virtual devices
and send data on them. It can be used to test Hibike's ability to
respond to devices.
\subsection{Unit Tests}
Unit tests for some of Hibike's modules are located in the
\texttt{unit\_tests} directory, and make use of the
\texttt{unittest} Python module. Each function that
is tested has its own class, and a few test cases. These tests
should not be considered comprehensive.

\section{Code Samples}
\subsection{\texttt{hibike\_tester.py}}
\subsubsection{Basic Usage}
\begin{minted}{python}
"""
Example code to print the UID of every sensor attached to the
robot.

Author: Brose Johnstone
"""
from hibike_tester import Hibike
import hibike_message as hm

robot = Hibike()
robot.enumerate()

while True:
    packet = robot.state_queue.get()
    if packet.get_message_id() == hm.MESSAGE_TYPES["SubscriptionResponse"]:
        # Get the UID
        _, _, uid = hibike_message.parse_subscription_response(packet)
        print(uid)
\end{minted}

\subsubsection{Sending and Receiving Packets}
\begin{minted}{python}
"""
Request sensor data from a single device.

Author: Brose Johnstone
"""
from hibike_tester import Hibike
import hibike_message

# The UID of the device to read from
DEVICE_UID = # XXX: fill in yourself
DEVICE_ID = hibike_message.uid_to_device_id(DEVICE_UID)
# The list of parameters to read
DEVICE_PARAMS = # XXX: Fill this in yourself

robot = Hibike()
robot.read(DEVICE_UID, DEVICE_PARAMS)

while True:
    packet = robot.state_queue.get()
    if packet.get_message_id() == hibike_message.MESSAGE_TYPES["DeviceData"]:
        decoded = hibike_message.parse_device_data(packet, DEVICE_ID)
        print(decoded)
        break
\end{minted}
\subsubsection{Subscribing to a Device}
\begin{minted}{python}
"""
Subscribing to a device to receive regular updates.

Author: Brose Johnstone
"""
from hibike_tester import Hibike
import hibike_message

DEVICE_UID = ...
DEVICE_ID = hibike_message.uid_to_device_id(DEVICE_UID)
DEVICE_PARAMS = ...
SUBSCRIPTION_DELAY = ...

robot = Hibike()
robot.subscribe(DEVICE_UID, SUBSCRIPTION_DELAY, DEVICE_PARAMS)

while True:
    packet = robot.state_queue.get()
    if packet.get_message_id() == hibike_message.MESSAGE_TYPES["DeviceData"]:
        decoded = hibike_message.parse_device_data(packet, DEVICE_ID)
        print(decoded)
\end{minted}

\subsection{Identifying Serial Ports and Smart Sensors}
\begin{minted}{python}
"""
Identify which serial ports contain devices, and print the mapping
of serial ports to UIDs.

Author: Brose Johnstone
"""
from hibike_process import get_working_serial_ports, identify_smart_sensors

ports, port_names = get_working_serial_ports()
devices = identify_smart_sensors(ports)

for (port_name, uid) in devices.items():
    print(port_name, uid)
\end{minted}

\subsection{Working with UIDs}
\begin{minted}{python}
from hibike_message import *

# Fill this in with whatever UID you are working with
MY_UID = ...

# Print the type of the device, based on the UID.
print(uid_to_device_name(MY_UID))
# Turn the UID into a device ID.
DEVICE_ID = uid_to_device_id(MY_UID)
# Get possible parameters for the device
print(all_params_for_device_id(DEVICE_ID))
# Check if a parameter is readable (or writeable)
print("Is parameter {} readable? {}".format("XXX", readable(DEVICE_ID, "XXX"))
print("Is parameter {} writeable? {}".format("XXX", writeable(DEVICE_ID, "XXX"))
\end{minted}

\chapter{Runtime, StateManager, and Ansible}
\section{Runtime's Architecture}
Runtime supervises other processes and handles errors as they occur. It is
essentially a state machine that reacts to messages from Dawn and student
code. If any process crashes, Runtime would (ideally) be able to restart
it seamlessly, although this doesn't happen yet.

\paragraph{Why Pipes over Queues?}

A pipe is more limited than a queue in every respect; it is single-consumer,
single-producer, as opposed to multi-producer, multi-consumer.
However, what it lacks in flexibility, it makes up for in speed.
There is a noticeable difference when using pipes versus queues.
In a scenario where the flexibility is unnecessary, pipes win.

\subsection{Runtime Steps}
\begin{enumerate}
    \item Spawn StateManager, Hibike, and UdpReceiver.
    \item Run the state machine.
        \begin{enumerate}
            \item Check if E-Stop was triggered.
            \item Check if we have restarted too many times.
            \item React to things in the bad things queue.
        \end{enumerate}
\end{enumerate}

\subsection{The \texttt{badThingsQueue}}
This unfortunately-named queue allows every process to send messages
directly to runtime. Typically, this is used as an error reporting
mechanism when an exception is encountered, so that runtime will at
least know about the cause of a failure. It is also used as a trigger
to switch the robot from teleoperated to autonomous mode.

\subsection{\texttt{runtimeUtil} and IPC}
Communication between processes happens by passing messages through StateManager.
Each process is given access to StateManager's message queue, and StateManager can
pass messages back to each process through pipes.
In order to make sure that processes can understand each other, there is
a set of several constants located in \texttt{runtimeUtil.py}, defining the
messages that a process is expected to send and receive.

\section{StateManager}
StateManager is, in essence, a large key-value store. It is used as
a centralized place to store state for each process on the robot,
and, indirectly, as a way to communicate between processes.

\subsection{Architecture}
StateManager consists of a large number of methods and a few message queues/pipes.
It receives messages from Hibike, Runtime, Ansible, and Student Code, and invokes
one of its functions based on who sent the message, and which message
was received. Every time a key is added to storage,
a timestamp is stored. This functionality will likely be removed in the future.

\subsection{Robot State}
The internal state of the robot is stored in a dictionary. Each key represents
one piece of the robot's state.

\begin{itemize}
    \item \texttt{studentCodeState} represents the current mode of the student code:
        teleoperated, autonomous, or emergency stop
    \item \texttt{dawn\_addr} stores information about the IP address of Dawn.
    \item \texttt{gamepads} stores information about the state of any attached
        gamepads, for teleoperated mode.
    \item \texttt{hibike} stores information about the state of every smart device
        attached to the robot. If a smart device is disconnected, it disappears
        from this dictionary.
\end{itemize}

\section{Ansible}
\subsection{Introduction and Overview}\label{introduction-and-overview}

This page will detail how Runtime communicates with Dawn. The code is
contained primarily in \texttt{Ansible.py}, with relative protos stored
in
\href{https://github.com/pioneers/PieCentral/tree/master/ansible-protos}{ansible-protos}.

There are two forms of communication with Dawn: UDP and TCP. UDP is used
for constant data transfer where it is not critical to not lose packets.
TCP is used to send data where it is critical to not lose information.
Communication with Dawn happens in three processes, which are spawned by
\texttt{runtime.py}. These three processes are \texttt{UDPSendClass},
\texttt{UDPRecvCLass}, \texttt{TCPClass}. \texttt{UDPSendClass} spawns
two threads, one for packaging and one for sending.
\texttt{UDPRecvClass} does not spawn threads, and receives and
unpackages in succession. \texttt{TCPClass} spawns two threads, one for
sending and one for receiving.

See \href{https://github.com/pioneers/PieCentral/wiki/Dawn-Runtime-Network-Protocol}{Dawn Runtime Network Protocol}
for specific networking details, and
\href{https://developers.google.com/protocol-buffers/docs/pythontutorial}{Google
Protobuf} for information on how to use protobufs in python.

\subsection{Starting the Processes}\label{starting-the-processes}

All processes are started by \texttt{runtime.py} via the
\texttt{spawn\_process} function. Initially, on startup, only the
\texttt{UDPRecvClass} class is spawned. This is because runtime needs to
learn the IP of Dawn, and can only do so after receiving one packet.
After determining the IP of Dawn and it is stored into
\texttt{StateManager}, \texttt{BAD\_EVENTS.NEW\_IP} is triggered which
now spawns \texttt{UDPSendClass} and \texttt{TCPClass}. Only one Dawn
instance can be connected at a time. Whenever Dawn disconnects,
\texttt{BAD\_EVENTS.DAWN\_DISCONNECTED} is triggered which terminates
all the processes and then respawns just \texttt{UDPRecvClass}. This is
the same as the initial state, and it repeats the entire process.

\subsection{UDPRecvClass}\label{udprecvclass}

This class runs as a single process. It receives the robot state
(\texttt{IDLE}, \texttt{AUTONOMOUS}, \texttt{TELEOP}, \texttt{ESTOP}),
the team color, and gamepad data.. If there doesn't currently exist an
IP stored (this is the first time receiving from Dawn), the IP will also
be saved and the other two communication processes will be spun up. If
the received state is different from the current state, a command will
be sent to \texttt{StateManager.py} via the \texttt{BadThingsQueue} to
switch student code state. If the team flag color has not been set, a
command (\texttt{SM\_COMMANDS.SET\_TEAM}) will be sent to
\texttt{StateManager.py} to set the team flag to the appropriate color.
Then, it takes the unpackaged data containing the gamepad data, and
sends it to \texttt{StateManager.py}.

\subsection{UDPSendClass}\label{udpsendclass}

This class runs as two threads in a single process. One process
constantly receives data from \texttt{StateManager}, and packages up via
protobufs all the sensor information, and the current robot state. It
then stores the data into a\\
\texttt{TwoBuffer} object which is shared by both processes. The second
process takes the packaged data from the \texttt{TwoBuffer}, and sends
it to Dawn viw UDP.

\subsection{TCPClass}\label{tcpclass}

This class runs as two threads in a single process, one to send and one
to receive. Both use the same TCP connection. The sender sends console
logs to Dawn, as well as acknowledges that runtime is ready for student
code upload. The receiver receives the command that student code is
going to be uploaded. Furthermore, when the TCP connection is broken (as
caught by an \texttt{except}), this indicates that Dawn has disconnected
and \texttt{Ansible} state is reset to idle.

\section{Student Code/Student API}
Student code itself runs in a separate process isolated from runtime, so that
it is not possible to deadlock runtime from student code. In addition,
signal handlers are installed to ensure that the code will stop
working if stalled for too long. The API communicates with StateManager
through a pipe.

\section{Testing}
Currently, Runtime's tests are located in \texttt{studentCode.py}. What
exists now is pretty basic, consisting mainly of fetching from and
storing into StateManager.

\chapter{Glossary}
\begin{itemize}
    \item Beaglebone Black (BBB) -- a single-board computer running Ubuntu Linux.
        More information at \url{http://beagleboard.org/black}.
    \item Smart Sensor or Smart Device (SD) -- a sensor, such as a switch
        or RFID reader, that is controlled by an attached Arduino.
\end{itemize}

\end{document}


text:
\section*{Run \#29}

\begin{figure}[H]
    \centering
    \includegraphics[width=0.5\textwidth]{images/29/stream_image}
\end{figure}

\begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{images/29/trajectories}
\end{figure}


text:
\documentclass[11pt,a4paper]{article}
\usepackage{graphicx}
\usepackage{subfigure}
\usepackage{amsmath}
\usepackage{makecell}
\usepackage[utf8]{inputenc}
\usepackage{listings} %放代码
\usepackage{xcolor} %代码着色宏包
\usepackage{color}
\usepackage{xeCJK}
\usepackage{float}

%好像是数学的包
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{mathrsfs}
%页面布局包
\usepackage{geometry}
%画图包
\usepackage{tikz}
%画图背景包
\usetikzlibrary{backgrounds}

\geometry{left=3.0cm, right=3.0cm, top=3cm, bottom=3cm}

%自定义命令
\newcommand{\psiG}{\psi_{G}}
%在tikz中画一个顶点
%#1:node名称
%#2:位置
%#3:标签
\newcommand{\newVertex}[3]{\node[circle, draw=black, line width=1pt, scale=0.8] (#1) at #2{#3}}
%在tikz中画一条边
\newcommand{\newEdge}[2]{\draw [black,very thick](#1)--(#2)}
%在tikz中放一个标签
%#1:名称
%#2:位置
%#3:标签内容
\newcommand{\newLabel}[3]{\node[line width=1pt] (#1) at #2{#3}}

\title{Introduction to Computing Systems\\Homework 1}
\author{PB18111697 王章瀚}

\begin{document}
	\maketitle
	\section{(Adaptedfromproblem1.5inthetextbook)}
	The answers are as following.
	\subsection*{a.}
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.7]{1_a.jpg}
		\caption{1.a\ $ax+b$}
		\label{1.a}
	\end{figure}\par
	\subsection*{b.}
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.7]{1_b.jpg}
		\caption{1.b\ average of $x, y, z, w$}
		\label{1.b}
	\end{figure}\par
	\subsection*{c.}
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.7]{1_c.jpg}
		\caption{1.c\ $a^{2}+2ab+b^{2}$}
		\label{1.c}
	\end{figure}\par
	\subsection*{d.}
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.7]{1_d.jpg}
		\caption{1.d\ $a^{6}$}
		\label{1.d}
	\end{figure}\par
	\subsection*{e.}
	\begin{figure}[H]
		\centering
		\includegraphics[scale=0.7]{1_e.jpg}
		\caption{1.e $ax^{3}+bx^{2}+cx+d$}
		\label{1.e}
	\end{figure}\par

	\section{(Adaptedfromproblem1.12inthetextbook)}
	\subsection*{a.}
	\underline{No. It lacks definiteness.} This description ignored the sequence of all steps, which means we can add row1 to row2 then row1 to row4, as well as the other sequence. Even though all kinds of sequences can result the same answer, it still lacks definiteness.
	\subsection*{b.}
	\underline{No. It lacks finiteness.} It is obviouly that there are an infinite number of prime numbers and natural numbers, which means the algorithm can't be finite.
	\subsection*{c.}
	\underline{Yes. It doesn't lack any of definiteness, effective computability or finiteness.}
	\subsection*{d.\textcolor{red}{no. finiteness}}
	\underline{No. It seems to lack the definiteness and the effective computability.} First, on each flip, the state of the coin is unpredictable, which renders the description missing definiteness. What's more, the computers nowadays cannot really generate a random number, making the item uncomputable.
	\subsection*{e.\textcolor{red}{no. x-1. finiteness}}
	\underline{The item is an algorithm when and only when the number given is a positive integer.} Suppose the number firstly given as x. After the first 6 steps, the number becomes x-1. This ensures all positive integer can finally become 0, while other numbers can't; so if the number given isn't a positive integer, then the item turns out to be infinite.

	\section{(2.3)}
	\subsection*{a.}
	$log_{2}400\approx 8.6$, so the minimum number of bits required is \underline{9}.
	\subsection*{b.}
	$2^{9}-400=112$, so \underline{112} students can be admitted.

	\section{(2.8)}
	\subsection*{a.}
	$0111\ 1111_{2}, 127_{10}$
	\subsection*{b.}
	$1000\ 0000_{2}, -128_{10}$
	\subsection*{c.}
	$(2^{n-1}-1)_{10}$
	\subsection*{d.}
	$(2^{n-1})_{10}$

	\section{(Adaptedfrom2.13)}
	\subsection*{a.}
	$010110_{2} \rightarrow 0001\ 0110_{2}$
	\subsection*{b.}
	$1101_{2} \rightarrow 1111\ 1101_{2}$
	\subsection*{c.}
	$1111111000_{2} \rightarrow 1111\ 1000_{2}$
	\subsection*{d.}
	$01_{2} \rightarrow 0000\ 0001_{2}$

	\section{(Adaptedfrom2.17)}
	\subsection*{a.}
	$01+1011=0001+1011=1100$
	\subsection*{b.}
	$11+01010101=1111\ 1111+0101\ 0101=0101\ 0100$
	\subsection*{c.}
	$0101+110=0101+1110=0011$
	\subsection*{d.}
	$01+10=11$

	\section{}
	\subsection*{a.(2.21)}
	If and only if one of highest and 2nd highest bit's carry occurs, then a overflow occurs.
	\subsection*{b.(2.22)}
	In the equation$\underline{1000\ 0000\ 0000\ 0000+1000\ 0000\ 0000\ 0000=0000\ 0000\ 0000\ 0000}$, overflow occurs.
	\subsection*{c.(2.25)}
	Because the negative 2's complement number(n bits) ranges $from\ -2^{n-1}\ to\  -1$, while the positive one ranges $from\ 1\ to\ 2^{n-1}-1$, which indicates that the sum is always in the range of $[-2^{n-1}, 2^{n-1}-1]$; so the sum can always expressed as a n bits 2's complement number.
	\subsection*{d.}
	Just as described in a.(2.21), if the situation of carry's occuring is the different at highest and 2nd highest bit, then overflow occurs; otherwise, the adding is normal.

	\section{(2.34)}
	\subsection*{a.}
	$NOT(1011)\ OR\ NOT(1100)=0100\ OR\ 0011=0111$
	\subsection*{b.}
	$NOT(1000\ AND\ (1100\ OR\ 0101))=NOT(1000\ AND\ 1101)=NOT(1000)=0111$
	\subsection*{c.}
	$NOT(NOT(1101))=1101$
	\subsection*{d.}
	$(0110\ OR\ 0000)\ AND\ 1111=0110\ AND\ 1111=0110$

	\section{(2.50)}
	\subsection*{a.}
	\begin{align*}
	\textrm{x5478}\ AND\ \textrm{xFDEA}&=0101\ 0100\ 0111\ 1000\ AND\ 1111\ 1101\ 1110\ 1010\\
	&=0101\ 0100\ 0110\ 1000=\frac{\textrm{xA468}}{\textcolor{red}{x5468}}
	\end{align*}
	\subsection*{b.}
	\begin{align*}
	\textrm{xABCD}\ OR\ \textrm{x1234}&=1010\ 1011\ 1100\ 1101\ OR\ 0001\ 0010\ 0011\ 0100\\
	&=1011\ 1011\ 1111\ 1101=\textrm{xBBFD}
	\end{align*}
	\subsection*{c.}
	\textcolor{red}{
		\begin{align*}
		NOT(NOT(\textrm{xDEFA}))\ AND\ \textrm{NOT(xFFFF)}&=NOT\ \textrm{x2106}\ AND\ \textrm{x0000} = \textrm{x1111}
		\end{align*}
	}
	\begin{align*}
	NOT(NOT(\textrm{xDEFA}))\ AND\ \textrm{NOT(xFFFF)}&=\textrm{xDEFA}\ AND\ \textrm{x0000} = \textrm{x0000}
	\end{align*}
	\subsection*{d.}
	\begin{align*}
	\textrm{x00FF}\ XOR\ \textrm{x325C}&=0000\ 0000\ 1111\ 1111\ XOR\ 0011\ 0010\ 0101\ 1100\\
	&=0011\ 0010\ 1010\ 0011=\frac{\textrm{x3293}}{\textcolor{red}{x32A3}}
	\end{align*}

	\section{(2.55)}
	\subsection*{a.}
	The maximum unsigned decimal value is $4^{3}-1=64-1=\underline{63}$
	\subsection*{b.}
	The maximum unsigned decimal value is $\underline{4^{n}-1}$
	\subsection*{c.}
	$023+221=\underline{310}$
	\subsection*{d.}
	Since $42 = 2\times 4^{2}+2\times 4^{1}+2\times 4^{0}$, the answer is \underline{222}
	\subsection*{e.}
	$123.3_{4}=01\ 10\ 11.11_{2}=\underline{11011.11_{2}}$
	\subsection*{f.}
	$123.3_{4}=01\ 10\ 11.11_{2}=011011.11_{2}$. And in IEEE floating point format, it will be \underline{0\ 10000011\ 10111100000000000000000}
	\subsection*{g.\textcolor{red}{$4^{4^{m}}$}}

	There is $4^{m}$ kinds of inputs and each input may result $4^{1}$ kinds of outputs, which means $4^{m}\times4^{1}=\underline{4^{m+1}}$kinds of unique functions this black box can implement.

\end{document}

max_issues_repo_name: Pengxiang-Hua/USTC-CS-Resources

max_forks_repo_name: Pengxiang-Hua/USTC-CS-Resources


text:
\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage[legalpaper, portrait, margin=1in]{geometry}
\title{Integral Fun Integral}
\author{Shreenabh Agrawal }
\date{\today}

\begin{document}

\maketitle

\section{Question}

$$I_{(\alpha, n)}=\int\limits_{0}^{\infty} \frac{\cos (\alpha x)}{x^{n}} \: d x$$

\section{Solution}
We Know,
$$\begin{aligned}
\int\limits_{0}^{\infty} f(t) \: g(t) \: d t=\int\limits_{0}^{\infty} \mathcal{L}\{f(t)\} \: \mathcal{L}^{-1}\{g(t)\} \: d t
\end{aligned}$$
Applying this,
$$\begin{aligned}
\therefore I_{(\alpha, n)} &=\int\limits_{0}^{\infty} \mathcal{L}\{\cos (\alpha x)\} \: \mathcal{L}^{-1}\left\{\frac{1}{x^{n}}\right\} \: d x \\
&=\int\limits_{0}^{\infty} \frac{s}{s^{2}+\alpha^{2}} \times \frac{s^{n-1}}{\Gamma(n)} \: d s \\
&=\frac{1}{\Gamma(n)} \int\limits_{0}^{\infty} \frac{s^{n}}{s^{2}+\alpha^{2}} \: d s
\end{aligned}$$
Taking Substitution,

$$\begin{aligned}
s&= \alpha \: \tan \theta \\
d s &=\alpha \: \sec ^{2} \theta \: d \theta
\end{aligned}$$

$$\begin{aligned} \Rightarrow \quad I_{(\alpha, n)} &=\frac{1}{\Gamma(n)} \int\limits_{0}^{\pi / 2} \frac{\alpha^{n} \tan ^{n} \theta}{\alpha^{2} \sec ^{2} \theta} \: \alpha \sec^{2} \theta \: d \theta \\ &=\frac{\alpha^{n-1}}{\Gamma(n)} \int\limits_{0}^{\pi / 2} \tan ^{n} \theta \: d \theta \end{aligned}$$

$$\boxed{I_{(\alpha, n)}=\frac{\pi \alpha^{n-1}}{2 \Gamma(n) \cos \left(\frac{\pi n}{2}\right)}}$$

\end{document}

max_stars_repo_path: Calculus/integral.fun's questions/integral fun laplace integral.tex