A typical hydrodynamic physics program may run up to 20 hours on a CDC 7600 computer and generate up to a billion numbers. The biggest problem facing the users of these programs is simply comprehending what has been calculated. Stacks of computer listings are typical outputs but serve as a poor communication medium. Static pictures are much better than listings but are limited to two dimensions. Through the use of movies, one adds a third dimension to the communication process. This paper will describe the evolution of computer generated movies at Los Alamos Scientific Laboratory and describe the techniques now in use.
"What results do we have from last night's production runs?" is a question asked daily by weapons designers at Los Alamos Scientific Laboratory. It is not a question that can be answered by a single number or a small set of numbers. A typical production run will take from 20 minutes to 20 hours of CDC 7600 time and may generate billions of numbers. Through the use of computer generated movies we are able to present a very good description of what has been calculated. The generated movies are not only an excellent source of information, but have proved to be valuable as a teaching medium.
The production codes are used to model physical events and usually calculate physical variables as a function of time. The geometry of a problem is usually described by a mesh containing from 1000 to 15000 nodes. These two dimensional meshes are not necessarily rectangular at the start of a problem and usually become, during the running of a calculation, quite distorted. A number of physical variables needed for the computation of the problem are associated with each node and each zone. With the values of the physical parameters and through the use of physical laws programmed into the codes, the code advances all the problem's parameters one small time step. This is repeated again and again and again until; the problem is termed finished. There are usually several thousand time steps during a problem run. Thus, this one problem run has produced tens of millions, with some running to billions of usable intraconnected parameter values. The presentation, interpretation and understanding of these parameter values is indeed a very complex and seemingly endless problem.
The production codes try to solve this problem by exhibiting their results in a number of ways. One method is to generate hundreds of pages of printed output which usually represents the physical parameters at a small number of selected times o the total run. This is the most visual demonstration to the casual observer that the individual is doing some work as shown by the huge piles of listings occupying his office. They are of very limited use otherwise with only a limited nwnber of pages giving useful information. It should be pointed out that the designer is constrained to produce such long listings since he never knows before-hand precisely which parameters will be essential for his analysis. In any given case, however, he may use only a small percentage of the information printed.
A second form of output used is to produce a set of tapes that are then used to draw pictures on paper through the use of a mechanical plotter. The pictures are indeed complicated, usually taking up to an hour each to plot. If the plotter is available, the tapes are readable, and the plotter does not malfunction, the designer will have one or two excellent plots late in the day - provided he chose the correct set of parameters to plot. These plots are indeed excellent to work from (very detailed, large scale, and may be written on) but are just too time-consuming and awkward to convey enough information about a production run.
The main source of information retrieval for production runs has been and will probably continue to be computer output microfilm (COM). This was generally 35 mm roll film with an ever-increasing percentage being in color. During the past two years, the laboratory has switched to the use of microfiche for even more compact information. The production run's results are usually printed, as with listings, and are also displayed in many different modes of parameter plotting at various time intervals during the course of a problem run. This film provides all the information that the designer was able to request before the problem was run. In most cases, hindsight indicates that a picture of the problems at a given time and a particular view was not requested and would have been invaluable in analyzing the results of the production run. The standard COM output gives little feel for the relationship between various physical variables and time. However, the data record of the production run is in a compact form on COM and is easily saved for later reference.
A more recent source of information retrieval for the production runs has been through the use of 16mm movies. The movies give to the user a qualitative indication of the relationship between physical variables and time. We generated our first movie from computer-generated output in 1960, a date that predates the existence of any COM device.. The problem was calculated by our two-dimensional code MAGEE and was run on an IBM 704 computer. The geometry or mesh modes were plotted on a mechanical plotter at equal intervals during the problem. These drawings were then photographed on 16 mm film with each plot being exposed 10 times. The result was a poor movie (compared to today's standards), rather jumpy (due to the small number of plot times), but still valuable. This first attempt certainly indicated to us that movies would indeed serve a useful purpose in problem analysis.
During the early development of 16 mm film on a COM device by the Laboratory's Central Computing Facility and indeed for some long time afterwards, the turn-around time for 16 mm film was from two to six weeks. When this was finally reduced to a one day turn-around time, the use of movies became a practical tool for the designers.
Several problems become immediately evident when attempting to make movies simultaneously during the running of a production code:
In item one (1) we have been able to reduce the number of frames needed by the use of a L-W International analytical projector. These analytical projectors are flickerless at pulse rates of 1-2-4-6-8 and 12 frames per second. They also provide variable cine rates from 16 to 24 frames per second, instant stop for still picture viewing, frame-by-frame advance by push button control at a speed as fast as you can push the button, and forward-reverse. This projector has proved invaluable, not only in computer-generated movies but for other experimental movies. Perhaps I should expand upon the idea of using such few frames for a movie (say 250-300 frames). Let us take a somewhat typical production run, say a problem run on the code MAGEE (a two-dimensional, time-dependent Lagrangian hydrodynamics code). The problem would typically contain about 1200 nodes, each node would carry 10 phtsical values (time-dependent) and the problem would take about 3000 time cycles to complete (about 45 minutes on the CDC 7600). Now,rather than plotting a picture every time cycle (3000 pictures), we have found that one needs only about 200-300 pictures to give excellent representation of the physical process taking place. This is probably because of the good interpolation qualities that reside in those humans whose eyes are connected to an active brain. By generating 240 frames of pictures for our problem, we are now ready to view these on a movie projector. Using normal projector speeds, the problem zips past in 10 seconds. We tend to use our analytical projector as a 6-frame-per-second rate giving 40 seconds viewing time. It is also possible to lengthen the total film time to four minutes. This concept and its results work quite well but must be tempered with intelligence. In certain problems, one must break up the total problem into various pieces to study the particular physics taking place at that particular time of the problem, i.e. there is no substitute for knowing what is going on in any particular problem.
In items two(2) through five (5), a separate movie code, M2C (MAGEE Movie Code), was developed to solve some of the problems, M2C picks up data to be processed from a standardized file written by the production codes. This intermediate file contains all the desired node variables at a reasonable number of problem times. The file is boot-strappable in that M2C can determine from the first record how to read and interpret the remaining data records. We have conserved space by going to a picked format whereby we save three words in the space of one word. The variables are represented by a 20-bit floating point word giving about four decimal digits and a data range of 0.000015 to 65536.0, both positive and negative. In most problems, several hundred problem times will adequately describe a problem. Often data are saved at large time intervals during certain phases of a problem and at small time intervals at other phases. This intermediate file structure is well defined and is now being generated by a majority of the production codes.
M2C has the ability to generate a specified set of problem times from those given through interpolation. This enables one to make a movie with constant time increments with data that is sparse at some times and dense at others or even when given at unequal time intervals. The code will also generate new variables from those given; for example, one may convert from rectangular to polar coordinates. The modified data is then available for the making of movies.
At present, M2C contains eight different plotting modules. Each module is independent of the other modules and is easily modified for special plots. New modules will be added as required. Each plot module contains a number of easily specified options; giving the user complete control of the generated movie. Some of the options available are color, plot orientation, background grid control, selection of variables, dynamic tracking of a spccified node, partial mesh selection, and time-step control. The plot modules include mesh plots, interface plots, contour plots, several isometric plots, rotational plots, and several experimental plots.
I thought it might be interesting to list some machine requirements for producing two-dimensional plots. These are dor a CDC 7600 and are expressed in units of seconds per plot per 1000 node points.
Point Plot = 0.10 Mesh Cell Plot = 0.16 Contour Plot = 0.24 3-D Surface Plot = 0.27 3-D Bar Plot = 0.48
M2C has also, in addition, a number of options for titles. A movie can be completcly generated by M2C with titles, any number of individual movies, and leader at both ends. The generated film is ready for public showing upon processing.
The movie code is at present used for movie generation by a number of production codes at Los Alamos Scientific Laboratory and is being adapted by others to provide all COM plotting output. A more recent use of the basic philosophy of the code has been in the use of graphical terminals operating in a time-sharing mode. The intermediate file produced by the production codes is now also used by a modified version of M2C to produce single pictures to be plotted at graphical terminals. The code will be extended to provide more types of plotting and to give multiple plots per frame.
This is not the only code in use at Los Alamos Scientific Laboratory for movie generation. It is a special code designed to display the results of calculations involving two dimensional meshes. It has proved itself as a valuable tool in a production environment and is unequaled in presenting the results of two dimensional time-dependent mesh calculations.
The development of this code was a part of the over-all development of the MAGEE code. There were three men, working as a team, responsible for the code development work. Raymond L Elliott, Elder C Pequette, and myself.