Giter VIP home page Giter VIP logo

open-space-collective / open-space-toolkit-astrodynamics Goto Github PK

View Code? Open in Web Editor NEW
56.0 6.0 14.0 342.32 MB

Flight profile, orbit, attitude, access.

Home Page: https://open-space-collective.github.io/open-space-toolkit-astrodynamics/

License: Apache License 2.0

CMake 2.53% Makefile 0.66% C++ 84.44% Python 11.57% Shell 0.26% Dockerfile 0.54%
space engineering toolkit astrodynamics orbit flight access trajectory attitude cpp

open-space-toolkit-astrodynamics's Introduction

Open Space Toolkit ▸ Astrodynamics

Build and Test Release Code Coverage Documentation GitHub version PyPI version License

Orbit, attitude, access, mission analysis.

Getting Started

Want to get started? This is the simplest and quickest way:

Binder

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:

docker run -it openspacecollective/open-space-toolkit-astrodynamics-development ipython

Once the shell is up and running, playing with it is easy:

from ostk.physics import Environment
from ostk.physics.time import Instant
from ostk.astrodynamics.trajectory import Orbit
from ostk.astrodynamics.trajectory.orbit.model import SGP4
from ostk.astrodynamics.trajectory.orbit.model.sgp4 import TLE

tle = TLE(
    '1 25544U 98067A   18231.17878740  .00000187  00000-0  10196-4 0  9994',
    '2 25544  51.6447  64.7824 0005971  73.1467  36.4366 15.53848234128316'
)  # Construct Two-Line Element set

earth = Environment.default().access_celestial_object_with_name('Earth')  # Access Earth model

orbit = Orbit(SGP4(tle), earth)  # Construct orbit using SGP4 model

orbit.get_state_at(Instant.now())  # Compute and display current satellite state (position, velocity)

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:

docker run --publish=8888:8888 openspacecollective/open-space-toolkit-astrodynamics-jupyter

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:

  • Runtime libraries: open-space-toolkit-astrodynamics-X.Y.Z-1.x86_64-runtime
  • C++ headers: open-space-toolkit-astrodynamics-X.Y.Z-1.x86_64-devel
  • Python bindings: open-space-toolkit-astrodynamics-X.Y.Z-1.x86_64-python

Debian / Ubuntu

After downloading the relevant .deb binary packages, install:

apt install open-space-toolkit-astrodynamics-*.deb

Python

Install from PyPI:

pip install open-space-toolkit-astrodynamics

Documentation

Documentation is available here:

Structure

The library exhibits the following detailed and descriptive structure:

├── NumericalSolver
├── Trajectory
│   ├── State
│   ├── Orbit
│   │   ├── Model
│   │   │   ├── Kepler
│   │   │   │   └── Classical Orbital Elements (COE)
│   │   │   ├── SGP4
│   │   │   │   └── Two-Line Element set (TLE)
│   │   │   ├── Tabulated (input csv)
│   │   │   └── Propagated (numerical integration)
│   │   ├── Pass
│   │   └── Message
│   │       └── SpaceX
│   │           └── OPM
│   ├── Model
│   │   ├── Static
│   │   └── Tabulated
│   └── Propagator
├── Flight
│   ├── Profile
│   │    ├── Model
│   │    │   ├── Transform
│   │    │   └── Tabulated
│   │    └── State
│   └── System
│        ├── SatelliteSystem
│        └── Dynamics
│            └── PositionDerivative
│            └── CentralBodyGravity
│            └── ThirdBodyGravity
│            └── AtmosphericDrag
├── Access
│   └── Generator
└── Conjunction
    └── Message
        └── CCSDS
            └── CDM

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:

make start-development

This will:

  1. Build the openspacecollective/open-space-toolkit-astrodynamics-development Docker image.
  2. Create a development environment container with local source files and helper scripts mounted.
  3. Start a bash shell from the ./build working 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 ./build directory:

cmake ..
make

Tip: The ostk-build command simplifies building from within the development environment.

Test

To start a container to build and run the tests:

make test

Or to run them manually:

./bin/open-space-toolkit-astrodynamics.test

Tip: The ostk-test command simplifies running tests from within the development environment.

Script

To build an executable for a simple script:

  • create a .cxx file in the scripts directory.
  • Enable the CMake BUILD_SCRIPT flag using ccmake or equivalent.
  • run ostk-build to build the executable, which will be found in the in /bin folder under the name open-space-toolkit-astrodynamics

Example:

