Three‑Body Kernel (TBK): a reusable kernel for the “not solvable” problem

Disclaimer

This is not a claim of an analytic solution to the general three‑body problem.

This is a kernel + tooling handoff: the clean internal formulation you use when you want to simulate a lot of three‑body systems, survive close encounters, and classify chaos without reinventing the wheel every time.

OSF project (spec + tooling PDF):
https://osf.io/najrm/

TL;DR

The Newtonian three‑body problem is famously non‑integrable and often chaotic. That doesn’t mean you can’t do serious work with it — it just means the job is structure + invariants + numerics + diagnostics.

TBK is a stand‑alone “Three‑Body Kernel” that packages the standard machinery into a reusable core:

Translation removed (COM reduction)
Units removed (dimensionless form; only mass ratios matter)
Internal coordinates (Jacobi) with diagonal kinetic energy
A clean, implementation‑friendly RHS (algebra simplified once, shipped forever)
Invariants (energy, angular momentum) and size/shape diagnostics (moment‑of‑inertia radius)
Planar runs included as an invariant slice of the 3D kernel
A tooling spec: integration modes, hybrid switching, encounter events, and chaos indicators (MEGNO/SALI)

If you’re sitting on a big three‑body workload (sweeps, stability maps, Monte Carlo encounter stats), this is the “start here” core.

1) Introduction

The first time you meet the three‑body problem, you get the same reflex most competent people get:

“That’s not solvable.”

And in the romantic, closed‑form sense — it isn’t.

But “not solvable” is not the same as “not usable.” In practice, most of the pain comes from a simpler problem:

Everyone keeps rebuilding the same internal engine.

They start with positions, velocities, and a force law… and then they spend their time re‑discovering:

how to remove translation cleanly,
how to pick coordinates that don’t fight you,
how to instrument invariants properly,
how to detect close encounters and regime shifts,
and how to decide when the motion is regular, chaotic, or “sticky.”

TBK exists to package that into a reusable artifact.

What you want is not “a miracle solution.” You want:

a clean kernel
a clean interface
and a clean tooling contract

So you can stop debating basics and move on to the problem you actually care about.

2) Changelog / Version history (brief)

This project went through a very practical evolution: from “kernel idea” → “stand‑alone math spec” → “implementation‑clean + tooling‑ready.”

TBK v0.x — Concept phase

The stance: not solvable in closed form → kernelize it.
The goal: isolate the internal dynamics and ship a handoff object.

TBK v1.0 — First complete build

3D master kernel (with planar as an invariant slice)
Internal coordinates (Jacobi)
Invariants + diagnostic channels
Tooling draft (integration modes, switching, chaos indicators)

TBK v1.1 — Corrected + implementation‑clean (current)

This is the “we ship this” version.

Changes that matter:

Correct restricted limit wording: as the third mass fraction goes to zero, the inner binary becomes pure two‑body, while the third becomes a forced restricted motion (not a free decoupled sector).
Inverse transform added: you can reconstruct the physical positions/velocities from the internal coordinates in a drift‑proof way.
RHS simplified: algebraic cancellations are performed once and shipped in the boxed ODE (better conditioning across mass ratios + fewer operations).
Tooling made TBK‑native: planetary‑specific assumptions (Hill switching / near‑Keplerian splits) are treated as optional backends, not defaults.

The OSF project contains the current specs and the upload‑ready tooling PDF.

3) Current build (what TBK actually is)

TBK is two things:

a Kernel Spec (the math core)
a Tooling + Integration Spec (how to run it at scale)

3.1 The kernel in words

A) Remove translation (COM)

In three‑body gravity, the center‑of‑mass motion is inertial. It’s not “physics,” it’s bookkeeping.

TBK works in an internal frame where translation is gone by construction, so you don’t waste numerical accuracy chasing drift.

B) Remove units (dimensionless form)

If you express the system in dimensionless variables, the only remaining parameters are the mass ratios.

That matters because it turns “three masses” into a small, clean parameter space.

C) Use internal coordinates that behave (Jacobi)

Jacobi coordinates are the standard move for a reason:

they represent the system internally,
they diagonalize the kinetic energy,
they make pair separations cheap to compute,
and they give you a natural place to hang invariants and event logic.

D) Ship the clean RHS (boxed ODE)

A kernel is only as reusable as its implementation reality.

So TBK ships the final ODE in a simplified computational form — not “a pretty derivation that cancels later,” but the version you actually want in code.

This reduces:

pointless multiplications/divisions,
conditioning problems for extreme mass ratios,
and “looks like 0/0 but isn’t” traps.

E) Explicit invariants (and drift gates)

TBK defines and ships the invariants you should track:

total energy (dimensionless)
total angular momentum (vector in 3D)

These are not optional. They are your truth sensors.

F) Size/shape diagnostics

TBK includes a natural internal “size” measure based on the mass‑weighted moment of inertia.

That gives you:

a scale radius you can use for encounter severity
and a diagnostic identity (Lagrange–Jacobi) that tells you when the size channel is behaving.

This is how you make “close encounter” detection dimensionless and comparable across sweeps.

G) Planar is not a separate derivation

A clean 3D kernel contains planar motion as an invariant submanifold.

So TBK treats planar runs as “3D with vectors constrained to a plane,” not a second derivation.

That keeps the kernel clean and avoids duplication.

H) Singular sets are declared (not discovered)

The force law blows up at collisions.

TBK explicitly declares the singular sets as kernel hazards:

pair collision manifolds (distance → 0)

This forces tooling to treat them as events (terminate, switch backend, regularize), not “numerical weirdness.”

3.2 The tooling spec in words

The kernel gives you the engine. Tooling gives you the operational behavior.

TBK’s tooling layer is built around four realities:

Close encounters happen.
Chaos is common.
You will want to run huge sweeps.
If you don’t define event logic and chaos contracts up front, every downstream implementation becomes a different incompatible system.

A) Integration modes (kernel‑native defaults)

TBK supports a sensible trio:

Adaptive “truth mode” for strong encounters and validation runs.
Fixed‑step symplectic baseline (kernel‑native) for long runs and large sweeps.
Hybrid switching that stays TBK‑general.

Important: TBK does not bake in planetary assumptions as defaults.

Planetary‑optimized integrators are great when their assumptions hold — TBK supports them as optional backends — but the default policy must work for equal‑mass chaotic triples too.

B) TBK‑native hybrid switching

Instead of Hill radii (planetary concept), TBK‑native switching uses internal, universal quantities:

smallest pair separation
an internal size scale (so “close” is dimensionless)
pairwise dynamical timescales (so “under‑resolved” is measurable)

When severity spikes or the fastest pair becomes under‑resolved, you switch to the safer mode.

C) Events (operational definitions)

Tooling defines events in TBK’s native variables:

collision / near‑encounter
exchange (bound pair identity changes and persists)
ejection (operational detector: far + outward + unbound proxy)

No hand‑waving. The point is: anyone implementing TBK gets the same event semantics.

D) Chaos indicators (contracts)

TBK supports chaos indication via variational/tangent dynamics.

Default:

MEGNO (fast chaos classification when implemented properly)

Optional:

SALI (additional chaos flag)

And importantly:

classification should be slope‑first (horizon‑aware), not “one magic MEGNO number.”

E) Sweep patterns

If you’re doing 10^6–10^9 runs, you don’t store trajectories.

TBK’s sweep pattern is:

a fast pass
early exits when confidence is high
escalation when encounters occur or classification is uncertain
compact result structs (class + confidence + invariant drift stats + event flags)

4) Possible next steps

The current TBK build is a spec + documentation package. The natural next moves are implementation and “make it hard to misuse.”

4.1 Reference implementation (minimal, correct, fast)

Ship a small reference core that matches the spec exactly:

tbk_rhs (kernel RHS)
pair_geometry (pair separations, relative velocities, internal size scale)
energy and angular_momentum
J_times_vec (tangent dynamics hook for chaos indicators)

Plus:

a minimal symplectic stepper
a hybrid wrapper (switching + hysteresis)
streaming callbacks (so sweeps don’t store everything)

4.2 Test pack (so outsiders can trust it)

TBK should ship a test suite that makes correctness hard to fake:

invariants drift gates (per mode)
planar invariance check
restricted limit regression
central configuration checks (Euler/Lagrange)

4.3 Benchmark pack (so performance claims are real)

throughput vs dt/tolerance
drift behavior vs mode
chaos indicator stability vs horizon

4.4 Examples (so adoption is easy)

one‑run demo (single triple)
sweep demo (batch)
“chaos map” example

4.5 Optional backends (only when needed)

extreme encounter regularization backends (when the use case demands it)
planetary‑specialized backends (when the assumptions hold)

Closing

The three‑body problem is still “not solvable” in the storybook sense.

But if what you need is compute + classify + scale, then the correct response is not despair.

The correct response is a kernel.

OSF project:
https://osf.io/najrm/

— Marcus