A major use of computers these days, after writing and text editing, graphics, program compilation, etc. is simulation.

A simulation is the answer to the question: "What if…?"

What if we do this? What if this is what happened?

More than 9 out of 10 experiments are done on computers these days. I have already mentioned my serious worries we are depending on simulation more and more, and are looking at reality less and less, and hence seem to be approaching the old scholastic attitude what is in the textbooks is reality and does not need constant experimental checks. I will not dwell on this point further now.

We use computers to do simulations because they are:

1. cheaper,

2. faster,

3. often better,

4. can do what you cannot do in the lab.

On points 1 and 2, as expensive and slow as programming is, with all its errors and other faults, it is generally much cheaper and faster than getting laboratory equipment to work. Furthermore, in recent years expensive, top quality laboratory equipment has been purchased and then you often find in less than 10 years it must be scrapped as being obsolete. All of the above remarks do not apply when a situation is constantly recurring and the lab testing equipment is in constant use. But let lab equipment lie idle for some time, and suddenly it will not work properly! This is called "shelf life", but it is some times the "shelf life" of the skills in using it rather than the "shelf life" of the equipment itself! I have seen it all too often in my direct experience. Intellectual shelf life is often more insidious than is physical shelf life.

On point 3, very often we can get more accurate readings from a simulation than we can get from a direct measurement in the real world. Field measurements, or even laboratory measurements, are often hard to get accurately in dynamic situations. Furthermore, in a simulation we can often run over much wider ranges of the independent variables than we can do with any one lab setup.

On point 4, perhaps most important of all, a simulation can do what no experiment can do.

I will illustrate these points with specific stories using simulations I have been involved in so you can understand what simulations can do for you. I will also indicate some of the details so those who have had only a little experience with simulations will have a better feeling for how you go about doing one—it is not feasible to actually carry out a big simulation in class, they often take years to complete.

The first large computation I was involved with was at Los Alamos during WW-II when we were designing the first atomic bomb. There is no possibility of a small scale experiment—either you have a critical mass or you do not.

