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

Is your feature request related to a problem? Please describe.
I would like to calculate the forward, backward azimuths between two geodetic coordinates.
There are additional geodesic operations available via geographic lib that would be useful to expose:
https://geographiclib.sourceforge.io/C++/doc/classGeographicLib_1_1Geodesic.html
https://geographiclib.sourceforge.io/C++/doc/classGeographicLib_1_1GeodesicLine.html

Describe the solution you'd like
C++ and python functions to solve the forward and inverse problem in Geodetic coordiantes

Describe alternatives you've considered
Currently this is done by using pyproj in python.

Describe the bug
In the Python bindings, the Earth gravity/atmosphere models can take the type as a kwarg, which makes it nice to be clear about the input arguments:

from ostk.physics.environment.atmospheric import Earth as EarthAtmos
atmos = EarthAtmos(
    type=EarthAtmos.Exponential
)

However, for the magnetic model, passing the type as a kwarg throws an error.

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

from ostk.physics.environment.magnetic import Earth as EarthMag
mag = EarthMag(
    type=EarthMag.Undefined
)

Expected behavior
The constructor should work in Python whether the type is passed in as an arg or kwarg.

Potential suggestion
Use the Gravity/Atmosphere model code as a reference. The inconsistency is likely in the Python bindings.

To automatically download/manage data files when needed.

Setting SPICE, IERS, and EARTH managers to "Automatic" throws an error on epehm downloads when creating a new Environment.:

os.environ["LIBRARY_PHYSICS_COORDINATE_FRAME_PROVIDERS_IERS_MANAGER_MODE"] = "Automatic"
os.environ["LIBRARY_PHYSICS_ENVIRONMENT_EPHEMERIDES_SPICE_ENGINE_MODE"] = "Automatic"
os.environ["LIBRARY_PHYSICS_ENVIRONMENT_GRAVITATIONAL_EARTH_MANAGER_ENABLED"] = "true"

The same error is thrown even if given a path to empty folders:

os.environ["LIBRARY_PHYSICS_ENVIRONMENT_EPHEMERIDES_SPICE_MANAGER_LOCAL_REPOSITORY"] = "./library/spice"
os.environ["LIBRARY_PHYSICS_COORDINATE_FRAME_PROVIDERS_IERS_MANAGER_LOCAL_REPOSITORY"] = "./library/iers"
os.environ["LIBRARY_PHYSICS_ENVIRONMENT_GRAVITATIONAL_EARTH_MANAGER_LOCAL_REPOSITORY"] = "./library/earth"

Is your feature request related to a problem? Please describe.
We pull the manifest file from remote every single time we need to access data. This is so we can check the age of any local data against what's on the remote to know if we need to update anything.

This is way overkill. We can pull the manifest like once per day and be fine. Implement a manifest age concept so we don't have to constantly do IO.

Is your feature request related to a problem? Please describe.
After trying to add python bindings for the physics::data::Scalar class (which currently lacks them) in OSTk physics, I have deemed that much harder than it seems on the surface because.

Context on the cpp side for OSTk physics:

• There is lots of convoluted code deep down inside of physics::Unit, which would take a non-trivial amount of time to modify if needed
• the tests for physics::Unit are weak, and the tests for physics::unit::Derived are non-existant (which is scary because we use physics::unit::Derived in a lot of places in astro
• the tests for data::Scalar and data::Vector and data::Direction are non-existant
• all derived units should be defined inside of physics::Unit, not as the Thrust and SpecificImpulse and MassFlowRate ones are currently defined inside of PropulsionSystem

Context on the python side for OSTk physics

• physics::Unit, physics::data::Scalar, physics::data::Vector, and physics::data::Direction are not bound to python at all as classes, and in order to add bindings to physics::data::Scalar, you need to add bindings to physics::Unit, which is not trivial at all due to the aforementioned convolutedness of physics::Unit
• if data::Scalar and data::Vector were to be bound to python, cpp tests would need to be added for them as well, which would again take time

Context on how the above relates to OSTk astro:

• ostk::physics::Unit is only used in two places in OSTk astro (AtmosphericDragDynamics (not at the API level) and PropulsionSystem (indeed at the API level)
• data::Scalar is only used in PropulsionSystem and data::Vector is used nowhere in OSTk astro
• SatelliteSystem, dynamics, and propagation all do their computations and store their variables in unitless Reals or VectorXds

Describe the solution you'd like
To address this, we will need a complete overhaul of the unit system in OSTk, by either a) completely removing it, b) replacing it with templated compile-time unit checking or boost::units

Is your feature request related to a problem? Please describe.
The data managers all have the same copy-pastad repository lock/unlock functions. These can be moved to a shared function specification to aid maintainability.

Is your feature request related to a problem? Please describe.

The DateTime class can parse strings, but only two formats.

This works:
2018-01-02 12:34:56.123.456.789

But this doesn't:
2018-01-02 12:34:56.123.456.789+0000

Additionally, it cannot parse isoformat like:
2018-01-02T12:34:56.123456789Z

I don't think we need to make datetimes timezone-aware, but being able to parse the +0000 case would be really convenient by itself.

Describe the bug
A clear and concise description of what the bug is. Describe if the bug appears in the cpp code, in the bindings, if it affects the unit tests, the compilation steps. Provide the versions of the library that are used in your setup or the hash of the images used (if any).

