We have been encountering a problem while executing this code

new KeplerianOrbit(15000, 1, 0, 0, 0, 0, PositionAngle.MEAN, FramesFactory.getTOD(false), new AbsoluteDate(2000, 01, 01, 01, 01, 01, TimeScalesFactory.getUTC()), Constants.WGS84_EARTH_MU);

It goes in an endless loop while resolving the kepler equation : it is stucked in KeplerianOrbit.eMeSinE().
We are aware that this orbit is inconsistent but in our use case, orbital parameters come from an external source with possible unexpected set of parameters.
We could ensure consistency of orbital parameters before invoking orekit library but still, we would like to share this problem, if you confirm it is? If so, it should have ended into an OrekitException?

This is an exactly parabolic orbit, with eccentricity equal to 1.0, so it lies exactly at the
boundary between elliptical and hyperbolic orbits.
We check for consistency between elliptical/hyperbolic by testing if a * (1 - e) < 0, because
a classical convention is that hyperbolic orbits have a negative semi major axis, and hence
we should have either a > 0 and e <1 or a < 0 and e > 1. Here … e = 1 exactly.

In the KeplerianOrbit constructor, once consistency has been checked, we use the sign of a
to select elliptical or hyperbolic equations. Here, since a > 0 we use the elliptical equations.
These equations have convergence problems near e = 1 and seem not to converge at all
when e = 1.

I don’t know if we should add a special case for exact parabolas (1.0 is an exact representation,
all integers with magnitude less than 10^15 having an exact representation in IEEE754 double
precision, so equality test here is possible), or if we should enforce parabolas to be
treated as hyperbolas (I don’t know if the equations converge properly there), assuming that
if e = 1 we overwrite a with -FastMath.abs(a).

A parabola is a possible orbit (a weird one, but a possible one), so throwing an exception just
at the boundary between two perfectly acceptable domains would be weird to me.

Maybe an acceptable compromise could be to add a “watchdog” around the equations ? This would allow to detect convergence issues instead of enforcing pre-conditions on the inputs ? All cases that converge properly would continue to do so, but cases that do not converge (the one that Anne-Laure identified, and potentially others unidentified cases as well) would result in a proper exception after a given number of iterations without reaching convergence.

Right now, a user can cause an infinite loop in the library. I believe the library should prevent that, either by refusing the operation altogether, or by breaking the infinite loop when it becomes obvious that convergence will not be achieved.

I think both approaches should be applied.
Of course endless loop, for whatever reason it occurs, is a major issue. It could even be considered a security issue in the sense wrong input parameters could freeze a server, resulting in a DOS attack. So I am +1 to add a (large) maximum number of iterations, say 100 or 1000 and an exception once it is exhausted.

However, properly handling parabolic orbit is also something to consider. For operational cases, you never hit exactly this eccentricity, but in made up test cases or in students workn this specific eccentricy may arise (and it did arise in Anne-Laure case).

I am with @luc on this one. To me a parabolic trajectory is unnatural but it is an excellent test case (specific energy is null) for a variety of scenarios. Would a maximum number of iterations and a check on specific energy be agreeable? I am afraid that there might some use cases other than parabolic where the number of iterations alone might be reached.
Regards,
BU