lunar-joint-od-clock (scenario kind)

Scenario kind of the engine v0.38.0, family Lunar and cislunar. Advisory: analysis output from a research and engineering tool, not type-approved navigation equipment and not a safety-of-life service. Every label here is the engine's or the verification matrix's; a kind is MODELLED unless the matrix says otherwise (how a label is earned: the README's Evidence section).

What it does#

Modelled joint multi-technique lunar OD + clock batch estimator on a SIMULATED network: a Gauss-Newton snapshot fit that fuses Earth-baseline geodetic VLBI delays, lunar-local station↔satellite ranges and inter-satellite ranges to recover, together, a lunar surface station's 3-D position, a small constellation's positions and every asset's clock offset from an injected truth. The headline honest result — VLBI makes the station's full 3-D position observable where lunar-local ranging alone leaves a weakly-observed direction — is reported as the with-vs-without-VLBI station-error contrast. MODELLED simulated closed-loop recovery (truth shares the observation model), deterministic (seeded), NOT real-data validated; no force-model propagation inside the solver; no TRL/heritage/agency endorsement.

One run of scenarios/lunar-joint-od-clock.toml summarises as: lunar-joint-od-clock | 3 sats, 6 Earth stations | station 3-D err with VLBI 3.54 m vs range-only 2184.02 m (617.5× sharper) | sat pos RMS 2.20 m | station clk err 2.87e-10 s | obs 40/16 params

Inputs#

From the schema (kshana kinds --json):

• Required fields: none
• Optional fields: n_sat, n_earth, seed, sigma_vlbi_s, sigma_range_m, sigma_isl_m, station_lat_deg, station_lon_deg, station_alt_m, orbit_radius_km, sigma_clock_s, orbit_ecc, orbit_inc_deg, orbit_argp_deg, orbit_planes, epoch_year, epoch_month, epoch_day

The example scenarios/lunar-joint-od-clock.toml sets, among others:

Run it#

kshana scenarios/lunar-joint-od-clock.toml

What it gives#

The scalar results of that run, with the units the engine states:

Evidence#

No matrix row names this kind by name; the label on its result is the engine's own, above.

The rows the run itself exercised, with the oracle the matrix gives each (the public sources are named there):

• MODELLED Deterministic, scenario-hashed, SBOM + cross-platform golden gates. Oracle (ExternalDataset): SBOM conformance to the official CycloneDX 1.5 JSON Schema (+ valid SPDX identifiers) — an external published standard, zero validation errors over the full dependency graph; the FoM-determinism / byte-reproducibility part remains a pinned self-consistency check, so the row stays MODELLED
• VALIDATED Batch fusion of VLBI + lunar-local range + inter-sat range to recover station+constellation positions and clocks. Oracle (ExternalDataset): P2: numpy 2.4.6 (numpy.linalg.lstsq with LAPACK gelsd, numpy.linalg.inv; BSD-3) recomputes each Gauss-Newton step, the converged weighted-least-squares solution, the formal sigmas and the station error on the committed Jacobians and observations of six simulated networks, pre-registered (5094bc31) at max(1e-8, 100 kappa eps) relative. The first run failed the no-VLBI network (6.1e-7 against 1e-8, a normal-equation in
• VALIDATED Fisher information M=HᵀWH, Cramér–Rao lower bound, observability rank / datum-defect null space (Moore–Penrose pseudo-inverse), and D/A/E/T-optimal experiment-d. Oracle (ExternalDataset): NumPy 2.4.1 (numpy.linalg.eigh / .inv; BSD-3-Clause, LAPACK-backed) — an independent third-party authority computing the same uniquely-defined eigenvalues, σ²(XᵀX)⁻¹ Cramér–Rao covariance and GNSS dilution-of-precision factors by a different algorithm (LAPACK divide-and-conquer + LU) than Kshana's cyclic-Jacobi sweep and spectral pseudo-inverse; matched to 1e-9. The same external-library class already validates the D
• MODELLED Fisher-information observability of the joint lunar solve: without Earth baselines the absolute-frame datum lies in the null space of HᵀWH (station position uno. Oracle (InternalConsistency): Analytic datum-defect structure — the unobservable absolute-frame mode lies in the null space of the Fisher information (closed-form), the rank threshold matches the published 3-station design rationale, and the estimator attains the resulting CRLB in Monte-Carlo. The lunar geometry itself is a representative network (not a flown ephemeris), so the row stays MODELLED; the underlying FIM/CRLB engine is checked against

Limitations#

What the run's own report says is not modelled or not validated:

• MODELLED simulated closed-loop recovery (truth shares the observation model), deterministic (seeded), NOT real-data validated; no force-model propagation inside the solver; no TRL/heritage/agency endorsement. (kind catalogue (kshana kinds --json))
• Honesty: MODELLED simulated closed-loop recovery. An injected truth is mapped to synthetic observables through the SAME geometry model the solver inverts, seeded Gaussian noise is added, and the estimator recovers the injected truth within the noise. The oracle is internal consistency (truth recovery + NEES covariance realism), NOT real-data validation. There is no force-model propagation inside the solver — the sate (scenario file comment, lines 24 to 29)
• Reproducibility & software assurance is MODELLED, not validated: a sub-claim is externally checked, but the whole capability composes modelled pieces, so the capability stays Modelled. (verification matrix (docs/MODELLED-RATIONALE.md))
• Lunar absolute-station observability (datum defect) is MODELLED, not validated: checked against its own closed-form / analytic identity — catches transcription and coefficient errors, but is not an external oracle. (verification matrix (docs/MODELLED-RATIONALE.md))

See also#

• Family page: Lunar and cislunar
• All kinds: KINDS.md