Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orbit analysis of celestial bodies #3493

Open
eggrobin opened this issue Dec 31, 2022 · 1 comment
Open

Orbit analysis of celestial bodies #3493

eggrobin opened this issue Dec 31, 2022 · 1 comment

Comments

@eggrobin
Copy link
Member

eggrobin commented Dec 31, 2022

We have been aware that this needed to be done for years, but it appears we never got around to filing an issue.

Analysing the orbit of the Earth about the Sun would be necessary in order to automatically compute the MeanSun that would need to be passed to get information about the relation between an Earth orbit and the Sun (such as heliosynchronicity).

OrbitGroundTrack::ForTrajectory(primary_centred_trajectory,
*primary,
/*mean_sun=*/std::nullopt);
// TODO(egg): mean solar times of the nodes.

It is a little bit embarrassing that the mod that automatically figures out what kind of orbit you are in and makes heliosynchronous orbits physically possible is incapable of recognizing those orbits:

[21:35]lpg: there's a very high chance that principia's orbit analyzer recognizes SSOs
[22:42]Stupidisco: SSO?
[22:43]test_account: Sun-synchronous_orbit
[00:12]egg: sadly it does not; we would need to analyse the orbits of celestials for that, which we never got around to.
[00:14]lpg: I demand my money back
[00:15]Al₂Me₆: https://notepad-plus-plus.org/news/v843-unhappy-users-edition/

There also appears to be an interest in those elements directly; I came across this question on reddit: https://www.reddit.com/r/RealSolarSystem/comments/zeiz87/orbital_elements_principia/.


The only thing here that isn’t just a matter of plugging APIs into each other is that the analyser currently really wants a discrete trajectory.

Given that the analyser mostly computes integrals, this is silly; it ends up having hand-rolled trapezoidal rules everywhere:

integrals.back().ʃ_a_dt += (it->a + previous->a) / 2 * dt;
integrals.back().ʃ_h_dt += (it->h + previous->h) / 2 * dt;
integrals.back().ʃ_k_dt += (it->k + previous->k) / 2 * dt;
integrals.back().ʃ_λ_dt += (it->λ + previous->λ) / 2 * dt;
integrals.back().ʃ_p_dt += (it->p + previous->p) / 2 * dt;
integrals.back().ʃ_q_dt += (it->q + previous->q) / 2 * dt;
integrals.back().ʃ_pʹ_dt += (it->pʹ + previous->pʹ) / 2 * dt;
integrals.back().ʃ_qʹ_dt += (it->qʹ + previous->qʹ) / 2 * dt;
ʃ_Mt_dt += (Mt + previous_Mt) / 2 * dt;
ʃ_ut_dt += (ut + previous_ut) / 2 * dt;
ʃ_Ωt_dt += (Ωt + previous_Ωt) / 2 * dt;

We could use our ODE integrators, or perhaps some of the fancy quadratures that we developed for the experiments with [Kud07] as part of #2400. This could also improve the performance of the analyser.

@eggrobin
Copy link
Member Author

eggrobin commented Mar 5, 2023

#3534 adds a factory for OrbitalElements that does not require the trajectory to have been converted to the primary-centred frame. We would like to use it in the analyser, but OrbitGroundTrack still requires a primary-centred trajectory.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant