perf: simplify third body gravity calculation (#707)
- perf: reduce per-step allocation overhead in the propagation loop
Two hot-loop cleanups on the astrodynamics side of numerical propagation, with no public API change and bit-identical numerical results:
Dynamics::DynamicalEquations: reuse a per-context scratch buffer for the reduced read state instead of heap-allocating a fresh VectorXd for every dynamics at every derivative evaluation. The buffer lives in the Dynamics::Context copies bound into the system-of-equations wrapper (per-propagation), not in the shared Dynamics objects.
NumericalSolver::integrateTime(State, Instant, …): defer construction of the observed State objects (one per accepted integration step) until accessObservedStates()/getObservedStates() is actually called, and build them from a const reference to the underlying solver’s observed state vectors instead of a by-value copy. Propagator::calculateStateAt no longer pays for building thousands of State objects nobody reads; Segment and other consumers get identical states, built lazily.
Measured (Release, EGM96 10x10 + PositionDerivative, RK4 fixed 5 s):
- loop overhead (PositionDerivative-only, 17,280 steps): 1.05 -> 0.78 us/step
- derivative-evaluation glue with 5 dynamics: 0.222 -> 0.173 us/eval
- 1-day propagation: ~991 -> ~950 ms, 7-day: ~4.76 -> ~4.65 s (medians of 3 interleaved A/B runs); final states bit-identical to baseline
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
- perf: avoid body-frame rotation round trip in ThirdBodyGravity
ThirdBodyGravity::computeContribution evaluated the third body’s gravitational field twice via Celestial::getGravitationalFieldAt, each call rotating the query position into the body’s own ephemeris-attached frame (a full SPICE sxform_c lookup for SPICE-backed bodies) and then rotating the resulting acceleration back out via inFrame. For a point-mass (spherical) gravitational model, the field does not depend on the body’s orientation, so this rotate-in/rotate-out round trip is pure overhead: the same result can be obtained from the body’s position alone (Celestial::getPositionIn, a pure translation lookup) combined with mu (Celestial::getGravitationalParameter) via the closed-form two-term third-body formula, with no per-call orientation lookups.
Since ThirdBodyGravity accepts an arbitrary Shared, nothing guarantees the attached model is point-mass (e.g. a higher-fidelity spherical-harmonics model could be attached). A new private static helper, IsPointMassGravitationalModel, dynamic_casts the Celestial’s gravitational model to Spherical (the generic point-mass model) or to Sun/Moon/Earth with their respective Type::Spherical (their only non-orientation-dependent type); this is computed once at construction and cached. The fast path is only taken when this positively identifies a point mass; otherwise computeContribution falls back unchanged to the original two-call getGravitationalFieldAt + inFrame path, so behavior is unaffected for any other configuration.
Standalone micro-benchmark (Release, unique instants per call): Sun (SPICE): 17.5 -> 15.5 us/call (
12% faster) Moon (SPICE): 19.3 -> 17.1 us/call (12% faster) Sun (analytical ephemeris): 9.9 -> 7.4 us/call (25% faster) Moon (analytical ephemeris): 10.6 -> 8.2 us/call (22% faster)Added tests verifying the fast path numerically matches the generic path for Sun::Default/Moon::Default/Sun::Analytical/Moon::Analytical, and a test with a synthetic non-spherical (WGS84) third body proving the generic fallback path is genuinely exercised.
Co-Authored-By: Claude Fable 5 noreply@anthropic.com
- feat: leverage new celestial method
Co-authored-by: Claude Fable 5 noreply@anthropic.com
版权所有:中国计算机学会技术支持:开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
Open Space Toolkit ▸ Astrodynamics
Orbit, attitude, access, mission analysis.
Getting Started
Want to get started? This is the simplest and quickest way:
Nothing to download or install! This will automatically start a JupyterLab environment in your browser with Open Space Toolkit libraries and example notebooks ready to use.
Alternatives
Docker Images
Docker must be installed on your system.
iPython
The following command will start an iPython shell within a container where the OSTk components are already installed:
Once the shell is up and running, playing with it is easy:
By default, OSTk fetches the ephemeris from JPL, Earth Orientation Parameters (EOP) and leap second count from IERS.
As a result, when running OSTk for the first time, it may take a minute to fetch all the necessary data.
Tip: Use tab for auto-completion!
JupyterLab
The following command will start a JupyterLab server within a container where the OSTk components are already installed:
Once the container is running, access http://localhost:8888/lab and create a Python 3 Notebook.
Installation
C++
The binary packages are hosted using GitHub Releases:
open-space-toolkit-astrodynamics-X.Y.Z-1.x86_64-runtimeopen-space-toolkit-astrodynamics-X.Y.Z-1.x86_64-developen-space-toolkit-astrodynamics-X.Y.Z-1.x86_64-pythonDebian / Ubuntu
After downloading the relevant
.debbinary packages, install:Python
Install from PyPI:
Documentation
Documentation is available here:
Structure
The library exhibits the following detailed and descriptive structure:
Tutorials
Tutorials are available here:
Setup
Development Environment
Using Docker for development is recommended, to simplify the installation of the necessary build tools and dependencies. Instructions on how to install Docker are available here.
To start the development environment:
This will:
openspacecollective/open-space-toolkit-astrodynamics-developmentDocker image.bashshell from the./buildworking directory.If installing Docker is not an option, you can manually install the development tools (GCC, CMake) and all required dependencies, by following a procedure similar to the one described in the Development Dockerfile.
Build
From the
./builddirectory:Tip: The
ostk-buildcommand simplifies building from within the development environment.Test
To start a container to build and run the tests:
Or to run them manually:
Tip: The
ostk-testcommand simplifies running tests from within the development environment.Script
To build an executable for a simple script:
scriptsdirectory.ostk-buildto build the executable, which will be found in the in/binfolder under the nameopen-space-toolkit-astrodynamicsExample:
Benchmark
To run benchmarks:
Benchmarks are pushed to the GitHub pages.
Validation
OSTk has a cross-validation framework built into it (inside the
/validationfolder), which allows us to compare its end-to-end propagation accuracy of a full “mission sequence” to other flight qualified tools like GMAT and Orekit.Scenario Definition
A standardized input format (a yaml file) to define the particular mission sequence scenario is used, and is tooling agnostic. An example of it is shown below.
spacecraftheaderCross Validation and Accuracy Tolerances
The validation framework takes this yaml scenario definition (from the
/validation/data/scenariosfolder) and runs the scenario using OSTk. Next, it compares the specified outputs (quantities like the position, velocity, mass, acceleration of the spacecraft) at the desired reporting step generated by OSTk with each external validation tool (whose outputs were generated via the same process and are in the/validation/data/gmat_astrodynamicsor/validation/data/orekit_astrodynamicsfolder as.csv), to ensure they are within a certain tolerance of each other.To add a scenario:
.yamlformat above, and name itscenarioX-mission-sequence.yaml, and put it in wth the others. If the format isn’t correct or there is another issue, OSTk will throw an error when validating..csvoutputs from the external tools you want to compare OSTk against (repos with an GMAT and Orekit wrapper that can ingest this.yamlformat do exist and will be open sourced soon).Framework.validation.cppfile, with the scenario name, the tool to compare against, and the output quantities and comparison tolerances for those. An exampe of this is provided below.Running the Validation Tests
The validation tests can be run with
ostk-validatefrom within the dev container, ormake validationas a standalone.Dependencies
2.10.10.6.03.3.72020-07-13thirdparty/vallado-sgp4)2.5.01.8.20.4.1mainmainmainmain⚠️ Until OSTk#183 is implemented, the fork of
cesiumpymust be installed separately in order to use theviewermodule. It is not specified as a dependency ofostk-astrodynamics.Contribution
Contributions are more than welcome!
For the contributing guide, please consult the CONTRIBUTING.md in the open-space-toolkit base repo here.
Special Thanks
License
Apache License 2.0