Design Line features a reminiscence of Jack Crenshaw about Calculating trajectories for Apollo program. This was an effort in the early 60’s in the Theoretical Mechanics Division at NASA, at Langley Research Center.
In those days, we didn’t have spreadsheet programs to draw graphs for us; we had to draw them ourselves. As low man on the TMD totem pole, I got elected to run parametric studies on the computer and plot the results. That task worked in my favor, though, because I gained an understanding of the physics of the problem and the relationship between parameters that I don’t think I would have gotten, otherwise. I wasn’t content to just make runs and plot curves; I wanted to UNDERSTAND what was going on, and I think that put us ahead of the Rand guys
The way to use a computer was to define a program to be written for the coders who implemented it in IBM 702 assembler. That would generate numbers which needed “desk checking” to make sure the program was working as intended. Then the numbers would be manually plotted to created graphs for analysis.
Generating a lunar trajectory is not easy. The problem is a two-point boundary-value problem, complicated by the fact that both points (the launch and return sites) are fixed on a rotating Earth, and we have the “minor” midpoint constraint that the trajectory come somewhere near the Moon. We quickly learned that simply trying to guess at suitable launch conditions was a hopeless venture. Therefore a large part of my energies went into building quite a number of patched-conic approximations, programs to solve the complicated spherical trig, front-end and back-end processors, and “wrappers” for GE’s N-Body program. My crowning achievement was a fully automated program that required only the barest minimum of inputs, such as the coordinates of the launch and landing points, plus a few other things such as year of departure, lunar miss distance, and lighting conditions at both the Moon and Earth reentry. The program would then seek out the optimal, minimum-energy trajectory that would meet the constraints.
To handle these calculations, the computers ran at the equivalent of about a 1 MHz clock with a 32K working memory. They did have hardware floating point capabilities and word lengths up to 60 bits which allowed for some serious number crunching. Batch mode, highly optimized assembly code, and no distractions made it work.
Those were the days – but kind of like realizing that modern toilet paper has a history of only 150 years or so – it certainly provides a perspective on how things have changed in this era.
Post a Comment