Near-parabolic (e ≈ 1) cometary→Cartesian conversion produces wildly wrong states

[KatKiker]

Summary

CometaryCoordinates.to_cartesian() fails badly for near-parabolic orbits (e ≈ 1). This is a pre-existing defect, independent of the non-gravitational work on PR #201, surfaced during its review.

Reproduction (verified 2026-08-04, branch codex/nongrav-support @ 9c06eec)

1. query_sbdb_new(["C/2022 E3"]) (e ≈ 1.00022, q ≈ 1.11 au, epoch MJD 59873 — ~84 days before perihelion) yields a Cartesian state at |r| = 30,401.7 au. The true heliocentric distance at that epoch is ~2.3 au.

2. The defect is in the converter, not the SBDB importer. Feeding clean JPL osculating elements directly:

elems = CometaryCoordinates.from_kwargs(
    q=[1.11238], e=[1.00022], i=[109.169], raan=[302.555], ap=[145.533],
    tp=[59956.18],  # perihelion 2023-01-12
    time=Timestamp.from_mjd([59873.0], scale="tdb"), ...,
)
elems.to_cartesian()  # -> |r| = 41,725.7 au

3. The Cartesian→cometary roundtrip is also broken at this eccentricity: converting back yields tp = -81,615,491 MJD.

Impact

• Any near-parabolic comet imported via SBDB/NEOCC elements gets a garbage initial state; downstream propagation is meaningless.
• Blocks claiming SBDB-elements-to-ASSIST parity for objects like C/2022 E3 or 1I/'Oumuamua. (The Horizons-anchored non-grav regressions in adam-assist deliberately start from Horizons Cartesian states to isolate force-model accuracy from this conversion path.)

Suspected area

The elliptic/hyperbolic branch selection or mean-anomaly/Kepler solve in the cometary→Cartesian path loses validity as e → 1 (a = q/(1−e) diverges). A universal-variables formulation or a dedicated near-parabolic (Barker) branch is the usual fix.

🤖 Generated with Claude Code