An Interview with Pat Crowley

Pat Crowley


PC = Pat Crowley
GAM = George Michael



GAM: Today is May 17, 1995, and it's my pleasure to interview another Lab pioneer named Pat Crowley. Pat, why don't you just begin by telling us where you came from, and when you got to the Lab, and so forth.

PC: I went to school at San Diego State College from '53 to '58. I was working in math and physics and I married Barbara Killian there in 1956. And, somehow, she got an interview with someone from the Lab—I think it was Bill Thompson who arranged for us to come up and be interviewed, which we then did. Then somehow they were blinded by something, and hired both of us! Barbara went into the Rover Project, and I went into Theoretical Physics, which was then headed by Mark Mills. Just before I started there, Mark died in a helicopter accident overseas.

GAM: Yes, in the Pacific. That happened in early April, 1958.

PC: Yes. So Sid Fernbach took over as Acting Head of Theoretical Division at that time. I was supposed to work in the Hydro Group. I think when I was interviewed, I said I was interested in "acoustics", and they got that confused with "hydrodynamics".

So, I was supposed to work in the hydro group, which was headed by George Bing in those days. George didn't do any hydro; he was looking at reentry problems and stuff like that. Bob Lelevier, who had been in the hydro group, had left the Lab by that time. I was supposed to work for Bill Noh who was developing a 2D, Eulerian hydro code; I was supposed to help him. But I didn't know what I was supposed to do, and he didn't know what he was supposed to do!

The programmer was Isabelle Blanford and she called that code GOLUX after the little man in Thurber's "Thirteen Clocks," who said "I am the Golux, the only Golux in the world, and not a mere device." Izzie was one of the best programmers at the Lab. She left in a couple of years, and went on to become a lawyer or something like that. I don't know— I've lost track of her.

GAM: Actually, she went on and became the wife of Fernando Corbato at MIT. And then, unfortunately, she died.

PC: Oh, did she really? That's too bad.

GAM: It was very sad.

PC: The person who took Izzie's place was Shirley Campbell, who had one of the most remarkable brains I've ever seen for keeping track of everything. She knew every line of code and where it was. She was a chemist by education, and a remarkable programmer. She was just really, really something.

In those days, you know, we didn't have computers in our offices. We had to go over and sign up for machine time. So you got a 15-minute shot, and that's all you got each day. Maybe you got two shots a day; you could negotiate with somebody else for an afternoon shot if you couldn't figure out what to do in the morning. You had to figure things out during those vital 15 minutes. At the end of that time slot, you probably got a memory dump, which you used to then figure out what went wrong so you could go on to the next 15 minute time. And, like as not, the memory dump was in Octal, which meant you got to convert Octal numbers into whatever number system worked for you— without a hand calculator. You learned how to do it by hand. Interactive computing has really changed the world! Then, finally, they gave us double memory dumps or something like that.

GAM: Apropos of how octal can get into your subconscious, here's an amusing anecdote about Izzy. It seems she was serving as a navigator in one of those Sport Car Rally things; a "Gymkhanna" or whatever. Anyway, she and her driver thought they would win something because they weren't making any mistakes. When they got to the finish line, they found they were almost in last place. It seems Izzy had done all her time calculations in octal.



PC: I remember those competitions, many Labbers competed; they were fun. I've got some names written down here. Seymour Sack was also in the hydro group. We were in the original Building 162, which had two mature palm trees out in front, they tore down the building and tore out the palm trees, much to my disgust—when they built the new administration building—111.

GAM: Yes. It was unfortunate.

PC: Building 162 had been a hospital, or something like that, when it was a Navy base, I think.

GAM: BOQ—Bachelor Officers' Quarters.

PC: Oh, was that what it was? All of Theoretical Physics and some of A Division, and B Division, were located in that building. During the summer, air conditioning amounted to a fan and an open window. Those of us who were fortunate enough to work on the computers could go to the computer room to cool off. The computer room was always nice and cool. So, we had all kinds of opportunities to get in an extra debug shot when someone didn't show up.

I just had one little remembrance of the 15-minute time slots. We had time cards. And when you got off, you punched out. The usual thing was we set sense switch 1, and that was supposed to initiate, by convention, the program's getting off. A minute or so later, the program would end, and we would punch out.

Well, Jack Trullio, who usually had the slot ahead of me, whenever he threw sense switch 1, he punched out. So, there was a minute of his time that I paid for—every day, consistently, he did the same damn thing! It didn't matter, but it was annoying to me. One of the things I remember about those days is that—when you got up to a 704 or something like that—memory was about 4,000 words and I think those were 36-bit words.

GAM: Yes, and the later 704s had 8K and 16K words of memory on them.

PC: But didn't the early ones just have 4K?

GAM: Yes. Both the 701s and the earliest 704s.

PC: I didn't work on the 701s. The 704s had 8K words. When you were doing a mesh calculation, like a hydro calculation, you wrote the mesh out on tapes. Then you would read in part of the mesh off of one tape, and compute on the middle of that, and then write it out on another tape. Then, when you'd get all done, you'd have to rewind the tapes. And you couldn't do any computing during the rewind. Then, Norman Hardy came up with the three-tape scheme, which eliminated the latency due to rewind. He had them arranged so that while you're reading one, and writing one, you're rewinding the other one. A marvelous little thing!

GAM: Well, Norman is just a genius, you know.

PC: Yes, I think I've known two geniuses in my life. One of them was Norman, and one of them was Chuck Leith. And, I don't know, maybe I've known others, but those are two who I know were geniuses.

GAM: Yes, you're right. I agree.

PC: If your program is 2D hydro, what you end up with is a bunch of numbers, and the raw numbers don't make much sense as such. Well, one of the things you'd like to see is how the fluid flows. And so it seemed to me that the right thing to do was to make up a plotting package that, at any instant in time, took a restart dump, and plotted what the velocity field looked like at that time.

GAM: Right.

PC: To do that, I had to plot vectors. And what I started out with is a hand-coded subroutine called "PLOTL" that Norman had written. PLOTL was a tightly written thing, with absolutely no comments in it (PLOTL stands for plot- line). It used such exotic things as unnormalized floating adds, and all of that. So the first thing I had to do was to figure out what Norman was doing in that routine, and then I had to figure out to put the head on the arrow. Alex Cecil helped me a lot in doing this. Eventually, it worked, and we called it PLOTV, which I think still exists to this day!

A lot of this, remember, was being done late at night. The machines were supposed to be used for production at night, but we just went in and took our debug shots. So, we got maybe several debug shots per day. We'd go home to dinner, and then come back, and work from 8 or 9 at night to 2 in the morning. And then we'd go out to the Hungry Truck and have some pancakes or eggs or hash browns.

GAM: Physics is what physicists do late at night.

PC: I've heard you say that many times, George. And even when we were out at the Hungry Truck, there we were—still talking about computers and things. Chuck and Norman, and others, were designing SOLOMON and, you know, it was a marvelous time.

I was uneducated when I got there, and the Lab really offered me opportunity and freedom. And that was really nice. It's not that way anymore, of course.

GAM: I'll say!

PC: But those were what we call "the good old days."

Eventually we had to write another version of this 2D code (GOLUX), which then became CEL. Parts of the CEL were Lagrangian and parts of it were Eulerian. The Lagrangian meshes floated around and covered parts of the Eulerian mesh. It was a fairly complicated code. All of that was done without benefit of time sharing.

I guess the first timesharing that came along was GOB, which you, and Bob Abbott, and Norm...

GAM: Yes. Well, there also was Shig Tokubo, and Cliff Plopper, and Ed Nelson.

PC: Shig was part of that. Do you remember the first editing routine was NAB—which was Norman, Ann, and Barbara (Schell)?

GAM: Yes.

PC: And what I remember was that somebody had the brilliant idea that all these tentacles on the Octopus ought to go into one, central location, which was a PDP-6. And when it went down, everything went down. And when it came up, everybody's office went "ring, ring, ring!"

GAM: On the Teletypes, yes.

PC: Yes, the Teletypes woke you up, and you madly went over and started doing your thing. And then it would go down, and then it would go "ring, ring, ring" again. I don't know how we got through those stages.

GAM: We were all learning.

PC: Boy, I'll say we were! But we learned, we learned. And look at where that's gotten us today.



GAM: You know, before we had time sharing, as you recall, I'll remind you that we had a thing called CRT Batch. Do you remember that?

PC: Well, I don't remember. I remember we had batch processing.

GAM: CRT Batch was this thing that you and I put together, clumping all the plotting routines together.

PC: Oh! Oh, the Library! The Library! Yes. Gosh, I'd forgotten all about that. Oh, my God. Yes, and that contained vectors and contour plots, which were important. There were some early attempts at shading. But I remember shading didn't do so well; there was always a problem with the seam at the edges of the zones.

GAM: Well, we didn't have enough points in the raster for that. But, you know, the Library's set of stuff lasted well into the '80s.

PC: Really? Is that right?

GAM: Yes.

PC: Well, probably parts of it continue on today in some form or another. It's been modernized, right?

GAM: Now we have better CRTs to work with, but the simple routines that let the physicist get close to his data don't seem to be around as much.

PC: One of the other things we thought about doing was linking one physics code to another. That is, you would run a problem at early times on the Lagrangian code; (a Lagrangian code is one where the mesh follows the fluid.) And then the mesh would get tangled because the fluid wanted to have vorticity and get all scrambled up. Then at that point, you couldn't continue the simulation without rezoning. So you would do an overlay calculation onto a Eulerian code, or maybe onto a smoother mesh, or something like that, and then continue on with the simulation. To do overlay calculations, you had to do volumes of intersections. And the earliest one was written by Norman, of course, called VIT—Volume of Intersection of Triangles.

Well, there was another guy who came along, and he wrote a code called ZOVOLI—Zone Volume of Intersection. I thought that was the funniest name for a subroutine I'd ever heard. And that was Dick Bentley who was working in T Division, and he was legally blind.

GAM: Yes.

PC: There's a story about him going up in the mountains with a mule—and he was a little bit stubborn, too—to carry his stuff. But he went backpacking by himself in the mountains with this mule.

GAM: Yes.

PC: You'd see Bentley sitting there at a keypunch machine, with his eyes about three inches from the keyboard, trying to punch cards, trying to debug this volume of intersection routine.

GAM: It worked, too!

PC: Absolutely! It worked for a long time, and it's probably still around in some form. These were fairly sophisticated routines—finding the volume of intersection of two lines is easy with pencil and paper, but when you come to doing it in finite arithmetic, it's a bitch! It's very complex, finding all the special cases, and getting them right.

For a person who's legally blind, it becomes an even greater achievement.

GAM: Quite an accomplishment, yes.

PC: Yes. I'd give him several stars for that. But he got it right, and it was one of the things that let us do overlay calculations from one code to another.

GAM: When did CHETZ come in?

PC: The name CHETZ was an acronym for "Continuous Hydro Eulerian To Lagrange. It was written "CHETL" and so it was originally pronounced "Chettle". And then that got transcribed into CHETZ, because Ts and Zs and Ls looked very much alike in my handwriting. But the idea with CHETZ is that you could have a hydro code where the mesh would always be a nice mesh, but the mesh would be moving. And so, in parts of the fluid, it would have the accuracy of a Lagrangian calculation, and in the other parts, it would not get tangled, because it would move so as to be a nice mesh. In the non-Lagrangian part of the mesh, the fluid would flow relative to the mesh. We wrote CHETZ in the early '60s or something like that. CHETZ was sort of an early attempt at what's called the "ALE" techniques these days—Arbitrary Lagrangian-Eulerian, which was a name coined by the Los Alamos people.

But you and I wrote this CHETZ code. And it ran some fairly interesting problems as I recall. And then somehow it got lost on the back burner someplace. I went off to school, and you went off to do other things.

GAM: Well, you gave it to me, and I ran it. And we always had trouble, because it wouldn't correctly run a shock wave in a pipe. So, it got put onto the back burner while we tried to figure that out.

PC: Yes.

GAM: Then you went to school at Berkeley, right?

PC: Yes, I think it was '62 or something like that.

GAM: Yes, because I ran this on the STRETCH.

PC: On the STRETCH? When did the STRETCH come?

GAM: In '60 or '61.

PC: Okay, because I remember running some things—I think I ran on the STRETCH before I went back to school.

GAM: Yes.

PC: And then I found myself in school, not thinking about how you do analytic solutions to differential equations, but how you do finite difference solutions. And the professors weren't interested in finite difference solutions at all in those days. So, I just daydreamed my way into coming back to the Lab after a year. But I learned some hydro in school, and I had a good time. So, Barbara and I were gone for a year, and then we came back. She went into the Plowshare Program, I think, at that time. When I came back, I moved into another Hydro Group—the H Group—which was headed by Chuck Leith in those days.

Those were the days when Chuck was writing his atmospheric model, LAM—Leith's Atmospheric Model, as some said. So I still didn't know what to do in those days. Maybe I still don't know what to do now! But the Lab was still such that you had a lot of freedom to do what you wanted to do. I think the CDC 3600 was coming.

GAM: Right. Well, they had the 1604, then the 3600, and then the 6600.

PC: Okay, yes. Before we leave all of that—remember computer programs were kept on punch cards. A large code might be several boxes of punched cards, and from time to time people dropped those boxes of cards.

GAM: Yes!

PC: Roger DeBarr was carrying his KRAKEN code around, and dropped it.

GAM: Oh boy!

PC: Pete Moulthrop tells that story. When he dropped it they all slid out, you know, nicely. And he just put it back together. And then, rather than reading all the cards in everytime we had alter decks. Do you remember, you could make alter decks?

GAM: Yes.

PC: You could just read in a little deck and use it to alter the main tape. You went from card-to-tape before you went on the machine. You had your source code on one tape, and your alter deck on the other. And you probably were writing in FORTRAN, which was becoming more respectable in those days. It still had bugs in it that had to do with nested do-loops and things like that. Gosh, I remember fighting some of those compiler bugs! We don't worry about them so much any more.

GAM: No, compilers are a little more robust in that respect.

PC: One of the things I remember was making the STRETCH play music. That was something that Norman was doing. He found out that the STRETCH was broadcasting, and that by writing do-loops of different lengths, you could make musical notes by modulating the broadcast frequency. And so we just tuned in a little FM radio, and listened.

GAM: Yes.

PC: So, there were some Bach partitas, and all of these things done late at night. And I don't know if anybody—it's probably illegal to make recordings of that—did anybody?

GAM: I think that Norman and Ted Ross did make a recording in Berkeley. They had produced music like that by flipping a sense light on a 709 or a 704 or something like that.

PC: Yes, yes. That was inside the do-loop, I guess, yes. It's amazing!

We also learned how to make movies. I don't know when that started.

GAM: Well, we started that in '56 and '57, but it got to be a much more elaborate art in the '60s.

PC: When did the dd-80 [1] come along?

GAM: In '61. We had this marvelous pulse-operated camera on it—it could run up to 30 frames a second [2].

PC: Right, yes. I made a movie routine that allowed you to watch your film being made on line. This eliminated a few days wait for film processing. Roy Woodruff, who was a designer in those days would go over and sit in the machine room, and watch the program as it produced the movie. That facility got information in the designer's hands ASAP—they didn't have to wait for film processing. Of course, after getting the hard copy you could then show it to a bunch of people. Roy wanted to see what was going on right as it was happening.

GAM: Right.

PC: I remember taking math classes at the Lawrence Radiation Lab from John Killeen from '58 to '62. I took several graduate math courses from John, which didn't get me anywhere. I mean, it got me some education, but I decided I wasn't going to be a mathematician.

People at Livermore were starting to write large physics codes in the late 50s and 60s. Each physics code requires a generator and an analysis routine. The generator defines initial conditions and the analysis routines synthesize all the billions of numbers into a few plots and numbers that humans can understand. And each one of those three efforts is a major code in and of itself.

GAM: Yes.

PC: The people that I remember who worked on making generators were Maggie Gee and Bob Cralle. And George, did you write generators?

GAM: I did some of that, yes, but I wasn't completely involved in it. I had all these other things I was screwing around with.

PC: Then, the output included some kind of integrals over time and over space. I mean, these hydro codes had thousands and thousands of numbers! And you can't just present the thousands and thousands of numbers to somebody—they can't comprehend it.

GAM: Right.

PC: So, you either have to come up with some kind of integrals—some measure of goodness of how this thing is working—or you have to make pictures, or some combination of those things. We figured out how to make movies, and how to do integrals, and how to present them, and how to do time histories, and how to save data as we were computing so we didn't recompute. These days, there are arguments about whether you should just recompute, rather than save, because saving is expensive.

GAM: But so is recomputing!

PC: But if you try to save an entire mesh in a 3D problem, that's a big...

GAM: Oh that's a bear.

PC: That's a bear, right, if you have to save everything. Well, there's always been a tradeoff between recomputing and saving—and I don't know what the answer is right now. The guys who do weather simulations...

GAM: Well, very early in the '60s, you were dipping into ocean modeling, weren't you?

PC: Ha—so to speak! Yes, when I came back and went into Chuck's group, Chuck had written an atmospheric model. And so I played around with toy ocean models—ocean model basins and such. And then I decided that the best thing to do would be to write a global ocean model, and then to couple that to the atmospheric model. And I remember writing the 3D, global ocean model with 5� zones. I think there were eight levels in the vertical. In writing it, I learned about some of the problems that were associated with such a beast, such as its initialization. It turns out that, in the atmosphere, after thirty days of model time— whatever your initial conditions are—the weather, the fluid patterns start looking like real weather patterns.

But, the ocean has time scales that are much longer than that and the initialization problem is one that, still, nobody has really solved. It's still an active research topic.

And then the coupling problem—how to couple an atmosphere to an ocean?

GAM: Oh, yes.

PC: The 3D ocean model never did get coupled to the 3D atmospheric model. But there was a 2D zonal model that went from the North Pole to the South Pole, and had averages from east to west; that got coupled, and some work was done there. But it was still clear that the initialization problem was unsolved.

GAM: It seems to me that I have some movies of those zonal flows.

PC: There were some movies made. And, again, the atmosphere always tends to look like the atmosphere pretty early on, but the ocean doesn't really settle down—and maybe that's reality. They find that the more they look at ocean circulation, the more activity there is out there. So, who knows?

Some of the recent stuff that's been done when you try to couple atmospheres and oceans is if you couple the fluxes, which is the physical thing to do, then the models won't settle down to anything realistic. So what you have to do is drive them with fixed temperatures on the boundary conditions, and then they'll settle down. Well, that sounds to me like there's something wrong.

GAM: Yes.

PC: It's possibly related to the initialization problem.

GAM: One of the things we did, as I recall, is we made some movies of the 9-point operator and the 4-point operator, and so forth? Do you remember that?

PC: Vaguely. There are a lot of things that are vague these days! One of the things I remember making movies of, and looking at, is the number of significant bits that are needed to do a calculation. And that shows up most readily in instability-type calculations. That is, if a word only contains 32 bits, then the round-off propagates up and messes up the solution at a given time.

GAM: Yes.

PC: Well, if you have more bits, even though the propagation occurs, it takes longer to get up to mess things up. So, to do things that are physically meaningful, you need at least 64 bits in a word. Tim Rudy and I did some stuff on some zonal flow calculations, not instabilities, but just zonal flow hydro, incompressible hydro, and looked at how many bits were needed. And we found that the same thing was happening there. We would always do the primary calculation with 64 bits but, then, we'd rerun and we'd shift off a certain number of bits, (throw them away), and so do a sequence of experiments at 64 bits, 32 bits, 20 bits, and so on. And you could see that the calculation broke down at earlier and earlier times as you used fewer bits to store numbers.

GAM: As you say, that was expected. There was a noisy mode on the STRETCH where the last bit could be chopped or set, by the way a flag was set. And that's where people started studying that. And they continued the study on the STAR, because it had a 32-bit mode and a 64-bit mode. So did the STRETCH, for that matter. Generally, it was seen that 32 bits was not enough for our calculations.

PC: Speaking of the STAR—during the time I was trying to be an administrator, the STAR came along. I remember the background to that is that Los Alamos backed out, and there was a meeting at Livermore, and everybody in the room except Bill Lokke said we should take the second machine from Los Alamos. Bill said no. He was the smartest person in the room at the Lab on that day.