Steps to reproduce

• Set system time to a time zone other than UTC, run the following code block
• note how ostk_instant has an unexpected offset from the utc datetime object even when printed with utc time

import datetime
from ostk.physics.time import  Instant, Interval, Scale
from ostk.physics.time import DateTime
dt = datetime.datetime(2024, 4, 19, 0, 0, 0, tzinfo=datetime.timezone.utc)
ostk_instant = Instant.date_time(dt, Scale.UTC)

print(dt)
print(dt.astimezone(tz=datetime.timezone.utc))
print(ostk_instant.to_string(Scale.TT))
print(ostk_instant.to_string(Scale.UTC))

Example output of the bug:

Don't hesitate to add screenshots if that helps.

Expected behavior

Additional context
Setting system time to UTC fixes the issue

Potential suggestion
Issue is likely here (from Lucas) https://github.com/open-space-collective/open-space-toolkit-physics/blob/main/bindings/python/src/OpenSpaceToolkitPhysicsPy/Time/DateTime.cpp#L79

In Python, trying to import celestial bodies other than Earth seems to fail:

Indeed, neither Moon nor Sun shows up in the list of attributes:

Describe the solution you'd like
So that we can autodocumentation in sphinx that leverages those docstrings, just like we do for OSTk astro

Is your feature request related to a problem? Please describe.
When defining an Earth gravity model, we have a required directory/aDataDirectory argument. This argument is meant to allow defining gravity model files manually. (e.g. the data underlying the EGM2008). If the argument is set to Undefined, OSTk will manage the files automatically.

In 99% of cases, we pass in Directory::Undefined(). Being required to do this every time is a pain (and looks kinda ugly).

Describe the solution you'd like
We should allow this to be optional, and default it to Undefined. Either by converting existing constructor to make the aDataDirectory argument optional, or adding a new constructor without it.

Is your feature request related to a problem? Please describe.
Currently, in the Instant class we print to stdout with the TT Scale, which while appropriate, can be confusing to users, when they've inputted it in a different frame.

Describe the solution you'd like
We should log in UTC as that is the most widely used.

Describe alternatives you've considered
Alternatively, we can track the Scale the instant was created with and log in that scale.

Describe the bug

From a list compiled by Dhruv Jain

1.	OTSK Physics:
1.	https://open-space-collective.github.io/open-space-toolkit-physics/html/index.html
1.	Documentation >> Python >> 404
2.	Tutorials >> C++ >> 404
3.	Tutorials >>Python >> 404
4.	Contribution >> Contributing guide >> blank

1.	README
1.	Documentation >> Python >> 404
2.	Tutorials >> C++ >> empty folder
3.	Tutorials >> Python >> empty folder

For an unavailable time period from the SPICE kernels, an unexpected {First Column} is undefined error is thrown instead of a polar motion error - which occurs for a time much later in the future.

Error is raised from LibraryMathematics

Is your feature request related to a problem? Please describe.
To configure where OSTk Data is stored, you currently have to set the path for each individual data set separately:

ENV OSTK_LOCAL_CACHE="${OSTK_LOCAL_CACHE}"

ENV OSTK_PHYSICS_DATA_MANIFEST_LOCAL_REPOSITORY="${OSTK_LOCAL_CACHE}"
ENV OSTK_PHYSICS_COORDINATE_FRAME_PROVIDERS_IERS_MANAGER_LOCAL_REPOSITORY="${OSTK_PHYSICS_DATA_MANIFEST_LOCAL_REPOSITORY}/coordinate/frame/providers/iers"
ENV OSTK_PHYSICS_ENVIRONMENT_EPHEMERIDES_SPICE_MANAGER_LOCAL_REPOSITORY="${OSTK_PHYSICS_DATA_MANIFEST_LOCAL_REPOSITORY}/environment/ephemerides/spice"
ENV OSTK_PHYSICS_ENVIRONMENT_GRAVITATIONAL_EARTH_MANAGER_LOCAL_REPOSITORY="${OSTK_PHYSICS_DATA_MANIFEST_LOCAL_REPOSITORY}/environment/gravitational/earth"
ENV OSTK_PHYSICS_ENVIRONMENT_MAGNETIC_EARTH_MANAGER_LOCAL_REPOSITORY="${OSTK_PHYSICS_DATA_MANIFEST_LOCAL_REPOSITORY}/environment/magnetic/earth"
ENV OSTK_PHYSICS_ENVIRONMENT_ATMOSPHERIC_EARTH_MANAGER_LOCAL_REPOSITORY="${OSTK_PHYSICS_DATA_MANIFEST_LOCAL_REPOSITORY}/environment/atmospheric/earth"

This can very cumbersome, and if you miss any, the ones you miss are set to a default location. I don't think I've ever seen a situation where they needed to be different.

Describe the solution you'd like
One environment variable to rule them all. OSTK_PHYSICS_DATA_LOCAL_REPOSITORY

This will set all of the OSTk data locations to the given path. However, if any of the above specific env vars are set, they should override this one.

Only reduced (sub-metric) precision has been tested... could (should) be improved.

In LLA.test.cpp:

• Library_Physics_Coordinate_Spherical_LLA.ToCartesian
• Library_Physics_Coordinate_Spherical_LLA.Cartesian