Octant

The chain

Octant runs Orekit compiled to JavaScript. Trust in a number therefore needs two links, not one — and they are checked separately:

The first link matters because it is the unusual thing Octant does. IEEE-754 arithmetic is identical on a JVM and in a browser engine, and the measurements say so: the same case run natively and in the browser returns the same position to every digit reported, for analytical and numerical propagation alike.

Against GMAT, on real satellites

GMAT is NASA's General Mission Analysis Tool — open source, used for real mission design, and entirely independent of Orekit. Both were given the same real TLE, fetched from Celestrak, and asked to propagate 24 hours with SGP4.

1,442 samples each, one per minute across a full day. Four orbits spanning low Earth orbit, a geostationary transfer orbit and GEO — and both the near-Earth (SGP4) and deep-space (SDP4) branches of the model. Seven metres on a 6,800 km orbit is about one part in a million.

Why SGP4 for the comparison

Deliberately. A TLE plus the SGP4 model determine the answer completely: there is no force model, integrator tolerance or gravity field for two tools to disagree about legitimately. Any difference that remains is implementation — which is the only thing worth measuring in a cross-check. Comparing numerical propagators instead would mostly measure how similarly the two were configured.

What the residual is

Not a propagation disagreement. It is a sub-millisecond time-tag offset, and the four cases above are what establish it.

The difference does not grow over the day, which already rules out genuine divergence. What it does instead is scale with orbital speed: divide each position difference by the satellite's velocity and the result is the same across all four orbits — 0.86, 0.86, 0.90 and 0.93 milliseconds — even though those orbits differ in speed by a factor of 2.5, in eccentricity from 0.0004 to 0.712, and run through two different branches of the model.

A propagation difference would not behave that way. A constant time offset would, and does: the two tools place the satellite in the same place at times that differ by about 0.9 ms, most likely a convention in converting the TLE epoch or in leaving the TEME frame. 0.9 ms of clock is 7 m in low Earth orbit and 3 m at GEO, which is precisely the pattern measured.

This has not been chased to its source, and it is stated rather than rounded away. But it is now an explained residual with a testable signature, not an unexplained one.

The numerical propagator, on the same gravity field

The comparison above is silent about spherical-harmonic gravity, by construction — SGP4 has none. So here is the other half: a full numerical propagation, run in both tools, on the identical gravity field.

That last part is the whole difficulty. Orekit ships eigen-6s and GMAT ships JGM-2, so propagating in each and comparing would mostly measure the difference between two geodesy products — a fact about the world, not about either implementation, and the easy number to mistake for a validation. GMAT's own coefficient file is therefore converted into the format Orekit reads, and both tools integrate the same 2,553 coefficients with the same GM and the same reference radius.

JGM-2 truncated to 20×20, gravity only, 24 hours, sampled every 60 s. GMAT: RungeKutta89 at 1e-12 accuracy. Orekit: Dormand-Prince 853 at 1 mm position tolerance. The initial state is taken from GMAT's own first report row, so element conversion is not in the comparison. 2,299 and 1,485 samples.

What is deliberately left out

Drag, solar radiation pressure, third bodies and tides. Each depends on a model the two tools do not share — an atmosphere, a flux history, a spacecraft area — so including them would measure how similarly two people configured two programs, which is the criticism a cross-check has to be immune to. Gravity alone is the part where "the same inputs" can actually be guaranteed.

What the residual is, and is not

It does not grow. Mean disagreement over the first hour and the last hour of the day differ by about 0.1 m in both cases, and the medians — 10 cm and 8 mm — sit far below the maxima. A force-model disagreement compounds; this does not, which places it with frame realisation and report rounding rather than with the physics.

The maxima land at perigee in the GTO case, where the spacecraft is fastest and any sub-millisecond difference in time-tagging buys the most metres — the same signature the SGP4 comparison above identifies, arriving by the same route.

What remains legitimately different is the Earth-fixed frame the harmonics are evaluated in: Orekit uses ITRF through IERS 2010 conventions with earth-orientation data applied, GMAT its own realisation. That is not a bug in either tool, and it is why this section reports a number rather than asserting a pass.

Run it: benchmark/scripts/validate-forcemodel.sh, after GmatConsole.exe cases/leo_numerical.script. The field conversion is benchmark/scripts/cof-to-gfc.py, and it prints a coefficient count against the number a full field of that degree must contain, because a silently truncated gravity field would look like a small disagreement rather than like a broken input.

What this does not establish

