Time from periapsis is always positive

[Stef Morojna]

I'm calculating the time from periapsis, but for some reason it always returns me a positive number.

So in this case, the calculation results correct, it gives me 5 seconds since rocket passed periapsis.

However here:

And in this case it also gives me 5 s since we passed periapsis, it should be -5 s ( or orbital period - 5), but no it gives me the absolute value.

Here is the code ( C#)

            GetStaticProperties(); // Calculates all the static parameters, like eccentricity semiMajoraAxis etc
            
            double e = _eccentricity;

			// works fine till here

			trueAnomalyAtStart = -Math.Acos( Double3.Dot(_eccV, posIn) / (e * Double3.Magnitude(posIn)) );

			print ( (Double3.Dot(_eccV, posIn)) / (e * Double3.Magnitude(posIn) ) );

			eccentricAnomalyAtStart =  2d * Math.Atan(Math.Tan(trueAnomalyAtStart / 2d) / Math.Sqrt( (1d + e) / (1d - e) ));

			anomalyToPeriapsis = (eccentricAnomalyAtStart - e * Math.Sin (eccentricAnomalyAtStart));
			// ^ this is the anomaly to periapsis, this is what I actually use in the orbit math

			timeToPeriapsis = anomalyToPeriapsis / meanMotion; // this is used just to show player time to periapsis

If anyone know what the problem is, I would really apreciate it.

Edited December 5, 2016 by Stef Morojna

[Bill Phil]

I think it's because you're solving for anomaly to Periapsis in such a way that it gives you a positive angle. Periapsis is usually angle 0, and so, if you're behind it you want a negative angle. Adding an if statement that checks the starting anomaly with respect to the Periapsis might help. I'm not familiar with C#, though. However, I don't think you need a double for eccentricity, since it's from 0 to 1 for most conics, only with hyperbolas being greater than 1. But I'm not familiar wity C#, so...

[LN400]

Seeing you use trigonometric functions, and me not knowing that programming language or the functions, have you accounted for these functions (mathematically speaking) being defined only over a 180* (pi in radians) interval?

Edited December 5, 2016 by LN400

[K^2]

As LN400 hints, your problem starts with true anomaly computation. Cos(+x) = Cos(-x), and Acos function always returns the positive result. So your true anomaly will always fall in the [0, pi] range.

This isn't a mistake, either. Based on position alone, it's impossible to tell which way the object is orbiting. Which means it's impossible to tell the difference between positive and negative anomaly. You need one more piece of information that will tell you direction of motion.

[Stef Morojna]

10 hours ago, K^2 said:

As LN400 hints, your problem starts with true anomaly computation. Cos(+x) = Cos(-x), and Acos function always returns the positive result. So your true anomaly will always fall in the [0, pi] range.

This isn't a mistake, either. Based on position alone, it's impossible to tell which way the object is orbiting. Which means it's impossible to tell the difference between positive and negative anomaly. You need one more piece of information that will tell you direction of motion.

I compute all the orbital parameters from position and velocity, so I should probably start by calculating what direction the orbit is going?

Edit: I have found out that making the "Mean Motion" positive or negative changes the direction the object orbits.

Edit2:  So aparently doing this:   MeanMotion * Math.Sign(angularMomentum.z);  solves most of the problems ( I'm not sure if this would work in 3d orbits, but it works fine for 2d)

 

10 hours ago, Bill Phil said:

 However, I don't think you need a double for eccentricity, since it's from 0 to 1 for most conics, only with hyperbolas being greater than 1. But I'm not familiar wity C#, so...

Its honestly just simpler to have all the parameters in doubles, also some extra precision never hurts.

Edited December 6, 2016 by Stef Morojna

[K^2]

There is absolutely zero reason not to use double on modern CPUs, unless you are dealing with massive arrays of numbers, where you'll be hurting for cache performance otherwise.

Absolutely always use double precision for intermediate results. It costs you nothing in performance, and can help you avoid nasty, unforeseen rounding errors. This includes trig operations and square roots, since modern compilers are good at replacing these with SIMD intrinsics, meaning you can compute these in double precision just as fast as single. The few rare exceptions on somewhat older CPUs where this can cost you an extra tick are not worth optimizing for at cost of precision.

This goes for C# as well, since JIT will convert all these trig operations to SIMD.