Calculating trajectories for Apollo program
The required angular momentum, translated to velocity at the distance of the Moon, works out to be around 600 f/s. This should not be altered if we expect to achieve the kind of grazing entry required for a manned mission. Suppose, however, that we design an orbit that leaves the Moon with zero velocity. Then it should reenter the Earth, with a vertical entry--fatal for astronauts, but not for instruments. Even if our errors impart as much as 600 f/s of unplanned velocity, we will still enter the Earth's atmosphere and land, somewhere. If you don't care where, this peculiar class of trajectories allows one to fly to the Moon and back, even with the crude guidance of the old Scout. Of course, the mission never flew, so the trajectory is now nothing more than a footnote to space history. But an interesting one, nevertheless.
In 1961 I moved to General Electric in Philadelphia, where they had landed a study contract for Apollo and were also planning to bid on the hardware contract. I was responsible for all the generation of nominal trajectories for those efforts. I did similar stuff for lunar missions that never flew or flew with radically altered plans; the names of projects Surveyor and Prospector come to mind.
I think I did some of my very best work at GE. 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.
I was also asked to study the problem of returning from the Moon to the Earth. Thanks to my experience with approximate methods, I knew exactly how to do this: Give the spacecraft a tangential velocity of about 600 f/s, relative to the Moon. From that desired end, it's fairly easy to figure out what sort of launch one needs at the Moon's surface. We generated quite a number of trajectories, both approximate and exact, that effected the Moon-to-Earth transfer. As far as I know, they were the first such studies ever done.
During this same period, I was developing a method for computing nearly parabolic orbits. The classical two-body theory upon which all approximate methods are based has three distinct solutions, depending upon whether the orbit is elliptic, parabolic, or hyperbolic. The equations for the elliptic and hyperbolic cases all go singular for an eccentricity of one. Unfortunately, that's exactly the kind of orbits involved in translunar missions. It drove both the computers and their programmers crazy, trying to solve problems so close to a singularity. I developed a set of power series solutions based on Herrick's "Unified Two-Body Theory." Though Herrick's original formulation was unsatisfactory (his functions required two arguments), it was a rather short step to replace them by new functions that used only one argument. Between 1961 and 1963, I published quite a number of papers on these functions, most of them internal to GE and widely distributed within NASA. I was also busily putting them to work in trajectory generators. Unfortunately for me, I never managed to get credit for them; you'll find them today in astrodynamics texts, called the Lemon-Battin functions.