An Interview with Dan Patterson

Dan Patterson


DP = Dan Patterson
GAM = George Michael



GAM: We are interviewing Dan Patterson today, the 12th of November, 1996.

DP: It's nice to see you again George, you squid.

GAM: Nice to see you again too Dan, you squid, you remembered, Tommy Udo, right? You taught me that! Well, why don't you start by telling us where you came from, where you got your degree and why you came to the Lab and stuff like that? Go ahead!

DP: I got my degree at Sacramento State in 1955 and I heard about the laboratory because five other classmates were looking around for jobs. They found a notice hanging on the bulletin board and said, "Let's go down and see these guys" and so we took a ride to Livermore from Sacramento and had a short discussion with someone in Personnel and they said to send in some application blanks. We went back and filled out application blanks, came back again and filled out Security PSQ (Personnel Security Questionnaire) requirements, so they had all the paperwork done. Bob Mainhart conducted my interview and he had a little test. In the test, there were some questions on relativity, I answered the questions and he asked me, "What do you know about relativity?" I told him "I don't know anything about relativity. I had a couple of classes and I understand what I was taught, but I don't really understand anything beyond that." He said, "That's a good answer! We will teach you what you need to know." So that started me off working with Sid Fernbach, Frank Bjorklund, and Noah Sherman. When I got my clearance they called me up and I started July 5th. They put 15 or 20 of us new people who would be programming in the cooler and started us first to use the IBM 650's. The cooler was in a building right next to the main entrance to the Lab. That building is still there. They were teaching us how to use the computers the Laboratory had. They gave us some instruction, books and cards with instructions on them. They didn't talk much about the UNIVAC, but they did talk about the (IBM) 650 and the (IBM) 701.

GAM: Actually, the 704 also by then, I think.

DP: No, I don't think the 704 was in yet. 704 was the first floating-point machine wasn't it?

GAM: Yes.

DP: That wasn't in yet. We had CPCs. They didn't tell us anything about programming on the CPCs either. Edna Viennop, Ralph Kierstead, and I think one other person, came in to give us programming classes. This went on for about three weeks and then they asked us to pick out something to do and they would take us down and let us try it out on the machines. So I picked out an equation for calculating square roots and did 20 square roots in the interval from one to hundred and programmed that up. We went down to the 650 and put it on the machine. After a minute or so, they said it looked like it was caught in a loop. They said, "Let's let it run a little bit longer and pretty soon the printer started to print. My first programming effort wasn't quite flawless. It was flawless by the time I got it to the machine, but it wasn't flawless when I started because about a half hour before we went to the machine I found a mistake. I was frantically trying to punch a new IBM card, but didn't have the time. I used some chips to plug some holes and punched some new holes in the existing card and put it back in the deck. So my first effort worked on the 650.

Then after we got that minimal time of training, they took me up to the other end of the Lab, the West side of the Lab, and I don't remember the building, I think it was 161, the old hospital building. They put me down in the Solarium, in the end of the middle wing with two or three other people. They assigned me to work with Royal Daw, who was working on the UNIVAC. They gave us equations for the POP [1] code and Royal started out. I watched what he did for about three weeks and he basically did the programming with me looking over his shoulder and then I took over the code and started to run it. Because the UNIVAC was hard to get time on, they said "Why don't you try to do this on the CPC? The CPC had 45 instructions on the plug board and 8 registers and it took 1 second to read or punch a card. I looked at what we were trying to do and there was just no way we were going to get it on that machine. The 650 used interpretive code. It was 2000 word memory and had an interpretive routine that would allow you to use floating point numbers. But it was very slow and used up most of the memory. So they said, "Why don't you try it on the UNIVAC? It's much faster," but it only had a 1000 word memory. So that's when I started working with Royal and he sort of laid it out and we started writing the program. Then they decided we needed another routine to set up the memory, so we put different parameters in so we could set up the code and once we had that part of it working Royal was off working on something else. Then they said, "We have this paper by Abramowitz. You'll have to do some calculations to set up the parameters and then load them to do the calculations. So I worked at it and started the programming process and it turned out that code was bigger than the main code. This had gone on for several months when Noah Sherman came around and wondered where I was and asked if we had run anything yet. I said no, I was still working on this. He came around a little while later and asked, "What are you doing?" I said, "Well, I'm trying to do this Abramowitz paper, it's more than I thought it was going to be". He asked for a copy of the code so I printed one and I gave it to him. He came back a while later and said he didn't realize it was going to be that big on the front end of this. We finally got it going and it turned out it took much, much, more time than they had anticipated. This was after about a year. We basically had it running, all the bug shooting and it would run, but it took way too long. About that time the 704 came in and Isabelle Blandford was new at the Laboratory, so she picked that up and reprogrammed it for the 704. Then I started to work with Mike May's Hydro Group, working for you and Dana Warren. That was the beginning of my Weapons career and I believe it was one year working on the POP code and then we started working on the weapons. And, as I remember, it was only a few months after that, or some short length of time, when over at Berkeley they had discovered, they had the experimental evidence for the existence of the POSITRON. Everybody was looking for it, and they had it. We changed our (the Daw-Patterson) code and it was used to calibrate the characteristics of the POSITRON. They were the first ones to do it. As for me, it was weapons from then on.

GAM: All these years?



DP: Yes, well, one part of that we got into some questions about the difficulties of underground testing. I got into that at the same time I was working on the SPARTAN ABM system.

GAM: That was much later?

DP: That was in the mid 60s and I was working two full time jobs during that part of it. Then we went back and looked at the machines. I remember, during the moratorium, we got the bigger machines and that gave us the first chance to put some tabular equations of state together.

GAM: Was this connected with the system that Dick White and Bill Lokke were developing?

DP: Well, Von Holdt developed the first interpolation scheme. And we had a whole tabular set that was developed for that particular code that we were working on and then Lokke and White came up with another scheme and that was the next one that got used.

GAM: We used the first one in the code you and I worked on. I'm referring to these old programs mostly to fix things in terms of time because, obviously, these things are much better developed now. This work puts the date as prior to 1958.

DP: Yes! Yes! Well, we still used that code after the moratorium.

GAM: Oh yes, I know. I spent a great deal of time trying to make it go faster and I succeeded. And part of that contribution came from the fast table lookup used for both equations of state and in extracting square roots. Turns out it is very fast if you just know how to do things the right (binary) way. What I'm interested in is your perspective; you've been in this program for a long time and part of my idea on recording all this is to expose the differing ways, as they are, of looking at computer use. A person who is a computer scientist is going to look at a computer differently from one who is an applications programmer; he is going to look at it differently from a person who is a code developer. These are the kinds of remarks I'm looking for; especially from you. We had Carte Blanche for many years at the Lab to get the fastest machine we could find. There was no argument about not needing the high speed.

DP: Biggest memory or the fastest cycle time.

GAM: Yes, and I think some of our work showed that speed alone wasn't the answer. We had to have a lot of good stuff around it, like programs that reduce big tables of numbers to pictures. Curve fits and things like that so you didn't have to look at all the numbers, but you could see a picture or just a small equation that described all those numbers.

DP: That's one of the things that I think was one of the real advantages of having those kinds of machines that didn't run fast. It took us a while to get the calculations and you had numbers printed out and instead of getting somebody to plot a particular parameter out of it, you looked at the numbers. While you were looking at them, you saw the other numbers around it whether you liked it or not. When you started your plot you would see these other numbers and that would trigger you to say "Well, why is this number over here when that number is what it is, and so you got much better insight into what you seeing. We were able to better understand the physics models by using that more global approach. Now, what I see is the kids all plot a graph on this and a graph on that and they haven't got any idea what's next to it or if they are looking at some particular region in space. They look at that one only and they don't see what's around it, they don't understand why it got to be what it is. I think that's a real disadvantage for them. It's a perception process, and now we've lost our microfiche capability. We are now on an electronic mode of doing this and I don't believe it is anywhere near as efficient as having two film readers comparing two problems together side by side, look at the numbers, see what you are. Now, you have to go in and do a lot of maneuvering with the computers to get a few things out to look at and it doesn't tell you anything like what you could get the other way. I think it's a real disadvantage.