#include <OpenSpaceToolkit/Physics/Coordinate/Frame.hpp>
#include <OpenSpaceToolkit/Physics/Coordinate/Position.hpp>
#include <OpenSpaceToolkit/Physics/Coordinate/Velocity.hpp>
#include <OpenSpaceToolkit/Physics/Time/Instant.hpp>

#include <OpenSpaceToolkit/Astrodynamics/Trajectory/State.hpp>

using ostk::mathematics::object::VectorXd;

using ostk::physics::coordinate::Frame;
using ostk::physics::coordinate::Position;
using ostk::physics::coordinate::Velocity;
using ostk::physics::time::Instant;

using ostk::astrodynamics::trajectory::State;

int main()
{
    VectorXd coordinates(9);
    coordinates << 3786681.30288918, -4897593.40751009, -2997836.66403268, 1124.5962634611, -3265.39989654837,
        6779.45043611605, 100.0, 1.0, 1.36738720713048;

    const State state = {
        Instant::Parse("2024-06-09 14:44:30.734.999", Scale::UTC),
        Position::Meters({3786681.30288918, -4897593.40751009, -2997836.66403268}, Frame::GCRF()),
        Velocity::MetersPerSecond({1124.5962634611, -3265.39989654837, 6779.45043611605, Frame::GCRF()}),
    };

    std::cout << state << std::endl;
}

Benchmark

To run benchmarks:

make benchmark

Benchmarks are pushed to the GitHub pages.

Validation

OSTk has a cross-validation framework built into it (inside the /validation folder), 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.

  • The spacecraft's parameters and initial state are defined under the spacecraft header
  • The sequence header contains the dynamic forces to be applied during propagation, the type of numerical propagator to use, and the segments (burning or coasting) to execute during the mission sequence
  • Finally, the output header contains the quantities that we want to output (in this case time elapsed, position, and velocity), and the interval at which to report them
type: MISSION_SEQUENCE
data:
  spacecraft:
    mass: 100.0
    drag-cross-section: 1.0
    drag-coefficient: 2.2
    orbit:
      type: CARTESIAN
      data:
        date:
          time-scale: UTC
          value: "2023-01-01T00:00:00"
        frame: GCRF
        body: EARTH
        x: -4283387.412456233
        y: -4451426.776125101
        z: -2967617.850750065
        vx: 4948.074939732174
        vy: -957.3429532772124
        vz: -5721.173027553034

  sequence:
    max-duration: 86400.1
    forces:
      - type: GRAVITY
        data:
          body: EARTH
          model: EGM96
          degree: 0
          order: 0
    propagator:
      type: RUNGE_KUTTA_DORMAND_PRINCE_45
      data:
        initial-step: 30.0
        min-step: 0.001
        max-step: 2700.0
        relative-tolerance: 1.0e-12
        absolute-tolerance: 1.0e-12
    segments:
      - type: COAST
        data:
          stop-condition:
            type: RELATIVE_TIME
            data:
              duration: 86400.0

  output:
    step: 120.0
    include:
      - ELAPSED_SECONDS
      - CARTESIAN_POSITION_GCRF
      - CARTESIAN_VELOCITY_GCRF

Cross Validation and Accuracy Tolerances

The validation framework takes this yaml scenario definition (from the /validation/data/scenarios folder) 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_astrodynamics or /validation/data/orekit_astrodynamics folder as .csv), to ensure they are within a certain tolerance of each other.

To add a scenario:

  1. Write a scenario definition using the .yaml format above, and name it scenarioX-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.
  2. Generate the .csv outputs from the external tools you want to compare OSTk against (repos with an GMAT and Orekit wrapper that can ingest this .yaml format do exist and will be open sourced soon).
  3. Add another test case to the Framework.validation.cpp file, 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.
{
    "scenario001-mission-sequence",  // Spherical gravity only
    {
        {
            Tool::GMAT,
            {
                {Quantity::CARTESIAN_POSITION_GCRF, 1.1e-0},
                {Quantity::CARTESIAN_VELOCITY_GCRF, 1.2e-3},
            },
        },
        {
            Tool::OREKIT,
            {
                {Quantity::CARTESIAN_POSITION_GCRF, 1.1e-0},
                {Quantity::CARTESIAN_VELOCITY_GCRF, 1.2e-3},
            },
        },
    },
},

Running the Validation Tests

The validation tests can be run with ostk-validate from within the dev container, or make validation as a standalone.

Dependencies

