Python interface for mission design and orbit determination

[ChristopherRabotin]

High level description

Note: Thomas Anthony has a done a lot of work on this, cf. https://gitlab.com/nyx-space/nyx/-/issues/217 .

Me: How about for a project that uses Nyx as package? How would you organize that? ChatGPT:

my_project/
  |-- data/
  |     |-- ground_stations.yaml
  |     |-- measurements.csv
  |-- src/
  |     |-- main.py
  |     |-- propagation.py
  |     |-- od.py
  |     |-- plotting.py
  |-- requirements.txt
  |-- setup.py
  |-- LICENSE
  |-- README.md

The data directory would hold any input data that the project needs, such as the ground station definitions and the measurement data.

The src directory would hold the source code for the project. In this example, there are three modules: propagation.py which propagates the orbit, od.py which sets up and runs the orbit determination process, and plotting.py which generates plots for a report. The main.py file would act as the entry point of the project and would use these modules to complete the desired tasks.

The requirements.txt file would hold the dependencies for the project, including Nyx. The setup.py file would define how to install the project and its dependencies.

The LICENSE and README.md files would contain the license and documentation for the project, respectively.

Human: this looks good to me, with the addition of the SPICE files in the data folder. There also needs to be a results folder to store the outputs.

Requirements

(Generic requirements)

• Nyx should provide a clear and concise API for interacting with its features, such as orbit propagation, orbit determination, and plotting. (Human: no plotting directly, instead, export stuff in Pandas or Polars format)
• Nyx should be easy to install and integrate into existing Python projects. This could involve providing clear instructions on how to install Nyx using common package managers such as pip, and providing clear import statements for accessing Nyx's functionality.
• Nyx should be well-documented, with clear examples and explanations of how to use its features. This could involve providing extensive documentation on Nyx's website, as well as inline documentation within the package itself.
• Nyx should be tested and validated to ensure that it produces accurate and reliable results. This could involve providing a suite of unit tests to verify the correctness of Nyx's algorithms, as well as providing validation cases that can be used to compare the output of Nyx with known-good results.
• Nyx should be actively maintained and supported by its developers. This could involve providing regular updates and bug fixes, as well as responding to user feedback and issues raised on Nyx's GitHub page.
• All logged messages shall be redirected to the Python user, cf. https://gitlab.com/nyx-space/nyx/-/issues/221

Test plans

How do we test that these requirements are fulfilled correctly? What are some edge cases we should be aware of when developing the test code.

Design

This is the design section. Each subsection has its own subsection in the quality assurance document.

Algorithm demonstration

No change in algorithms.

API definition

• [x] It is important to note that PyO3 and Python do not support generics. As such, any exported structure will need to be fully concrete types. Examples of where that matter is for the propagators, which will likely need to be fixed type to a Spacecraft, ground stations (will need one ground station kind per measurement kind), and the filters (which are currently generic over state and estimated state).
• [x] Nyx will need to re-export hifitime's Python stuff. This might require keeping both hifitime and Nyx PyO3 versions in line, not sure.
• [ ] Nyx will need to re-export ANISE types.

High level architecture

Document, discuss, and optionally upload design diagram into this section.

Detailed design

The detailed design *will be used in the documentation of how Nyx works.

Feel free to fill out additional QA sections here, but these will typically be determined during the development, including the release in which this issue will be tackled.

[ChristopherRabotin]

Some observations:

1. Any large data set should be passed between Python and Rust via a Parquet file. This allows independent processing as a DataFrame both in Python and in Rust. There does not seem to be a trivial way to share such large data set in both processes without serializing it before hand.
2. All crates shall be vendored. This allows for re-exporting of the PyO3 classes from one crate to another. Specifically, ANISE and Hifitime will need to be re-exported. This means that both must use the same version of pyo3, and Nyx will need to stick with that version as well.