• The SGP4 comparison is not a validation of the interactive propagator — and neither is the numerical comparison above it. The tool's sliders use Eckstein-Hechler — mean elements, J2–J6, no drag, no solar radiation pressure, no third body. It is fast, and it is approximate. Against a full numerical force model it drifts about 3.3 km over 24 hours in low Earth orbit. That number is the honest cost of an instant answer, and the tool always names the model it used.
• Agreement is not accuracy. Two tools agreeing means they implement the same model consistently. SGP4 itself is only good to roughly a kilometre against reality, and degrades with age of the TLE.
• The Moon and Mars are unvalidated. Gravity fields are the real measured ones — GRGM660PRIM and jgm85f01 — but no independent cross-check has been run, and the body-fixed frames use the IAU rotation model without libration terms (roughly 600 m on the lunar surface).
• Eclipse geometry is unvalidated. Conical umbra, sanity-checked against physics — a dawn–dusk sun-synchronous orbit comes out fully sunlit, an ISS-like orbit 39.4% against a real 35–38% — but not compared with another tool.

The analyses, and what each one is checked against

The orbit is the part GMAT can arbitrate. Everything built on top of it — link budgets, data budgets, coverage, manoeuvre costs — is checked instead against closed forms, published figures, and invariants that a wrong implementation cannot satisfy. Those are weaker than an independent tool and stronger than nothing, and the difference is worth being explicit about.

Run automatically, against the shipped bundle

Seventeen suites in benchmark/scripts/, run by check-all.sh against the compiled Orekit build rather than the Java source — TeaVM is a translation step that can drop things, and the compiled file is what ships.

Closed-form and invariant spot checks

Measured against textbook formulae or against a quantity the same run computes another way. Six of these are now re-run on every build by the spot-check suite above — the two radio figures, both derived masses, the CSM tank and vis-viva. Two files had to be split out of the application before that was possible, because the arithmetic lived inside code that needs a browser to load.

Four are still measured-on-a-date and are marked below. The exported velocity, the data latency and the coverage figures come from orchestration — which spacecraft, which pass, which window — rather than from a formula, and reaching them from a headless check needs a harness that does not exist yet. Saying which is which matters more than the count.

What the analyses do not establish

• Conjunction screening is verified in the application, not on every build. It screens the spacecraft in one scenario against each other — never a public catalogue, which would need thousands of TLEs of varying age and would answer with a probability of collision rather than a miss distance. On the 24-satellite Walker template it finds the closest approaches to be cross-plane pairs at about 4700 km, which is what the geometry requires, and its refinement moves every approach 9–13 km closer than the sampled grid and never further.
• No independent tool has arbitrated any of them. A closed form checks arithmetic; it does not check that the right question was asked. The GMAT comparison above covers orbits, eclipse, access and lifetime — and nothing else on this page.
• The link budget is clear-sky, single-carrier and downlink only. No rain fade, polarisation mismatch, multipath, interference, or pointing loss from a real attitude error.
• Coverage and access for an off-body ground object are geometry. A lunar site's access is computed against its own local vertical, but nothing models what its terrain hides.
• The data budget's duty cycle is a proxy. It states how much of a window an instrument runs for, not when — the when would need a per-phase command.
• Component figures are representative, not datasheets. Panels, radios, batteries and thrusters carry numbers typical of their class, each with its source stated in the asset library. They are enough to size a mission and not enough to build one.

Reproduce it

Everything here is a script in the repository. Nothing is hand-copied into this page from a run that cannot be repeated.

benchmark/scripts/validate-sgp4.sh          # fetch TLEs, run Orekit, diff against GMAT
GMAT-R2026a/bin/GmatConsole.exe cases/iss_sgp4.script
benchmark/scripts/run-native.sh             # native Orekit timing baseline
benchmark/scripts/run-teavm.sh OctantApi    # the browser build

Raw output lives in benchmark/results/. The GMAT scripts, the TLEs used and the comparison harness are in benchmark/cases/ and benchmark/src/.

Eclipse and ground-station access, against GMAT

Orbits were cross-checked against GMAT from the start; eclipse and visibility were not. That mattered more than it looked: a power budget begins with an eclipse fraction, so an unvalidated eclipse makes every number downstream of it a number with nothing underneath.

GMAT's EclipseLocator and ContactLocator were run over one day of the same orbit, from the same epoch, with the same station. The 10° elevation mask is expressed on our side as the half-cone that is a 10° mask at that altitude — from Wertz, sin ρ = R/(R+h) and cos ε = sin η / sin ρ — so neither tool is answering an easier question than the other.

Every number in this section is read at page load from data/validation-events.json — the same file the golden tests assert against. A page whose numbers are typed separately from the numbers the tests enforce is a page that goes quietly out of date.

Reproduce it:

GMAT-R2026a/bin/GmatConsole.exe -r benchmark/cases/eclipse_access.script

Raw GMAT reports are committed at benchmark/results/gmat_eclipse.txt and gmat_contact.txt.

Orbital lifetime — what it is, and what it is not

Lifetime is estimated by integrating the orbit-averaged decay rate, King-Hele's first-order result for a near-circular orbit:

da/dt = −(Cd·A/m) · ρ(a) · √(µ·a)

The density ρ is Orekit's — Harris-Priester, the same atmosphere its numerical propagator uses — sampled around each revolution and averaged, because the day–night bulge changes it by a factor of two.

It is not a numerical propagation with drag. Octant has one, and it is the wrong tool here: a numerical run costs roughly 170× an analytical one, and a lifetime is measured in years. Integrating a decade that way would take longer than the mission.

Computed, for a 3U CubeSat

C_d = 2.2, area 0.03 m², mass 4 kg — a ballistic coefficient of 0.0165 m²/kg, circular, 51.6° inclination.

Note the vehicle these came from. Those are bare figures, typed. The 3U CubeSat in Octant’s own vehicle library derives 0.0204 m²/kg — it has four deployed panels and a camera, so it is both heavier and draggier, and it would decay sooner than the table says. Neither number is wrong; they describe different spacecraft. Deriving the coefficient from parts rather than typing it is what makes that difference visible instead of silent.

That comparison was wrong, and GMAT settled it. This page used to say Octant’s figures were “short, consistently and by roughly a factor of two” against the published column above. Given the same spacecraft — C_d·A/m = 0.0165 m²/kg — an independent tool reproduces our numbers instead:

Lifetime cannot be a like-for-like check the way SGP4 was: GMAT does not implement Harris-Priester at all. So the question is not whether GMAT agrees to a digit but whether we sit inside the spread two respectable atmospheres produce — and we do, at 300 km and at 400 km, and within 7% at 350 km. At 400 km GMAT’s two atmospheres differ from each other by 41%, more than either differs from us.

A published lifetime table is only meaningful with its ballistic coefficient and its solar activity attached; the column above carried neither. The self-criticism was honest and it was wrong, which is a decent argument for checking against a tool rather than against a remembered range.

The uncertainty that dominates everything above — now measured

The solar cycle. This page used to assert that it dominated. It does, and here is by how much. Harris-Priester has no solar-activity input at all — one fixed table — so the same decay was run over Orekit’s NRLMSISE00, which does, at three points of the cycle.

Two things fall out. The spread grows with altitude — a factor of 4 at 300 km, 10 at 400 km. And Harris-Priester turns out to track the mid-cycle case to within 5% at every altitude, so calling it “a fixed level on the high side” was wrong in the same way the factor-of-two claim was. It is essentially the mean.

NRLMSISE00 needs no space-weather file here, which is why this was affordable at all: Orekit drives it through a five-method interface, and that interface can be implemented with constants. The activity becomes an explicit input the caller chooses rather than a data file to bake and keep current. Constants rather than a predicted flux series on purpose — a prediction would give one confident answer for a launch date five years out, which is exactly the false precision worth avoiding.

What the averaging costs — the one thing GMAT could not tell us

GMAT averages the same kind of thing we do, so both tools could share an approximation error and agree beautifully. Isolating it needs the same spacecraft, the same epoch and the same atmosphere integrated two ways: Orekit’s numerical propagator with a real drag force and no averaging anywhere, against the King-Hele orbit-averaged loop Octant ships.

Orbit-averaging over-predicts lifetime by 3.5% at 400 km, rising to 11% at 300 km. The sign is consistent and the trend is the right way round: the approximation assumes the orbit changes little over one revolution, and that weakens exactly where the decay per revolution grows. Over-predicting is also the safe direction for a disposal argument — it makes a 25-year claim harder to satisfy, not easier.

The numerical side is stepped one day at a time, so it is quantised to a whole day — at 300 km that is 4% of the answer and a real part of the 11%. Reproduce with benchmark/scripts/validate-decay.sh.

So which uncertainty actually matters

They are not the same size, and that is the practical conclusion of this whole section. The tool now shows a range rather than a number — not out of caution, but because the headline uncertainty is two orders of magnitude larger than the modelling ones, and a single figure to three digits would be a statement about arithmetic rather than about the spacecraft.

What is checked, and what is not

Checked: against GMAT at three altitudes with two independent atmospheres — reproducible with GmatConsole.exe -r benchmark/cases/lifetime.script, raw output committed at benchmark/results/gmat_lifetime.txt. The scaling also behaves as it should, about ×2.5 per 50 km, which is the expected exponential.

Not checked: against a numerical propagation with drag over the full decay. The orbit-averaging approximation itself has not been isolated from the atmosphere it is averaging, and agreement with GMAT does not do that — both tools are being asked to average the same kind of thing.

Scope

Earth only — the Moon has no atmosphere and Mars is not implemented. Near-circular orbits only (e < 0.05): King-Hele's eccentric case is a different formula, and applying the circular one to a transfer orbit would produce a confident wrong answer rather than no answer. TLE objects are refused, because SGP4 elements carry their own B* drag term which this estimate would contradict rather than use.