Name Version License Link
Pybind11 2.10.1 BSD-3-Clause github.com/pybind/pybind11
ordered-map 0.6.0 MIT github.com/Tessil/ordered-map
Eigen 3.3.7 MPL2 eigen.tuxfamily.org
SGP4 6a448b4 Apache License 2.0 github.com/dnwrnr/sgp4
NLopt 2.5.0 LGPL github.com/stevengj/nlopt
benchmark 1.8.2 Apache License 2.0 github.com/google/benchmark
Core main Apache License 2.0 github.com/open-space-collective/open-space-toolkit-core
I/O main Apache License 2.0 github.com/open-space-collective/open-space-toolkit-io
Mathematics main Apache License 2.0 github.com/open-space-collective/open-space-toolkit-mathematics
Physics main Apache License 2.0 github.com/open-space-collective/open-space-toolkit-physics

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

Loft Orbital

License

Apache License 2.0

open-space-toolkit-astrodynamics's People

Contributors

apaletta3 avatar derollez avatar etiennevincent avatar guillaumeloftorbital avatar kyle-cochran avatar lucas-bremond avatar phc1990 avatar robinpdm avatar vishwa2710 avatar vishwaloft avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

open-space-toolkit-astrodynamics's Issues

[refactor] replace all cpp class getters with accessors for consistency

Is your feature request related to a problem? Please describe.
There is a mix of getters and accessors in OSTk cpp code, which is unnecessary and adds duplicate code.

Describe the solution you'd like
We could simply refactor all OSTk cpp getters to become accessors that return const references. This will reduce the amount of boilerplate code and also allow the user to choose what they want returned either a copy (const or non-const) or a const reference. But, for ease of use in Python we map the cpp accessors to python getters.

[feat] Add dependency updating bot and script for our dockerfiles

Is your feature request related to a problem? Please describe.
Everytime we update an ostk repo and do a release we have to manually propagate that up the chain

Describe the solution you'd like
We have already installed dependabot for the pip package manager, but that doesn't update our dependencies listed in the dockerfiles. So we should

  1. Centralize all the versions of all our dependencies in a versions.env file at the root level
  2. Create a github action that can go and modify the dependencies in our dockerfile every so often and open a PR if they need to be updated

[fix] Access generation fails when using a Tabulated Orbit model

Describe the bug
There seems to be a bug in Access generation where we request the state at an instant that is beyond the end of the search interval. This is not a problem in Orbit models such as SGP4 where states can be requested at arbitrary instants.

