Abaqus founder interview 2019 Dr. David Hibbitt:evolution of an engineering simulation software venture
n5321 | 2025年6月15日 08:42
Welcome everybody, welcome to the seminar series. This is the CEE seminar series, distinguished speaker series of the Department of Civil and Environmental Engineering, founded in honor of Professor Chiang Mei who had made major contributions in fluid mechanics in the department. The series aims to host a range of speakers from a range of disciplines that are relevant for CEE, but also the broader MIT and the community.
And so to see the range of topics that we cover you can go to the website written just behind me, we assess that mit.edu, where most of the talks are recorded that you can use for resources. You'll find we try to have talks that have pretty broad appeal that you can basically learn a lot from. So for today we have the pleasure to have Dr. David Hibbitt as the speaker of our distinguished speaker of the day and I will leave his introduction to my colleague Oral Buyukozturk. Thank you Lydia.
Oral: It is indeed a great pleasure for me to introduce our distinguished speaker today, Dr. David Hibbitt. David received his BA in mechanical sciences from Cambridge University in England and a PhD in engineering mechanics from Brown University. He founded Abaqus in 1978 and was the CEO and the chairman of Abaqus until its acquisition in 2005 by Dassault Systèmes. David is a member of the National Academy of Engineering. He received the American Society of Mechanical Engineers' Timoshenko Medal in 1993 and a Brown University engineering alumni medal in 1997.
Just a personal note that I met David ages ago in Providence, Rhode Island on the east side, Brown campus, while working on the development of a nonlinear finite element program. We were in the same office for about four years. Then I left for MIT. He made a better decision. All this time we were disconnected and we reconnected again at an interesting event. And when I saw him again, I asked him why he misspelled the word abacus. Maybe he will explain that.
I would like to thank David and Susan for making the time to come here today, and I am sure he will have a lot of interesting stories. We look forward to his talk and I guess, David, it's all yours. Thank you.
David Hibbitt: I'm supposed to switch myself on so you can hear me. I hope I'm not too loud or am I okay? First of all, it's really a treat to be here and I have to thank Oral for inviting me. It really is a great pleasure. I've seen a lot of old friends here and I have to say, even some young friends. So I think it's a delight. This is really about a company and that's what I want to talk about. I've called this a description of an engineering simulation software venture and you'll notice on the bottom I use the dictionary definition of venture. It's an enterprise in which there's considerable risk of loss and a chance of gain. So in those, you're much more likely to fail than succeed. And this is where I spent the bulk of my career.
And I've got, I split the talk into five parts, and I'm going to begin with a historical sketch. And I'll go right back to January 1978, which was a cold winter in Rhode Island. There were two of us, myself and a guy called Bengt Karlsson. We were each 33, we'd done PhDs in engineering, had about seven years of work experience. We had no computers, no software, no customers, almost no money, and no formal business training. So it wasn't the most exciting start. We'd failed to attract any investment, so our short-term financial plan was very simple. We had enough in the savings account to pay our mortgages and feed the family for a year. So we'll have a go for a year, and if we can't generate enough revenue by then to carry on, then we'll give up.
So that was very simple, but we knew what we wanted to do over the longer term and we had some pretty clear objectives. The first was to develop software to deliver engineering simulation into an industrial environment, primarily finite element methods for solids and structures. So the key thing is, this is for engineers who are working on the design cycle. They've got to get a design qualified within a certain amount of time, so the software has to be robust. They must have reliable tools. We wanted to compete by providing capabilities needed but aren't easy to develop or support, so large heterogeneous models, nonlinear behaviors and so on. So for us, it was mainly, the motivation was primarily the intellectual challenge of trying to pull this off and make it work.
And thirdly, we wanted to work for ourselves. We wanted to make our own decisions about what we were doing. We did have a business strategy, although I think we never thought of it quite as formally as I'm describing it here. First of all, we wanted to be a product company. We wanted our revenue to come primarily from selling or leasing software because that gives you a pretty stable revenue stream. If you're selling man-hours, you're only billing when you're charging billing time. If you're selling software, people are using it on the other side of the world while you're sleeping, and they're paying a license fee, so that's a good idea.
Secondly, we wanted to focus on organizations with demanding requirements so we could basically win by delivering value, delivering something they wanted to use in their engineering operations and they were willing to pay for because they couldn't get it many other places. So we didn't want to compete based on price, we wanted to compete based on functionality.
But we also always wanted to keep in mind who our customer really is. It's very nice to be able to say, oh well, Boeing or Toyota or what have you use our software, but in the end we always said the customer is not the company. The customer is somebody like us, it's an engineer or an engineering manager who's made the decision to use our software to get his or her job done. And we better not let that person down. So our customer is always the individual who needs to have this software as a tool that he or she can use to get their job done.
We wanted to go into niche markets based on understanding what functionality a customer really needs and then address their problems. And we needed to address the opportunities worldwide because we're going after niches, you've got to have enough business to have a viable business. And so you've got to go all over the world. But these are complex simulations, so you really have to provide skilled technical support. And that has to be in the local language, at local time zone. If you're in Japan or China and somebody gives you a hotline number in Rhode Island and somebody's speaking English, that isn't going to work very well. So we knew if we were successful, we'd put local offices in place all over the place, staffed by engineers like us who just wanted to help people use this software.
And finally, we wanted to be pretty conservative financially. We just didn't want to worry too much about business issues. We wanted to keep our focus on the technical issues.
The product strategy was the usual engineer's approach: design and then build. Design what you're trying to do, then build it. So our design basically in those days was really three manuals. We began with a user's manual. These are the days when there was no computer graphics or screens to input stuff and so on, so people put in lines of input, got out lines of output. So we wrote a user's manual to put user convenience and ease of use first, to make it easy for people to use the software.
We then designed the software architecture, documented in a systems manual. And we saw the software primarily as a data management system with some engineering routines that were basically accessing those data, working on those data, putting them back into the database. So the core of the software was primarily data management, but there's engineering functionality that talks to or with those data. We wanted a very general architecture that would give us the broadest anticipated functionality. And we also designed a modular code, the idea being that of course we wouldn't get it right first time, but we wanted to be able to make sure what we got wrong we could replace a module rather than redoing the whole thing. And of course we had to have a theory manual.
We had a tactical approach and that is, we wanted to get into the market quickly for the obvious reason that if we didn't get some revenue by the end of the year, we were out of business. And so what we said is, okay, we'll pick out a problem or a couple of problems where we know somebody will pay us to deliver functionality. Deliver that engineering functionality, and then for this core software, all the backbone of the software, we'll develop just enough to support that engineering functionality. So essentially, more or less a single-use code, but then work out from there, expand out from there.
So that was the concept. And now, here's where it happened. This is the first office of the company. This is actually my house. It's an 1815 farmhouse in rural Rhode Island. And the first engineering office were these three windows here. That was the front parlor of the house and that's where the engineers sat. The back of the house there was a dining room with a table, and that was the administrative side. And that was my wife, sitting behind or in front of a rented IBM typewriter. So that's where we started.
And now I'm going to jump forward a whole year and we've already expanded gigantically. We now have three engineers instead of two. We've survived and we've grown by 50%. That's not bad. And here we are, and it's a very typical American technology business. We're all immigrants. This is me and I came from England. This is my original partner, Bengt Karlsson from Sweden. This was the third man in, our third partner, Paul Sørensen, who grew up in Ecuador. So there we are. You'll notice no sign of a computer. That's because this piece of furniture in the back here is a filing cabinet for punched cards. And this stuff on our desk are the stacks of folded paper that came out of the printer. And the way we accessed the computer is we had to go and bow to the computer, it wasn't sitting on our desk. And the computer we bowed to was up in Waltham. It was a CDC so-called supercomputer. So we commuted 60 miles each way to that data center to get computer time. In those days it cost a thousand dollars an hour during the day, which in today's money is four thousand, but at night, between midnight and 7 a.m., it was only 400 an hour. So our working day was to essentially drive up to Waltham, sit by the computer from midnight till 7:00, then go home, figure out what went wrong and what we're going to get ready for the next night, get some sleep and repeat it. So that was the way we got started.
So now I'm going to jump forward 26 years to the spring of 2005. And by now we've got several hundred engineers in our offices—engineers, mathematicians, computer science people, and support staff. We've got 28 offices around the world. It's a wonderful culture, just smart people, loyal, dedicated. We've got a healthy growth rate, we've got strong product plans for the next five to seven years and we don't have any plans to do anything except get on with it.
And this just shows you what the office looks like. It's no longer the front room of my house. These were two old mill buildings, about 120,000 square feet of space in Providence, Rhode Island. There's a nice atrium between the buildings. And this is just a picture of the interior of the atrium with some of the headquarters staff milling around for some event. And it was just a great place with great people in the office. Many Americans, but also a lot of immigrants like us. And just out of interest at this point in time, I just had a look at where we all came from. And this is the list of countries. You can see 29 countries here. We had people from every one of these countries in the office. So it was just a wonderful community, very cosmopolitan and we had good fun working together.
Then Dassault Systèmes arrives and they propose to acquire the business. DS are a major supplier of what in those days was called product data management software and related engineering software. If you're a big engineering enterprise and you're building complex engineering products, all of your data for those products sits in the PDM system. Their big one was called CATIA. So for example, if you're Boeing, a commercial aircraft nowadays typically has about 20 million parts in it. All the data for each of those parts—the engineering drawings, the material specifications, the supplier and so on—are all in their data system.
So what was being done with Abaqus is the data would be taken out of that system, a model would be made in finite elements to go into Abaqus, they'd do some calculations in Abaqus, find out they had to change the design, go back into this PDM system to change the design, then bring the data back out again, do more calculations and so on. And the interface between the PDM system, where the engineering data reside for that product, and the analysis code like Abaqus sucked down a lot of man-time because the way Abaqus wanted the model put together was different from the way it came out of that system and so on.
So it made a lot of sense to build our analysis software into Dassault Systèmes' PDM system. That showed a significant value to our big customers, and we had a number of large enterprises using the code. And so we felt that would provide stronger opportunities for our younger colleagues. And so we did the transaction. They bought the company. They renamed it Simulia. I thought that was kind of an odd name, but that's what they chose. And the idea is they wanted to have essentially simulation-based engineering. So they were trying to develop a suite of software which would allow you to do lots of engineering problems primarily based on simulation. And Abaqus was really the first component within that suite of software. And after some years to absorb the acquisition, they have indeed made a number of acquisitions. So if you look at Simulia now, Abaqus is still a very big part of it, but lots of other pieces go along with it as well.
And by now, the last check I made, there are about 1,400 employees in the company worldwide. The headquarters is a rather nice building in a sort of a nice office park that's fairly close to Providence. It's in a town called Johnston, near Providence. And it's only 10 miles from that farmhouse where we started. So the company hasn't moved very far, but it certainly has come a long way in terms of the number of people it has and just how the technology has developed.
So that's the history. Now I'm going to just turn to the technology and I'm going to start by showing you just some examples of applications. And the first one is here, and this was actually the first application we did with Abaqus. It's called restraint for a fast flux test facility. This is a liquid sodium-cooled reactor, a very high-temperature nuclear reactor. And I can describe the problem very easily. You can see this is the core of the reactor. These circular things are actually hexagonal external section tubes. They're like a beam. The fuel pellets are inside them, and they're held together inside these restraining rings on the outside. And the whole mechanical problem is simply to hold those rods together so the physics will work, so you can refuel the reactor when you have to, and so it'll stand up to the safety cases if there's an earthquake or something like that.
Mechanical issues are pretty much shown here. There's creep going on because there are such high temperatures, radiation swelling, temperature-dependent properties, there's contact and friction between the rods and between the rods and the restraining rings, and they have a deforming hex section. And the tolerance is very tight. So we had to use Lagrange multipliers to impose the contact conditions to get the accuracy. Of course, the loadings, as you might expect, are large, with thermal cycles, non-uniform irradiation, and so on. So this is the first application, and delivering this actually saved us. I learned about this problem in June of our first year. We delivered the software at the end of September, and it worked in the sense that it did the test case, didn't do anything else, but it did. We got paid and we got a follow-on contract, so we were off.
I'll next show the second Abaqus application, and this has to do with offshore oil fields. And this is just a little picture, if you like, showing our offshore oil installations. You have surface equipment on platforms, some of it's floating. You have risers that go from there to the seabed. Remember that the water can be hundreds of feet deep, so these are pretty flexible pipes going down. And on the seabed you've got wellheads, you've got manifolds, you've got a bunch of pipes around on the seabed to join these together. And the basic problem is installing those pipes. And that doesn't sound like a really difficult problem, but what makes it difficult is these are very long, slender pipes. They're typically a kilometer or more long. They may be a foot in diameter or a hollow section steel pipe.
The problem you have is if you get these in the water and get them on the seabed, you've not got them down where you want them because you're putting them down from the surface from a ship. You can only control it through cables from the ship. You get it laid down someplace, but that's not where the wellhead is or the manifold. So you've got to pull it around on the seabed. And it's like a big drinking straw. If you bend it too far, the cross-section buckles, you no longer have a pipe, you've got some expensive steel on the seabed. So you've got to be able to move it around. So you've got large motions of these long, slender pipes. You can't do it with a stiffness method, you have to use a hybrid method.
And there are some unusual loadings. You're in a fairly dense fluid and there are currents, so you've got drag on the pipe. The seabed is often soft, so it's moving on the seabed, you've got to model that. They often use a combination of buoyancy lift bags and drag chains. They'll get a couple of meters off the seabed with a lift bag, and underneath is a drag chain. It's obvious what a drag chain is. So you've got to model that as a boundary condition. And they sometimes put guide posts in the seabed to guide it.
I'm just going to show you an example from a customer. I'll flip through these slides pretty quickly. That shows a pretty simple case of this. The first thing is actually to get the pipe on the seabed. What you do is you launch it off what's called a stinger on the back of the lay barge, so it goes down onto the seabed. Since this is hundreds of feet deep, and this is a foot in diameter, you can easily lose the pipe doing this. You've got to get enough tension on it to avoid losing the pipe doing that.
If you get it on the seabed, then in this case you can see the seabed isn't flat. These are the contour lines on the seabed. They laid the pipe down along this red line here. They want to pull it around to get it up, this is actually coming up on shore here. The steep part of the seabed is actually coming up onshore. So that's the problem. Your pipe has been laid here, you want to move it over here, and your tool for doing that is this. It's a vessel from which you've lowered down some cables, attached them to the pipe, and drive your boat so you can move the pipe around. And I'm just going to take you through a series of snapshots showing this. This is looking at this particular pipe. So here's where it was originally laid. This is where you want to pull it up on shore. So you're going to move this end around over this mountain and get it up. And you can see they've got a few guideposts here to guide the pipe around. So I'll just flip through this. We put on the buoyancy bags and the drag chains, we apply the cables, we lift it up, around we go, lower it down, take this stuff off, you're finished. So it's as simple as that. Unfortunately, in real life it isn't at all that simple. And there's a lot that goes wrong, but they get them laid, they get them done, and it's a pretty tricky, sort of fun kind of problem.
I'm going to show you something a little bigger now, if I can make it play. Here we go. I'm just going to play a movie, and when I'm showing this to a lay audience, I basically begin by asking, "Well, what did we just see?" And they say, "Well, we just saw a car crashing on its front corner." And if you look carefully, you can see it's a BMW. And that's not quite true. In fact, formally, it's about 15 million equations being solved about 20,000 times. So it's a simulation. And it's a simulation with a lot of complication in it. You can see we've got metals, we've got plastics, we've got rubber, all undergoing large deformations, buckling, crushing, and so on. We've got a lot of rigid bodies. We've got some glass in here. The engine, the gearbox and so on are all rigid bodies, and they're having contact with some other rigid bodies. So it's a pretty complex problem. And lots of large-scale computing is needed to do this kind of a simulation.
But it's far more valuable than a test when you're doing design. Remember, when you're designing a car for crashworthiness, you don't have any cars to crash because you've not built your tooling yet. So every one of these things you crash, you've hand-built that car to crash it. So a very expensive prototype. Much better to do simulation, particularly because you can also see much more about what's going on.
Again, I'll try, I'm now looking underneath one of these cars and you can see we can take a look at what's really going on from the underneath. Or we can go, and with good visualization tools, what we've done here is we've made the side of the car transparent so we can look in and see what's going on while the car is crashing from the side. And you will notice, you'll notice the design technique here is the powertrain goes down under the floor pan so it doesn't run into your knees and crush your thighs. So simulation really helps. And these days, if you actually look at what's going on in the car industry, then pretty much this is done so well that nowadays they always have to build models and crush them, or build real cars and crush them. But when you do that, you know it's going to pass its crash test because you've done all of this simulation to get it done.
Let me talk about some ingredients of the technology. And first of all, materials constitutive modeling is a huge part of it. I've listed a bunch of materials that we worked on from time to time. I'm not going to take you through that list, but it's a lot of constitutive modeling that you have to have. Many materials with complex responses to high loads. The models are often heterogeneous, lots of different materials, beams, shells, deformable and rigid bodies. So if you're thinking that mathematically, the eigenspectrum of the stiffness matrix is pretty broad. There are complex interactions that are very challenging to simulate, multi-body contact. And there are large models. You know, those models I was showing, 15 million variables is not a small model, at least for me. And so you've got to be effective in the use of parallel processing, but that's quite hard when you've got these heterogeneous models. Keeping all the cores of a parallel processing machine busy with this kind of modeling isn't easy. And the challenges are very different for quasi-static and dynamic cases, such as I showed you the car crash.
I borrowed some slides from a colleague who happens to be sitting here, Vladimir Belsky. He works on solver technology. He directs that technology in Simulia now, and he's lent me a few of his slides. So guys, if you want questions about these slides, Vladimir can talk to you after I shut up. But this is an AMG-based iterative solver. And I'm just going to show you a couple of cases. This is an internal combustion engine, and in this case we're putting, we're bolting the head of the engine onto the cylinder block of the engine. So the load sequence is to assemble. There's a gasket in here, and the gasket has a nonlinear behavior. And the whole idea is to make sure you've got enough fatigue life you need out of this engine. So you've got to assemble the engine by tightening the bolts, squash the gasket, take it up to temperature, do the fatigue cycles, and see what goes on. And there's a lot of detail in these models.
And I'm just showing you some results that Vladimir has with his solver, and you can see that we're doing this with about 125 million degrees of freedom. And I've got wall clock time over here. You can see they'll do that calculation in a few hours on this kind of a computer. So pretty effective use.
Another example here is a turbine blade. Again, this is heat transfer analysis. You may know that these blades, typically the airflow over the blades is at a temperature above the melting temperature of the metal. So you do that by having lots of holes in the blade and blowing out cooling air. So you've got a film of cold air between the hot fluid and the metal. So what you're interested in doing basically is you've got to do some heat transfer analysis and then stress analysis just to get fatigue life out of these. And in this case, it's at a high enough temperature, there's creep going on. Again, what I'm looking at here is the computational performance. And you can see here that with this heat transfer analysis here, the thermal creep analysis is about almost 200 million degrees of freedom. You couldn't do this with a direct solver. What I think is impressive is the scaling he's getting on the number of cores on the machine to get this down to a good compute time.
So that's the kind of computation you have to do to do that class of calculation. The solver technology you need to do that is pretty sophisticated. But this is an issue, of course, because now we're putting out vast volumes of data from the analysis code, but in the end, the user, the customer, has to make an engineering decision: is the design acceptable? And if not, how am I going to improve it? So you've got to reduce all of those data to that engineering decision. So high-speed, high-functionality visualization is absolutely essential. And bear in mind, this is spread over a parallel processing machine, so you've got to be able to do that kind of stuff as well.
But how do we know the simulation really is close to reality? Well, first of all, I want to make the point that it can be far more cost and time effective than building prototypes. What I'm showing you here is an ultimate load wing test on an airplane. This is an Airbus A380, the double-decker airplanes. All commercial aircraft have to do an ultimate load wing test. What they're doing here is they've built the airplane, they bend up the wing and load it until it breaks. Now I think if you were riding in this airplane, you might get a little nervous if the wing was bent up this far, but that's the test they do. And there's a regulatory requirement.
This plane failed. They tested it, it got to 96% of the requirement, it didn't pass its test. It was fairly easy to diagnose the problem. What happens is these wings are complicated structures. Down in this part of the wing, there's a lot of interior structure with walls in it, and those walls are helping. They didn't expect those walls to buckle, but they did. So they just had a buckling problem. They hadn't modeled that. What they did is did lots of simulation with Abaqus, they redesigned this part of the wing, they did a test program on that part of the wing, showed Abaqus predicted the failure in the original wing, showed the redesigned wing passed the test. So as far as I know, this is the only commercial aircraft flying that never passed its wing test. But I don't think I'd be quite happy to ride in that airplane, that wouldn't worry me.
But there is an issue here, because this requires pretty sophisticated engineering understanding, skilled usage of the software, and there are lots of assumptions in these models. You just might not have got it right. So there's a huge constraint on practical deployment. There are just simply too few skilled engineering analysts who understand what they're trying to do, understand the software that they're using, and so on, and the modeling they're using to make sure that they're getting it right. And so there's a real risk that the analysis is wrong and could be even badly wrong.
Let's have a look at that. This is called a Condeep structure. These are oil platforms that are used in the North Sea. They're built in fjords in Norway. Gigantic concrete structures. The North Sea is about 800 feet deep, so that's how big these things are. The top stuff is above the surface. They build them in the fjord so they can push them down in the fjord, put the top structure on, then they tow them out, put them down on the seabed in the North Sea and they use it to pump oil out of the North Sea. They're the tallest structures ever moved by mankind. And this is just a design load case. This is just a storm in the North Sea. And you get a sense of the scale of these things. This six-story building is where the guys sleep when they're on the platform. So that's how big these things are.
August 1991, Sleipner A Condeep cracked and sank during a test. It was in the fjord. They'd sunk it down and they pumped one of those tall pieces dry. And the guys working on it heard this big bang, they heard water pouring in. They got off the platform. A short while later, there was a seismic event locally and there was a bunch of concrete on the seabed. It turned out that the loss was about 700 million in 1991 dollars, 1.3 billion today. It was a bad finite element mesh in these joints where these cylinders join onto each other. You can see a test specimen here. They just didn't have enough rebar in there. They didn't have enough reinforcement, and the finite element mesh was too crude to pick that up. So that there's a huge loss just because the people weren't doing the simulation accurately enough.
How do we deal with that? Well, one approach we used is to do application-specific customization. If you think about it, many engineers are doing the same problem over and over again. If you're doing turbine blades on jet engines, turbine blades always have about the same shape, about the same concept. So the whole idea is to create a custom suit. Forget about using a general purpose code like Abaqus. Put a frame around it so you can use it for a particular problem. And then you can make sure your experts create a custom system that has a user interface that the user can understand. You'd limit the parameter range, pre-qualified meshing, all the right materials data built in, so you've got a high degree of confidence that your designs are going to work.
Let me show you a couple of examples. This is one at Procter & Gamble. This is the kind of stuff you see in the supermarket. There's a constant battle between the designers and engineers for these things. The designer wants it to look nice in the supermarket so you'll pick it up. The engineer wants to make sure it works. And making sure it works in the case of a product like this is generally load cases like filling, squeezing, and top-loading.
Filling: these things are made in huge volumes. They're moving through the factory faster than the eye can see. You've got to be able to stand up to the loads while you fill them. Squeezing is how the customer responds to them. Top-loading is because they stack them in the warehouse about 40 feet high. The ones at the bottom buckle, you've got a lot of stuff on the bottom of the warehouse and not much product. So what they do is, these are forms, so the thickness variations are included. The engineers at P&G can take a new design, put it through this system. In 24 hours, they can go back and say to the designer, "Well, it's not working. You've got to fatten it up here, or do this to it so it actually will work as a product."
There's another one, a pretty sophisticated one. This is heavy section steel rolling. This is where the steel comes out of the continuous casting oven as a billet about this wide, about that deep, of white-hot steel. They take it into the rolling mill, they run it through these rollers, and they do several passes through the rollers and turn it from that rectangular cross-section to, I think I'm showing an I-beam here, or sheet piling, whatever it is you want to do. And your job as the roll mill technician is to design these rollers so that with the smallest number of passes through the rollers, you will end up with the product that you want. So a very complex problem. It's fully coupled thermal stress analysis with obviously very large deformations, radiation boundary conditions, contact problems, so on and so on.
So this is all embedded in a user interface like this that is used by these roll mill technicians. These are the guys who just sit in the mill and they have to tell how to machine these rolls so they can get this product made. So they do a bunch of simulation. Inside this is Abaqus. What they see is just this stuff. And they then get their process designed, and that's in daily use in this steel mill.
Okay, that's what I want to say about the technology. Next, I'm going to talk about the market. And this is just a snapshot in 2005 when Dassault acquired the business. First of all, I said we wanted to get our money from selling software, and primarily that worked. 95% of our revenue came from software leases or sales. So we had a very stable revenue stream. That's enormously valuable because the typical development project would be a five to seven-year project, and you need stable revenue to sustain that. I think the geography wouldn't surprise you. Roughly a third in the US, a third in Asia Pacific, a third in Western Europe. Asia Pacific is basically China, India, Japan, and Korea.
The industry segments, I think probably aerospace and defense wouldn't surprise you, automotive wouldn't surprise you. Consumer goods and packaging was our third biggest industry segment, and I think that surprises a lot of people. But the reason is very simple: it's because of high volume. All these consumer products are being made in enormous volume. So getting the engineering right on your product or on your manufacturing process can save you a lot of money or cost you a lot of money.
And I'll give an example that I think probably most people would not associate very much with engineering calculations. That's disposable diapers. To give you a sense of the market, there are about 20 billion disposable diapers used in the US every year. So you save a fraction of a cent or cost a fraction of a cent on a diaper, that's a lot of money. So getting the diapers designed right is a good idea. It happens that we delivered functionality for fluid flow through a deforming porous medium, primarily for geotechnical applications. People who are putting, say, subways under cities. So they've got to put a tunnel through a saturated, partially saturated soil. So we had that functionality in Abaqus.
And of course, you can think about a diaper. It's fluid flow through a deforming porous medium. And the engineering problem is pretty simple. You've got fluid flowing into the diaper from here. You've got hydrophilic particles up here in the diaper. And the idea is to divert the flow up there and hold it there long enough for these things to do their chemistry and suck up the fluid and hold it. So you've got to do that without spillage. And by the way, there's some large deformation because while you're doing that, the baby is kicking his or her legs around, so the medium is kind of moving around quite a bit. So that's what they do. And there's a lot of Abaqus calculations done to design a disposable diaper. So there you are, that tells you why that's our third biggest segment.
I haven't talked about the academic market because we really didn't think of it as a business. I know a lot of academics now, I don't mean to be rude or anything, but we had a lot of friends who were researchers and they wanted to use Abaqus to try out constitutive models. So we designed a general user interface called a user material interface where we let you have as many state variables as you wanted for a material, the material parameters, and then you could plug in your constitutive model to the code to do that and then use it with all the other functionality in Abaqus. And we later extended that to a user element capability where you could do the same thing with anything that looks mathematically like a finite element. And in fact, it was David Parks here who was the originator of those concepts and that need. And in those days, we gave the code away to academics. We didn't charge anything for it. But then it turned out it got quite popular and got to the point where we actually had to have people, the administrative cost of us supplying academic licenses was large enough that we actually had to charge for it just to cover our costs.
And just to take you down memory lane, this was our three keynote speakers at the first Abaqus Users' Conference. This is H. T. Tang, who worked at the Electric Power Research Institute, and his job was to make sure the electric utilities and their suppliers had good tools to do safety studies on nuclear power plants. This is Erich Haug, who headed the stress group at Porsche development in Germany. And this is a gentleman who's sitting here, David Parks, who was a professor at MIT.
Now I want to talk about the competition. And when I started, it was formidable. I could list over 20 viable commercial competitors, mostly US and European. Almost all the industry experts told us we were wasting our time. It was a crowded, mature market, not very large. Most of these competitors disappeared. One has been decidedly successful, and this is a company called ANSYS. The software was originally evolved at Westinghouse for nuclear applications. In 1978, the key developer, John Swanson, left and started his own company. He's a very good engineer, a really good entrepreneur. 24 years later, he sold it to a Boston company called TA Associates, whose business was to buy these businesses and do an IPO on them. It went public two years later. They raised 40 million in those days, which is 65 million today. The successor CEO who ran this now public company did a very good job. He did a lot of acquisitions quite successfully. So the company has grown extremely well. Today, that company is worth 15 billion dollars. Its revenue last year was 1.3 billion. And it's obviously really successful because the price-earnings ratio is about 36, meaning people think it's going to be worth a lot more. So one company in this little finite element business now has a 15 billion dollar market cap.
I'll show you a very different story. 1991, a leading academic researcher, a professor at Stanford, started a company called Centric Engineering Systems. It was richly funded by one of the best venture capital firms in Silicon Valley. They raised about 16.5 million in six rounds. They took five years before they announced their product, Spectrum. We were very frightened because these were really superb guys. They really knew all the technology. Many of their papers helped us in terms of stuff we put into Abaqus. And we couldn't get any information until they announced their product.
They'd hired a sales force, their marketing people had done a good job of identifying our customers and our competitors' customers. And the sales story was very simple: "Look, we've now got the real software. You've had this stuff like Abaqus. You can replace that with our code, and all these other things you're using for this kind of engineering simulation. You'll save license fees, training costs, and so on." Of course, the customers do exactly what you'd expect them to do. They say, "Well, okay, that's very interesting. Here's a couple of examples of what I do with Abaqus. Here are some examples of what I do with something else. Show me that Spectrum can do these well enough and we'll switch."
Well, every one of these applications had some tricky details that had to be implemented. You know, you're trying to lay pipes on the seabed, you need to model drag chains, you need to model fluid drag on the pipe, and so on. They didn't have that. You're trying to do engine assembly, you need gaskets. They didn't have a model for gaskets. They didn't know how to do the boundary condition of the bolt loading and so on. Always, there was a list of details. So their salespeople go back with these benchmarks, and every one of them requires enhancements to the software so they're overwhelmed with requests for enhancements before they can make any sales.
So very quickly, I mean, these are Silicon Valley venture capitalists. They're used to software where you build it, you send it out, the revenues go up the hockey stick, and it just doesn't work. So three years later, the company was sold for less than a million to ANSYS. As far as we can tell, they never did anything with it. So why such a spectacular failure? I mean, they had absolutely ideal initial conditions: the best brains, rich funding from experienced VCs, creative concepts, a market that was already at a billion a year with every promise of expanding. Today, it's about 4.7 billion a year and it's expected to be 5.8 in 2021. What, why did it fail?
Well, the key mistake is they focused on technology, but customers don't buy technology, they buy tools. You've got to deliver a tool that the customer can use. Delivering technology doesn't make a sale. And they had no one with industry experience on the management team to tell them that. They really didn't understand the market dynamics. If you're designing airplanes and you want to make sure that airplane doesn't fall out of the sky, you're going to be very careful about what your software does. So getting the quality assurance on a new software package to make sure that it's going to fit your needs is a long process, it's a difficult process. The sales cycle for our software to major enterprises is measured in years, not in days. So the venture capital people didn't understand that. And maybe I'm being rude here, but I'll say the principals weren't hungry. All of these were academics, the management team and so on. They didn't give up their day jobs. They kept their tenured positions in their universities. And as Andy Grove famously said, "Only the paranoid survive."
Okay, I'm now going to talk about what we got wrong and what we got right. And first of all, what did we get wrong? Well, tons of stuff. We made lots of mistakes, and we knew we would. And we just worked hard at sort of learning on the job. So in most cases, we could get over the problem without losing a ton of money. But not always. And there were two that really were pretty catastrophic for us. In each case, we wanted to add a new software component to Abaqus, a big piece of software. And we didn't want to buy somebody else's package and then try to make it fit in, because we wanted it to be consistent with our design of the software suite. So both, we started with a clean sheet of paper. We hired the best people we could attract, told them what the specification was, gave them the budget and authority to do it, and said, "We want the best functionality here to go into the Abaqus software suite." In both cases, they were much too costly and very delayed. So it was a tremendous struggle, but we had to make it happen. And in both cases, I'm afraid we replaced the managers more than once. And these were really good people, so they unfortunately lost their jobs over these. Eventually, we made them succeed and they became very big contributors to our business. So we were able to pull it off, but I can assure you it was a big battle to get them done.
What I think we did right, well, first of all, my phrase is we stuck to our knitting. A lot of people said, "Well, you know, you're good at doing this kind of software, you should do that kind of software or something." We kind of like doing this finite element stuff, I think we'll just carry on. As I mentioned to you, we were a great believer in going after niches. We identified niches where people needed capability we thought we could deliver. Not many people were trying to do it, so we said, "Well, we'll exploit those nice niches and expand out from there." So it was a very simple strategy.
As the business matured, we had a very disciplined approach to product planning. What we basically said is, "Look, we compete by delivering capabilities that people need that are not very easy to develop." The question is, what should we be investing in now so that five or seven years from now we can still compete based on delivering stuff that other people are not delivering? And interestingly, in all the time I was involved in the company, we would have a two-day meeting to discuss this long-term product strategy. And our job in that meeting was not to think things up, it was to make choices between all the possible things we could do because we didn't have the resources to do everything. So we were making choices. And so that's how we tried to keep things going that way.
I think we did a reasonably good job at designing the core software. Very much a traditional engineering approach. Listen to what the customers want, then give them what they need, and that's not always the same thing. And get the details right on paper before you write code. Always design before you build.
Without question, the thing that was hugely important were the people who came to work with us. They're just great people, amazingly talented people. They stayed. Many are still there. I've been in the office recently and it's kind of an interesting experience for somebody like me because I'll see this large crowd in front of me and I can see about a third of the people are sort of older looking versions of the guys I knew when I was running the company. But a third of them weren't even born when I started this business, and a third of them are in between there somewhere. So very, very good people, and they stay. It's remarkable how many people I hired are now, I'm getting notes about them now retiring after spending, we usually hired them right after graduate school or after a postdoc and they stuck around.
our plan. And of course, plans go wrong. If it's our plan and it goes wrong, we say, "Okay, we screwed it up. Let's get down and do it again and fix it." If it's David's plan, the first thing they do is point out, "David's being dumb again," you know? And then we're not making good progress. So we all have to make it work if it's our plan, and that's why it's important to emphasize teamwork.
I think my senior partners and I were tremendously compatible and complementary. We're all reasonably good at some things, really bad at other things, but we knew each other very well. We knew what our strengths and weaknesses were, and we worked in a complementary way. And we were all fully engaged until the business was sold, and we're close friends to this day.
The last thing I'd say on this is really trust. We see this as absolutely critical. And I've had so many conversations with customers who would say, "Well, David, yeah, we like your software and we use it a lot, but you know, the one thing that really causes us to stick with you as a supplier is we trust you. If you say you'll do something, you'd do it. If you're going to deliver something, you'll deliver it." And that is so important with customers. And I think it's the same with our colleagues throughout the company. Our colleagues, I think, trusted us to give them interesting jobs, pay them fairly, give them sensible performance evaluations, and so on. And that's why I think people stayed with us as a company. So I wouldn't ever underestimate the value of trust in this kind of a business.
I've got two final comments and then I'll shut up. First of all, business leadership is very demanding. There's a graphic here that shows you some of the things associated with leading a business. I'm not going to talk about that. It's very hard to do well. I never imagined I had any leadership skills. I wasn't brought up that way, but I kind of got the job done. So I think you can learn it. So I think if you're ever thinking of starting a business and you're not sure about whether you've got the right kind of leadership skills and so on, I would argue that at least in my case, I managed to get the job done and build a reasonably successful business on that basis.
On the other hand, my last slide is is pretty simple: never underestimate the value of luck. I really think you shouldn't. I mean, yeah, we can laugh, but it really is true. I've been incredibly lucky in my life. Not everybody is as fortunate as I am. You really do have to have good luck going for you. So, you know, if you try something and it doesn't work, don't give up, because you may have better luck next time.
That's what I want to say, but I want to have a little fun at the end. And this is fun with mechanics. So this is mechanics. What we have here is a series of hyperelastic balls. These spheres are made of rubber. They have curious surface features, which is interesting. They're sitting in a gravity field on a conveyor belt. Those little square things are a conveyor belt. And they're in a fluid. The fluid has the properties of air at normal atmospheric temperature and pressure. And you see there's a rigid tube above them. What we're going to do is start the conveyor belt, pull a vacuum on the top end of that tube, and see what happens. So let's see what we can do.
[Video plays with music]
So you see there's some contact problem being solved here, there's friction in the contact, wrinkling bodies with water...
[Music continues]
Alright, that's it.
Q&A Session
Audience Member: Great lecture. And of course, a great question. For these specific instances, what needs to be done from an academic perspective?
David Hibbitt: I don't think... I think the reality is that there are just not enough people who would really want to have the jobs to do that. I think you are always going to have to have specialist organizations to do this kind of thing. We see in the large enterprises, there are teams of people who do that within their company. I mean, I mentioned blades on engines. There are groups in Rolls-Royce and GE and so on who essentially create these special applications to do blade design. And they will create a blade... you know, inside is Abaqus, but the users don't see Abaqus, they see a user interface that's for blade design. The same for the heavy section steel rolling. That was a joint effort by us and by the research group at what then was British Steel.
What has happened towards the end of my term at the company, and much more now, is with the very large customers, Abaqus or Simulia now has actually its own engineers embedded in some of the larger companies. So if you go to Boeing, Airbus, Toyota, and so on, you will find people who are on the Simulia payroll who are actually working with the engineering teams inside that company, helping to create the applications to do this.
And one thing that we moved into, and I very much saw this as an important part of developing the business, is really with these very large companies, we tried to position ourselves more in a partnering relationship than a supplier relationship. So we'd be able to sit down with their engineering management and say, "Look, it takes us five or seven years to get functionality in the software for what you need. And so let us work alongside of you so that you can tell us what you'll likely be doing some years from now, and we will make sure, working with you, with your in-house experts, we'll get the software ready." So when you want to go into heavy volume production, and with, again I mentioned Procter & Gamble, companies like that, there's a lot going on in that kind of area with Simulia people working with the company. I know, for example, with Airbus, there's a lot of work now on 3D printing for airplane parts, and again, there's a lot of technology there. So I think that's the only approach you can take.
The danger, I think, is really, you know, what happened with that Condeep platform. You know, there are a lot of companies, and it's something that we saw and was sometimes frankly scary. You will see companies hiring young engineers out of graduate school and giving them a tool like our code and saying, "Well, here's what we've got to do, get on with it." And sometimes it can go wrong.
Audience Member: Not when you were there?
David Hibbitt: No. And I think, I mean, you know, in terms of just liability and so on, first of all, we took Quality Assurance very seriously. The Quality Assurance group was huge. And when you've got software like this with 300 people with their hands in the software every day doing software development, you're constantly trying to find if you've broken the software, if something new you've added has broken something else. The QA group was big, and we had a lot of computers running all the time, running test cases to make sure the quality was there. And we published our bug list. We were never private about what bugs were in the software. And so, you know, I think we met our responsibilities. And if you look, I think, at the thing from a legal perspective, at least in this country, the engineer who's using a tool is responsible for the sensible use of the tool.
Audience Member: [Question about the potential for open-source software in this field]
David Hibbitt: I'm not quite sure which question you're asking. If you're asking about the use of... well, I think your question really is, are we likely to see this sort of open-source software, with lots of people working on it, going into this kind of a field? I know there are efforts of people trying to do it. I doubt if it would be accepted easily by the companies whose designs really are critical and could be, let's say, life-threatening if something goes wrong. You know, I mean, if airplanes start losing their wings and the software was to blame, that's probably not going to work very well. So I doubt if that's ever going to take off very much. I think that there are, I know, academic efforts now to do open-source, shared-source software and so on. I doubt if they would be seen as competitors for our kind of software for years to come.
Audience Member: [Question about finding unexpected applications for the software]
David Hibbitt: Oh yeah. I mean, it was surprising to me how many... I think the best way I can perhaps answer your question is to say we spent a lot of time visiting our customers and tried to understand what they wanted. And we would very often find situations where something we developed for one reason was valuable for another reason. I mean, I mentioned the diapers. You know, we did lots of work on geotechnical problems, soil mechanics and stuff like that, and it just happened to work for diapers. And there's a funny side story about the diaper one. Believe it or not, the two biggest diaper suppliers in the US had a lawsuit over a patent that was filed on the use of Abaqus in designing diapers. So we thought we were going to get dragged into that.
Audience Member: [Question about the role of embedded engineers in customer companies]
David Hibbitt: Well, our guys are embedded in mainly to help the customer's engineers do the job. So they're there on a consulting basis. The business relationship is just that. These days, with the very large enterprises... I mean, I know some of the amounts of money they pay for using what was our software today, and those numbers are huge. And embedded in those contracts is a requirement that Simulia supplies a certain number of man-hours of skilled people to work with their engineers. And so they're there on that basis. They're paid by Simulia, but they're working with the engineers in the customer's company, and that customer is deciding how they deploy that manpower.
Audience Member: [Question about the relationship with hardware providers]
David Hibbitt: Did we have more of a reactive relationship with them? Or did you build the product knowing what the demands would be? Let me see if I understand your question. Do we know what products our customers will want to develop with Abaqus, or in terms of computers? Well, what's going on there really, what happened a lot is that because Abaqus eats up computers, you know, you need a lot of computer time to run these big models, a lot of the vendors of high-performance computers had a good relationship with us because they wanted Abaqus to work well on their computer so they could sell hardware to the customer. So we had quite close relationships with the hardware companies. And Vladimir, maybe you know that they now design their machines so Abaqus runs well. So we definitely have conversations. You know, the hardware companies want to know what sort of hardware they need to be designing so Abaqus will run well, so Boeing or John Deere or whoever it is is going to buy their computers.
Audience Member: [Question about what was done before visualization tools existed]
David Hibbitt: I have to understand your question again. What did we do before we had visualization? We read numbers and copied them onto graphs and that kind of stuff. The user interface to build models and so on... well, we didn't have that functionality. Abaqus initially was purely an analysis code. And we added that functionality... I mentioned we had two major product development efforts that were disastrously bad before we succeeded. One of them was to build that whole environment. It was very, very difficult.
Audience Member: [Question about a discrepancy between the theory manual and the code]
David Hibbitt: I think your suggestion might be something in our manuals that wasn't in the code in the theory manual? Well, you better talk to the guys at Simulia. It's not my problem. When I was there, I would have been astonished if that was the case. But if you know something that was there in my era, then come beat me over the head. Well, I'm sorry if you're finding that, but I hope not. I hope it's for real.
Oral: Okay, well we tried.
David Hibbitt: I mean, again, you know, towards the end of my talk, I used the word "trust," and I really do feel that is so important. It was so important that our customers knew what they were getting in the way of a tool. So we tried pretty hard to make the documentation accurate.
Audience Member: You mentioned the importance of serving different niches, especially at the beginning. How did you identify suitable niches? For example, I would have not really come up with the problem of...
David Hibbitt: Okay, I'll tell you. I was desperate for revenue. I mean, we were sitting there writing manuals, hoping one day we'd write some code. We didn't have any money. I went to an ASME meeting in Montreal, Canada. I was standing in a lobby and the doors of an elevator opened. A gentleman came out who I knew, greeted me and said, "David, how's it going?" And I said, "Well, actually, not so well. We're looking for business." He said, "Oh, we've got some year-end money. Would you like to try and do something for us?" And I said, "Tell me what." And he started describing some problem on the nuclear physics side, and I said, "No, no, we want to do finite element stuff." He says, "Oh, well, what about this problem?" And so I said, "Well, that sounds interesting."
So we went up to his room and we wrote some stuff out and I said, "Yeah, I think we can..." He said, "Well, you've got to deliver it by the end of the fiscal year, the end of September." I said, "Yeah, I'll have a go." And so he gets on the phone to his manager. And his manager says, "Well, wait a minute. We've had guys doing this stuff for a couple of years and they haven't got anywhere with it yet. You think this guy Hibbitt can do that in three months?" And my friend, I'll call him my potential customer, said, "Well, look, we've got this year-end money, we've got nothing to spend it on. So why don't we let him have a go, or we just throw the money away." So his manager said, "Well, okay." So based on the sheet of paper that we put together in that hotel room in Montreal, I got in the car, drove back to Rhode Island, wrote a proposal, and started writing code. And by September, we went out there, delivered the code, and it worked. So the answer is, a niche shows itself because I was desperate for anything I could find.
Audience Member: [Question about professors starting companies part-time]
David Hibbitt: Do I have any comments about this? Well, I mean, I know some professors who have quite successful businesses that they run and they're still professors. I know some here at MIT. And I think they can do it very well. I think in this particular case [Centric Engineering Systems], they didn't do it very well. I can't say I'm sorry they didn't. I think there are some very good things done here, and I certainly learned a lot from reading papers published here.
Audience Member: [Inaudible question about contracts]
David Hibbitt: Could somebody say what you just said out loud? Like, big companies have to contract you for you're doing the investigation. If you do an investigation without a contract...
Audience Member: Oh, excuse me.
David Hibbitt: We developed Abaqus as a software tool. We didn't use the tool, or... we didn't have any business reusing the code to solve problems for customers. We would help customers, but the customers do their own engineering using the code themselves. We supply the code as a tool. Does that make sense?