GAM: Yes, In fairness, probably you can always write routines that will do what your eyes did when you compared two fiche. But they're not written, and they take a long time to develop, and they are very specialized.

DP: Well, yes, you can, but nobody does it.

GAM: That's true.

DP: There's not the time. One of my perceptions of the computers is when we were in those days; we would get a lot more time to discuss the problems, a problem, and a physics calculation. You could look at it, it would take you a while to calculate it, you would go to consult with other people about what you were seeing, they would tell you to go look at other things. It gave you a chance to really think about what was happening and now as we've moved on, things have been faster, more zones, better physics. And the more detailed, with more physics it gets much harder to look at the details, because the memories are so massive now you can overwhelm your calculations. Things that you worried about before which actually taught you something about what the physics and mathematics were doing. When you are overwhelmed you just take it on faith the calculations are accurate and that's a serious problem. How are you going to vet the code, how do you know it's been checked out?

DP: Every time I had a serious problem to calculate I spent a significant fraction of the total calculation time checking the code to make sure it was in what I thought was the right domain. Having come through the code end of it, I got a better feel for how you get into the code and what kinds of problems you run to check it to make sure it's running right. Those kids that get a big code handed to them and haven't come from the days when you could actually go probe the person who wrote it and ask him what's there and get a straight answer. And then figure out what kinds of problems to run, are really at a disadvantage. Now, we just take the code's capabilities on faith, and that's not going to be good enough and so we've got to regenerate that culture where you don't trust the codes. The real answer for my success if I have any one key to what has been my success over the years is that I didn't trust anybody. I learned along time ago don't trust anybody, especially don't trust yourself. I used that as a guide, plus the fact that we had a tremendous infrastructure and the support was massive. You could certainly be a failure in this process if you didn't take advantage of the, massive infrastructure that helped to get what was needed for designing.

GAM: It was a team success.

DP: Absolutely, it was a team of people that didn't think of it as a team, but it functioned that way. Everybody helped to get whatever was there.

GAM: So, apropos of your remark that we've got to get back to this older way of doing things, are you doing anything in that respect now?

DP: I'm trying to make that point to the younger designers coming up. I think they have a hard time understanding what I'm talking about. Today we don't have enough people being trained. Right now I would characterize our training process as failed. It's a failed process, we don't have enough people to back up the rate at which we are going to lose the experience base and much of our data is going to be lost because we don't have people trained to interpret it.

GAM: You mentioned losing the microfiche capability. Was there anything you think that you might have done to delay that? We got rid of 6 FR-80's to save some small amount of money I'm told. That's where we were making these fiche.

DP: Gosh, I don't know! If technology comes back and gives us something as useful on CD ROM's or whatever it is, I would say we should go back and at least have that kind of capability again so people can look at such comparisons.

GAM: But you don't have any active effort to find that stuff now? You know, in the technology?

DP: I haven't had any money to assign a group of people to go solve that problem. What I do is raise it as an issue and ask people what is available on the outside and they come back with various options. Much of what has happened since say, 1980 on, is the result of the emergence of the PC's. Everybody's PC setup is different from everyone else's so you don't sit down at someone's terminal and just operate. The software is set up differently, so each unit is a separate item on it's own. This non-standardizing leads to people developing their own styles of approaching problem solving, which I think then gets this over into an almost artistic sense, which I think is not scientific.

GAM: You're right about that.

DP: We should have a (not that we want to limit ourselves,) uniformity so we can converse as though the languages were the same, and be able to understand how someone else is operating.

GAM: Have you participated in any of the procurements that we've gone through over the years here?

DP: Not really, no. I've not been in a position where I wasn't making any input. I think now with the ASCI push to do things in three dimensions that our problem with validation is going to become a formal process. Before, it was up to the designer to do his own validations. The designer is still going to have to convince himself that the codes are reasonable and right. But, there will have to be a more formal approach to these massive machines and massive codes where you build in checking routines and checking processes so that you can interrogate the machine while it's running to find out if it's doing the right thing. I don't know how you're going to do that!

GAM: The new designers will need new ways to carry on. How about some of the other questions in the memory jogger I sent to you?

DP: Let's see. Favorite computer languages? FORTRAN! Well, the machine language wasn't that bad, except we had to do a lot of stuff over and over again.

GAM: Well, not really.

DP: I mean everybody had to go redo everything. Remember the first thing on the IBM machines was to write a loader, because if you couldn't write the loader you shouldn't be on the machine. Then, after that, it was write the machine language. But, then, FORTRAN makes it a lot easier to transfer between machines and it has continued to evolve.

GAM: But FORTRAN brings with it the difficulty that you were mentioning in terms of the other aspects. These new young guys, the new users of the machines, have only a FORTRAN sense; they don't have this sense of presence that comes from struggling with the entire code and understanding how it's put together and understanding what each part does, and so forth. You were mentioning that before. We didn't have fiche; we had to look at stuff on line. FORTRAN has that problem. But, I must admit it's like a crossbow in the programming world.



DP: Well, now they've got C, and C++, and object oriented programming, of which I have no understanding at all. I do understand that it comes from a very different slant, but I also know that there 's no free lunch. And if you're going to program something, you can assume that somebody programmed it someplace in some kind of a language. Now, you may assemble it in some overall modular approach, but somebody did the heart and the guts in some fashion. What I'm hearing, from some of the more successful people, not those necessarily recognized in the broad sense, but the real ones that I think are successful because they get something done, are saying the FORTRAN 90 is probably the way to program these things. You can build your module so you can do things with C++ the object-oriented system making it easier to handle and manage. I don't know, that sounds like it could be just another fad that's going to run up against whatever its limitations are and you'll have to go around them in some fashion.

GAM: There's high-speed FORTRAN, etc.

DP: Much of the problem is the volatility of the computers, you don't have time to finish a code before the next machine is out. Even these, not PCs, but the next level up, are so massive and so capable compared to what we had before. They change out so fast, by the time you get something as complex as what we're trying to do and even more complexity and more physics into it they never have time to check it out. They're all doing the next machine and that's what I think is one of the real disadvantages of the era we're in now. The answer might be that once you can build things modularly you could take a lot of people and give them all pieces and they'll assemble it all together and hope that it works. Instead of having a mastermind that puts the whole thing together and does it himself.

GAM: I'd like to disagree with you, just about these new machines. I do agree that they have faster arithmetic units and they have bigger memories, but they do not act like balanced things. You starve getting operands out of the memory up to the arithmetic registers; you starve trying to move stuff from the memory to I/O devices and vice-versa. They're not fast at all, the 7600, the real CRAY s, will run circles around these other machines that don't have the I/O and memory bandwidths to match that of the arithmetic processor. They aren't as nicely balanced as the Cray machines.

DP: Yes, I'm very nervous about the future of where we are headed. Because, I think, just as you say, the real functional things that you want to do to get our questions answered are becoming so confused that we may not be able to solve the problem or do it in any kind of reasonable time. The other thing is, typically, and this is an observation I've made over the years, that the Laboratory always cut a pretty sharp deal with the computer companies. So the Computer Company, in order to get the job, always bid just a little lower or a little bit shy of what we asked for. We wanted the operating system if they had it or we wanted whatever we wanted and by the time they got around to do it, it cost them more than what they had signed up to do. That cost put them either behind the rest of the industry because they were spending their time trying to get the machine delivered to us the way we wanted it, or when it started to run it wasn't running quite right. Everybody saw that, so they put more effort into it. So, because of the sharpness of the deal we broke em, they went broke, periodically, or put them at a disadvantage. That's just a general observation, not a rule, an observation that I saw. I see that happening now where the big machine companies can go out of business now before they've even sold one. They can have a good idea and while they're out front making deals with a limited number of customers they either fold up or they only make one machine. What is that for our future, that's not a good trade?

GAM: Like it or not, it appears that the Laboratory is in the backwater on the business of getting big machines, fast machines, new machines. The people don't even come here anymore to tell us about them. Were that the case, you could invite the people who are leftover from Seymour's last company to come here and talk about the plan that he had developed, one nanosecond cycle times, commodity parts, cheap.

