Right now plotting functions and visualizations use Plots, which is great, but there should also be Makie integration.

There is likely an issue with the orbit orientation parameter calculations in CanonicalOrbit(::CartesianOrbit). Is 2 * pi - ... the correct calculation?

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

# Make orbit
r = [0.0, 11681.0, 0.0] * u"km"
v = [5.134, 4.226, 2.787] * u"km/s"
orbit = Orbit(r, v, Earth)

# Propagate 1000 seconds
kepler(orbit, 1000u"s"; max_iter=100000)

Returns: NaN error. This works if tol and max_iter are set accordingly.

This should return a user friendly answer to the user.

Submodules should include...

• Module for handling abstract orbit types
• Module for handling bodies
• Module for handling two-body problem
• Module for handling n-body problem

• I horribly misunderstood how isapprox operates
• atol defaults to 0, so x \approx 0 is equivalent to x == 0
• All of the isapprox checks I make through the Cartesian / Keplerian transform functions are likely not needed

• Should solve Kepler's problem for all conic in the two body problem
• Should use universal variables
• Should converge quickly (<10 iterations)

• Should work for an arbitrary number of bodies

Trajectories could be better!

Right now, they're just Vectors of Orbit structures. This could be so much better for many reasons, including lots of memory allocation necessary to get a high degree of precision for trajectory calculations, and more.

Ideas for Improvement

• Allow for returning ODESolution structures from propagate with a odesolution=Val{true} switch, and manually add methods for applying astrodynamics calculations

I don't like that solution. Is there another?

OrbitalTrajectories.jl

While watching Julia-related talks online, I found the OrbitalTrajectories.jl talk. Turns out OrbitalTrajectories also uses DifferentialEquations for propagating orbits (no surprises there). What is interesting is that the ODESolution object is returned directly from the propagation. That allows for interpolating by epoch, and access to DifferentialEquations helper methods.

Conclusion

• The Trajectory design by OrbitalTrajectories is far more robust. This should be the default, and a simple Vector of Orbit structures should be available via vec=Val{true}

• Add circularize function

• Add Hohmann function

• Add eccentricity change function

• Add semi major axis change function

• Add common simultaneous orbital element change function

• New package name should be UnitfulAstrodynamics.jl

Add custom show functions for each data structure.

The twobody propagation result produced by propagate has an invalid perifocal state at start. The second step appears to be fine.

• Add CanonicalToCartesian orbit transformation

• Add CartesianToCanonical orbit transformation

• Plots and Propagators should be their own, separate submodules
• Add unit test files for each submodule in Astrodynamics

• Add initial unit tests (possibly using PS1 cases)

An incorrect calculation is in CanonicalOrbit(::CartesianOrbit): true anomoly's conditional is incorrect. The condition should check if dot(r_vec, v_vec) > 0.

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

• Separate common equations from conic-specific equations

• Remove ::TwoBodyState calculation function calls from CartesianState(::KeplerianState) and KeplerianState(::CartesianState) to avoid circular references in the future

• While we're at it... remove CartesianState and KeplerianState - the states should track in the background, always

• Change helper functions to target TwoBodyOrbit

• Pick a ...Orbit and ...State design and stick with it, damnit!

That's all for now, but there's definitely a lot more that can be improved.

Change to a more functional-styled design. Data structures should have the minimum necessary information to reconstruct any related value.

Check if two-body equations change based on conic section. If so, Orbit types should be parameterized by conic sections so we can dispatch accordingly.

The first cut at GeneralAstrodynamics.jl contained many submodules.
Now, all substantial portions of GeneralAstrodynamics.jl's v0
functionality has been added to the following external packages.

1. AstrodynamicalModels.jl
2. AstrodynamicalCalculations.jl
3. AstrodynamicalSolvers.jl

New packages have also been independently developed and released,
including the following.

1. SPICEKernels.jl
2. SPICEApplications.jl
3. SPICEBodies.jl
4. HorizonsAPI.jl
5. HorizonsEphemeris.jl

Moving forward, GeneralAstrodynamics.jl should simply tie together
all of the functionality provided by the above packages. This is also
a good opportunity to release v1!

• Non-dimensionalization
• Re-dimensionalization
• Propagation
• All calculation functions
• Zero Velocity Curves

Is your feature request related to a problem? Please describe.
Both orbit data structures are not iterable, and need to be unit stripped and parsed before they can be used in solvers. As a result, the propagation functions strip units and parse, and return all data twice: one copy with units, and the other without.

Describe the solution you'd like
All structures should be ComponentArrays, and should be iterable for solvers with units. The arrays should be explicitly typed so the solver calls are still fast.

CR3BP, R2BP, and NBP orbits all have the same fields,r, v to represent some Cartesian position with respect to something. This should be standardized.

The motivation for this issue is some ideas I have for ephemeris wrappers. At first, I outputted TwoBodyState instances from the ephemeris files. But this isn't always valid! I'd like to use ephemeris for CR3BP, 2BP, and NBody analysis, as well as CR3BP and 2BP patched conics. So I should just output some Cartesian state that's valid across all modules.

Or maybe I should export Body instances?

Let's see what this turns into!

• Currently only Earth and the Sun are supported, but I should add:

1. Mercury
2. Venus
3. Moon
4. Mars
5. Jupiter
6. Saturn
7. Uranus
8. Neptune
9. Pluto

That's all for now, maybe I can add some interesting non-Earth moons as well in the future.

• Implement Lambert's problem with universal variables (as shown in Vallado's textbook)

• This is literally what Val is for!
• This will remove the ugly typeof(lengthunit) calls

Users should be able to do this!

Tools

AstroLib

• Integrated?
• AstroLib has a lot of useful routines for space navigation, and variables for information about solar system bodies
• Right now, GeneralAstrodynamics uses its own variables for solar system planets, and CelestialBodies – maybe we should use tools provided by AstroLib instead

• User should be able to enter ?orbital_period in the Julia REPL, and see all two-body orbital_period equations written out (not just the arguments).

• Add Documentor.jl documentation
• Host on GitHub Pages

• 3d position

• Scalar magnitude position, velocity

• Energy, angular momentum

• Orbital element deviations

• Energy, angular momentum deviations

• 2d position

Some plotting functions, e.g. Plots.plot(::Manifold...), don't use recipes! This is bad.

The new v0.10 re-write is way faster than v0.9, but somehow v0.09 was always type stable and v0.10 functions are nearly always type unstable.

This needs to be fixed!