GAM: He certainly proved to be right.

PC: But, we ended up with two STARS, and, my God, the number of people that had to be pushed into getting the STAR to work at any kind of efficiency was just amazing. The production codes had to be ninety percent or more vectorized before they'd run at more than scalar speed. [Note added: the scalar speed on the STAR turned out to be approximately half that of a 6600, a ten year older machine.] But the amount of work that it took to vectorize them was considerable. All the codes were rewritten—and maybe that was a good investment.

GAM: Well, possibly. Jim LeBlanc said that for seven years he didn't get any physics done. And he said, "Never again."

PC: Yes, I think that was true for a lot of us, but I didn't get any physics done because I was working in administration in those days as a Group Leader in A Division. But a lot of people who should have been doing other things—George Zimmerman probably paid the price—a lot of people spent their time trying to get codes to work on the damned STARs. That was one of the big computational mistakes that the Lab made—poor, poor judgment.

GAM: I think it was—whether one is willing to admit or say it—the mistake was getting two STARs, okay?

PC: Yes! Yes! Okay, yes! Getting one STAR—we could have lived with one STAR, but getting two! And then being told by energy officials in Washington that, look at all this computing power you have! Why do you need more? Use what you have! While Los Alamos is going out and bagging—I don't remember what...

GAM: They got the CRAY 1.

PC: Some 7600s and then the CRAY 1.

GAM: Yes, they got extra 7600s while they waited for the CRAY 1.

PC: Yes. You know, they were getting all kinds of stuff. They didn't know what to do with computers, but they were getting them!

GAM: Yes. They're still doing that!

PC: Well, I don't know what the link is there.

GAM: They have a huge stable of computers there—much larger than ours—you know, they even have one that they run for the Defense Nuclear Agency (DNA). And the Army.

PC: Oh, really?

GAM: Yes.

PC: Well, they got ahead of us in the parallel processors because Harold Trease was pushing a lot of that.

GAM: Yes, and it seems like they got burned by that in the same sense that we got burned by two STARs—not much came out of it in their case.

PC: Well, I don't think that was the same story. I think that may have had to do more with people than with the machines?

GAM: Well, yes. But the difference may be that Los Alamos is economically, more important to New Mexico than Livermore is to California. In any event, the point is: It did not measure up to what their expectations were.

PC: Yes.

GAM: And they still have a lot of parallel machines laying around the place, but they're research, not production, machines.

PC: Yes. Well, aren't we trying to learn how to work with the parallel machines these days?

GAM: That was the idea, but, you see, with the meddling that comes from Washington, there's no opportunity to do that. They're trying to turn everything into a production facility.

PC: You know, Chuck talks about message-passing versus FORTRAN 90. That debate rages on, and probably will for a long time. I would like to see everything done in the compiler, so the guys could just write physics rather than worry about message passing. Chuck told me that efficient message passing is like doing buffered I/O. It's exactly the same process.

Oh, I have to go back just a little bit. We missed a computer, and that is the computer that Chuck did most of his work on, the LARC. The Remington Rand LARC, which was made especially for the Lab—maybe one or two in the world.

GAM: There were two.

PC: I don't know where the other one was.

GAM: At the David Taylor Model Basin.

PC: Oh, yes, that's right. And we had a LARC which had a FORTRAN that nobody used because it was too clunky, I think, or maybe too unreliable. So, everything we did on the LARC was hand coded. Chuck's atmospheric model, my global ocean model, Bernie Alder's molecular dynamics, and Nevin Sherman's N-body problems.

GAM: In fact, he and Jack Noonan used it to find a logic error in the LARC floating-point unit.

PC: Oh, is that right?

GAM: Right. It's a story I have to get. After the thing had been settled in for a while, they found this error: the floating point was computing incorrectly, although only slightly inaccurately.

PC: Oh, my God. That must have been early on. I didn't get on the LARC early on. I think Chuck was one of the first ones on there. And on the LARC you could make code patches in a paper tape that you could read in at execute time.

GAM: The LARC had many brilliant ideas in it. Its major difficulty was that it was a decimal machine, and we had learned binary by then.

PC: Yes, Well, it also had a small memory—30K or something like that, and it had drums. But we learned how to do buffered I/O.

