\chapter[Safety analysis]{Safety analysis}

\section{Safety and operational parameters} \label{sec:safety-param}
The proposed work will investigate the following safety and operational
parameters: the temperature reactivity feedback coefficient, reactivity worth
of the control rods, and power axial offset. Dynamics of these parameters will
be investigated for the \gls{TAP} concept during lifetime-long operation and
short-term load-following transient. Validation against previous work
mentioned in section~\ref{sec:saf-par-literature} will be performed for
confidence building.
\subsection{Temperature coefficient of reactivity}
The main physical principle underlying the reactor temperature feedback is an
expansion of heated material. When the fuel salt temperature increases, the
density of the salt decreases, but at the same time, the total volume of fuel
salt in the core remains constant because it is bounded by the vessel. When
the moderator rod temperatures increase, the density of zirconium hydride
decreases, creating additional space for fuel salt.

Chapter 2, equation~\ref{eq:feedback} defined Total or Isothermal Temperature
Coefficient (ITC) which expresses the dependence of the core reactivity on the
combined effects of fuel and moderator temperature. However, fuel and
moderator temperature are rarely equal because fuel heats up much faster than
the moderator; thus, the fuel temperature coefficient (FTC) and the moderator
temperature coefficient (MTC) should be calculated separately. In the base
case simulation in this work, the fuel salt and the moderator temperatures are
fixed at 900K, which is an operational temperature in the core. To determine
the fuel salt temperature coefficient (FTC), I will perturb the fuel salt
temperature to 800K and 1000K while fixing the moderator temperature at 900K
(base case). Likewise, the moderator temperature coefficient (MTC) will be
found by perturbing the moderator temperature from 900K to 800K and 1000K,
while the fuel temperature is fixed at 900K.

The range of temperature perturbation for the temperature coefficient
calculation has been selected based on operational parameters. The \gls{TAP}
\gls{MSR} operates between 773 and 973K (500-700$^o$C), which is far below the
salt boiling point of approximately 1473K. The salt freezes if the temperature
drops below 773K. At the other end of the temperature spectrum, the
temperature higher than 973K passively melts a freeze plug, which drains the
fuel salt from the reactor vessel to the drain tanks. The drain tanks have a
subcritical configuration with a large free surface area to readily dissipate
heat by passive cooling \cite{transatomic_power_corporation_technical_2016}.
Thus, calculating temperature coefficients in the temperature range from 800
to 1000K will capture  the outcomes of most
accident transients.

Fuel and Moderator Temperature Coefficients for the temperature in the range
from 800 to 900K would be useful for analyzing the following transients
related to sudden fuel salt cooling:
\begin{itemize}
	\item increase in heat removal by the secondary system;
	\item increase in the fuel salt flow rate;
	\item planned reactor shutdown.
\end{itemize}
Temperature coefficients for the temperature in the range from 900 to 1000K
would be used for transients related with salt overheating:
\begin{itemize}
	\item loss-of-coolant accident (LOCA);
	\item loss-of-flow accident (LOFA);
	\item loss of ultimate heat sink;
	\item  station blackout (SBO).
\end{itemize}
Thus, temperature coefficients will be calculated separately for above 900K
and below 900K. My dissertation will include the following cases:
\begin{enumerate}
	\item FTC (moderator rods temperature is fixed at 900K):
		\begin{enumerate}[label=(\alph*)]
			\item temperature of the salt between 900 and 1000K;
			\item temperature of the salt between 900 and 800K.
		\end{enumerate}
	\item MTC (the fuel salt temperature is fixed at 900K):
		\begin{enumerate}[label=(\alph*)]
			\item temperature of the moderator between 900 and 1000K;
			\item temperature of the fuel between 900 and 800K.
		\end{enumerate}
	\item ITC:
		\begin{enumerate}[label=(\alph*)]
			\item whole reactor temperature between 900 and 1000K;
			\item whole reactor temperature between 900 and 800K;
		\end{enumerate}
\end{enumerate}
In the first case, changes in the fuel temperature will impact cross section
temperature (Doppler broadening) and fuel density, but the geometry is
unchanged because the fuel is a liquid. The density of fuel salt
changes with respect to temperature as follows \cite{janz_molten_1974}:
\begin{align}\label{eq:salt-den}
\rho_{salt}(T[K]) &= 6.105 - 12.720\times10^4 T \quad [g/cm^3]
\end{align}
The uncertainty in the salt density calculated using
Equation~\ref{eq:salt-den} is approximately 0.036 $g/cm^3$ at 900K.
In contrast, when the moderator temperature is changing, the density, cross
section temperature, and the geometry are also changing due to thermal
expansion of the solid zirconium hydride (ZrH$_{1.66}$) rods. Accordingly, the
new moderator density and sizes will be calculated using a linear temperature
expansion coefficient of $2.734\times10^{-5}$K$^{-1}$
\cite{yamanaka_thermal_1999}. A new geometry input for Serpent 2, which takes
into account displacement of the moderator  surfaces, will be created based on
this information. Finally, the temperature coefficient for each case will be
calculated separately as follows:
\begin{align}
\alpha &= \frac{k_{eff}(T_{i+1}) - k_{eff}(T_i)}{k_{eff}(T_{i+1})
k_{eff}(T_{i}) (T_{i+1} - T_i)}
\intertext{where}
k_{eff} &= \mbox{effective multiplication factor} \nonumber \\
T_i &= \mbox{fuel salt temperature in (800K, 1000K).} \nonumber
\end{align}
By propagating the $k_{eff}$ statistical error provided by Serpent 2,
uncertainty for each temperature coefficient will be obtained using the
formula:
\begin{align}
\delta\alpha &= \abs{\frac{1}{T_{i+1} - T_i}} \sqrt{\frac{\delta
k_{eff}^2(T_{i+1})}{k_{eff}^4(T_{i+1})}
+ \frac{\delta k_{eff}^2(T_i)}{k_{eff}^4(T_i)}}
\intertext{where}
\delta k_{eff} &= \mbox{statistical error for $k_{eff}$ from Serpent output.}
\nonumber
\end{align}
Notably, other sources of uncertainty are neglected, such as cross section
measurement error and approximations inherent in the equations of the state
providing both the salt and moderator density dependence on temperature.

\subsection{Reactivity control system rod worth}
In the \gls{TAP} concept, control rods perform two main functions: to shut
down the reactor at any point during operation by introducing sufficient
negative reactivity and to control the excess of reactivity after moderator
rod reconfiguration during regular maintenance. In an accident, the control
rods would be dropped down into the core. The reactivity worth of the control
rods will be calculated for various positions to separately estimate the worth
of each control rod, and the whole reactivity control system. Finally, control
rod with the maximum worth will be localized to conduct basic safety test: at
\gls{BOL} the reactor should not startup if a single rod (maximum worth rod)
is accidentally ejected from the \gls{TAP} core.

The reactivity worth of the single control rod is defined as:
\begin{align}
& \qquad\qquad\qquad CRW = (k_{eff}^W - k_{eff}^I)\times 10^5 \;\; [pcm]
\intertext{where}
k_{eff}^W &= \mbox{effective multiplication factor when control rod is fully
withdrawn} \nonumber \\
k_{eff}^I &= \mbox{effective multiplication factor when control rod is fully
inserted} \nonumber
\end{align}
The statistical error of the  reactivity worth will be obtained using formula:
\begin{align}
\delta CRW &= \sqrt{(\delta k_{eff}^W)^2 + (\delta k_{eff}^I)^2}
\intertext{where}
\delta k_{eff}^{W}, \delta k_{eff}^{I}, &= \mbox{$k_{eff}$ statistical error
from Serpent output.}
\nonumber
\end{align}

