Orbital Modelling Brief: Assumptions, Equations, Simulation, and Validation

Hello, and welcome. This course develops a compact applied-mathematics workflow through orbital simulation: formulate a physical question, choose a defensible model, express it as differential equations, compute a trajectory, and test whether the result deserves to be believed. The end product will be a visually compelling Python simulation, but the central habit is broader: make the model explicit before trusting the output.

This first lesson establishes that habit. You will create a modelling brief for a deliberately limited orbital question. The brief will state what system is being represented, what the simulation must return, which idealisations make the problem tractable, what has been left out, and how numerical correctness and physical adequacy will be assessed.

---

A model is a purposeful simplification

A simulation is not “the real system in Python.” It is a chain of choices that connects a real-world question to a computed output:

1. State a question whose answer is observable or measurable.
2. Set a system boundary: decide what is inside the model and what is treated as external or absent.
3. Select assumptions that reduce the system to a tractable mathematical form.
4. State the governing equation and initial data.
5. Implement a numerical approximation to the equation.
6. Verify the implementation and validate the model for its intended use.

The order matters. Starting with code can produce an animation quickly, but it makes it difficult to identify what the animation means, what it excludes, or why it should be trusted.

SIAM’s short overview makes the central modelling point well: the real world contains too many potentially relevant variables, so assumptions are not a regrettable afterthought. They define the question that the model can actually answer.

For this course, a good brief has one governing principle:

An assumption is acceptable only relative to a stated purpose, spatial scale, and time horizon.

For example, ignoring atmospheric drag is generally reasonable for a high-altitude satellite over a few orbits. It is unsuitable for a low-Earth-orbit satellite tracked over months, and disastrous for a re-entry calculation. “Neglect drag” is therefore incomplete; “neglect drag for a first-pass, ten-orbit model at sufficiently high altitude” is a modelling decision.

---

From a visual idea to a precise orbital question

“Simulate an orbit around Earth” is a project idea, not yet a modelling question. It leaves open the body being modelled, the duration, the coordinate system, the quantities of interest, and the level of fidelity.

A useful initial question for the simulator is:

Under an ideal Newtonian Earth–satellite model, what three-dimensional path does a satellite follow over ten nominal orbital periods, and how accurately does the computation preserve a circular orbit when given circular-orbit initial conditions?

This question is deliberately modest. It separates two purposes:

• Physical prediction within an idealised model: compute the satellite’s path.
• Numerical assessment: determine whether the chosen integration method reproduces a case whose behaviour is known.

The output should be specified as concrete objects, not as “a simulation”:

Output	Why it is needed
Position history $\mathbf{r}(t)$	Defines the trajectory and supports plotting or animation.
Velocity history $\mathbf{v}(t)$	Is required to continue the calculation and later derive orbit properties.
Radius history $\Vert \mathbf{r}(t)\Vert$	Makes deviations from a circular orbit immediately visible.
Estimated orbital period	Provides a scalar result for comparison with theory.
Minimum radius	Flags collision with, or passage through, the central body under the point-mass model.
Numerical diagnostics	Record timestep, method, runtime, and later conservation-law errors.

Notice that an animation is a presentation output, not by itself a scientific result. It can reveal gross errors, such as an orbit spiralling outward, but it cannot establish numerical accuracy. A credible simulator needs quantitative diagnostics alongside the picture.

MIT’s model-development workflow is worth using as a mental template. It begins with objectives and governing equations, then includes implementation, testing, benchmarking, and iteration rather than treating programming as the whole task.

---

The system boundary: what exists in version 1?

The first simulator will use the restricted two-body approximation:

• Earth is the central gravitating body.
• A satellite is the moving body of interest.
• The model computes the satellite’s motion relative to Earth.
• The calculation runs for a specified finite horizon, initially perhaps ten orbital periods.
• The state is represented in three spatial dimensions, even if the particular initial orbit lies in a plane.

That boundary does not assert that the universe literally contains only Earth and a satellite. It says that, for the selected question, other influences are assigned zero effect.

There are two related but distinct simplifications that are often conflated:

1. Two-body model: only the Earth and satellite participate gravitationally.
2. Test-particle approximation: the satellite’s mass is small enough that its gravitational effect on Earth is ignored.

Later, you will treat the full two-body problem, where both masses respond and the system’s centre of mass moves uniformly. For a satellite around Earth, the test-particle approximation is an excellent starting point. For an Earth–Moon calculation, it would not be.

The computational domain also needs a physical exclusion condition. The equation for a point-mass gravitational field is singular at Earth’s centre. A satellite trajectory that passes inside Earth’s physical radius is not an interesting mathematical orbit to continue under this model; it should be classified as a collision or model-failure event. The real radius of Earth therefore matters even though Earth’s mass is treated as concentrated at its centre.