Without going into classified details, you will recall one of the two designs was spherically symmetric and was based on implosion, Figure 18.I. They divided the material and space into many concentric shells. They then wrote the equations for the forces on each shell (both sides of it) as well as the equation of state which gives, among other things, the density of the material from the pressures on it. Next they broke time up into intervals of 10–8 seconds (shakes, from a shake of a lamb's tail, I suppose). Then for each time interval we calculated, using the computers, where each shell would go and what it would do during at that time, subject to the forces on it. There was, of course, a special treatment for the

Figure 18.I

shock wave front from the outer explosive material as it went through the region. But the rules were all, in principle, well known to experts in the corresponding fields. The pressures were such there had to be a lot of guessing things would be much the same outside the realms of past testing, but a little physics theory gave some assurances.

This already illustrates a main point I want to make. It is necessary to have a great deal of special knowledge in the field of application. Indeed, I tend to regard many of the courses you have taken, and will take, as merely supplying the corresponding expert knowledge. I want to emphasize this obvious necessity for expert knowledge—all too often I have seen experts in simulation ignore this elementary fact and think they could safely do simulations on their own. Only an expert in the field of application can know if what you have failed to include is vital to the accuracy of the simulation, or if it can safely be ignored.

Another main point is that in most simulations there has to be a highly repetitive part, done again and again from the same piece of programming, or else you cannot afford to do the initial programming! The same computations were done for each shell and then for each time interval—a great deal of repetition! In many situations, the power of the machine itself so far exceeds our powers to program it is wise to look early and constantly for the repetitive parts of a proposed simulation, and when possible cast the simulation in the corresponding form.

A very similar simulation to the atomic bomb arises in weather prediction. There the atmosphere is broken up into large blocks of air, and the relevant conditions for cloud cover, albedo, temperature, pressure, moisture, velocity, etc. must be initially assigned to each block, Figure 18.II. Then using conventional physics for the atmosphere, we trace where each block goes in a short time interval, along with the relevant changes. It is the same kind of step by step evolution as before.

However, there is a significant difference between the two problems, the bomb and the weather prediction. For the bomb small differences in what happened along the way did not greatly affect the overall performance, but as you know the weather is quite sensitive to small changes. Indeed, it is claimed whether or not a butterfly flaps its wings in Japan can determine whether or not a storm will hit this country and how severe it will be.

This is fundamental theme I must dwell on. When the simulation has a great deal of stability, meaning resistance to small changes in its overall behavior, then a simulation is quite feasible; but when small changes in some details can produce greatly different outcomes then a simulation is a difficult thing to carry out accurately. Of course, there is long term stability in the weather; the seasons follow their appointed rounds regardless of small details. Thus there is both short term (day to day) instabilities in the weather, and longer term (year to year) stabilities as well. But the ice ages show there are also very long term instabilities in the weather, with apparently even longer stabilities!

I have met a large number of this last kind of problem. It is often very hard to determine in advance whether one or the other, stability or instability, will dominate a problem, and hence the

Figure 18.II

possibility or impossibility of getting the desired answers. When you undertake a simulation, look closely at this aspect of the problem before you get too involved and then find, after a lot of work, money, and time, you cannot get suitable answers to the problem. Thus there are situations which are easy to simulate, ones which you cannot in a practical sense handle at all, and most of the others which fall between the two extremes. Be prudent in what you promise you can do via simulations!

When I went to Bell Telephone Laboratories in 19461 soon found myself in the early stages of the design of the earliest NIKE system of guided missiles. I was sent up to MIT to use their RDA #2 differential analyser, given the interconnections of the parts of the analyser, and much advice from others who knew a lot more than I did about how to run the simulations.

They had a slant launch in the original design, along with variational equations which would give me information to enable me to make sensible adjustments to the various components, such as wing size. I should point out, I suppose, the solution time for one trajectory was about 1/2 hour, and about half way through one trajectory I had to commit myself to the next trial shot. Thus I had lots of time to observe and to think hard as to why things went as they did. After a few days I gradually got a "feeling" for the missile behavior, why it did as it did under the different guidance rules I had to supply. As time went on I gradually realized a vertical launch was best in all cases; getting out of the dense lower air and into the thin air above was better than any other strategy—I could well afford the later induced drag when I had to give guidance orders to bend the trajectory over. In doing so, I found I was greatly reducing the size of the wings, and realized, at least fairly well, the equations and constants I had been given, for estimating the changes in the effects due to changes in the structure of the missile, could hardly be accurate over so large a range of perturbations (though they had never told me the source of the equations, I inferred it). So I phoned down for advice and found I was right—I had better come home and get new equations.

With some delay due to other users wanting their time on the RDA #2, I was soon back and running again, but with a lot more wisdom and experience. Again, I developed a feeling for the behavior of the missile—I got to "feel" the forces on it as various programs of trajectory shaping were tried. Hanging over the output plotters as the solution slowly appeared gave me the time to absorb what was happening. I have often wondered what would have happened if I had had a modern, high speed computer. Would I ever have acquired the feeling for the missile, upon which so much depended in the final design? I often doubt hundreds more trajectories would have taught me as much—I simply do not know. But that is why I am suspicious, to this day, of getting too many solutions and not doing enough very careful thinking about what you have seen. Volume output seems to me to be a poor substitute for acquiring an intimate feeling for the situation being simulated.

The results of these first simulations were we went to a vertical launch (which saved a lot of ground equipment in the form of a circular rail and other complications), made many other parts simpler, and seemed to have shrunk the wings to about 1/3 of the size I was initially given. I had found bigger wings, while giving greater maneuverability in principle, produced in practice so much drag in the early stages of the trajectory the later slower velocity in fact gave less maneuverability in the "end game" of closing in on the target.

Of course these early simulations used a simple atmosphere of exponential decrease in density as you go up, and other simplifications, which in simulations done years later were all modified. This brings up another belief of mine—doing simple simulations at the early stages lets you get insights into the whole system which would be disguised in any full scale simulation. I strongly advise, when possible, to start with the simple simulation and evolve it to a more complete, more accurate, simulation later so the insights can arise early. Of course, at the end, as you freeze the final design, you must put in all the small effects which could matter in the final performance. But (1) start as simply as you can provided you include all the main effects, (2) get the insights, and then (3) evolve the simulation to the fully detailed one.

Guided missiles were some of the earliest explorations of supersonic flight, and there was another great unknown in the problem. The data from the only two supersonic wind tunnels we had access to flatly contradicted each other!

Guided missiles led naturally to space flight where I played a less basic part in the simulations, and more as an outside source of advice and initial planning of the mission profile, as it is called.

Another early simulation I recall was the travelling wave tube design. Again, on primitive relay equipment I had lots of time to mull over things, and I realized I could, as the computation evolved, know what shape to give other than the always assumed constant diameter pipe. To see how this happens, consider the basic design of a travelling wave tube. The idea is you send the input wave along a tightly wound spiral around a hollow pipe, and hence the effective velocity of the electromagnetic wave down the pipe is greatly reduced. We then send down the center of the pipe an electron beam. The beam has initially a greater velocity than the wave has to go along the helix. The interaction of the wave and the beam means the beam will be slowed down—meaning energy goes from the beam to the wave, meaning the wave is amplified! But, of course, there comes a place along the pipe when their velocities are about the same and further interactions will only spoil things. So I got the idea if I gradually expanded the diameter of the pipe then again the beam would be faster than the wave and still more energy would be transferred from the beam to the wave. Indeed, it was possible to compute at each cycle of computation the ideal taper for the signal.

I also had the nasty idea since I had found the equations were really local linearizations of more complex nonlinear equations, I could, at about every twentieth to fiftieth step, estimate the nonlinear component. I found to their amazement on some designs the estimated nonlinear component was larger than the computed linear component—thus vitiating the approximation and stopping the useless computations.

Why tell the story? Because it illustrates another point I want to make—an active mind can contribute to a simulation even when you are dealing with experts in a field where you are a strict amateur. You, with your hands on all the small details, have a chance to see what they have not seen, and to make significant contributions, as well as save machine time! Again, all too often I have seen things missed during the simulation by those running it, and hence were not likely to get to the users of the results.

One major step you must do, and I want to emphasize this, is to make the effort to master their jargon. Every field seems to have its special jargon, one which tends to obscure what is going on from the outsider-and also, at times, from the insiders! Beware of jargon—learn to recognize it for what it is, a special language to facilitate communication over a restricted area of things or events. But it also blocks thinking outside the original area for which is was designed to cover. Jargon is both a necessity and a curse. You should realize you need to be active intellectually to gain the advantages of the jargon and to avoid the pitfalls, even in your own area of expertise!

During the long years of cave man evolution apparently people lived in groups of around 25 to 100 in size. People from outside the group were generally not welcome, though we think there was a lot of wife stealing going on. When the long years of cave man living are compared with the few of civilization: (less than ten thousand years) we see we have been mainly selected by evolution to resent outsiders, and one of the ways of doing this is the use of special, jargon, languages. The thieves' argot, group slang, husband and wife's private language of words, gestures, and even a lift of an eyebrow, are all examples of this common use of a private language to exclude the outsider. Hence this instinctive use of jargon when an outsider comes around should be consciously resisted at all times—we now work in much larger units than those of cave man and we must try continually to overwrite this earlier design feature in us.

Mathematics is not always the unique language you wish it were. To illustrate this point recall I earlier mentioned some Navy Intercept simulations involving the equivalent of 28 simultaneous first order differential equations. I need to develop a story. Ignoring all but the essential part of the story, consider the problem of solving one differential equation

Figure 18.III. Keep this equation in mind as I talk about the real problem. I programmed the real problem of 28 simultaneous differential equations to get the solution and then limited certain values to 1, as if it were voltage limiting. Over the objections of the proposer, a friend of mine, I insisted he go through the raw, absolute binary coding of the problem with me, as I explained to him what was going on at each stage. I refused to compute until he did this—so he had no real choice! We got to the limiting stage in the program and he said, "Dick, that is fin limiting, not voltage limiting." meaning the limited value should be put in at each step and not at the end. It is as good an example as I know of to illustrate the fact both of us understood exactly what the mathematical symbols meant—we both had no doubts—but there was no agreement in our interpretations of them! Had we not caught the error I doubt any real, live experiments involving airplanes would have revealed the decrease in maneuverability which resulted from my interpretation. That is why, to this day, I insist a person with the intimate understanding of what is to be simulated must be involved in the detailed programming. If this is not done then you may face similar situations where both the proposer and the programmer know exactly what is meant, but their interpretations can be significantly different, giving rise to quite different results!

You should not get the idea simulations are always of time dependent functions. One problem I was given to run on the differential analyser we had built out of old M9 gun director parts was to compute the probability distributions of blocking in the central office. Never mind they gave me an infinite system of interconnected linear differential equations, each one giving the probability distribution of that many calls on the central office as a function of the total load. Of course on a finite machine something must be done, and I had only 12 integrators, as I remember. I viewed it as an impedance line, and using the difference of the last two computed probabilities I assumed they were proportional to the difference of the next two, (I used a reasonable constant of proportionality derived from the difference from the two earlier functions) thus the term from the next equation beyond what I was computing was reasonably supplied. The answers were quite popular with the switching department, and made an impression, I believe, on my boss who still had a low opinion of computing machines.

Figure 18.III

There were underwater simulations, especially of an acoustic array put down in the Bahamas by a friend of mine where, of course, in winter he often had to go to inspect things and take further measurements. There were numerous simulations of transistor design and behavior. There were simulations of the micro wave "jump-jump" relay stations with their receiver horns, and the overall stability arising from a single blip at one end going through all the separate relay stations. It is perfectly possible while each station recovers promptly from the blip, never-the-less the size of the blip could grow as it crossed the continent. At each relay station there was stability in the sense the pulse died out in time, but there was also the question of the stability in space—did a random pulse grow indefinitely as it crossed the continent? For colorful reasons I named the problem "Space stabilization". We had to know the circumstances in which this could and could not happen—hence a simulation was necessary because, among other things, the shape of the blip changed as it went across the continent.

I hope you see almost any situation you can describe by some sort of mathematical description can be simulated in principle. In practice you have to be very careful when simulating an unstable situations—though I will tell you in Chapter 20 about an extreme case I had to solve because it was important to the Laboratories, and that meant, at least to me, I had to get the solution, no matter what excuses I gave myself it could not be done. There are always answers of some sort f or important problems if you are determined to get them. They may not be perfect, but in desperation something is better than nothing—provided it is reliable!

Faulty simulations have caused people to abandon good ideas, and these occur all too often! However, one seldom sees them in the literature as they are very, very seldom reported. One famuous faulty simulation which was widely reported (before the errors were noted by others) was a whole world simulation done by the so called "Club of Rome". It turned out the equations they chose were designed to show a catastrophy no matter how you started or chose most of the coefficients! But it also turned out when others finally got the equations and tried to repeat the computations the comuputations has serious errors! I will turn to this aspect of simulating things in the next chapter as it is a very serious matter—to either report things which make people believe what they want to believe, and are not so, or which you discourage people from pursuing their good ideas.