This text is a script of the audio recorded for the lab-14 presentation for AERE-361.
Written by Zachary Luppen.

1: Hello everybody, teaching assistant Zachary Luppen here. Welcome back to another week of programming!
This week’s lab is lab 14, titled, “ODE Solver”. Just like the last few weeks, I’ll first be discussing
various logistical items, and then I’ll proceed with describing the lab. So let’s dive in!

2: Lab 11 grading is complete now, and Lab 12 grading has just begun. We’ll be looking over your lab 13
submissions soon, once lab 12 grading is out of the way. Thanks again for being patient!

3: Here’s a quick reminder about where to ask questions. Just to reiterate, all of the posts on the
discussion forum are anonymous to the class, but not the instructor and TAs. So please keep your
comments appropriate or you won’t be able to use it. The discussion forum for lab 14 is aptly titled,
“Lab 14 Discussion.”

4: That done, let’s actually get into lab 14 for this week!

5: In this week’s lab, you will be programming an ordinary differential equation solver to simulate
orbital propagation. For this assignment, you’ll apply numerical methods to find solutions to ordinary
differential equations. This is a very aerospace engineering-oriented problem and hopefully you will find
it very relevant to material you’ve studied in some of your other classes. Most classes in the department
that study orbital propagation or the guidance of aerial or space vehicles.

6: In this lab, you’ll make use of a Runge-Kutta method, which is part of a set of implicit and explicit
iterative methods used to solve ordinary differential equations (ODEs). These were developed around the
year 1900 by Carl Runge and Wilhelm Kutta, and they’re very well-established tools in the aerospace
world. You’ll be using the RK4 method, which is also referred to as the “classic Runge Kutta method”.
The 4 implies that the method is of the fourth-order, which relates directly to the Big-O notation of the
solver, just so you know!

7: Creating an ordinary differential solver may sound like a lot, but the lab manual will be a big help
for you. The manual provides pretty explicit pseudocode for how to create the RK45 solver as a function.
You’ll need to adjust some of the lines, but otherwise you shouldn’t have much difficulty implementing
it. And if you haven’t seen it yet and don’t believe me, I invite you to look at the lab manual on page 
198 and see for yourself. There’s a decent number of things going on, but it’s honestly just math heavy.
Since that’s the case, I recommend you go through slowly and make sure all of the math is right, all
necessary mathematical operators are present, that the signs for each computation are correct, etc. 
Before you ask us why the math may be incorrect for your implementation, we want you to check this since
there’s potential for error. One incorrect sign can throw off your math and solver entirely, so it’s 
very important that you catch these discrepancies!

8: The program we want you to create will be a lunar orbit propagator. This may sound complex, but it’s
a generic problem for a typical orbital mechanics or guidance and navigation class. The only difference
here is you’re programming it in C (rather than say, Matlab). Like in these classes, we will make use of
multiple simplifications, assumptions and restrictions so that the problem is doable. You will begin with
a starting position, along with other constants and equations, and use your solver to solve for the
orbit (and therefore solve a restricted 3-body problem). The spacecraft (whose orbit you’ll analyze)
will start in a geostationary orbit (at t=0, and as shown in the image on the right of the slide) and
then its main engines will fire (Delta V), altering the spacecraft’s orbit. 

9: Your program should use the dumb terminal from gnuplot to display a plot of the orbit. As is listed in
the requirements, your program should then prompt the user to see if they want to choose a different
Delta V value and recalculate everything. Once the user is satisfied, your program should print out a
good-looking PNG of the orbit (so, a PNG file) as well as statistics about the solver (either in a file
or on the command line).

10: Your LaTeX report this week should have the following components: a title page, references, a
complexity analysis of your code, as well as a loop analysis. Just like listed in the lab manual. While
not required, you could also document your process of writing up the code for this lab, and discuss the
problems you encountered while doing it. Please remember that reports that do not compile will be awarded
0 points!

11: Let’s look at the point distribution for this lab. In total, lab 14 is worth 150 points. The orbit
program you’ll write is worth 100 points, and the report is worth 50 points. The program portion is made
up of lots of steps, so there’s a lot of chances for partial credit. Ten points for prompting the user
for an initial Delta V value. You’ve had several homeworks asking the user for input, so this should be
easy for you. 50 points for solving the trajectory with RK45, implementing the solver and actually doing
the simulation. This is the meat of the program. 10 points for using the dumb terminal to display the
orbit. 10 points for additional functionality allowing the user to modify the Delta V value and having
your program recalculate. 10 points for generating a PNG of the orbit when the user is satisfied with
their input. And lastly, 10 points for printing out statistics about the solver. There’s more information
on this in the lab manual.

Along with making this lab a group lab, we’re also planning to institute “glitter points” again. So if
you can implement cool functionality with the plotting portion or other parts of the simulation, we will
take that into account!

12: Always remember that since lab 8, we run the make command to generate your executable(s). We will
then run the program as instructed. In this lab, your makefile should generate an executable called
“orbit” (all lowercase). We will then run the program and give it an initial Delta V value, just as
described in the requirements. We will test all the functionality listed in the Requirements section.
Please make sure that your program and report compile. Test that the make command works and that your
program is actually compiled. Programs and reports that fail to compile will be awarded zero points.
Also remember that you can’t use slip days on this, the final lab. The lab is due on May 4th at 11:45am,
and we CANNOT accept late assignments. This time coincides with the final exam period assigned to this
class, and once the two-hour window is up, we are not allowed to accept anymore submissions. So, anything
that is submitted late will automatically receive a zero. If your team doesn’t get as far as you’d like
with the assignment, still make sure to submit before this time so it’s not just counted as a zero.

14: As soon as you and your group have submitted your lab, you should give yourselves a pat on the back
because you’re done with AerE 361! I had a lot of fun being a TA for this course, and I hope that, while
it was difficult for you, you also had some fun as well! Being able to program (no matter what language
you use) is a very useful skill, and I think many of you will find some way to put this knowledge to use.
Being able to use Git is also extremely important to know, in order to maintain proper version control
and efficiently work in groups. So many different fields of engineering make use of Github (or SVN), so
it’s fairly universal for us. LaTeX you will find useful if you want to create nice documents, and,
speaking from a graduate perspective, will be direly important if you plan to pursue graduate studies.
 
I’d also like to thank all of you for being able to work with going remote. We obviously weren’t planning
to see the world suddenly experience a pandemic, and we know it’s been a huge shift full of craziness
and uncertainty. So be proud of yourselves for that. Nothing like this has happened in our time, and it’s
a huge event that has affected everybody.

I know I’ll still talk to a bunch of you during my office hours and lab hours next week, but in case I
don’t get to talk to you, I just wanted to say thank you for all of your hard work. I wish all of you
well in your future endeavors, and I hope that by the time the next semester rolls around everything
will be back to some level of normalcy and I’ll get to see your faces again. Stay safe, and good luck on
your finals! And have a relaxing summer. All of you definitely deserve it!