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:
- The model required about one second to run a single point,
- The model was too unstable for field use, and
- 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.