Frostline — thermal mining
for airless bodies.
On an asteroid or in a lunar cold trap, the water is locked in the regolith as ice. To get it out you point a solar-thermal beam at the surface, heat diffuses in, the ice sublimates, the surface recedes, and the vapor is captured. Frostline simulates that whole chain — as physics, with the energy and mass ledgers closed.
It is a moving latent-heat front (a Stefan problem) solved in real-time 3-D on the GPU in Rust + wgpu, with every stage gated against an independent reference — an exact analytic solution, an f64 CPU twin, and real lunar radiometry. The interactive console below runs that validated physics in your browser.
- release
- 02 · frostline
- domain
- phase change · ISRU
- license
- MIT OR Apache-2.0
- stack
- Rust + wgpu
Touch the physics.
The console is a line-for-line JavaScript port of the engine's validated f64 twin — the same damped-Newton surface balance (radiation + a Hertz–Knudsen latent sink + conduction), the same Murphy & Koop (2005) vapor-pressure fit, the same moving front and energy/mass ledgers. The conservation gauge in the corner shows the energy ledger closing live, to ~10⁻¹². It is a demonstration of the physics, not a toy inspired by it.
Three real model seams are exposed as controls on purpose: the beam profile (Gaussian vs top-hat — worth ~14% in g/MJ), the sublimation coefficient α (the 1.0 gate value vs the ~0.14 measured one), and a triple-point flag marking the v1.5 melt boundary. The HUD numbers land on the gated values below — that is the whole point.
runs in-page on click — the Canvas-2D loop stays idle until you activate it. prefer it standalone? open full-screen ↗
Validated against independent references.
No stage is trusted until it reproduces something it can't fudge: an exact analytic solution, a bitwise f64 twin, or real spacecraft radiometry. These are the gate values — the console above lands on them.
- 1-D thermal profilenoon ~390 K / pre-dawn ~98 K · no tuning · vs LRO Diviner
- Moving sublimation front≤4×10⁻⁴ · vs Neumann's exact Stefan solution
- Extraction efficiency334.2 g/MJ · 95% of ceiling · vs 353 g/MJ latent-heat bound
- 3-D GPU lane≤1×10⁻⁴ · family gate · vs f64 CPU twin (bitwise)
- 3-D crater depth89% of bound · wall losses quantified · vs 1-D depth bound
- Thermostat at mining flux~250–251 K · 3-D Gaussian spot ~285 g/MJ · vs gated envelope
Each gate has a record in the repository's validation/ directory — the reference, the metric, and the threshold that had to be cleared.
The honest part.
A number without its caveats is marketing. What the instrument is, what it isn't, and where the seams are:
- ›The console runs the validated f64 twin — the same CPU formulation the engine is gated against — not the 3-D GPU engine itself. The engine proper runs this physics in 3-D on wgpu, checked against the exact solutions above. The instrument is the physics, faithfully; it is not the full parallel lane.
- ›It hard-codes the engine's physical constants as of 2026-07-10 (ice properties, the Murphy & Koop 2005 vapor-pressure fit, latent heat). The repository is the single source of truth — if those constants move, the console's thermostat or g/MJ readouts will drift from the gate numbers, and the file must be updated by hand.
- ›The sublimation coefficient α is exposed as a control, not buried: the gate value is 1.0, but the physically measured value is ~0.14. You can dial it and watch the yield respond — the honesty is in showing the seam, not hiding it.
- ›A concentrator buys rate, not efficiency. The yield curve flattens: focusing the beam raises throughput but not the grams-per-megajoule ceiling. The sim reports the trade-off rather than implying a free lunch.
- ›The triple-point / melt regime is flagged as a v1.5 boundary. Below it the constant-ice sublimation path is exact; the melt transition is marked honestly rather than silently extrapolated.
open source under MIT OR Apache-2.0 — the engine, the validation records, and this console all live at github.com/ElroyAyala/Frostline.