GAM: Chuck did that marvelously well using those drums.

PC: Well, the same problem was...

GAM: Message passing?

PC: Yes, it was message passing. You had to do the same thing. You read in something that you hadn't computed yet, you wrote out what you had computed, and you worked on something in between. But we don't do that any more!

GAM: Oh, more than that, I think of the quality of people that were involved made it work very well.

PC: I think so. You know it's hard to say. If you have a more or less endless supply of money, and people can do what they want to do, they can do marvelous things. And they don't always just do stuff that's useless. A lot of scientists that I know are doing creative things. It just takes somebody with another kind of creativity to put all of that stuff together and make it work in a useful way for other people.

GAM: Yes, that was the idea of the Lab.

PC: Well, yes. But there were also people at the Lab who were doing just out-and-out physics. Bernie Alder, for example, did particle dynamics but it wasn't always tied to the Lab's programmatic effort. Today, that is the basis for Computational Materials Science.

He was able to do all that because he was on the Academy of Sciences; he attracted good people or something like that. But I'm not sure that any of the molecular dynamics models that he and Tom were working on did anything directly for the Lab, except to use machine time.

GAM: Well, they polished ideas in Monte Carlo techniques through those codes. And they also polished ideas about how to do shell computing: You don't have to search every point, you just find a sphere that includes these points, and then you can stay inside or outside of it, and things like that. In fact, Norman had a great deal to do with that, too, of the so-called neighborhood technique that he developed for making the STEP code run fast.

PC: Yes, he had his finger in a lot of things, Norman did.

GAM: Well, that's what made him so good, you know? The story is, he gave up in disgust in the early days, because FORTRAN wouldn't compile the big design program then being used. So, he sat down with the program FORTRAN deck, and he wrote the assembly program on a keypunch!

PC: Really? You know, what I remember is that for that program, Leo Collins was the first programmer.

GAM: Yes, I think that's true.

PC: Leo Collins was a botanist.

GAM: Oh, was he? I didn't know that!

PC: Yes, he was a botanist! I mean, we didn't know the word "programmer" in those days, or "computer scientist"—what is that? We were all called "coders". We wrote machine code, and then some of us learned how to do FORTRAN. And I remember there was a parallel version that Frank Holden was working on for the designers. But that didn't work. Then Bill Schultz flowcharted everything. I don't know if any of his flowcharts still exist. Now, there's a person who should have gotten the Lawrence Award.

GAM: I quite agree! By the way, Bill's flow charts are still relevant, and some of the originals are saved in the Lab's archives.

PC: A Lawrence award for Schultz is something that we tried—Bill Zagotta worked very hard at trying to make that happen.

GAM: That's good!

PC: This was after Schultz left the Lab. Zagotta tried but it never happened. And I think that's one of the many unfortunate things we can blame on the administration. What they did, was to deny Bill Schultz that honor.

GAM: He's the guy who established, by way of that design code, big, big computations. It is also clear that his work was the biggest justification for our getting Supercomputers.

PC: Yes, exactly. A long computation in those days was 300 hours. And I think that's always held true, that 300 hours is about the amount of time that a human being can devote to a calculation. By the time 300 hours of calculation have gone by, you've forgotten what the question was!

GAM: Just right.

PC: And that design code has evolved to the point, these days, where it can be now less than a five-minute calculation. Machines have changed so much. But now you get your answer to a 2D hydro calculation in a very short period of time—about the time that it used to take to get a 1D result. It's really amazing. Yes, you should interview Bill.

GAM: If I can find him! I tried once before to find him, but I couldn't.

PC: He's in Berkeley. And I'm not sure how—I think he still has bad feelings about the Lab, and so he might tend to froth at the mouth a lot.

GAM: Let him! It certainly historically true.

PC: Yes.

GAM: Well, it seems like you've reviewed your memories, so this is a good time to stop. Pat, I want to thank you for taking the time to reminisce about some of your early Lab experiences.



[1] The dd-80 was a very high-speed display system built by Data Display, Incorporated in St. Paul, MN.

[2] This camera was called a flight-research camera that received a pulse for each frame; it was originally designed for spark chamber work and was adapted for use with the dd-80.