DP: They're not even around.

GAM: They're around. They went over to NASA-Ames and talked. They've been to various agencies in the government, you know the ones, and have talked, but no one comes here. I think that since our STAR experience, it's been less and less the case that we have followed the large machine path in computing. To a large extent, that is your fault and I say 'you' as A Division. You represented the reason for us pushing high-speed computation, for going for the big stuff, and if you didn't do that it didn't happen. Computation Department by itself doesn't justify high-speed machines.

DP: If you roll things back to the Star Wars days and the final days of the Cold War, we were spending all of our effort trying to generate this new defense or answer to a threat and we spent all our time working on those with reduced budgets. The budgets have been coming down since the mid 70's. And have been coming down very fast in all aspects. So even if we had asked for something, we wouldn't have gotten it, because the focus was other places.

GAM: Well that's surely a sad state of affairs.

DP: Well, if I had asked for it at the low level I exist at, I would not have gotten it through the Laboratory management because I could not have made a plea strong enough to get it by.

GAM: I think we spent an enormous amount of influence and money on false alarms. Had that been more accurately aimed, things could have been better. I could cite you chapter and verse, but I don't see value of belaboring it.

DP: Yes, I go along with that. But we were diverted. The Division was diverted off into other areas and the focus was on other things.

GAM: But, the more important thing now is that having, in a sense, recognized that this diversion occurred, we can change course and more correctly aim at the real targets that you think are important?

DP: Well, ASCI is going to be the major vehicle for that because everything will be done in ASCI because ASCI has the money. If we can get our act together, and say what it is we want them to do, then its going to be up to the designers to say it. Everybody says it's for the designers and the designers had better get their act together and tell everybody what it is they want. The designers haven't done that yet.

GAM: The designers, you claim, are not a healthy mixture of old timers and fresh new ones. Mostly they are fresh new ones who have no experience in this trade.

DP: That's true. That's just right and, in many instances, it's computer scientists or computer builders, code builders, who have not got the message from designers of what they need. It's the designer's fault for not getting them the proper information. Also, there are not very many designers left. Right now we go through fifteen major reviews a year, which is once every three weeks. We spend all of our time answering questions for the National Academy of Science, the JASONS, and all these panels that come through, and we don't have time to sit down and do our real job. That is what's wrong. These panels have not been here forever, they just started up in the last two or three years. Once we get a better understanding of what it is and get them satisfied that we know where we are going, and that we are going in the right direction, then we'll have more time to do these problems. First, we've got to get past the initial surge of these and get things under control, and it's looking a lot better in the last sixteen months.

GAM: Good!

