ENGI

science:

On September 2, 1859, the Earth witnessed the perfect solar storm. If anything on the same scale happened today, “the damage could range upwards of a $1 trillion, largely because of disruptions to the electrical grid.”

science:

Maybe you’re all tired of articles about the moon landing, but I found this description of the sheer dumb luck involved in the moon lander’s computer making a successful descent fascinating:

Allan’s descent program needed a routine to accurately estimate the new thrust level, which could be accomplished by reading the “delta-V” (change in velocity) measured by the LM’s accelerometers. He wrote a short routine that took into consideration, i.e., compensated for, the engine’s lag time, which TRW’s “interface control document,” full of useful information for the programmers, said was 0.3 seconds. It took 0.3 seconds for the LM’s descent engine to achieve whatever thrust level the computer might request. The final version of the thrust routine, which was put into the LM, was written by Allan’s friend Don Eyles. Eyles was sufficiently enthusiastic about the programming challenge that he found a way of writing it which required compensating for only 0.2 of the 0.3 seconds. The IBM 360 simulator showed Eyles’ program worked beautifully. His routine was aboard Apollos 11 and 12 which landed successfully. However, telemetry transmitted during the landings later showed something to be very wrong. The engines were surging up and down in thrust level, and were barley stable. A guy at Johnson Space Center called Allan and informed him that the LM’s engine was not a 0.3-second-lag engine after all. It had been improved some time before Apollo 11’s launch such as to lower the lag time to only 0.075 seconds. Correction of this item in the interface control document had simply been overlooked. Once this discrepancy was discovered, the IBM 360 simulator was reprogrammed to properly simulate the actual, faster engine. Running on the simulator, Don Eyle’s thrust program, with the 0.2-second compensation, exhibited the surging that had occurred on the real flights. But here’s the most interesting fact: the simulator also showed that had Allan Klumpp chose to “correct” Don Eyles’ program by compensating for the full 0.3 seconds that was printed in the document, the LM would have been unstable and Apollo 11 would never have been able to land. By pure luck, Don Eyles was creative enough to write the thrust routine in a way that kept the LM just inside the stability envelope and allowed successful landings!

Allan’s descent program called “P64” periodically computed a polynomial function to describe the optimum descent trajectory. This polynomial would smoothly merge the LM’s current position and velocity vectors into the target point position and velocity vector. The “target point” for P64 was just above the landing point (When the LM reached the target point with a small vertical descent rate, P64 would cease execution and the landing phase would be handled by a program called “P66”). The computer would then make the LM fly the trajectory, which would be recomputed every 2 seconds. An opportunity for disaster presented itself here. Many sci.space.tech readers may know enough mathematics to understand the undesirable “wiggles” that can be generated by high-order polynomial curve fits. Under conceivable circumstances, the polynomial function computed by P64 could droop down, go beneath the lunar surface, rise out of the surface, then descend to the target point! If such a trajectory were computed during a real landing, and the LM were allowed to follow it, the LM would crash. There was no logic coded in to detect this situation and prevent it. No programming solution was ever found. An example scenario where this disaster could have happened follows. If the LM was off course, away from the terrain model stored in the computer, and flying over a deep crater, the landing radar would fool the computer into thinking the LM was higher relative to the mean surface than it previously assumed. This could cause a newly computed polynomial trajectory to “droop” down sharply, unintentionally intersect the real lunar surface, then rise back out of the surface, inviting the LM to crash! Allan said this problem could also be caused by an astronaut retargeting the landing point beyond the fuel range.