Looking at this display of conic sections: conic.jpg (1280×720) (bp.blogspot.com)
it seems to be a straightforward matter of “tilting” the cross section as a function of delta v.

I’m not an astrodynamicist, but I think what you may be missing is the fact that there’s no simiple analytical way to transition from a given elliptical orbit to a different type of conic trajectory of a spaceship relative to a not-entirely-spherical earth, with other non-uniform dynamic effects.

You are correct that the issue of whether some conic section is an ellipse or a parabola or a hyperbola depends only on the angle of intersection between the cutting plane and the axis of the cone. But the issue here, AFAICT, is that you’re on a specific elliptical path at a given time and you need to determine the characteristics of the non-elliptical path that will get you to your chosen splashdown point.

As in, you REALLY REALLY need to determine that path’s characteristics as accurately as possible, because that’s all you’ve got to tell you exactly when and in what direction to fire your thruster, or whatever, to minimize your landing distance from the chosen splashdown point. You probably do not want to be hanging around in the ocean for the time it takes for a recovery ship to come get you from hundreds of miles away, for example.

“Iteration procedure” is mathematician-speak for “The exact analytical solution to this problem is either analytically impossible in theory or a total beast to implement in practice, but fortunately we have a simpler formula that gives us an approximate answer that gets more and more accurate the more we repeat the calculation.”

The trajectory that the presenter in your second video draws (at about 4:20) certainly is neither a simple ellipse nor a parabola. Without knowing any of the details or the physics behind it, I can certainly believe that it would be described by differential equations that cannot be solved analytically but can have solutions approximated by Euler’s method.

For what it’s worth, I have the book Hidden Figures for Kindle but have not yet read it. But I was able to do a little searching, and there’s nothing in the book about Euler’s method or differential equations or parabolic trajectories.

One bit that bugged me about that scene is that of course everyone in that room would have already been intimately familiar with Euler’s method, as it’s the most fundamental and straightforward method for numerically solving differential equations. I suspect (though I haven’t read any of the source material) that Johnson’s big revelation was that, with the use of the new electronic computer, it was possible to use Euler’s method with a much smaller stepsize, and hence much greater accuracy, than was practical with human computers using mechanical adding machines.

I would think that for the precision required, a more advanced method for numerically solving differential equations would be warranted, assuming it had to be calculated by hand. Sure, Euler’s method involves less calculation per step, so you can use a smaller step, but the classical Runge-Kutta method is far more accurate and I’d think that it doesn’t require all that many times more calculations as Euler’s method needs more steps to be accurate, or else Runge and Kutta wouldn’t have bothered.

At the very least, the existence of things like RK4 is because there was a rich history of numerical methods certainly from the early 1900s onward (and probably much earlier). And it was well-know that most ODEs don’t have closed-form solutions. Certainly the idea that one could resort to using a numerical method to get a quick and dirty approximate solution would not be an “I never thought of that” moment.

(And the idea that you’d have to pull out an old book to see how to implement Euler’s method is pretty silly, too. The method is basically “the obvious” way to discretize an ODE).

And today I just finally looked it up, and discovered that Runge and Kutta did their work circa 1900, much earlier than I’d thought. I guess that’s my modern biases showing: Nowadays, the only reason to work any numerical solution by hand is as a proof-of-concept to illustrate that it can be done, and for that, you use the simplest method, and so Euler’s method is still often implemented by hand, but higher-order Runge-Kutta methods are only ever implemented on a computer. But I suppose that when automated computing was expensive or nonexistent, and people were doing numerical calculations by hand out of necessity, the need for more efficient methods would have been even greater than it is now.

The impulsive transition from one ballistic trajectory to another will not be a conic section but an Archimedean spiral (or some close approximation). In interplanetary trajectories when transitioning from one sphere of influence (SOI) to another it is possible to use the method of patched conic approximations to get a first order estimate by hand but this cannot be used in transitions between orbits within the SOI of a single body, and there is no general closed form solution to orbital transitions.

It should be understood that in the context of the time the “computing machines” that were used had about the same level of computational ‘power’ as a cheap pocket calculator today, and lacked memory safety and error correction methods which meant that it was imperative to perform some degree of hand calculation to validate the algorithm. and verify the numerical results. The Runge-Kutta methods of order 4 and greater are quite powerful but computationally intensive and difficult to perform reliably by hand, while Euler’s method is quite obvious and easy to check. The real downside to Euler’s method is that it tends to have larger error with too large of a step size, particularly with ‘stiff’ differential equations, but it is easy to implement and validate, and computationally preferable on such a primitive system. Although the scene in the film milks great drama about the “revelation” of applying Euler’s method (which would have been evident to anyone who had studied calculus and basic differential equations), I believe Johnson’s actual insight was how to determine the appropriate step size for the calculation to minimize error down below some threshold.

Today, of course, if you were doing numerical integration for an approximate solution for a differential equation you’d use an implicit Runge-Kutta method drawn from a standard library like IMSL, QUADPACK, or SciPy, and you probably wouldn’t spare a thought for the reliability of the algorithm (although you should because even if the method is reliable the application may not be correct). But to implement a method manually in some early version of FORTRAN that could be validated by hand, Euler’s method makes perfect sense.

I’m sure GBS methods have some dedicated applications and it is listed in Numerical Recipes in C (albeit with caveats that it is not ideal for functions that are discontinuous or have singular points in the integration interval) but I have literally never seen it in use, and a quick look through Novak and a half a dozen other modern texts on numerical methods and optimizaation don’t mention it. Most ODE solvers that are widely available tend to default to general linear methods that are some variety of Runge-Kutta methods (like Gauss-Legendre), or linear multistep methods, and in practice most people who are directly implementing an integration scheme into their code almost always use some flavor of Runge-Kutta because they are straightforward to implement, easy to use with adaptive step size, and any computational inefficiency is generally not the main bottleneck anyway.

But again, if I were trying to approximate some trajectory transition in FORTRAN II on a 7000-series IBM mainframe circa 1962, I’d stick with a straightforward Euler method algorithm. Even for a machine of that era, this isn’t a particularly challenging calculation; it probably took longer to actually compile the program than to run through the calculations, and you could output enough of the calculations to spot-check and make sure it wasn’t giving you garbage. Frankly, you could do that problem by hand if you had a week and a big roll of butcher’s paper, and frankly with the variability in the primitive control systems on the Atlas SLV and Mercury capsule any solution you get is going to be way more accurate than the precision in measuring orbital elements and execute transfers anyway.

OK, my assumption was that it was all being done by hand, and that Runge-Kutta was developed specifically to be done by hand, since it vastly predated electronic computers, and thus if you were doing them only by hand and wanted as high of a precision as you could get for a given effort, you’d use RK or something else developed since then. If they were actually using the electronic computers available at the time (I assumed they were far too weak to be useful for this task), then certainly programming them with Euler’s method with a small step size would likely have been a safer route than the more complex calculations and memory space needed for RK.