---

Assumptions that turn the system into mathematics

A modelling brief should distinguish assumptions about physics, geometry, and coordinates.

Newtonian gravitational physics

We assume Newtonian gravity and constant masses. For a satellite position vector $\mathbf{r}$, measured from Earth’s centre, the core equation will be

$$\ddot{\mathbf{r}}=-\frac{\mu }{\Vert \mathbf{r}{\Vert }^3}\mathbf{r},$$

where $\mu =GM$ is Earth’s standard gravitational parameter, $G$ is the gravitational constant, and $M$ is Earth’s mass.

You do not need to derive this equation yet; that is the next mathematical component of the module. For the modelling brief, its role is to identify what the simulator will eventually solve: a second-order vector differential equation requiring an initial position and velocity.

Point-mass and spherical-symmetry assumptions

The satellite is modelled as a point mass. Its shape, size, attitude, rotation, and internal structure do not affect its translational motion.

Earth is modelled as a spherical mass distribution whose external gravitational field is exactly equivalent to that of a point mass at its centre. This is more than a graphical convenience: it is what justifies acceleration depending only on distance from the centre.

The following short segment makes these assumptions explicit and also identifies the usual Earth-centred, non-rotating frame used for the elementary model.

Coordinate assumption

The model will use an Earth-centred, non-rotating Cartesian coordinate system. Within the ideal isolated model, this can be treated as inertial: Newton’s laws retain their familiar form and no fictitious centrifugal or Coriolis forces are added.

This choice is appropriate for calculating trajectories. It is different from a frame fixed to Earth’s surface, which rotates once per day. A ground-fixed coordinate system is useful for questions about where a spacecraft appears above Earth, but it introduces rotational effects and is not the right default frame for deriving the simplest gravitational equations.

---

Omissions are part of the result

A high-quality modelling brief names omissions and explains their likely relevance. This prevents the common error of interpreting disagreement with reality as a bug when it is actually a known consequence of the model boundary.

Omitted effect	What it changes physically	When omission becomes problematic
Earth’s oblateness, especially the $J_2$ term	Causes long-term rotation of the orbital plane and periapsis	Inclined Earth orbits over many days or longer
Moon, Sun, and other bodies	Produce third-body perturbations	Long time horizons, high-altitude Earth orbits, interplanetary motion
Atmospheric drag	Removes orbital energy and lowers low-altitude orbits	Low Earth orbit, especially over many revolutions
Solar radiation pressure	Produces a small non-gravitational acceleration	High area-to-mass spacecraft and long-duration missions
Propulsion and attitude control	Changes velocity through deliberate thrust	Any manoeuvring spacecraft
Earth’s finite surface and terrain	Determines collision geometry	Low periapsis or impact questions
Relativistic corrections	Slightly changes gravitational motion	High-precision navigation or relativistic systems
Mass loss and flexible-body effects	Alters spacecraft mass and motion in specialised settings	Propellant-intensive or extended-body missions

The omissions do not make the two-body model “wrong.” They delimit its validity regime. The model is intended to capture the geometry and numerical structure of unperturbed Keplerian motion, not to reproduce a mission-grade satellite ephemeris.

A useful sentence for the brief is:

This model is intended for qualitative visualisation and numerical study of ideal Earth-centred Keplerian motion over a limited number of orbits; it is not intended for operational orbit prediction.

That one sentence protects against an unjustified leap from a neat trajectory plot to a real-world navigation claim.

---

Equation, simulation, and validation are different layers

It is helpful to regard the project as three connected layers.

1. Mathematical model

The model consists of:

• the differential equation for gravitational acceleration;
• parameter values such as $\mu$;
• initial position ${\mathbf{r}}_0$ and initial velocity ${\mathbf{v}}_0$;
• a time interval;
• assumptions and stopping conditions.

At this layer, the central question is: does the equation faithfully represent the chosen idealisation?

2. Numerical simulation

The computer does not solve the differential equation exactly. It generates an approximation at discrete times. The implementation will eventually include:

• a function that maps position to acceleration;
• an integrator that advances position and velocity through time;
• arrays storing sampled states;
• plotting and animation;
• diagnostic calculations kept separate from the force and integration code.

At this layer, the question is: does the algorithm correctly approximate the mathematical model to the required accuracy?

3. Verification and validation

These terms are often blurred, but their distinction is useful.

• Verification asks whether the code solves the stated equations correctly. A circular orbit with known radius and period is an excellent verification case. Timestep refinement and comparison of independent integrators are also verification tools.
• Validation asks whether the equations represent the real physical system adequately for the intended purpose. Comparing against an authoritative ephemeris or observed data is validation, but only after accounting for omitted physics.

