New feature: Conics and orbital math support

[aaronfranke]

See https://en.wikipedia.org/wiki/Conic_section and http://www.braeunig.us/space/orbmech.htm

• A conic section has a variable amount of eccentricity. 0 means a circle, >0 and <1 means an ellipse, 1 means a parabola, and >1 means hyperbola. <1 eccentricity means that the shape is "closed", but >=1 eccentricity means that the shape has diverging endpoints.

• A conic section should also have a way to define their size. This is typically done with defining the semi-major axis.

It may make sense to separate the above features from the below ones, since we could implement both 2D and 3D conics. The above features apply to 2D and 3D conics equally.

Of course, like all objects, conics will need a position. This must be defined by one of the focal points, which is the center in the case of the circle, but not on an ellipse, and parabolas have no "center".

Conic sections also need to have an orientation.

• In 2D, you'd only need one angle.

• In 3D, this is typically done by defining the longitude of the ascending node (the point at which the conic section rises above a reference plane), the inclination of the shape to the plane at that point, then the angle between the ascending node and a specific point on the conic section (typically the periapsis). See the below image. Even if we decide to use Quaternions, there should be methods for working with 3D conic section orientation using this math.

Conic sections should have a way to sample points around them, perhaps by providing an angle, and returning a position. However, for orbits, the relationship between angle and time is not linear, so it would be nice to provide a time and get a position. Also, for usage with orbits, it would be nice to have a way to provide the position & velocity of an object, and the gravity of the body it's orbiting, to return a conic section and its current position along it.

The class hierarchy could look something like this:

• IOrbit (interface with gravity, time functions)
• ConicBase (basic math, eccentricity and size, could be abstract)
  • Conic2D (2D position and angle)
    • Orbit2D (implement IOrbit)
  • Conic3D (3D position and orientation)
    • Orbit3D (implement IOrbit)

[JohanLarsson]

I have never had a need for this but that does not mean it cannot be a good fit for the library.

[mehmetakbulut]

I'm all for having native support for conic sections (not sure what this "support" should look like) but, as an aerospace engineer by training, I don't think orbital propagation is a good fit for the library (simply because this is too specialized). I have done this with my own library written on top of Math.NET Numerics and Spatial. To assist such endeavors, time would be better spent on expanding and maturing the built-in Quaternion functions, more integrators/solvers etc..

Most of what you want are solved with Keplers equations fundamentally. Two capabilities are necessary for such a simulator: conversion between Cartesian and Keplerian elements given mu (i.e. G*(m+M)) and propagation of Keplerian elements over time (via integrators because there is no analytical solution to Kepler's equations). For example, if you are building a simulator, you don't want the orbital definition to be an interface because of boxing it will become useless for high frequency / high number of objects. (i.e. most scientific purposes) Additionally you have to make application-specific tradeoffs to implement these "two capabilities". Propagation is super simple for a 2-body point-particle system but is non-trivial for n-body and/or volumetric objects. Based on how you implement propagation, conversion between Cartesian and Keplerian elements also become non-trivial since Keplerian elements describe a very idealized orbit in 2-body system.

To understand the effort required to properly do this, please take a look at General Mission Analysis Tool by NASA: https://sourceforge.net/projects/gmat/
The C++ source code is Apache licensed and mostly well modularized (i.e. great to be used as a reference implementation). This should show that to do this in the most generalized manner (i.e. without crafting for a specific application), it would take significant effort that is better spent on expanding core capabilities rather than adventuring into domain-specific simulation features.

[jkalias]

I think that trying to expand Spatial, so that orbital mechanics are properly covered, is beyond the scope of the library.

However, I do think that providing support for basic geometric primitives would definitely be something work investigating. In your case it seems to me that what you basically need as a building block is the concept of an ellipse. Then you could use Spatial to suit your custom needs. This could also help other people who are in need of support for elliptical shapes.

Based on #200 I wouldn't add a separate 2D and 3D case, but a general purpose (3D) case directly. However since this is a big braking change, it might take some time to implement.

Let me know that you think of this.