Code
DraftThis page indexes programs written to support work recorded elsewhere on the site: propagators, link budget tools, data pipelines and analysis scripts.
It contains no code, and that is deliberate.
Why no listings
The style guide prohibits code in content, and the reasoning applies most directly here.
An algorithm is better documented by stating it. The governing equation, the iteration in mathematical notation, and a table of the steps an implementation needs with the reason each exists: that survives a change of language and says why rather than only what. A listing does neither.
A listing invites copying untested code. Code on a documentation page has not been run in the reader’s context, has no tests visible, and has no version. Copying it is a worse outcome than the reader writing their own.
Code and prose drift apart. A listing embedded in a page is a copy that stops matching the repository the moment either changes, and nothing signals that it has.
So an implementation is linked, not listed. The page records what it does, how it was validated, and where to find it.
What to record
| Field | Content |
|---|---|
| What it does | The problem it solves, in one sentence |
| Why it exists | What motivated writing it rather than using something existing |
| Interface | Inputs, outputs, units and conventions |
| Method | The algorithm, stated mathematically, with the reference it follows |
| Validation | What it was checked against, and the residual agreement |
| Limitations | Where it is not valid, and what it does not handle |
| Repository | Where the source lives, and its licence |
| Status | Working, experimental, superseded, abandoned |
The validation field is the one that determines whether the tool’s output can be trusted, and it is the field most often empty.
Validation
The same discipline as Simulations, applied to the implementation rather than the model.
| Check | What it establishes |
|---|---|
| Analytical case | A two-body propagator conserves energy and reproduces the closed-form solution |
| Published reference | Reproduce a documented result with the documented inputs |
| Independent implementation | Agreement with an established tool such as Orekit, GMAT or SPICE |
| Conservation | Quantities the physics conserves are conserved numerically |
| Limiting cases | Degenerate inputs produce the known degenerate answers |
| Round trip | Convert state to elements and back; the result should return to the input |
The round-trip check is cheap and catches a large class of conversion errors, including the quadrant mistakes described in Orbital elements.
An unvalidated tool should be labelled as such. A tool that produces plausible numbers and has never been checked is worse than no tool, because its output will be believed.
What is worth writing
Most things are not. Established libraries exist and are validated far more thoroughly than a personal implementation will be.
| Write it | Use an existing library |
|---|---|
| To understand the algorithm by implementing it | For anything whose result will be relied upon |
| For a niche calculation nothing covers | For orbit propagation, ephemerides, frames and time |
| To automate a specific repeated workflow | For anything with subtle conventions, especially reference frames |
| To check another implementation | When the library is well validated and you are not |
Writing a propagator to understand propagation is a good reason. Writing one because an existing one seemed inconvenient is usually not, and the frames and time handling described in Reference frames and time systems is exactly the kind of thing that appears simple and is not.
Conventions
Consistency across tools matters more than any individual choice.
| Convention | Default |
|---|---|
| Units | SI internally; convert at the boundary only |
| Angles | Radians internally; degrees only for display |
| Time | A single scale internally, with explicit conversion at interfaces |
| Frames | Every state carries its frame; never assume |
| Language | Rust for anything numerical or long-running |
The units and angles rules exist because mixed conventions inside a program produce errors that are invisible until the output is wrong by a factor of 57.3. Converting only at the boundary makes the internal code uniform.
Index
No entries yet. Each program written will be recorded here with its validation and repository link.
References
Individual programs cite their algorithmic sources. This page is a convention.