Spacetrack Report #3 questi

ROB MATSON (ROBERT.D.MATSON@cpmx.saic.com)
11 Apr 1997 15:12:42 -0800 

Hi Curtis,

Have been meaning to reply to you regarding the message you sent Bruno (and
cc'd me on).  Bruno has probably answered some if not all of your questions by
now, but if not, perhaps my answers will help.  First, you wrote:

"But here is the real question: why do the FORTRAN versions fail on the test
case?  Rob Matson does his work using Lahey FORTRAN, and and as he has shown
us, the unmodified code can fail.  ...  I find it very hard to accept that the
code in Spacetrack Report No. 3 really is flawed, so I decided to check it out
for myself. ..."

It's flawed.  By now that's probably obvious to you.  The Air Force didn't
catch the error because it's well-hidden.  And only a very specific test case,
such as the one I devised, will demonstrate the effect of the bug in a
dramatic fashion.

You went on to write:

"What does not make sense is that the FORTRAN code (as posted by Kelso)
fails, but his Trakstar program does not.  Kelso converted the FORTRAN
code to PASCAL for that project.  So if his PASCAL code came from the
FORTRAN, why doesn't it fail too?"

He made a few changes in the code when he converted it to PASCAL.  His changes
don't elliminate the bug -- they merely shift it.  Trust me -- his PASCAL
version fails just like the FORTRAN does; it just occurs at a slightly
different time. This has been confirmed by multiple users of Trakstar.

Continuing:

"To further complicate the situation, in at least one place the FORTRAN
code in SPACETRK.FOR differs from the code printed in my photocopy of
Spacetrack Report No. 3 (from NTIS).  On page 76 of the printed copy
you will find, in subroutine DEEP:

*     ENTRANCE FOR DEEP SPACE SECULAR EFFECTS

      ENTRY DPSEC(XLL,OMGASM,XNODES,EM,XINC,XN,T)
      XLL=XLL+SSL*T
      OMGASM=OMGASM+SSG*T
      XNODES=XNODES+SSH*T
      EM=EO+SSE*T
      XINC=XINCL+SSI*T
      IF(IRESFL .EQ. 0) RETURN
  100 IF (ATIME.EQ.0.D0)    GO TO 170

But the corresponding section in SPACETRK.FOR from Kelso has added code
(marked below):

*     ENTRANCE FOR DEEP SPACE SECULAR EFFECTS

      ENTRY DPSEC(XLL,OMGASM,XNODES,EM,XINC,XN,T)
      XLL=XLL+SSL*T
      OMGASM=OMGASM+SSG*T
      XNODES=XNODES+SSH*T
      EM=EO+SSE*T
      XINC=XINCL+SSI*T
      IF(XINC .GE. 0.) GO TO 90            <----- Not found in printed
      XINC = -XINC                         <----- Spacetrack Report No.3
      XNODES = XNODES + PI                 <----- (AD A093554 from NTIS)
      OMGASM = OMGASM - PI                 <-----
   90 IF(IRESFL .EQ. 0) RETURN
  100 IF (ATIME.EQ.0.D0)    GO TO 170

As you surmised, the additional lines of code have no effect on the bug in the
Lyddane modification section of the code.  It's merely meant to handle the
near-zero inclination case.  There is a page in my spiral bound copy of
Spacetrack Report #3 that explains the extra 4 lines.  Basically it's an
ERRATA page.  The page reads as follows:


CODE MODIFICATION FOR SUBROUTINE DEEP

EFFECTIVE FOR APRIL 1983 RELEASE OF SCC

1.  Following line 6, add the following line:

COMMON /C2/ DE2RA, PI, PIO2, TWOPI, X3PIO2

2.  Following line 297, add the following four lines:

IF(XINC  .GE.  0.) GO TO 90
XINC = -XINC
XNODES = XNODES + PI
OMGASM = OMGASM - PI

3.  Modify line 298 to become statement label 90.

- - - - -

You also asked if anyone else besides Kelso tried to type up the source code
directly from the report (or have all the unclassified FORTRAN versions of
SDP4 really originated from Kelso's code)?  I, for one, typed in the code
myself from the hardcopy.  The primary reason I did is that I had no choice. 
I *only* had a hardcopy back in 1987, so typing it in was my only option. 
Quite a nightmare considering that zeroes and ohs were indistinguishable in
the listing, and my photocopy wasn't a very good one.  Kelso must have had the
same problem reading the report -- just look at some of his variable names. 
Many have "ohs" that should be zeros.  Of course, as long as you are
consistent with your variable names, it won't cause any problems.

Next question:

"(2) Did Kelso make any *additional* changes when he converted to PASCAL?"

Yes.

"If so, then conversions originating from Kelso's PASCAL code might exhibit
different behavior than those that started with the FORTRAN."

Correct.  My Lyddane-bug test case is a good example.  "Different" behavior,
but still wrong behavior.  And at the risk of repeating myself, let me remind
you that the Lyddane bug is just ONE problem.  There are other problems in the
deep-space routines that were fixed in Spacetrack Report #6.  But Spacetrack
Report #6 still has the Lyddane-section bug.  --Rob