The calculation of KeplerianElements needs to be checked for special cases

[szabolcsvelkei]

Describe the bug Excrept from wiki (https://en.wikipedia.org/wiki/Longitude_of_the_ascending_node) For non-inclined orbits (with inclination equal to zero), omega is undefined. For computation it is then, by convention, set equal to zero; that is, the ascending node is placed in the reference direction, which is equivalent to letting n point towards the positive x-axis.

To Reproduce Spacecraft with this statevector:

 StateVector testOrbit = new StateVector(
     new Vector3(0, 6700000, 0),
     new Vector3(7900, 0, 0), earth, start, frame);

AscendingNode and ArgumentOfPeriapsis values are NaNs. testOrbit.ToKeplerianElements().ToStateVector() is far from the original if Position.Z=0

Expected behavior Correct calculation of Keplerian elements from StateVectors and vice versa.

[sylvain-guillet]

Hello @szabolcsvelkei, in case of orbit in equatorial plane ascending node and argument are strictly undefined this is why you have these values. But I understand this can be annoying for computations. In the literature sometimes convention are defined but 0 for these values is not always used, for example some communities use AOP = 90° for circular orbit... I need to think about what conventions I should apply globally to the framework for special cases. I'll keep you informed

[sylvain-guillet]

@szabolcsvelkei I've applied convention for singularities in release v3.0.4. Now you should have these values :

• A=7045497.0180164594
• E=0.049037990809302601
• I=3.1415926535897931
• AN=0.0
• AOP=4.7123889803846897
• M= 0.0

The AOP could appear counter-intuitive but this is due to the retrograde property of your orbit.

I converted back keplerian elements to state vector and they are identical.

Tell me if it's good for you ?

[szabolcsvelkei]

Tested with various scenarios in 3.0.4. The results are perfect.