An apparent mismatch with a real satellite’s orbit may therefore have at least three origins:

1. a programming error;
2. numerical error from timestep or integration method;
3. model discrepancy due to drag, oblateness, third-body gravity, or another omitted effect.

A simulation should be designed to distinguish these explanations rather than merely display a mismatch.

---

A complete version-1 modelling brief

Here is a model brief that is appropriately scoped for the beginning of this course.

Investigation

Question. Under a Newtonian restricted two-body model, simulate a satellite’s Earth-centred trajectory for ten orbital periods and assess whether the numerical method maintains a prescribed circular orbit.

Intended outputs and success criteria

The simulation will produce:

• a three-dimensional trajectory plot and animation;
• time series for $\mathbf{r}(t)$, $\mathbf{v}(t)$, and $\Vert \mathbf{r}(t)\Vert$;
• an estimated period;
• a record of timestep, integration method, and computation time;
• later, errors in conserved energy and angular momentum.

For a circular-orbit verification run, the radius should remain close to its prescribed value, the trajectory should remain in its initial plane, and reducing the timestep should reduce the discrepancy in a systematic way. The exact tolerance will be selected after studying numerical integration; it should not be chosen arbitrarily before the method is known.

System boundary and frame

The system consists of Earth and one satellite. Earth supplies the gravitational field; the satellite moves in that field. The simulation covers a finite interval of ten orbital periods and is halted if the satellite crosses the specified Earth-radius boundary.

Coordinates are Earth-centred and non-rotating. Position and velocity are expressed in a Cartesian inertial frame. The state will later be formalised as the six-dimensional quantity

$$\left(\mathbf{r},\mathbf{v}\right).$$

Assumptions

• Gravity obeys Newton’s inverse-square law.
• Earth is a spherically symmetric point-mass gravitational source with constant parameter $\mu$.
• The satellite is a point mass with constant mass.
• The satellite’s gravitational effect on Earth is neglected.
• No non-gravitational forces act on the satellite.
• The trajectory is solved in three dimensions, although a planar initial condition is permitted.

Explicit omissions and limitations

The model neglects atmospheric drag, Earth’s oblateness, lunar and solar perturbations, radiation pressure, thrust, attitude effects, mass loss, and relativistic corrections. It cannot make operational predictions of a real Earth satellite’s position over substantial time horizons. It is suitable for learning, visualising, and numerically scrutinising ideal Keplerian motion.

Equation–simulation–validation workflow

1. Derive the vector acceleration law from Newton’s laws.
2. Recast the second-order equation as a first-order initial-value problem.
3. Implement the acceleration function independently of the integrator.
4. Integrate a known circular orbit with progressively smaller timesteps.
5. Compare computed radius and period with the analytic circular-orbit benchmark.
6. Compare methods using trajectory error, invariant errors, and runtime.
7. Only after numerical verification, compare a suitably scoped case with external orbital data, while interpreting systematic differences in light of the stated omissions.

This is a useful brief because every element can later be inspected. If the orbit spirals, you know to investigate the integrator and timestep. If an otherwise accurate unperturbed orbit slowly differs from a real Earth satellite, you know that the two-body boundary excludes effects, such as $J_2$ and drag, that cause genuine long-term changes.

---

A practical habit: maintain an assumptions ledger

Keep the modelling brief in the repository beside the code, perhaps as model_brief.md. When a new feature is added, update one of its sections rather than merely adding a code comment.

For this project, the ledger should answer four questions at every stage:

• What question is the simulator now answering?
• What quantity will count as evidence for the answer?
• Which physical effect has just been included or excluded?
• Which test would reveal that the addition has failed?

For example, adding Earth’s oblateness later would require changing the governing acceleration and validation target. It would not be a harmless visual enhancement: it changes the physical model and the expected long-run motion.

Before proceeding, write the version-1 brief in your own words, keeping it to roughly one page. Do not optimise its prose. Its purpose is to create an auditable contract between the physical question, the equations you will derive, and the outputs you will later interpret.

---

Key takeaways

A credible orbital simulation begins with a modelling brief, not an integrator. The brief specifies:

• a focused question and concrete outputs;
• a system boundary, time horizon, and coordinate choice;
• Newtonian point-mass and test-particle assumptions;
• omitted effects and the regime in which they matter;
• a staged route from equation to numerical solution to verification and validation.

The restricted two-body model is intentionally narrow, but it has substantial value: it is simple enough to derive, solve, visualise, and test rigorously. Later additions will be meaningful precisely because this baseline is explicit.

Next, we will choose an inertial reference frame carefully and define the position–velocity state of a system of point masses.