Typed Cartesian and equinoctial states, with conversions #26

New Issue

2026-09-30T14:29:58-04:00

connor commented

2026-09-30 14:29:58 -04:00

Keplerian elements are a typed struct but a Cartesian state is a pair of bare Vector3s, which is inconsistent. A Cartesian state should be a type, and it should carry the frame it is expressed in.

Add:

Cartesian<T> — position, velocity, and frame
Equinoctial<T> — non-singular elements, for the work Keplerian handles badly. Keplerian needs three substitutions and a Degeneracy flag because a near-circular orbit has no defined periapsis and an equatorial one no defined node; equinoctial elements have no such cases and are the right representation wherever that matters.
conversions among all three, and between each and State<T, D, L>

The frame on these is the foundation #6 builds transformations on, and it is where the central body of #21 attaches. Doing it here keeps #6 down to the transformations themselves.

Open question to settle here: whether the frame carries mu, which would remove the mu: f64 parameter from every conversion. ANISE's Frame has an optional mu_km3_s2, so it can, but the optionality makes conversions fallible. Our own body type with a non-optional mu avoids that, which argues for folding #21 in.

Keplerian elements are a typed struct but a Cartesian state is a pair of bare `Vector3`s, which is inconsistent. A Cartesian state should be a type, and it should carry the frame it is expressed in. Add: - `Cartesian<T>` — position, velocity, and frame - `Equinoctial<T>` — non-singular elements, for the work Keplerian handles badly. Keplerian needs three substitutions and a `Degeneracy` flag because a near-circular orbit has no defined periapsis and an equatorial one no defined node; equinoctial elements have no such cases and are the right representation wherever that matters. - conversions among all three, and between each and `State<T, D, L>` The frame on these is the foundation #6 builds transformations on, and it is where the central body of #21 attaches. Doing it here keeps #6 down to the transformations themselves. Open question to settle here: whether the frame carries `mu`, which would remove the `mu: f64` parameter from every conversion. ANISE's `Frame` has an optional `mu_km3_s2`, so it can, but the optionality makes conversions fallible. Our own body type with a non-optional `mu` avoids that, which argues for folding #21 in.

connor added this to the M1 milestone 2026-09-30 14:29:58 -04:00

connor added the size/M label 2026-09-30 14:29:58 -04:00

connor referenced this issue

2026-09-30 14:29:58 -04:00

Reference frames #6

connor referenced this issue

2026-09-30 14:29:59 -04:00

Planetary bodies instead of bare mu #21

connor commented

2026-09-30 16:10:11 -04:00

Done in b089b20 (Cartesian, Body, Frame) and 1f02cac (Equinoctial).

Cartesian<T> carries position, velocity and frame
Equinoctial<T> with from_cartesian/to_cartesian implemented directly through the equinoctial basis, not routed through Keplerian
conversions among all three, and each to and from State<T, D, L>

The open question is settled: the frame carries mu, via our own Body with a non-optional one rather than ANISE's Option<mu_km3_s2>, so no conversion is fallible and no signature takes a mu. #21 folded in for that reason.

Worth remembering from the equinoctial work: the published basis formula uses the opposite h/k convention to this type, and applying it as written gives an orthonormal, right-handed basis normal to the wrong plane. It round-trips through itself perfectly and is only caught by cross-checking against the Keplerian path.

Frame transformations remain #6. Whether State should carry a frame is #27.

Done in b089b20 (Cartesian, Body, Frame) and 1f02cac (Equinoctial). - `Cartesian<T>` carries position, velocity and frame - `Equinoctial<T>` with `from_cartesian`/`to_cartesian` implemented directly through the equinoctial basis, not routed through `Keplerian` - conversions among all three, and each to and from `State<T, D, L>` **The open question is settled: the frame carries `mu`**, via our own `Body` with a non-optional one rather than ANISE's `Option<mu_km3_s2>`, so no conversion is fallible and no signature takes a `mu`. #21 folded in for that reason. Worth remembering from the equinoctial work: the published basis formula uses the opposite `h`/`k` convention to this type, and applying it as written gives an orthonormal, right-handed basis normal to the *wrong plane*. It round-trips through itself perfectly and is only caught by cross-checking against the Keplerian path. Frame *transformations* remain #6. Whether `State` should carry a frame is #27.

connor closed this issue

2026-09-30 16:10:11 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: connor/astrokit#26