An Interview with 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
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
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  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
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
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
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
GAM: But you don't have any active effort to find that stuff now? You know, in the
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
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
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
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
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.
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
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
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
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.
 POP was a code to calculate the physical parameters
according to theory of elementary particles.
For information about this page, contact us at: firstname.lastname@example.org