However, this causes issues when using a Tabulated Orbit model with a fixed validity window. Requesting an Instant outside of the valid range results in an error like:
Provided instant [2024-02-01 19:30:59.620.066 [UTC]] is outside of interpolation range [2024-01-18 19:40:59.620.066 [UTC], 2024-02-01 19:30:49.620.066 [UTC].

Steps to reproduce
Steps to reproduce the behavior (add code snippets as needed):

  1. Run access generation with a Tabulated Orbit model.

Expected behavior
Access generation works for Tabulated orbit models.

Additionally, if access generation is performed on a tabulated model without sufficient data for the search interval, it would be nice to have a useful error that says there is not sufficient data.

Additional context
Fuller error log that makes me suspect the source of the issue:

Provided instant [2024-02-01 19:30:59.620.066 [UTC]] is outside of interpolation range [2024-01-18 19:40:59.620.066 [UTC], 2024-02-01 19:30:49.620.066 [UTC].

[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 0# ostk::core::error::RuntimeError::RuntimeError(ostk::core::types::String const&) at /app/src/OpenSpaceToolkit/Core/Error/RuntimeError.cpp:14
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 1# ostk::astro::trajectory::models::Tabulated::calculateStateAt(ostk::physics::time::Instant const&) const [clone .cold] at /app/src/OpenSpaceToolkit/Astrodynamics/Trajectory/Models/Tabulated.cpp:161
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 2# virtual thunk to ostk::astro::trajectory::orbit::models::Tabulated::calculateStateAt(ostk::physics::time::Instant const&) const at /app/src/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Tabulated.cpp:53
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 3# ostk::astro::Trajectory::getStateAt(ostk::physics::time::Instant const&) const at /app/src/OpenSpaceToolkit/Astrodynamics/Trajectory.cpp:92
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 4# ostk::astro::access::GeneratorContext::GetStatesAt(ostk::physics::time::Instant const&, ostk::astro::Trajectory const&, ostk::astro::Trajectory const&) at /app/src/OpenSpaceToolkit/Astrodynamics/Access/Generator.cpp:519
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 5# ostk::astro::access::GeneratorContext::isAccessActive(ostk::physics::time::Instant const&) at /app/src/OpenSpaceToolkit/Astrodynamics/Access/Generator.cpp:469
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 6# ostk::astro::solvers::TemporalConditionSolver::EvaluateConditionAt(ostk::physics::time::Instant const&, ostk::core::ctnr::Array<std::function<bool (ostk::physics::time::Instant const&)> > const&) at /app/src/OpenSpaceToolkit/Astrodynamics/Solvers/TemporalConditionSolver.cpp:144
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 7# ostk::astro::solvers::TemporalConditionSolver::solve(ostk::core::ctnr::Array<std::function<bool (ostk::physics::time::Instant const&)> > const&, ostk::physics::time::Interval const&) const at /app/src/OpenSpaceToolkit/Astrodynamics/Solvers/TemporalConditionSolver.cpp:73
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 8# ostk::astro::solvers::TemporalConditionSolver::solve(std::function<bool (ostk::physics::time::Instant const&)> const&, ostk::physics::time::Interval const&) const at /app/src/OpenSpaceToolkit/Astrodynamics/Solvers/TemporalConditionSolver.cpp:46
[ERROR] 2024-01-18 19:44:24.542 [P:1] [T:140272016541440] 9# ostk::astro::access::Generator::computeAccesses(ostk::physics::time::Interval const&, ostk::astro::Trajectory const&, ostk::astro::Trajectory const&) const at /usr/include/c++/9/bits/std_function.h:369

[feat] Improve CI

Describe the solution you'd like

  • making the release workflow conditional on the main workflow passing, before it allows you to run it
  • If there's a way to reduce the time between releasing (where github dispays a new patch) and the .deb packages actually being deployed because you can't develop on any downstream ostk repos during this time period since the dev container knows about the new tag but can't find it since it hasn't been pushed yet.

[fix] dead links in docuementation

Describe the bug

From a list compiled by Dhruv Jain

1.	OTSK Astrodynamics:
1.	https://open-space-collective.github.io/open-space-toolkit-astrodynamics/html/index.html 
1.	Documentation >>Python >> 404
2.	Tutorials >> C++ >> 404
3.	Tutorials >> C++ >> 404
4.	Contribution >> Contributing guide >> blank
5.	Dependencies >> Eigen >> http://eigen.tuxfamily.org/index.php “website seems to be down”

1.	README 
1.	Documentation >> Python >> “I do not believe the link is landing on the correct page”
2.	Tutorials >> C++ >> “sensor modelling example lacks description and comments to be easy to understand”
3.	Tutorials >> Python >> “no tutorial” -> route it to notebooks folder

Re-enable tests

The following tests have been temporarily disabled:

  • Library_Astrodynamics_Trajectory_Orbit_Models_Kepler.Test_2
  • Library_Astrodynamics_Trajectory_Orbit.SunSynchronous
  • Library_Astrodynamics_Access_Generator.AerRanges

Re-enable them and make sure they pass before releasing anything.

[fix] ostk python import error in virtual environments

Bug description

Hello! Thanks a lot for sharing this very powerful library!
OSTk dependencies work when installed in a python based docker container.

However, I get import errors when I simply pip install open-space-toolkit-astrodynamics in a python virtual environment:

> from ostk.physics.unit import Angle
Traceback (most recent call last)
  File "./ostk-project/main.py", line 1, in <module>
    from ostk.physics.unit import Angle
  File "./ostk-project/.venv/lib/python3.11/site-packages/ostk/physics/__init__.py", line 3, in <module>
    from ostk.io import *
  File "./ostk-project/.venv/lib/python3.11/site-packages/ostk/io/__init__.py", line 3, in <module>
    from ostk.core import *
  File "./ostk-project/.venv/lib/python3.11/site-packages/ostk/core/__init__.py", line 3, in <module>
    from .OpenSpaceToolkitCorePy import *
ModuleNotFoundError: No module named 'ostk.core.OpenSpaceToolkitCorePy'

Steps to reproduce

  1. Buy a macbook
  2. Create a local python virtual environment
pyenv local 3.11.3
python -m venv .venv
source .venv/bin/activate
  1. Install dependency pip install open-space-toolkit-astrodynamics==8.2.0
  2. Import ostk in a python shell
python
> from ostk.physics.unit import Angle

Expected behavior

No error when importing modules.

Additional context

I'm on Mac OS Sonoma 14.4.1

Thank you for your help!

[feat] Reduce runtime of unit tests

Is your feature request related to a problem? Please describe.
As new unit tests have been added, the CI pipeline time has greatly increased.

Describe the solution you'd like
The tests for Orbit take a significant portion as they compare analytical results for 10 days of data at a 1 minute resolution. We can reduce the resolution and total length of this dataset to speed up the tests.

Additional context

[fix] Compute accesses returns false results when the altitude is too low

Describe the bug
I've run into an issue when I (wrongly) set the altitude of a ground station at 0m instead of 13m, and got back fragmented accesses.
This is apparently a known issue, due to surface aliasing / numerical noise when the altitude is too low.

Steps to reproduce
Steps to reproduce the behavior (add code snippets as needed):
Using the function ostk.astrodynamics.access.Generator.compute_accesses
https://github.com/open-space-collective/open-space-toolkit-astrodynamics/blob/main/src/OpenSpaceToolkit/Astrodynamics/Access/Generator.cpp

Expected behavior
If the error itself cannot be solve, ensure the altitude is always high enough to avoid this problem.

Additional context
none

Potential suggestion
none

[fix] OStk Docs search function

Describe the bug
Screenshot 2024-06-10 at 1 25 37 PM

When attempting to search the docs, a javascript needs to be enabled message is displayed despite javascript being enabled.

[fix] Git can't clone on windows 11

Describe the bug
Git can't clone this repo on windows 11 because filename contains special characters : which not support on windows:

Steps to reproduce

  1. git clone git clone https://github.com/open-space-collective/open-space-toolkit-astrodynamics.git

Expected behavior
image

Additional context

related files:

test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_0.0_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_0.0_0.0_1.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_0.0_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2021-05-13T12:34:13.345_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_1015.0_0.1_1500.0_3600.0_LVLH_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_1015.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_14400.0_LVLH_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_14400.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_LVLH_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_QSW_0.0_1.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_TNW_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VVLH_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_10.0_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_7500000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_0.0_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2021-12-23T11:23:21.235_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_1015.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_14400.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_QSW_0.0_1.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_4.2_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_25.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_7200.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7000000.0_98.1_2023-01-01T00:00:00.000_115.0_1.0_150.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv
test/OpenSpaceToolkit/Astrodynamics/Trajectory/Orbit/Models/Propagated/Orekit_ConstantThrustThruster_Drag_7300000.0_98.1_2023-01-01T00:00:00.000_115.0_0.1_1500.0_3600.0_VNC_1.0_0.0_0.0_30.0_EXPONENTIAL_1.0_2.1_TRUE.csv

[fix] Re-organize python tests fixtures for clarity

Is your feature request related to a problem? Please describe.
Currently python test fixtures are imported from other files to be used in multiple tests, and this isn't the best style-wise

Describe the solution you'd like
Add an extra fixtures/ folder in the test folder and move fixtures relevant to specific classes into that folder with names for the same classes

[fix] Build Failure in FiniteDifferenceSolver Due to Eigen Matrix Explicit Constructor Initialization

Describe the bug

The bug occurs in the FiniteDifferenceSolver.cpp file, specifically when attempting to initialize an Eigen::MatrixXd object with a brace-enclosed initializer list. This operation fails due to the explicit constructor of Eigen::Matrix, which does not allow implicit conversions that would be necessary for this kind of initialization. The error is triggered at the following line:

const MatrixXd coordinatesMatrix = {coordinates};

This line attempts to copy-initialize an Eigen::MatrixXd object with a VectorXd (or similar), which is not directly supported due to the explicit nature of the Eigen::Matrix constructor. The error message provided by the compiler points out that the chosen constructor is explicit in copy-initialization, referencing the explicit constructor declaration in the Eigen library's Matrix.h file.

The issue stems from a misunderstanding or oversight regarding Eigen's initialization requirements, leading to a build failure when attempting to compile the FiniteDifferenceSolver.cpp source file.

Steps to reproduce

  1. Fork and clone the repository.
  2. Start the dev environment in container: make start-development
cmake ..
make

Screenshot of the error message:
Screenshot from 2024-02-06 00-38-08

Potential suggestion

To resolve this issue, directly construct the MatrixXd object using a method that Eigen supports for converting or initializing from a VectorXd. If the intent is to create a matrix where coordinates are column elements then update to:
const MatrixXd coordinatesMatrix = coordinates;
If supposed to be a row in the matrix then:
const MatrixXd coordinatesMatrix = coordinates.transpose();

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.