DP: I remember one time, when we were running a problem, and you had said the thing had been run seven times before on the 701 and each time it gave a different answer. Because the Williams Tubes (Ed: memory) dropped bits and then one day it stopped working. The machine was going wacko, the machine wouldn't work, and wouldn't work, and nobody could figure out what it was. Finally, somebody stumbled onto the idea that the thing went wacko every time somebody opened the (building's outside) door because, then, the Williams Tubes were exposed to the sunlight. It was later in the year and the sun had dropped down and just at that time when the sun shined on those tubes it upset the memory. So they put a black curtain on there and the machine went back into business again.

GAM: The only thing that is incorrect about that story is, I tried fifteen times, not seven. I saved one of the Williams Tubes as a souvenir. You know they were breaking them when we decided to trade in the 701s, and they were going to put core memory in there eventually because Prof. Cunningham, the astronomer at Berkeley was being given that machine. They gave him a core memory. But I saved the tube, and it's in our museum collection somewhere.

DP: In the Museum?

GAM: What's left of it, yes. This guy, who is President of the Northern California Computer History Association, and Gordon Bell and his wife, Gwen, although it's still just rumor, are planning to take our collection, and I understand they may even have some permanent exhibits around the bay area.

DP: They ought to put the collection in the Smithsonian.

GAM: Well, we tried, we did offer some stuff to the Smithsonian, but their budget wasn't very good either. For instance, we had serial one of so much stuff including the IBM 1360, the Photostore, which was a revolutionary thing when you think back on it. They couldn't accept it, they were happy with pictures. That was the same for the STAR.

DP: Just take pictures of the machines and put them on the wall.

GAM: Absolutely, and they put them up on the wall. I arranged to get them to the computer museum in Boston. They couldn't take the STAR either, there just wasn't enough room. The STAR was a huge machine. It cost us quite a lot of money.

DP: The 650s were a nice little machine.

GAM: They were very nice.

DP: Reliable, drum memory, they didn't go very fast, but they were reliable and didn't take up much space.

GAM: I should arrange for you to read Joe Brady's interview; very nice. He tells a story about how he was able to develop his orbit calculations, and how it was the only thing available when the Sputnik went up, and it was used by NASA to predict the full orbit since the Russians refused to provide such data about Sputnik.

DP: He was the only one doing double-precision arithmetic in those days.

GAM: Yes, but it turned out you didn't need double precision for the in-close orbits. So they were using a version of the code that Nevin Sherman had developed. When Nevin moved it on to the LARC, he couldn't get it to agree with his own estimates of the numbers, and he and Jack Noonan eventually traced that difficulty to a logic error in the LARC's arithmetic logic controls.

DP: See? You can't trust anybody or anything!

DP: I meant to mention this earlier. When they were trying to measure the efficiency of running the time sharing system, compared with running a batch of the sort that we started with, Hans Bruijnes compared the numbers of cards they had processed; 2000 cards in a day and so on. They came by in a few days later and said; "Well, we processed 3500 today," and I grabbed them and started complaining to them and said; "Yes, of course you did, because we've got the same ones we had from every day. We just keep adding more to them and none of them ever run. There's more than two decks in there; why don't you report what was running on the machines? " You can get any kind of answer to fit the current political situation. It all depends on how you want to cook the books.

GAM: Yes, that's true. In interviewing him, I learned that Sid found him extremely effective. Hans could get things done.

DP: Oh, he did, he got out the fact that what he was reporting was a measure of using cards and he was telling us that he was running some cards through there. So that was a way of showing that he did get things done. He did, and he listened, he listened to what we were saying.

GAM: He was quite effective. When I interviewed him, he was also pretty generous about acknowledging the other people who worked with him that really made things fly. B Division, in particular, benefited greatly from how he was able to extend the IBM monitor batch system. That's how they did most of their calculations, whereas, I think that A Division followed the time-sharing path a little more closely.

DP: Yes, we had a lot of people who set up and were doing development under the time sharing system. A lot more development and a lot more individual reporting was possible and with no real inconvenience to others.

GAM: Yes, you had Norbert Ludkey, Ed Goodwin, Bob Cralle, and people like that who were helping with these generator codes.

DP: Yes, the generators and post processors. But the designers would all prefer to set up their own individual problems. When we batched them, they complained that we were controlling them. The time-sharing system helped to set them free but, in the early days, there just weren't enough terminals to go around. Just the same, those were fun days. I remember, one time, just trying to set up a forty-five second generation. It took us a whole day to find a Teletype that we could use because there were so few. We used to gather around someone typing on one and make snide remarks until we got him off of it. For forty-five seconds: it doesn't take long if you can just get at a terminal. Now of course, everyone has his own workstation, but frankly, I'm not sure we made any real gains.

GAM: It was an exciting period to go through, no question about that. It's been my claim that a great deal of the things that were done, were done essentially as firsts in the entire industry and they never got reported nor credited. The official attitude around here was that a weapons lab had no business doing system development. That's one of the things these interviews are intended to fix.

DP: I was thinking about that the other day. When people write things up now, or when they write a paper on something, that's proper. We never wrote. Millions of quality papers were possible and we just rode right through them; we didn't have time to write anything up, we just kept going. We didn't tell anybody. There wasn't particularly anybody who cared a lot.

GAM: That's what we thought.

DP: But on the other hand, there were a lot of outstanding things done.

GAM: I guess we've about done. When I finish you will be able to enjoy reading about the few I've been able to uncover. It'll be fun. Dan, thanks for taking the time to chat about our early days.



[1] POP was a code to calculate the physical parameters according to theory of elementary particles.