\subsection{Axial Offset} \label{sec:axial-offset}
\gls{AOA} refers to a neutron flux depression in the top of a nuclear reactor
core, which complicates the reactor operation. This problem occurs in
\gls{PWR} plants and leads to a variety of problems: increased local power
peaking factors, lower than expected burnup and decreased control rod worth.
The Axial Offset is defined as:
\begin{align}
& \qquad\qquad\qquad A/O  = \frac{p_{top} - p_{bottom}}{p_{top} + p_{bottom}}
	\intertext{where}
p_{top}, p_{bottom} &= \mbox{fraction of rated power in a top and bottom half
of the core.} \nonumber
\end{align}

For the case of the \gls{TAP} \gls{MSR}, off-gas system components (e.g.,
sparger, entrainment separator) introduce small bubbles of inert gas
(helium) into the fuel salt during operation. These helium bubbles entering
into the core would then introduce unpredictable reactivity. Moreover, the
diameter of the bubbles would increase as they rise from the bottom to the top
of the core because of approximately the 140$^{o}$C temperature difference
between the reactor inlet and outlet. To take into account the effect of the
gas present in the fuel salt, I will split the reactor core model into a few
axial regions with different corresponding salt density
(figure~\ref{fig:axial-offset}).

The ideal gas law must be employed to find the density of the fuel salt with
gas bubbles\footnote{Assuming we know the bubble number and size from the
component design.}
in it:
\begin{align}
PV &= nRT
\intertext{where}
P &= \mbox{pressure of the gas} \nonumber \\
V &= \mbox{volume of the gas} \nonumber \\
n &= \mbox{number of moles of the gas} \nonumber \\
R &= 8.31 \frac{J}{K\cdot mol} \nonumber \\
T &= \mbox{temperature of the gas.} \nonumber
\end{align}
Assuming the pressure in the vessel remains fixed and  the number of moles
of helium is constant, the helium volume change related to temperature
change can be defined as:
\begin{align}\label{eq:he-vol-change}
&\qquad\qquad\qquad V^{He}_i = \frac{V^{He}_0}{T_0} T_i
\intertext{where}
V^{He}_0, V^{He}_i &= \mbox{total He volume in the salt with temperature
T$_0$,
	T$_i$} \nonumber \\
T_0, T_i &= \mbox{temperature of the salt in a lower and i$^{th}$ axial
layer.}
\nonumber
\end{align}
\begin{figure}[bth!] % replace 't' with 'b' to
	\includegraphics[width=\textwidth]{axial_offset.png}
	\caption{Preliminary schematic view showing the \gls{TAP} model divided to
		multiple axial layers with different densities of the salt. This model
		will assume a linear temperature growth from the bottom to the top.}
	\label{fig:axial-offset}
\end{figure}

Using equations~\ref{eq:salt-den},\ref{eq:he-vol-change}, density of the
salt/helium mixture in each axial layer ($\rho_i$) will be calculated.
Finally, a Serpent 2 calculation will be performed for the model with
non-uniform axial density distribution in the fuel salt to determine axial
neutron flux distribution and axial offset (A/O) in the \gls{TAP} core.

\section{Preliminary results}\label{sec:safety-param-res}
Temperature coefficients and control rod worth were calculated for the
\gls{TAP} reactor at startup as discussed in section~\ref{sec:safety-param}.

\subsection{Temperature coefficients and rod worth at BOL}
Table~\ref{tab:tcoef} summarizes temperature effects on reactivity in the
\gls{TAP} core calculated for the initial fuel salt composition. The fuel
temperature coefficient is $-0.693$ and $-0.116$ pcm $\Delta k/k\cdot K^{-1}$
when perturbing the salt temperature from 900K to 800K and from 900K to 1000K,
respectively. The MTC and ITC are negative and relatively large for both
cases. All three temperature coefficients when perturbing from 900K to
1000K did not match coefficients when perturbing from 900K to 800K because
cross sections are nonlinear with temperature.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{table}[ht!]
	\caption{Temperature coefficients for the \gls{TAP} reactor at startup for
	different temperature perturbations.}
	\begin{tabularx}{\textwidth}{ X  r r } \hline
		\textbf{Coefficient} & \textbf{From 900 to 800K [pcm/K]} &
		\textbf{From 900 to 1000K [pcm/K]}                  \tabularnewline
		[5pt] \hline
		FTC & $-0.693\pm9.25\times10^{-2}$ & $-0.116\pm9.33\times10^{-2}$
		\tabularnewline [3pt] \hline
		MTC & $-1.106\pm9.25\times10^{-2}$ & $-1.195\pm9.27\times10^{-2}$
		\tabularnewline [3pt] \hline
		ITC  & $-1.768\pm9.17\times10^{-2}$ &  $-1.301\pm9.27\times10^{-2}$
		\tabularnewline [3pt] \hline
	\end{tabularx}
	\label{tab:tcoef}
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
These reactivity coefficients will change most likely during operation due to
changes in the neutron spectrum, salt volume fraction, core geometry, amount
of fuel in the core and fuel composition. The FTC is expected to be more
negative during operation as the spectrum thermalizes due to additional,
retained fission products and actinides building up in the fuel salt.
Temperature coefficient calculations will be repeated at middle-of-life and
end-of-life to capture changes in these characteristics.

A configuration of 25 control rods (Figure~\ref{fig:tap-serpent-plan})
provides a reactivity worth of $1110\pm9.7$ pcm (1.1\%) at \gls{BOL}. The
control rod worth is expected to become more negative during operation
because the spectrum thermalizes and many fission product poisons exhibit
larger absorption cross sections in the thermal energy range. At the same
time, that effect would be counteracted by actinide (particularly, plutonium)
accumulation in the core. Thus, control rod worth change during the reactor
operation must be estimated.


The safety and explainability of robotic systems has become increasingly important as applications for robotic systems transition to more unstructured and interactive environments. While one component to developing safe robots is to design robust and high-performing autonomy algorithms, another critical component is the analysis of the system's design. System analysis could come in several forms, including unit, component, or system-level testing, but one challenging aspect of testing is the determination of appropriate success criteria. It is also highly desirable to develop systems that are \textit{provably correct} or \textit{correct-by-construction} with respect to the stated success criteria.

This chapter introduces a set of rigorous mathematical tools and concepts for specifying desired behavior (i.e. requirements or specifications), proving that the system achieves the desired behavior, and synthesizing robot systems to be correct-by-construction. These mathematical tools are known as \textit{formal methods}\cite{ClarkeGrumbergEtAl2018}.

\notessection{Formal Methods}
Formal methods provide a mathematical framework for reasoning about a system's specifications as well as analyzing whether the system's behavior guarantees their satisfaction. Approaches for synthesizing provably correct behavior can also be built on top of these tools and are commonly incorporated within the umbrella of formal methods. Historically these techniques have been developed within the computer science community, and have been used to study problems related to logic, automatically proving properties of algorithms, checking the correctness of properties of circuits, and more. However in this chapter formal methods will be explored within the context of autonomous systems.

\begin{definition}[Formal Methods]
Formal methods are mathematically based techniques for the specification, development, and verification of software and hardware systems.
\end{definition}

It is important to note that formal methods are not just particular solutions or algorithms but rather are a class of tools and formalisms. Accordingly, this chapter will not focus on a particular algorithm (solution) for applying formal methods to problems in robotics, but will rather introduce several broadly used tools and techniques. Specifically, Section \ref{subsec:ltl} will introduce \textit{linear temporal logic}, which is a specialized language for writing specifications. Then the concept of the robotic system as a reactive model that can be \textit{verified} to satisfy the stated specifications will be introduced in Section \ref{subsec:verification}. Finally, the ability to \textit{synthesize} robot systems to provably be able to satisfy a specification will be explored in Section \ref{subsec:reactivesynth}.

