Getting pretty close on Section 5

LaTeX/thesis.tex

@@ -653,12 +653,11 @@
 
 				\begin{figure}
 					\centering
-					\includegraphics[width=\textwidth]{fig/kepler}
+					\includegraphics[width=\textwidth]{fig/laguerre_plot}
 					\caption{Example of a natural trajectory propagated via the Laguerre-Conway
 					approach to solving Kepler's Problem}
 					\label{laguerre_plot}
 				\end{figure}
-				% TODO: Generate an orbit figure for here
 				% TODO: Consider adding a paragraph about the improvements in processor time
 
 			\subsection{Sims-Flanagan Propagator}
@@ -681,20 +680,85 @@
 
 				\begin{figure}
 					\centering
-					\includegraphics[width=\textwidth]{fig/kepler}
+					\includegraphics[width=\textwidth]{fig/spiral_plot}
 					\caption{An example trajectory showing that classic continuous-thrust orbit
 					shapes, such as this orbit spiral, are easily achievable using a Sims-Flanagan
 					model}
 					\label{sft_plot}
 				\end{figure}
-				% TODO: Generate an orbit figure for here
 
 				Figure~\ref{sft_plot} shows that the Sims-Flanagan transcription model can be used
-				to effectively model these types of orbit trajectories.
+				to effectively model these types of orbit trajectories. In fact, the Sims-Flanagan
+				model is capable of modeling nearly any low-thrust trajectory with a sufficiently
+				high number of $n$ samples.
 
 			\subsection{Non-Linear Problem Solver}
-				Mention the package being used to solve NLPs and how it works, highlighting the trust region
-				method used and error-handling. Mention validation.
+
+				Now that we have the basic building blocks of a continuous-thrust trajectory, we can
+				leverage one of the many non-linear optimization packages to find solutions near to
+				a (proposed) trajectory. This trajectory need not be valid.
+
+				For the purposes of discussion in this Section, we will assume that the inner-loop
+				algorithm starts with just such a ''Mission Guess``, which represents the proposed
+				trajectory. However, we'll briefly mention what quantities are needed for this
+				input:
+
+				A Mission Guess object contains:
+				\begin{singlespacing}
+				\begin{itemize}
+					\item The spacecraft and thruster parameters for the mission
+					\item A launch date
+					\item A launch $v_\infty$ vector representing excess Earth velocity
+					\item For each phase of the mission:
+						\begin{itemize}
+							\item The planet that the spacecraft will encounter (either flyby or
+								complete the mission) at the end of the phase
+							\item The $v_{\infty,out}$ vector representing excess velocity at the
+								planetary flyby (or launch if phase 1) at the beginning of the phase
+							\item The $v_{\infty,in}$ vector representing excess velocity at the
+								planetary flyby (or completion of mission) at the end of the phase
+							\item The time of flight for the phase
+							\item The unit-thrust profile in a sun-fixed frame represented by a
+								series of vectors with each element ranging from 0 to 1.
+						\end{itemize}
+				\end{itemize}
+				\end{singlespacing}
+
+				From this information, as can be seen in Figure~\ref{nlp}, we can formulate the
+				mission in terms of a non-linear problem. Specifically, the Mission Guess object can
+				be represented as a vector, $x$, the propagation function as a function $F$, and the
+				constraints as another function $G$ such that $G(x) = \vec{0}$.
+
+				This is a format that we can apply directly to the IPOPT solver, which Julia (the
+				programming language used) can utilize via bindings supplied by the SNOW.jl
+				package\cite{snow}.
+
+				IPOPT also requires the derivatives of both the $F$ and $G$ functions in the
+				formulation above. Generally speaking, a project designer has two options for
+				determining derivatives. The first option is to analytically determine the
+				derivatives, guaranteeing accuracy, but requiring processor time if determined
+				algorithmically and sometimes simply impossible or mathematically very rigorous to
+				determine manually. The second option is to numerically derive the derivatives,
+				using a technique such as finite differencing. This limits the accuracy, but can be
+				faster than algorithmic symbolic manipulation and doesn't require rigorous manual
+				derivations.
+
+				However, the Julia language has an excellent interface to a new technique, known as
+				automatic differentiation\cite{RevelsLubinPapamarkou2016}. Automatic differentiation
+				takes a slightly different approach to numerical derivation. It takes advantage of
+				the fact that any algorithmic function, no matter how complicated, can be broken
+				down into a series of smaller arithmetic functions, down to the level of simple
+				arithmetic. Since all of these simple arithmetic functions have a known derivative,
+				we can define a new datatype that carries through the function both the float and a
+				second number representing the derivative. Then, by applying (to the derivative) the
+				chain rule for every minute arithmetic function derivative as that arithmetic
+				function is applied to the main float value, the derivative can be determined,
+				accurate to the machine precision of the float type being used, with a processing
+				equivalent of two function calls (this of course depends on the simplicity of the
+				chained derivatives compared to the function pieces themselves). Generally speaking
+				this is much faster than the three or more function calls necessary for accurate
+				finite differencing and removes the need for the designer to tweak the epsilon value
+				in order to achieve maximum precision.
 
 		\section{Outer Loop Implementation}
 			Overview the outer loop. This may require a final flowchart, but might potentially be too