Programming orbits
Welcome to my series on how to build scientific models in code.
I'll be using a model of Earth and Mars orbiting the Sun to demonstrate what this means in theory and practice.
I'll start by creating a simple conceptual model of the orbits of each planet. The result will be turned into working code in subsequent posts, along with discussion of the context, considerations and motivation for this kind of work.
Along the way, we'll see how the model and code can be improved and extended to explore some basic questions about orbits.
How to know Not Much about space travel
I've been into space and science fiction most of my life. In all that time, I've mostly avoided understanding much at all of the science of actual space travel. My knowledge of fictional space travel, by comparison, is excellent.
[The Algorithm]: He's watched a lot of star trek, perhaps he'd be interested in a very brief intro to orbital mechanics?
Maybe you too don't know much about space travel. Except, you probably haven't been a student programmer at a national space agency:
- I was hired last minute by phone interview, and I'm fairly certain because a position had opened unexpectedly. By comparison, the requirements to work there with any responsibility seemed to be high.
- It was the first time in a long time, and also the last time, I saw a computer running Windows 3.1.
- My boss had a shelf of big books with titles like "space mission planning." Makes sense that there would be thick books about that, I thought. I don't recall what we were talking about, I only remember the shelf.
- Space mission planning software is expensive, although maybe it doesn't feel like it when your budget includes artisinal space stations and satellites.
- I lost a bet that the Mars Science Laboratory couldn't possibly land intact, based entirely on how complex the landing sequence appeared. Someone had to be brave and take the bet, but yeah... they did the math.
- My boss is on a list titled Bosses I Should Apologize To Someday. Mostly because I was obstinate for no especially good reason. The strongest mitigating factor is that he had me inerit a Perl program written by another co-op student who had never programmed Perl before. Fair's fair would be my defence.1
Space marketer
My job was to program a looping video that showed the current location of satellites in the lobby, I suppose to impress visitors. Marketing was a surprisingly large part of space work in my country. I can't remember if it was ever used.
To be clear, I did learn a bunch of things about a space agency, and something about technology in orbit. Just not a whole lot about travelling between planets.2
So between that and The Martian, which I watched and read, my formal training in space flight is, to be generous, rudimentary.
The Martian and modelling orbits
Blogging about Silico and scientific programming seems to be the perfect incentive for learning just a tiny bit more about the topic.
The stapler is a ship.
Since it came up a lot in The Martian, I'm going to focus on how the orbits of Earth and Mars affect travelling between the two. Not that it really matters to this exercise, but the plot of the movie was that a mission to Mars left something important behind, and everyone had to figure out how the ship might get back there to retrieve it. The thing left behind was... perishable, so they were on the clock.
Nobody is going to make of a movie of the task I'll be setting myself, although it should be illuminating. I'm going to build a simple model of the orbits of Earth and Mars, while also showing how you can build models in code, in Silico, and some of the things to think about while doing so.
Earth. Mars. Orbits: Too complex
How do we get to Mars? Through space? That's already a big simplification. First we have to get through Earth's atmosphere and gravity, through space and whatever may exist there, and finally into Mars orbit. Plus, you can assume I've just skipped over all sorts of interesting problems I have no idea about.
Making cuts
Since the purpose here is to gain a tiny window into the problem of orbits, travel and modelling - rather than land an actual mission to the satisfication of people accountable for funding such expeditions - simplifying the problem space will help a lot.
Time for some quick cuts:
- No radiation, asteroids, debris, gravity, space weather etc. Assume nothing but space between Earth and Mars.
- Ignore the complexity of launch or landing, or getting into a target orbit.
- No spacecraft propulsion, acceleration, deceleration. No other spacecraft things - fuel, payload.
- Ignore any economic, social and political dimensions of space travel.
- No interactions with other planets... and you know what? The Sun too.
Perfect, that's just about everything I could think of in a couple minutes. If anything else comes to mind, feel free to cut that too.
How far should these simplifications go? Given our purpose, it's not useful to think of Mars and Earth as stationary - we're interested in orbits. They'll have to move in some fascimile of an orbit (circle-like) around the Sun.
It'll also anchor the model to include some factual data: The distance of a planet from the sun, and how long it takes to go around the sun, for example. This kind of thing isn't strictly necessary, but then we can attach names like "Earth" and "Mars" to the "planets" in our model.
Guessing, errr... using judgement
There are a number of orbital details that could be important and it's a judgement call as to their inclusion. Is the 3rd dimension useful? Put another way, would its exclusion impose too heavily on our purpose? I don't know. Imagine the orbital planes as perpendicular to each other. I can see that making a difference.
A bit of searching suggests that Earth and Mars are in similar orbital planes. Accuracy isn't our objective, and so it's probably fine to ignore the 3rd dimension. It will almost certainly make the model building easier.
Other problems (after some quick glancing at Wikipedia) could include orbital irregularities (they're not perfect circles or ovoids). These will also be ignored.
Everything simplified out of the model would likely be useful given another purpose, but again, I'm trying to learn something from a very simple model of the systems we're interested in, and to learn something by building it in code.
A conceptual model
The result is a conceptual model of the following form:
- Earth and Mars orbit the Sun. The sun is a fixed center point, two planets go around it in two dimensions.
- Grid/Cartesian plane. There are x,y values for all objects in the model. Dimension x, and dimension y, by convention.
- Independent orbits around the sun. Earth and Mars are not part of a gravitational system. They do not affect each other in any way. The Sun is merely the center of our 2d x,y grid. It also does not affect either planet.
- No gravity. There is no modelling of why anything is where it is, or does what it does.
- No irregularities in orbits. Orbits are perfect circles.
- Positions of objects in the model change as a function of time. E.g. If we know where Earth is today in the 2d plane, and can figure out where it'll be in two days. Or seconds, or whichever unit of time makes sense when we build it.
- The model will be grounded by some approximately factual details of the orbits, such as distance from the sun and time to complete a single orbit.
In your mind it might look something like this:
I'm assuming the planets are moving around the sun in the same direction too, which is another factual detail I'm including from some wikipedia animation I glanced at for a couple seconds.
Read it thirty times
Having established this conceptual model, I had little idea how to implement it. I've seen orbits in space video games and this means it's probably within the reach of mortals and the computers they might program.
What's needed is a programmatic way to move Earth and Mars around in their orbits on a 2d grid, a way to calculate their x,y coordinates and do this in a way that can include the real world data I'm using.
Modelling physical systems in code isn't something I do, so imagine a few hours of distracted, but increasingly coherent internet research, much of which was Wikipedia rabbit holes for some of the relevant math.
It became apparent that trigonometry and angular velocity are useful mathematical tools for the problem. At the least, they're one way to approach the programming problem. I've never learned anything about angular velocity (I hope I haven't...) and haven't touched trigonometry since high school.
Working in my favour, however, is that the modern programmer is most at home understanding just enough to hopefully, probably, possibly-until-they-can-find-a-new-job, craft a solution. A lot of my life has lead up to this moment.
Here are links to concepts, and posts that pointed me in the right direction. I'll discuss how to approach the programming in the next post.