\subsection{Linear Temporal Logic} \label{subsec:ltl}
Linear temporal logic (LTL) is a mathematical \textit{language} for formally expressing specifications or requirements on the system's behavior\footnote{Similar to how ordinary differential equations provide a mathematical ''language'' that is useful for modeling the kinematics and dynamics of physical systems.}. LTL is useful in robotics applications because it extends propositional logic\footnote{A formalism for expressing logical operations including conjunction (and), disjunction (or), and negation (not).} to handle \textit{temporal} components (assuming discrete time steps), which are common in sequential decision making problems and other robotics tasks. For example propositional logic can be used to write a specification that ``proposition $a$ and proposition $b$ must both be true'', while LTL extends the possible specifications to include temporal constraints such as ``proposition $a$ must be true \textit{until} proposition $b$ is true''.

The language of LTL can be expressed in terms of several atomic operators, the first few of which are inherited from propositional logic:
\begin{enumerate}
    \item \textit{true} or \textit{false} (Boolean values)\footnote{Technically false can also be written as $\lnot \text{true}$, where $\lnot$ is the ``not'' operator.} represent Boolean constants.
    \item $a$, $b$, $\dots$ (propositional symbols) denote single variables that can either be true or false at the current time step.
    \begin{figure}[ht]
    \begin{center}
    \includegraphics[width=0.5\textwidth]{tex/figs/ch25_figs/prop.png}
    \label{fig:propositionalvar}
    \end{center}
    \vspace{-\baselineskip}
    \end{figure}
    \item $\lnot \psi$ (negation operator\footnote{Technically \textit{false} can be written as $\lnot$\textit{true}.}) denotes the negation of $\psi$.
    \item $\psi_1 \land \psi_2$ (conjunction ``and'' operator) which can be read as ``$\psi_1$ and $\psi_2$''.
    \item $\psi_1 \lor \psi_2$ (disjunction ``or'' operator) which can be read as ``$\psi_1$ or $\psi_2$''. This operator can be expressed in terms of ``and'' and ``not'' as $\psi_1 \lor \psi_2 = \lnot(\lnot \psi_1 \land \lnot \psi_2)$.
    \item $\psi_1 \to \psi_2$ (implication operator) denotes that $\psi_1$ implies $\psi_2$. This operator can be expressed in terms of ``not` and ``or'' as $\psi_1 \to \psi_2 = \lnot \psi_1 \lor \psi_2$.
\end{enumerate}

Additional operators that are fundamental to LTL provide the capability for expressing temporal constraints:
\begin{enumerate}
\setcounter{enumi}{6}
    \item $X \psi$ (``next'' operator) denotes that $\psi$ happens next (at the next time step).
    \begin{figure}[ht]
    \begin{center}
    \includegraphics[width=0.5\textwidth]{tex/figs/ch25_figs/next.png}
    \label{fig:ltl_next}
    \end{center}
    \vspace{-\baselineskip}
    \end{figure}
    \item $\psi_1 U \psi_2$ (``until'' operator) denotes that $\psi_1$ should happen until $\psi_2$ happens.
    \begin{figure}[ht]
    \begin{center}
    \includegraphics[width=0.65\textwidth]{tex/figs/ch25_figs/until.png}
    \label{fig:ltl_until}
    \end{center}
    \vspace{-\baselineskip}
    \end{figure}
    \item $F \psi$ (``eventually'' operator) denotes that $\psi$ happens at some point in the \textit{future}. This operator can be expressed in terms of the eventually operation as $F \psi = \text{true}\: U\: \psi$.
    \begin{figure}[ht]
    \begin{center}
    \includegraphics[width=0.5\textwidth]{tex/figs/ch25_figs/eventually.png}
    \label{fig:ltl_eventually}
    \end{center}
    \vspace{-\baselineskip}
    \end{figure}
    \item $G \psi$ (``always'' operator) denotes that $\psi$ happens globally (at all times). This operator can be expressed in terms of the negation and future operations as $G \psi = \lnot F {\lnot \psi}$.
    \begin{figure}[ht]
    \begin{center}
    \includegraphics[width=0.5\textwidth]{tex/figs/ch25_figs/always.png}
    \label{fig:ltl_always}
    \end{center}
    \vspace{-\baselineskip}
    \end{figure}
\end{enumerate}
From these atomic operators it is possible to define many new specifications through \textit{composition}, and they can become arbitrarily complex as needed. A couple of common and useful compositions include:
\begin{enumerate}
\setcounter{enumi}{10}
    \item $GF \psi$ (``infinitely often'' composition) denotes that $\psi$ will eventually happen an infinite number of times (i.e. globally, $\psi$ will happen eventually). In other words there is always a $\psi$ in the future.
    \item $FG \psi$ (``stability''\footnote{This notion of stability is similar but not directly the same as the notions of stability from control theory.} composition) denotes that at some point in time $\psi$ will be true for all time thereafter (i.e. eventually $\psi$ will happen globally).
    \item $G(\psi_1 \to F\psi_2)$ (``response'' composition) denotes that for all time, whenever $\psi_1$ occurs then $\psi_2$ will occur sometime in the future. There are other useful variations on this composition, such as by replacing the $F$ operator with $X$ operator.
\end{enumerate}

Linear temporal logic provides a very powerful tool\footnote{There are also alternatives to LTL that provide even more powerful features, for example by not requiring a ``linear'' temporal structure but rather allowing for temporal ``branching''.} for abstractly talking about time, and in general the specifications written using LTL can in a way be more ``vague''. For example the eventually operator $F$ does not explicitly state \textit{when} something must occur, just that at \textit{some point} it will. It is also important to keep in mind that LTL is not an algorithm or technique for solving problems, but rather a language for \textit{formulating} problems (i.e. for expressing properties of interest such as system specifications).

\begin{example}[Coffee Machine Specification] \label{ex:coffeespec}
Consider a simple robot that makes coffee. This robot has a button that a user can press, and has two functions: grinding coffee beans and brewing coffee. The desired behavior of this robot could be expressed by the designer as: \textit{if the start button is pressed, the robot will immediately start grinding beans for the next two cycles, and then brew the coffee for the next two cycles after that}. This specification, denoted as $\phi$, could be expressed via linear temporal logic as:
\begin{equation*}
\phi : G \big( \text{button} \to \text{grind} \land X \text{grind} \land XX (\lnot\text{grind} \land \text{brew}) \land XXX (\lnot\text{grind} \land\text{brew}) \big).
\end{equation*}
Note that the entire statement needs to be wrapped in the ``always'' operator to ensure this behavior can occur at any arbitrary time that a user presses the button.
\end{example}

\subsection{Verification} \label{subsec:verification}
System verification is the process of \textit{proving} that the system's behavior will satisfy the stated requirements and specifications (often expressed using linear temporal logic). In the terminology of formal methods, this system is typically referred to as the \textit{model}\footnote{The model could refer to a piece of software, a hardware component, an individual algorithm, or even an entire robot.} and the output of the verification\footnote{Also commonly referred to as \textit{model checking}.} procedure is a simple yes/no stating whether the model satisfies the specification. In this chapter the model will be denoted by $P$ and the specification by $\phi$, and the notation for stating that model $P$ satisfies specification $\phi$ is $P \models \phi$ (which can be read as ``$P$ models $\phi$'').

\begin{figure}[ht]
\begin{center}
\includegraphics[width=0.65\textwidth]{tex/figs/ch25_figs/verification.png}
\caption{Given a system (model) and a specification, the process of verification proves whether the system satisfies the specification.}
\label{fig:verification}
\end{center}
\end{figure}

In this chapter it is assumed that the model $P$ is a \textit{reactive system}, meaning that its behavior is defined based on inputs $i$ which effect the system's outputs $o$\footnote{The inputs and outputs occur at each time step, and the behavior is assumed to be non-terminating.}. In contrast to robotic control problems where the ``inputs'' are generally the control inputs determined by the control algorithm, the inputs $i$ within this context refer to signals coming from the environment. The outputs $o$ of the model can then be thought of as the result of the system's decision making or underlying algorithm/process. As was mentioned previously, the model $P$ can take on many forms depending on whether the system is a hardware component, software component, algorithm, finite state machine, or even simply a mathematical function such as a machine learning model or control law.
\begin{marginfigure}
\begin{center}
\includegraphics[width=0.5\textwidth]{tex/figs/ch25_figs/model.png}
\caption{The model $P$ is a system with inputs $i$ and outputs $o$. These inputs and outputs are used to express the model's specification $\phi$.}
\label{fig:reachtive_model}
\end{center}
\end{marginfigure}

For a given model $P$ the specification $\phi$ is assumed to be written in terms of the input and output sequences (i.e. the behavior is defined by the inputs and outputs of the system). Specifically, these sequences will be denoted as $\hat{i} = (i_0, i_1, \dots)$ and $\hat{o} = (o_0, o_1, \dots)$. With these definitions, the expression that $P$ satisfies $\phi$ can equivalently be written as $P \models \phi$ or $\hat{i} \cup \hat{o} \models \phi$.

To summarize, the problem of model verification is to simply determine whether the input-output behavior of the model $P$ guarantees that $\phi$ is satisfied \textit{for all possible input sequences}.
There are several existing techniques that can perform system verification, and they may be tailored to the specific model form\cite{KwiatkowskaNormanEtAl2011}\cite{KatzHuangEtAl2019}.

\subsection{Reactive Synthesis} \label{subsec:reactivesynth}
Given a reactive model $P$ and a LTL specification $\phi$, the problem of verification is to determine whether the behavior of $P$ satisfies $\phi$ for all possible input sequences $\hat{i}$. But several important questions remain: how should the system be designed, and what should be changed if the verification step shows that $P \not \models \phi$? \textit{Reactive synthesis} addresses these problems by \textit{synthesizing} the system model $P$ to be correct-by-construction. In other words, in reactive synthesis the specification $\phi$ is first defined and then a model is constructed from scratch to satisfy the specification.
\begin{figure}[ht]
\begin{center}
\includegraphics[width=0.65\textwidth]{tex/figs/ch25_figs/synthesis.png}
\caption{Given a specification $\phi$, the process of reactive synthesis generates a model $P$ that realizes the specification under all possible environmental inputs.}
\label{fig:formalmethod_synthesis}
\end{center}
\end{figure}

\subsubsection{Specification Satisfiability and Realizability}
The first step in reactive synthesis is to determine whether a model\footnote{Technically speaking, a \textit{finite state model}.} even exists which can satisfy the LTL specification $\phi$ for all possible input sequences. If no such model exists, then the system designer should reevaluate the specification itself.

In the nomenclature of formal methods, the specification $\phi$ is said to be \textit{realizable} if it can be satisfied for all possible input sequences, and it is \textit{satisfiable} if there exists at least one input sequence leading to satisfaction. These properties can be more rigorously defined in terms of the input and output sequences that describe the system's behavior:
\begin{definition}[Satisfiability]
A specification $\phi$ is \textit{satisfiable} if for some input sequence there exists an output sequence that satisfies the specification. Mathematically:
\begin{equation*}
\exists \: \hat{i} = (i_0, i_1, \dots), \quad \exists \: \hat{o} = (o_0, o_1, \dots), \quad s.t. \:\: \hat{i} \cup \hat{o} \models \phi.
\end{equation*}
\end{definition}
\begin{definition}[Realizability]
A specification $\phi$ is \textit{realizable} if for all possible input sequences there exists an output sequence that satisfies the specification. Mathematically:
\begin{equation*}
\forall \: \hat{i} = (i_0, i_1, \dots), \quad \exists \: \hat{o} = (o_0, o_1, \dots), \quad s.t. \:\: \hat{i} \cup \hat{o} \models \phi.
\end{equation*}
\end{definition}

Obviously the property of satisfiability is weaker than realizability, and realizability is much more important in practice. For example in order to guarantee safety in a rigorous way it is not sufficient to show that the system will be safe under a single scenario, but rather it should be shown for all scenarios. However, designing specifications that are realizable can be quite challenging, even in seemingly simple problems. As an example consider again the coffee machine robot from Example \ref{ex:coffeespec}.

\begin{example}[Coffee Machine Realizability]
The coffee machine robot from Example \ref{ex:coffeespec} had inputs $I = \{\text{button}\}$ and outputs $O = \{\text{grind}, \text{brew}\}$. For simplicity let $i_\text{button} = 1$ and $i_\text{button} = 0$ denote the button is pressed and not pressed, respectively. Additionally let $o_\text{grind}=1$ and $o_\text{brew}=1$ denote that the actions are occurring and let them be zero otherwise.

Recall that the linear temporal logic specification for the robot's behavior was defined as:
\begin{equation*}
\phi : G \big( \text{button} \to \text{grind} \land X \text{grind} \land XX (\lnot\text{grind} \land \text{brew}) \land XXX (\lnot\text{grind} \land\text{brew}) \big).
\end{equation*}
This specification can now be analyzed to determine whether it is realizable. First, notice that one possible sequence of inputs and outputs that satisfies this specification is:
\begin{equation*}
\begin{split}
(i_\text{button}, \: o_\text{grind}, \: o_\text{brew})_k = \:&(0, \: 0, \: 0)_0, \\
&(1, \: 1, \: 0)_1, \\
&(0, \: 1, \: 0)_2, \\
&(0, \: 0, \: 1)_3, \\
&(0, \: 0, \: 1)_4, \\
&(0, \: 0, \: 0)_5, \\
& \quad\:\:\:\: \vdots
\end{split}
\end{equation*}
Because there exists a sequence that satisfies the specification $\phi$ it is by definition \textit{satisfiable}. However, consider a second input sequence $\hat{i} = (0, 1, 1, 0, 0, \dots)$ where the coffee machine's button is pressed twice in a row:
\begin{equation*}
\begin{split}
(i_\text{button}, \: o_\text{grind}, \: o_\text{brew})_k = \:&(0, \: 0, \: 0)_0, \\
&(1, \: 1, \: 0)_1, \\
&(1, \: 1, \: 0)_2, \\
&(0, \: ?, \: 1)_3, \\
\end{split}
\end{equation*}
At time step $k=3$ there is no combination of outputs that will satisfy the specification, since the first button press requires that $o_{\text{grind}, 3} = 0$ but the second button press requires that $o_{\text{grind}, 3} = 1$! Therefore by definition this specification is not \textit{realizable}\footnote{Does this mean it is impossible to automate a coffee maker? No! It just demonstrates that writing \textit{specifications} can be challenging.}.
\end{example}

\subsubsection{Synthesis for Realizable LTL Specifications}
If a LTL specification $\phi$ is realizable, then the synthesis problem seeks to find a finite state system that satisfies $\phi$ under all possible inputs. This can be accomplished by formulating the problem as a two-player game where the objective is for the system to generate ``winning'' outputs while the environment generates adversarial inputs. The two-player game formulation can be expressed mathematically by defining the following components:
\begin{enumerate}
    \item With the inputs $I$ and outputs $O$, at each time step the environment gets to choose from a set of $2^{\lvert I \rvert}$ actions and the system gets to choose from a set of $2^{\lvert O \rvert}$ actions.
    \item The strategy of the system is expressed as a function $f: (2^{\lvert I \rvert})^* \to 2^{\lvert O \rvert}$, where $f$ is a function from a finite sequence of environmental inputs to a specific output.
    \item The linear temporal logic specification $\phi$ is defined by the input and output sequences.
    \item The game is played for an infinitely long horizon, generating sequences $\hat{i} = (i_0, i_1, \dots)$ and $\hat{o} = (o_0, o_1, \dots)$.
    \item The game is won if $\hat{i} \cup \hat{o} \models \phi$.
\end{enumerate}

The process of converting a problem specification into this two-player game follows two main steps. First, the specification is converted into a \textit{non-deterministic B\"{u}chi automaton} and then the automaton is determinized to yield the game.
Once the game is appropriately formulated, it can be solved using existing algorithms to generate the policy $f$ that defines the system's behavior. Unfortunately, converting the specification into the automaton is computationally very challenging! In fact the computational complexity is \textit{doubly-exponential} in the size of the specification\footnote{A doubly exponential function has the form $f(x) = {a^b}^x$.}, which significantly limits the complexity of the problems that can be considered\footnote{This is one of the most significant limitations of formal methods in practical robotic settings, and approaches to overcome this complexity are still a topic of research.}.

While the precise details for converting a specification into a two-player game and solving the game are beyond the scope of this chapter, the process can be explored visually through the following example.

\begin{example}[Simple Reactive Synthesis Problem] \label{ex:simplereactivesynth}
Consider the LTL specification $\phi: G(r \to X g)$ which states that whenever a request $r$ is received the system should provide a grant $g$ in the next time step. In this problem $I = \{r\}$ where $r$ denotes a request or no request and $O = \{g\}$ where $g$ specifies if a grant was made or not. The first step in transforming this specification into the two-player synthesis game is to generate the following B\"{u}chi automaton representation, as shown in Figure \ref{fig:automaton}.
\begin{figure}[ht]
\begin{center}
\includegraphics[width=0.55\textwidth]{tex/figs/ch25_figs/automaton.png}
\caption{The B\"{u}chi automaton representation of the LTL specification $\phi: G(r \to X g)$.}
\label{fig:automaton}
\end{center}
\end{figure}
In Figure \ref{fig:automaton} the variables $q_0$ and $q_1$ represent states of the automaton, and the transitions between the states are dependent on the environmental inputs and the system's behavior.

The two-player game is generated from this B\"{u}chi automaton\footnote{This automaton is already deterministic, so no determinizing step is needed.} by introducing intermediate states as well as the unsafe ``contradiction'' state (denoted in Figure \ref{fig:synthesis_2pgame} as $\bot$). This game is represented graphically in Figure \ref{fig:synthesis_2pgame} where the $*$ denotes that any action could be taken by the model and the small grey circles represent the intermediate states.
\begin{figure}[ht]
\begin{center}
\includegraphics[width=0.5\textwidth]{tex/figs/ch25_figs/game.png}
\caption{The two-player game representation derived from the B\"{u}chi automaton in Figure \ref{fig:automaton}.}
\label{fig:synthesis_2pgame}
\end{center}
\end{figure}
The system can ``win'' this two-player game by ensuring that the contradiction state is never reached, which then defines the system's behavior! By analyzing Figure \ref{fig:synthesis_2pgame}, it turns out that one ``winning'' strategy strategy (behavior) is for the system to \textit{always} provide a grant! This strategy is shown graphically in Figure \ref{fig:synthesis_2pgamesol}.
\begin{figure}[ht]
\begin{center}
\includegraphics[width=0.45\textwidth]{tex/figs/ch25_figs/game_solution.png}
\caption{A strategy for the system in Example \ref{ex:simplereactivesynth} to ensure the specification is met is to \textit{always} provide grants, which is guaranteed to avoid the contradiction state in the two-player game shown in Figure \ref{fig:synthesis_2pgame}.}
\label{fig:synthesis_2pgamesol}
\end{center}
\end{figure}
\end{example}


\chapter{Conclusion}
\label{c:conclusion}

\begin{comment}
We propose that a geometric construct, the \emph{straight skeleton}, and its generalisations, are a powerful technique for the creation of PGM systems that are accessible to people without programming skills.  Systems exploiting these skeletons and variations thereof are able to generate large scale, varied and highly realistic results within the domain of urban procedural modeling.
\end{comment}

%%%%%%%%%%%%%%%

%#1. Expand hypothesis intro introductory story.
%. exapand the contributions of intro 1.2 using below text
%3. as now

%%%%%%%%%%%%%%%

\section{Summary of Objectives}

In this dissertation we examined the straight skeleton as a procedural modeling technique. We proposed that the straight skeleton is a powerful PGM primitive that is useful in a variety of situations to users who are unable or unwilling to write classical computer programs. In particular we suggested that skeletons are able to create highly realistic results within the domain or urban procedural modeling.

To pursue this goal, Chapter~\ref{c:readings} studied the wide variety of geometric modeling tools available, forming a spectrum of proceduralisation. We saw a strong correlation between this spectrum and the requirement that users must write computer programs. Those systems that required programming were the most general and expressive, while those that didn't were easier to use and more specialised. This led to the realisation that the concept of a ``procedural system'' was poorly defined between these two extremes. Eventually we took the stance that the ``most procedural'' systems lay in the middle of this spectrum, those that gave the most expressive power, with the simplest possible interaction. When we examined a variety of man-made objects, it became clear that some generalised offset mechanism may be able to describe many features of man-made geometry.

This offset mechanism was formalised in Chapter~\ref{c:various_skels}, which introduced the protagonist of this dissertation, the straight skeleton. A theoretical diversion at this point led us to examine the types of events that occur in generalisations of the straight skeleton. This line of enquiry led to both positive and negative outcomes. We discovered a novel skeleton with unique categories of events that would prove to be usefully applied to urban modelling, but at the same time we showed that there were some situations in which we could not define this new skeleton well. This mixed weighted straight skeleton, however, proved to be a very flexible and powerful modeling primitive.

The SS was applied to two urban PGM scenarios. We were not able to apply our techniques to a wider range of applications due to time limitations. The first application was given in Chapter~\ref{c:pgop} and described how to use the straight skeleton to subdivide city blocks into parcels. The direction of this work was heavily motivated by the requirements of the commercial CityEngine PGM system. This lead to a real-time system with an emphasis on robust results for application to industry requirements.

Chapter~\ref{c:procex} introduced the second application of the SS, in particular the mixed weighted straight skeleton, to the modeling of buildings themselves. This work was strongly motivated by our offset observations, and the relationships between the straight skeleton and the classical form of buildings' roofs. As we explored the modeling possibilities of the MWSS we found several varied and related techniques for its application to architectural modeling. Given our emphasis on procedural modeling we showed how cities could be reconstructed from their floorplans using this approach.

%%%%%%%%%%%%%%%

Both the systems we have applied the MWSS to have proven robust and flexible enough to generate kilometer-scale geometry procedurally. The block subdivision system was shown to reproduce particular subdivision styles over several expansive real-world examples, whilst the procedural extrusion system was able to generate a cityscape of multiple building styles from given building footprints. In both systems additional variation could be added without programming -- either by changing parameters, or by editing polylines. Importantly, in both systems a wide range of inputs were shown to create domain-meaningful output; a wide range of inputs created output with an urban appearance.

These systems utilising the straight skeleton take a position in the spectrum of proceduralisation, of Chapter~\ref{c:readings}, that would otherwise require a written programming. While the urban modeling domain of applications in this dissertation pushes the skeleton based systems towards the specific end of the spectrum of generality; both the parcel subdivision and procedural extrusion systems have shown ---

\begin{itemize}

\item{self sensitivity: Usually reserved for very general procedural modeling system, the SS is a geometrically self-sensitive construct. Because any part of the perimeter of the polygon may affect the resulting skeleton, the skeleton responds to any change in the perimeter. This is particularly true of the MWSS used in the PE system.}

\item{themselves capable of producing a wide range of results within their domain: Both systems were tested on a wide range of input data, and were able to create realistic procedural approximations in the parcel subdivision and architecture domains.}

\item{that they are useful without programming: The systems require no end user programming. The procedural extrusion system was demonstrated to be useful to users with no programming expertise, while the parcel subdivision was shown to be able to extract the required parameters automatically.}

\end{itemize}

In addition the SS and MWSS proved to be intuitive geometric elements in the interactive systems. Users were able to understand the logic behind the centreline position in the parcel subdivision system, and were satisfied with the way it moved when the block's boundary was interactively edited. Similarly, users of the procedural extrusion system were able to control the MWSS, without understanding the underlying geometry, or algorithms, involved. Even when chaotic configurations were encountered, users were able to interactively modify the plans to explore and understand what was causing the instability.

\section{Contributions}

\subsubsection{The general intersection event}

Chapter~\ref{c:various_skels} introduced our contributions to straight skeleton theory.

The SS is formed by shrinking a polygon, and allowing each edge to move towards the interior with a constant speed. By generalising SS we encounter the \emph{positively weighted straight skeleton}. In this case each individual edge could move with an independent, if positive speed. For this case we introduced novel degeneracies as well as a simplification of existing events for computing the PWSS. This \emph{general intersection event} was able to calculate the result of all PWSS events encountered, with fewer special cases.

This unification of existing skeleton events allows for both more general events and more general skeletons, such as the PWSS. In addition the resulting algorithm is simpler and easier to implement.

\subsubsection{The mixed weighted straight skeleton}

When we again generalised the PWSS we discovered the \emph{mixed weighted straight skeleton}, a novel skeleton which allowed the edges to move either towards the interior of the plan, or toward the exterior. These new skeletons had interesting geometric features such as splitting faces into two, introducing holes into faces, or allowing faces to merge together and split apart.

The degeneracies in the MWSS were quite involved, including one category of events which appeared to have no ``nice'' solution. We introduced the \emph{pincushion problem} as a description of this situation.

This mixed weighted skeleton is relevant to many modeling tools which extrude 3D surface geometry. In addition we continue to use and evaluate the MWSS as a powerful PGM tool in Chapter~\ref{c:procex}.

\subsubsection{A city block-to-lot subdivision system and evaluation}

We introduced a system for city block to lot subdivision in Chapter~\ref{c:pgop}.

Within this system we used the SS to model the block centrelines. The geometric sensitivity of the skeleton ensured that the entire block was taken into account when calculating centrelines, therefore even complex concave blocks were realistically divided. The presence of commercial robust implementations of the straight skeleton algorithm was also an advantage. In addition, because the skeleton could be intuitively understood by users as the ``limit of an offset'', we ensured a smooth parametrisation between patio and non-patio lot subdivisions via a single parameter. Users were able to modify a small number of parameters to change the characteristics of the subdivision, or automatically extract such statistics from existing subdivisions.

We  quantitatively evaluated two block subdivision systems over a range of North American real-world data. Analysis of the generated parcels was performed by visualising the areas, aspect ratios, and the number of neighbours of both the real and procedural subdivisions. We found that after automatically fitting several parameters, the new procedural models compared favourably across our metrics. In addition, we found local lot arrangements that were very close to the baseline data.

The most frequently observed deficit in our subdivision system was the inability to model parcel subdivisions with external patterns in a manner similar to observed data. For example power-lines or rivers create divisions between sets of lots that our subdivision schemes are unable to model. We hypothesise that additional simulation elements in the subdivision process may resolve this issue. Another issue was the inability to move the centreline closer to either one side of the block or the other, this would have created better matches when the strips of a lot were of different depths. Selecting the corner priority was a further weakness in the system; we did not develop a mechanism to extract the priority of the streets at the corners from the example data automatically.

This application and evaluation of the skeleton to modeling block subdivision is the first within computer graphics, and presents a baseline for future work in this area. In addition our integration of the system within a commercial product allows a high level of robustness and interoperability with other GIS systems. For example the product has been used by commercial special effects houses and architects worldwide.

% the first evaluation of block to lot in graphics
% real time
% robust commercial software used by foster and partners, dneg etc..
% parameter retreval

\subsubsection{A method for the modeling of architectural shells using the MWSS}

Our final contribution is the procedural extrusion architectural shell modeling system of Chapter~\ref{c:procex}.

By applying the 3D interpretation of the MWSS to this problem, we created the procedural extrusion system. It proved very capable at creating mass models of many complex buildings, and in particular roof structures.

The procedural extrusion system applies the MWSS in a variety of ways to create procedural models. Basic buildings without overhangs can be assembled by stacking truncated MWSS geometry. In order to create over-hangs or hollow roofs we use a sub-application of the MWSS to robustly create the offsets. Lastly, to introduce new features at a certain height, plan events can use the MWSS to create a robust perturbation of the buildings geometry. To model the windows and doors themselves we resorted to a deformable bone-based system which could ``stretch'' decorative meshes across models. These meshes were external to our system, and had to be created using an external 3D package.

Because the entire PE input is geometric, it is possible to describe the system entirely with a graphical editor for plans and profiles. We were able to evaluate the system and show that it is both usable and useful to people without significant programming experience. The expressibility of the system was successfully evaluated by modeling a large number of sample buildings from a catalogue with our user interface. In addition, we also illustrated that PEs are suitable for kilometer scale procedural cityscape visualisation. We built a framework to generate large scale geometry given a set of floorplans provided from a GIS source. In this framework we observed minimal geometric errors and proved that the PE system was useful for robust large scale procedural geometry creation.

There were several limitations of the basic approach. One is that conventional programming was used to position the decorative meshes on the large scale evaluation project. Ideally this could be specified graphically, in a per-plan-edge manner. However, accounting for different ways of repeating elements over varied geometry is challenging. Another issue was that the \facades{} of the output geometry were not rectangular, making it difficult for conventional systems, such as split shape grammars, to position windows and doors. To resolve this issue we introduced several types of anchors, giving different parametrisations of \facades{}. Finally our evaluations also showed that our floating point implementation of the MWSS had some numerical issues, and would occasionally fail to generate a polygon. An arbitrary precision implementation would lessen these issues, at the expense of execution time.

The ease of use of the PE system, combined with its proven expressivness and suitability to large-scale geometry creation are rare. Because of these features, concepts from the procedural extrusion system have been adopted by commercial video game creators and a research PGM system. Finally, the system provides a concrete application and validation of our theoretical work on the MWSS.

% wider range of surfaces than before
% concepts used in video games and wider research
% relitevely easy to use
% large scale proof

\section{Future Work}

There is a wide variety of work still to be undertaken in understanding the application of the SS to procedural modeling. The most obvious direction to undertake would be to attempt to combine the work of Chapter~\ref{c:pgop} and Chapter~\ref{c:procex}. Given the wide range of polygon subdivision results in Sec.~\ref{sec:subdiv_events}, we may ask ``is there a general language of offsets?'' Such a language may be applicable to parcel subdivision, footprint extrusion, and other urban modeling situations. When we consider the objects in the home, it may be that a large number of the frames, borders, skirting boards and other features can be created using such a system.

More specific future work might attempt to combine the techniques documented in this dissertation with the more mainstream shape grammar modeling systems. In particular extending CGA Shape\cite{Pascal06} to work intuitively with non-rectangular \facades{}, such that the MWSS can become a primitive within the large existing libraries of CGA Shape operations. We suspect that it is possible to construct such an irregular \facade{} only using some language of skeletons.

With the PE system it would be most advantageous to be able to generate unique plans and profiles, or even position and repeat the anchors. This problem is quite challenging, and solutions may involve shape grammars, pattern synthesis or even by-example modeling.

One further avenue for future work is to question whether the techniques introduced in this dissertation are applicable to other domains. Geometric techniques to simulate other types of skeleton, such as the medial axis, with the straight skeleton\cite{Tuanase:2004} offer the promise of being able to model more curved forms in unison with the human-designed appearance of the SS. In particular exploring 3D growth mechanisms, such the 3D WSS, offer some interesting avenues of research into the modeling the growth of flora and fauna. However, it becomes clear quite quickly that the first stumbling block of the 3D WSS is the degeneracy caused by a valency four mesh vertex --- an imaginative solution would be required!

An early problem in our studies was that of evaluating procedural content. This dissertation has used several different methods for evaluation --- comparing statistical measures against ground truth with the lot subdivision project, examining the ability to recreate the ground truth exactly in the PE UI demonstration, or subjective analysis of procedural output as in the PE GIS evaluation. Because PGM has no requirement to reconstruct such a ground truth, only create a novel, yet characteristically valid geometry, objective evaluation is difficult. The trade off between producing realistic or novel geometry is probably something the user wants to control very closely.  The ``best'' solution probably changes for each application of procedural technology and is thus highly subjective. It may depend on the amount of user input desirable, the required speed or the level of detail required. Future work in this direction would be very useful, although there is a question as to whether we need better, more photo-realistic procedural systems for it to begin.

One extreme application of the WSS may be in the classification of data points, from the field of machine learning. In 2D we can imagine using a skeleton to ``colonise'' the space around each data point. The area composed of skeleton faces would form a classification boundary. This would be somewhat similar to a weighted Voronoi diagram, but with the potential to change the propagation weights based on direction, propagation distance, or a property of the data point. The initial problem is how to generalise the skeleton higher dimensions efficiently.

%It is informative to attempt to place the PE on our spectrum of proceduralisation. The interactive system, is, at it's simplest a very specific mesh modeling system. However, the ease of reparameterisation of the plan places it somewhere in the middle of the spectrum. It is a system dedicated to the generation of architecture from one domain, but it still able to create a range of such architecture. In particular, the PE system stands out against other systems at this level of specialisation in that it requires no end user programming, and can be entirely graphically driven.

%In conclusion, we have explored some of the theory and properties of several new varieties of straight skeletons. We found that these geometric structures have the nice properties of being both intuitively understandable, yet still modeling a wide range of behaviours. We exploited these behaviours to create elements in the urban procedural geometric modeling pipeline. Both the block to lot subdivision and procedural extrusion systems proved to be powerful procedural tools which exploited the skeleton to ensure that users no longer had to write programs to create procedural urban models.


\documentclass[12pt]{article}
\setlength\parindent{0pt}
\usepackage{graphicx}
\usepackage[margin=1.0in]{geometry}
\usepackage{amsmath}
\usepackage{ulem}
\usepackage{color}
\usepackage{hyperref}
\setlength{\parindent}{2em}
\graphicspath{ {./images/} }
\title{CTA200H Final Project}
\author{Sarah Thiele}
\date{\today}

\begin{document}
\maketitle

In this project I spent time exploring the usage of COSMIC, or Compact Object and Monte Carlo Investigation Code, a binary population synthesis Python interface. It uses a statistical approach to synthesis, allowing us to create large fixed populations in a relatively short amount of computational time in comparison with normal stellar evolution software. See   \href{https://cosmic-popsynth.github.io/docs/latest/index.html}{\color{blue}\uline{here}} for documentation.

\section{Getting Familiar with COSMIC:}
\subsection{Single binary systems}

I began by installing COSMIC both to my own computer as well as the CITA cluster. This was done by cloing from the public Github repository. As the code is updated often, pulling from git on a semi-regular basis is needed to ensure the most up-to-date processes are in place.

The next task was to practice with simulating single binary systems. A binary system can be initiated using COSMIC's InitialBinaries method within the InitialBinaryTable class. By trying out various initial parameters (the initial stellar components' masses, their orbital period, eccentricity, and metallicity), I was able to create binaries which when evolved produced double white dwarf (WD), double neutron star (NS), and double black hole (BH) systems. The Evolve package in COSMIC is used for binary evolution, which outputs multiple useful DataFrames. For example, ``bpp" gives parameters at time steps where important changes occur in the system, and ``bcm" gives parameters at the first and final time step. I then found the time step at which the second remnant formed and plotted the evolution of the system's masses, orbital period and eccentricity from Zero Age Main Sequence (ZAMS) until Second Remnant Formation (SRF). This can be done by resetting the time step of the initial conditions table, re-evolving the system with this smaller time step, and extracting the relevant columns until SRF. This data is plotted in Figures 1-4 and the outcome of each system is noted in the respective captions. The initial conditions and final SRF parameters are listed below. Because of the nature of COSMIC's statistical processes we see large and often discontinuous jumps in parameters as the binary system evolves over time. We also see the primary and secondary stars exchange mass when one gains proportional to the others' loss at the same time. This is often accompanied by simultaneous changes in eccentricity and orbital period.

\begin{table}
\centering
\scriptsize
\begin{tabular}{c|cccccccc}
\hline  \\
Remnants &  $m_{1,i}$ $[M_\odot]$ & $m_{2,i}$ $[M_\odot]$ & $e_i$ & P$_{orb,i}$ [days] &  $m_{1,f} $ $[M_\odot]$ & $m_{2,f}$ $[M_\odot]$ & $e_f$ & P$_{orb, f}$ [days] \\
\\
\hline
WD & 4.00 & 6.00 & 0.04 & 40.808 & 0.89 &  1.12 &  0.00 & 0.95 \\
NS  & 16.00 & 15.00 & 0.50 & 400.00 & 1.45 & 1.43 &  0.84 & 1.47\\
BH & 80.00 & 85.00 & 0.01 & 10.05 & 33.58 & 24.91 & 0.01 & 7.27 \\
\hline
\end{tabular}
\label{Table1}
\caption{Summary of the single binary systems' initial conditions and their final parameters at time of SRF.}
\end{table}

\begin{figure}
    \centering
    \includegraphics[trim={4cm 0 4cm 0},clip,
    scale=0.45]{WD_bin_3panel.png}
    \caption{A system which forms a WD + WD binary system. The system survives undisrupted for the full 13.7 Gyr evolution.}
    \label{Figure1}
\end{figure}

\begin{figure}
    \centering
    \includegraphics[trim={3cm 0 4cm 0},clip,
    scale=0.45]{NS_bin_3panel.png}
    \caption{A system which forms a NS + NS binary system. The system eventually merges into a single black hole.}
    \label{Figure2}
\end{figure}
\begin{figure}
    \centering
    \includegraphics[trim={3.5cm 0cm 4cm 0},clip,
    scale=0.45]{BH_bin_3panel.png}
    \caption{A system which forms a BH + BH binary system.  The binary survives undisrupted for the full 13.7 Gyr evolution.}
    \label{Figure3}
\end{figure}
\begin{figure}
    \centering
    \includegraphics[trim={3.5cm 1cm 4cm 0},clip,
    scale=0.45]{All_3panel.png}
    \caption{All binary systems evolution plotted as percentages of the maximum of the respective parameters. All three systems undergo mass transfer and large temporary jumps in orbital period before converging to their final states.}
    \label{Figure4}
\end{figure}

\pagebreak
\subsection{Binary grid}

Here a grid of initial binaries was run to see how changing the secondary mass impacts the outcome of the system. I used primary masses from $10$ to 100 M$_\odot$, and for each primary mass a grid was created with 10 secondary masses with a mass ratio $m_2 / m_1$ ranging from 0.1 to 1.0. The initial orbital periods were 50 days, with eccentricities of 0.5. I then selected the orbital period for each ($m_1, m_2$) combination at the time of SRF. These were then plotted as a function of mass ratio for each primary mass. These plots are shown in Figure 5 and 6.

An orbital period of 0.0 indicates a merging event, a supernova of one/both of the stars, or an outcome from a common envelope phase, resulting in a massless remnant(s) as the system's outcome. An orbital period of -1.0 indicates a disrupted system, which is more likely the further the separation between bodies is. We see in \autoref{Figure5} that when the other initial conditions are held constant, binaries with a smaller total mass had much higher merger/disruption fraction for these conditions compared with the higher mass systems. For example, for a 10 M$_\odot$ primary mass, none of the binary systems survive, but 70\% of the systems with a primary mass of 100 M$_\odot$ survive, creating double BH binaries.

In \autoref{Figure6}, all of the data is plotted together. There is no data above an orbital period of 20 days for primary masses greater than 50 M$_\odot$, with lower primary masses sitting mainly below 10 days, with most below 40 M$_\odot$ disrupted/merged.

\begin{figure}
    \centering
    \includegraphics[trim={1cm 2cm 1cm 2cm},clip,
    scale=0.6]{Period_Grid_Panels.png}
    \caption{Orbital period at SRF for various primary and secondary masses, with an initial orbital period of 50 days and eccentricity of 0.5. Legend indicates the primary mass.}
    \label{Figure5}
\end{figure}

\begin{figure}
    \centering
    \includegraphics[trim={1cm 0 1cm 1cm},clip,
    scale=0.8]{Period_Grid_All.png}
    \caption{Orbital period at SRF for various primary and secondary masses, with an initial orbital period of 50 days and eccentricity of 0.5. P$_{orb}$ is in days. The legend indicates the primary mass.}
    \label{Figure6}
\end{figure}

\section{Simulating double white dwarf populations}
\subsection{Methods}

Our next goal was to simulate two double white dwarf populations with changes to a single parameter for comparison. We can use COSMIC's independent sampler to generate a binary population by hand. Within the independent sampler, one can input the desired final stellar type, and choose independent models for each parameter. For example, in this setup we used a model for eccentricity following a uniform distribution, and with metallicity Z=0.017. We initialize the binaries with a star formation burst 13.7 Gyr in the past. These binaries can then be evolved in the same way as before using the Evolve package in COSMIC.

Due to issues with working with the CITA cluster we were unable to initialize the original goal of 1,000,000 binaries; a segmentation fault occured for higher than 1,000, so we lowered our population size to this instead. These binaries were initialized separately from the jupyter notebook for this project, coded on the CITA cluster ``bubbles" under the scripts sim.py and sim\_2.py, which will be attached in the Github repository for this project.

Next, from the output systems, all the WD + WD binaries were selected by masking over the stellar type column for WD types: either Carbon/Oxygen, Oxygen/Neon, or Helium WDs. We can find the age of the binary as the time from ZAMS to SRF, as well as the systems' masses and orbital periods at SRF. These are plotted in histograms in \autoref{Figure7}.

We can also study the time it would take each binary to merge from the time of SRF. This can be found by solving differential equations for the change in semi-major axis and eccentricity with respect to time. From \href{https://ui.adsabs.harvard.edu/abs/1964PhRv..136.1224P/abstract}{\color{blue}\uline{Peters (1964)}}, we have:
\begin{align}
    \frac{da}{dt} &= -\frac{64}{5}\frac{G^3m_1m_2(m_1+m_2)}{c^5a^3(1-e^2)^{7/2}}\left(1+\frac{73}{24}e^2+\frac{37}{96}e^4\right) \label{Eq1} \\
    \frac{de}{dt} &= -\frac{304}{15}e\frac{G^3m_1m_2(m_1+m_2)}{c^5a^4(1-e^2)^{5/2}}\left(1+\frac{121}{304}e^2\right)
\end{align}

The mass values are those at the time of SRF, and $a_0$ is the separation of the two WDs at SRF. We expect that all the WD + WD binaries to be in approximately circular obits. For circular binaries ($e=0.0$), \autoref{Eq1} can be solved for the semi-major axis as a function of time, and can be simplified by defining a constant $\beta$ (\autoref{Eq3}). We can then define the time it takes for the binary to merge $T_m$ by setting $a(t)=0.0$:
\begin{align}
    \beta &= \frac{64}{5}\frac{G^3m_1m_2(m_1+m_2)}{c^5} \label{Eq3}\\
    a(t) &= (a_0^4 - 4\beta t)^{1/4} \label{Eq.2} \\
    T_m(a_0) &= \frac{a_0^4}{4\beta}
\end{align}

The delay time, defined as the time it would take for a binary system to merge from its ZAMS system formation, is then simply the sum of the age of each binary system at SRF time and the merger time:
$$T_{delay} = T_{ZAMS} + T_m $$

Within a dictionary of flags/parameters which are fed into the binary evolution models with COSMIC, denoted BSEDict, there is a parameter alpha which describes the common-envelope efficiency. It dictates the efficiency with which orbital energy is transferred to the envelope surrounding a binary system. A common envelope is when the binary system is contained completely within a gas, sometimes arising from unstable mass transfer. The gas doesn't necessarily rotate at the same rate as the binary system, and so the common envelope phase is thought to bring binary systems to closer separations due to this energy and momentum transfer, often causing a merger if it is not expelled in a short enough period of time while the stars inspiral. For the first set of initializations, alpha=1.0 (\autoref{Figure7}). This was then redone with alpha=0.25 (\autoref{Figure8}). The delay time is plotted as a log plot as this was more informative than a regular histogram.
\begin{figure}
    \centering
    \includegraphics[trim={1cm 1cm 2cm 1cm},clip, scale=0.5]{WDBins_a1.png}
    \caption{Parameter distributions of population of WD + WD binaries, common envelope efficiency alpha=1.0.}
    \label{Figure7}
\end{figure}
\begin{figure}
    \centering
    \includegraphics[trim={1cm 1cm 2cm 1cm}, clip, scale=0.5]{WDBins_a025.png}
    \caption{Parameter distributions of population of WD + WD binaries, common envelope efficiency alpha=0.25.}
    \label{Figure8}
\end{figure}

\pagebreak
\subsection{Comparison between alpha=1.0 and alpha=0.25 populations}
From the initialized populations of $\sim$1000, only 81 become WD + WD binaries from the alpha=1.0 population, and 67 from the alpha=0.25 population. In both cases, the masses of the WDs are generally between 0.5 and 1.0 M$_\odot$ as expected. However, for alpha=0.25, all of the total system masses are greater than 1.0 M$_\odot$, whereas for alpha=1.0 there is closer to a normal distribution of mass. Both systems have a peak total mass between 1.0-1.25 M$_\odot$. The age of SRF has a distribution skewed slightly more to younger ages for alpha=0.25 than for alpha=1.0. The orbital periods for alpha=0.25 have a few more stars at higher orbital periods (past the leftmost histogram bin) and thus larger separations than for alpha=1.0. This is consistent with our earlier discussion of the effects of common envelope efficiency. When there is a lower efficiency of orbital energy and momentum transfer, the closing of separation of the binary system will not occur as effectively and thus we are left with more long-range binary systems as a result. The largest effect of changing the alpha parameter is in the delay times. $\log[T_{delay}]$ produces a large population between 10-15 for alpha=1.0, which is completely missing from the alpha=0.25 population. This can again be related to the efficiency of the common envelope phase. Binaries which go through a more effective common envelope phase will be brought closer together on shorter timescales are are more likely to merge.

\end{document}


\subsection{Moments of stochastic processes}