by Bryan Rasmussen

Many mathematicians make a transition from pure to applied areas over their careers, and some even make the reverse transition, but few have seen as many reversals as me. My educational background is multi-faceted: I have a B.S. and M.S. in Mechanical Engineering from the University of Alabama in Huntsville (UAH) and a Ph.D. in Mathematics from Georgia Tech. My employment history is even more varied.

U.S. Space & Rocket Center; photograph courtesy of the Huntsville Convention & Visitors Bureau.

As an undergraduate, I worked alternating semesters at NASA Marshall Space Flight Center in Huntsville, where I pretty much abandoned my academic studies in Mechanical Engineering and instead designed ground software for use in scientific experiments on the space shuttle and space station. This was not a particularly deep application, but I did learn a lot of "nitty-gritty" details about data storage and low-level number representations. (One perk of the NASA job was that I occasionally got paid to don SCUBA gear and operate a camera during underwater astronaut training exercises -- not something that mathematicians typically do in academia.)

I left NASA a couple of semesters before graduation and began working part time at the UAH Propulsion Research Center, where I remained for the next two years as a graduate research assistant. (There were brief stints at ONERA in France and Sandia in California, but that is another story.) My M.S. research at UAH was a thermodynamic model of composite solid propellant combustion on short time scales. The purpose of my research was to find the response of burning rate to pressure oscillations as part of a larger effort to predict and control combustion instability in modern solid rocket motors. I wrote a complicated thesis filled with plots and diagrams and received my M.S. from UAH, whereupon I decided to reinvent myself once again, this time as a mathematician at Georgia Tech.

After four and a half years in Atlanta and one dissertation on flow-invariant tori, my wife and I decided to move back to Huntsville where her family is located, so her mother could take care of our then-two-month-old baby girl. We both took positions at a local company called Dynetics, Inc. where my wife, who has a M.S. in Applied Mathematics, had previously worked. Dynetics is a 1000-person engineering company that started life as a defense contractor and later spawned a commercial division. The best way to describe how such a company might use someone with my background is to give an example.

Aerial view of downtown Huntsville; photograph courtesy of the Huntsville Convention & Visitors Bureau.

In 2003, Dynetics had developed a new guided weapon for the Air Force. The engineers had saved the government a lot of money by using extensive computer modeling and "off-the-shelf" parts and software in the guidance system. The weapon was performing well in tests, and Dynetics was under contract to provide software to aid in planning missions.

The requirements for the software were simple: users would enter various conditions such as target altitude, heading, and wind speed, and the software would superimpose an acceptable release region on a navigational map. We were supposed to determine which latitude-longitude points were "acceptable" by running a sophisticated computer model to predict the miss distance. If the miss distance was below a certain threshold, then the release point was acceptable, and the software was supposed to mark it as such on the map. The computer model itself was the result of many months of strenuous effort by a team of engineers, and it was very complicated and accurate; for example, it incorporated actual, on-board flight software to predict how the missile would seek its target. Unfortunately, the sophistication of the model complicated the process in three ways:

1. The model required about one second to run a single point,
2. The model was too unstable for field use, and
3. The model was so sensitive (just like in real life) that the only reliable way to tell if a region was acceptable was to run the model explicitly on a point -- interpolation and linearization would not work over a distance of more than a few hundred meters.

These constraints obliged us to abandon "on-the-fly" reconstruction and instead compute millions of acceptable points ahead of time and store them in a table for later reference.

When I arrived at Dynetics, the people who were writing the software were using several hundred points in both the downrange and crossrange directions. They had also decided to use a variety of different wind speeds and directions, and drop and target altitudes.

A simple calculation illustrates the problem with this approach. If eight computers evaluate pieces of the table simultaneously and if each run takes one second, then the total computation time is approximately one year, and that is if the model (and the person running it) performs flawlessly! Imagine now that you have just stepped into this situation, and you discover that the software is due in three months. What do you do?

As for me, the first thing I did was to note that we were actually searching for a six-dimensional manifold. All the people who had previously examined the problem had become so engrossed in navigational maps that they saw the problem strictly as a series of two-dimensional slices. In reality, the table of acceptable points depended on six variables: wind speed, wind direction, target altitude, release altitude, downrange distance at release, and crossrange distance at release. (We could absorb everything else using symmetry.) Thus, we were really trying to find a six-dimensional manifold that comprised combinations of those six variables that would lead to a successful mission.

Perceiving the problem in toto allowed us to see that the spacings on the table were not balanced well -- there were too many latitudes and longitudes and too few altitudes. Adjusting the spacings alone cut the computation time in half, but it still was not enough; we had to be more creative.

The next thing we did was to determine that we were computing too many points outside the acceptable region. Some simple estimates indicated that the acceptable region itself was not too large -- we could compute the table of acceptable points within a couple of weeks' time if we didn't spend time on a lot of unsuccessful simulations. Therefore, we needed a way to fill out the acceptable manifold without wasting computer power on release conditions that were not likely to lead to a hit.

Bryan Rasmussen and the computer cluster used for his problem.

There are obviously many ways to attack this problem, and someone with a different background might choose a completely different method from mine. My approach was to write an algorithm that could fill any connected region of an arbitrary-dimensional lattice by recursive application of an acceptability criterion. I will omit the gory details for this article, but the algorithm itself was actually quite simple and could produce the table in about 10 days. (One example of difficulty that we ran into was that the recursion depth climbed up to 30000 for some pieces of the table. It's a good thing memory is cheap.)

The above example illustrates just one three-month period in the life of a former mathematician working in industry. It is by no means a complete map of all possible avenues for someone with a mathematical background. While my widely variegated experience is probably not a perfect guide for other students, I do hope that the recounting of observations and experiences adds to the general body information on industrial careers.