Re: SDP4 Algorithm

ROB MATSON (ROBERT.D.MATSON@cpmx.saic.com)
27 Mar 1997 16:30:43 -0800

Hi Bruno,

You wrote:

"A more fundamental fix to this problem, which might occur in more places of
the code, is to replace the ACTAN function by the function ATN2 which, if it
doesn't already exist in the programming language used, can be written
in such a way as to always yield a result in the range 0... 2*pi. That's what
I have done about 5 years ago."

Actually, Rainer has since realized he was mistaken about the ACTAN business. 
ACTAN is not an intrinic function, but a user-defined function included with
Spacetrack Report #3.  It's an ugly function as coded there, but it works,
returning values from 0 to 2*Pi.  It is the ACTAN implementation in the PASCAL
version (that I believe T.S. Kelso coded) that is flawed (it doesn't always
return values from 0 to 2*Pi).

But this ACTAN function is completely unnecessary.  I never coded it.  As you
pointed out, every decent programming language has a 2-argument arctangent
function that is quadrant-preserving.  For my FORTRAN, it's ATAN2(Y,X), where
Y is the sine of the angle, and X is the cosine.  It returns values from -pi
to +pi.  A simple change will return values from 0 to 2*pi:

Angle = Pi - ATAN2(-Y,-X)

Not surprisingly, they got rid of the ACTAN function In Spacetrack Report #6. 
And the coding of the deep space routines in SR #6 contain some of the very
code fixes we've come up with for SR #3.  But the coding in even SR #6 is
flawed.  Some time in the next few days, I expect to be perhaps the first
person ever to be running an implementation of SDP4 *as it was originally
designed by R.S. Hujsak and Felix Hoots*.  I can tell you that anyone running
SDP4 based on SR #3 is getting the wrong results.  They may seem accurate most
of the time, but the solar/lunar perturbations are not correctly accounted
for.  (They should be zero at epoch, and aren't).  --Rob