Orekit Space Flight Dynamics Library

Orekit is a comprehensive library for space dynamics, providing high-fidelity tools for several key domains:

• Time: High accuracy absolute dates, multiple time scales (TAI, UTC, GPS, etc.), and leap second handling.
• Geometry: Hierarchical frames (fixed and time-dependent), predefined frames (ICRF, ITRF, etc.), and extensible central body shapes.
• Spacecraft State: Support for Cartesian, Keplerian, circular, and equinoctial parameters, TLEs, and Walker constellations.
• Covariance: Propagation, transformation, and interpolation of covariance matrices.
• Maneuvers: Analytical, impulse, and continuous maneuver models.
• Propagation: A unified interface for analytical (Kepler, SGP4, etc.), numerical (gravity models, drag, radiation pressure), and semi-analytical (DSST) models.
• Attitude: Extensible evolution models and predefined laws (nadir pointing, spin-stabilized, etc.).
• Orbit Determination: Batch least squares, Kalman filtering (EKF, UKF), and various initial orbit determination methods.
• GNSS: DOP computation, RINEX file handling, and Ntrip protocol support.
• Earth Models: Atmospheric, tropospheric, ionospheric, and geomagnetic models.
• Collisions: 2D probability of collision computing (e.g., Patera 2005, Laas 2015).
• Data Loading: Flexible loading from local disk, classpath, or network, with support for compressed formats.

Orekit supports four primary orbital representations via the org.orekit.orbits package. Choose the representation based on the eccentricity and inclination of the orbit you are modeling:

1. Keplerian Orbit: Classic elliptical representation. Supports both elliptical and hyperbolic orbits using semi-major axis (a), eccentricity (e), inclination (i), argument of periapsis (ω), right ascension of the ascending node (Ω), and an anomaly (v, M, or E).
2. Circular Orbit: Used for orbits with low eccentricity. Uses semi-major axis (a), eccentricity vector components (ex, ey), inclination (i), right ascension of the ascending node (Ω), and a longitude argument (αv, αM, or αE).
3. Equinoctial Orbit: Used for orbits with both low eccentricity and low inclination. Uses semi-major axis (a), eccentricity vector components (ex, ey), inclination-related components (hx, hy), and longitude arguments (λv, λM, or λE).
4. Cartesian Orbit: Represents the state using position (X, Y, Z) and velocity (Vx, Vy, Vz) vectors within a specific frame.

Note: Two-Line Elements (TLEs) are not considered a standard orbit representation in Orekit because they are inextricably linked to the SGP4/SDP4 propagation model.

In Orekit, an Orbit is an immutable data holder representing the kinematical state of an object at a specific date and within a specific frame. It is not a propagator; for orbit evolution, you must use the Propagator interface.

Key characteristics of Orbit objects:

• Immutability: All orbit classes are guaranteed to be immutable. You do not need to perform defensive copying.
• Frame Awareness: Every orbit is tied to a defining frame (must be a pseudo-inertial frame). This allows for transparent conversions to other frames (e.g., converting from EME2000 to a ground station frame) using methods like getPVCoordinates(Frame).
• Pragmatic Parameter Access: Certain parameters are available across different representations for computational convenience. For example, the semi-major axis getA() and position/velocity getPVCoordinates() are available even if the orbit is not in a Cartesian representation.
• Central Body Acceleration: All orbits include a value for µ (the acceleration coefficient of the central body), which is used for parameter representation and conversion.

Orekit employs a two-stage testing lifecycle to ensure accuracy and prevent regressions:

1. Validation Phase: When a new feature is implemented, developers create validation tests. These tests compare implementation results against external reference values (from papers or other software) or check behavior against different mathematical models (e.g., comparing finite differences with algorithmic differentiation).
2. Non-regression Phase: Once an implementation is validated, tests transition into non-regression tests. In this phase, output results are saved as reference values with an intentionally very small tolerance (often far below the actual physical accuracy of the model, e.g., micrometer level).

This strict tolerance ensures that any future code evolution that changes computed values—even by a tiny amount—will trigger a test failure, forcing a human review to determine if the change is a legitimate improvement or a regression.

The ImpulseManeuver models an instantaneous velocity change ($\Delta V$). It is implemented as an EventDetector that triggers a state reset (Action.RESET_STATE) to update the spacecraft velocity.

Compatibility

• Supported: Analytical, semi-analytical, and numerical propagators.
• Unsupported: TLE propagators or ephemeris-based propagators (because they forbid state resets).

Configuration

• Trigger: You can use any EventDetector to trigger the maneuver. Common choices include:
  • DateDetector: For maneuvers at a specific known date.
  • NodeDetector: For inclination maneuvers at orbital nodes.
  • PositionAngleDetector: For circularization maneuvers at apogee.
• $\Delta V$ Vector: Defined in the spacecraft frame. It is converted to the inertial frame using the propagator's attitude or a specific AttitudeProvider override.
• Mass Update: Uses the specific impulse to update the spacecraft mass during the event.