[NASSP 8][Apollo 8] State vector propagation stuck?

STS

Well-known member
Joined
Feb 1, 2009
Messages
531
Reaction score
273
Points
78
Location
Vigo
Website
orbisondas.es
Hey guys

I am practising Apollo 8 and I think I got to a glitch. I am at GET 05:20:00 and I ran P21. However it never finishes, and State vector seems as stuck around 68:53:36 (V16N38).

I did two of the three P23 runs.

Can you check if something is wrong?

Best regards.
 

Attachments

  • P21 stuck.txt
    187.4 KB · Views: 103

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
Hey guys

I am practising Apollo 8 and I think I got to a glitch. I am at GET 05:20:00 and I ran P21. However it never finishes, and State vector seems as stuck around 68:53:36 (V16N38).

I did two of the three P23 runs.

Can you check if something is wrong?

Best regards.
You used "69:10:00" for your P21 time, so you are forcing it to propagate out to that point. The actual mission stalled out as well here.

007:27:43 Borman: We can't get the Program 21 to integrate up to LOI; just stalled out around 61 hours and 2 minutes.
007:57:43 Mattingly: Okay. On P21, the thinking runs that you had a slight error in your state vector at the time you started, and when that was integrated out, it intercepted the lunar surface where it locked up and this is contained in a fairly recent program note.

Post-flight analysis of their trajectory is included in the Mission Report on page 5-9. In table 5-III, the best available state vectors that resulted from a manoeuvre are calculated forward to show the expected time and altitude of closest approach to the Moon. According to this table, their current trajectory as set by their second separation manoeuvre is too fast and, if uncorrected, would swing them behind the Moon at an altitude of 848.4 kilometres. However, Mission Control are still analysing their flight path and the state vector within the spacecraft's computer is out of date. When P21 calculates it forward, it shows the flight path actually hitting the lunar surface (in a mathematical sense) whereupon, the program refuses to go on working.

Ken Mattingly's comment regarding the 'program note' might very well resonate with those readers who support any software application. Even in the 1960s, software vendors maintained documentation of known bugs and programming limitations in their products. It is often said that few if any bugs were discovered during a flight. This is perhaps quite true, but the conditions known to create problems were well documented in program notes. Procedures and mission rules were designed to avoid these problematic situations.
 

rcflyinghokie

LM Junky
Addon Developer
Joined
Jun 4, 2016
Messages
608
Reaction score
327
Points
78
Location
Colorado
There's something deeply satisfying about the number of times I've seen NASSP "bugs" on OF, in effect, marked as "WONT_FIX (bug-compatible)".
Well the nice thing about running the actual AGC software for instance is we get the actual quirks and bugs the astronauts dealt with ?
 

indy91

Addon Developer
Addon Developer
Joined
Oct 26, 2011
Messages
1,224
Reaction score
582
Points
128
Yeah, your current trajectory seems to impact the Moon and so does the AGC state vector. In the later AGC software they added a program alarm for this, alarm 430 "Orbital integration has been terminated to avoid possible infinite loop". If I change the software used for Apollo 8 to Comanche 45 (Apollo 10 CMC) then I do get that alarm instead of the infinite loop in your scenario. So they at least taught the AGC to handle this case a little bit better.
 
Top