Better Than the Real Thing: Virtual Earthquakes in Berkeley

by Bart Eisenberg, Pacific Connection, Software Design magazine

Professor Gregory Fenves could hardly have picked a better location to study earthquakes. His office on the University of California, Berkeley campus sits almost on the Hayward Fault, which runs just east of Davis Hall, where Fenves is the chairman of the Department of Civil and Environmental Engineering. From there, the Hayward slices right through Memorial Stadium where, each fall, crowds of 70,000 come to watch Cal football. Relative to each other, half the stadium is poised to lurch slightly towards Canada, while the other half aims for Mexico.

Fenves's research interest is in using computers to predict how structures of various designs will hold up in earthquakes with varying vector forces. Where some earthquake researchers employ shake tables, centrifuges, and reaction wall systems, Fenves and his graduate students stage virtual quakes on computers. "Physical and software simulation have developed somewhat in parallel," he says. Software simulation relies on algorithms and data models, as well as the kind of number crunching that has accelerated over the years with Moore's Law. Meanwhile, physical simulation "is important for understanding what happens in the real world under controlled conditions. We use the data to validate and calibrate our software models."

Both the physical test equipment and software analysis comprise the research conducted by the Pacific Earthquake Engineering Research Center, a 10-year project funded principally by the National Science Foundation. PEER's website gives much detail about the actuators, controllers, and pounds of force used to re-create earthquake conditions, but the over-arching message is this: when it comes to designing structures for earthquakes, simulation is much preferable to the real thing. Software simulation involves the use of finite element analysis, which is also employed for virtual product stress testing—the kind used to analyze, say, aircraft designs. That is what Berkeley's Ray Clough was doing when he first coined the phrase "finite element method" back in 1959. "He called it that because the technique turns a continuum into discrete elements that have simple mathematical properties, which can lead to an understanding of larger systems," Fenves says. Researchers have used FEA software in analyzing structural design for earthquakes since the early 1970s, "but the software was incredibly crude compared to what we are now doing. FEA programs now accommodate far larger models and deliver more precise results. But to push the technology even further, at least two essentials are needed: a coordinated software development effort with common tools, as well as a few smart civil engineering students who can also program. Both these non-linear problems have occupied Fenves for the last 10 years or so.

"We want to build upon each person's research accomplishments without every person having a different version of the code," Fenves says. "And when someone develops a model or equation solver or a time integration scheme, we want a common software framework to ensure they all work together." He is of course describing the methods found in the open source development model. That may seem like old news, but in the structural engineering field, the idea is relatively new. And for good reason: the open source movement was created by full-time programmers who think a lot about software development, whereas engineers prefer to spend their time doing engineering. "In the Unix/Linux/Apache world, people are very literate in modern computing," Fenves says. "In structural engineering, that's not usually the case because the core instruction is on the design and behavior of structural systems. So our goal here has been to see if open source can be pushed into a technical field whose focus is not computing, but engineering."

In the mid-1990s, Fenves's graduate students developed an object-oriented development framework called Open System for Earthquake Simulation. The framework is written in C++, with a unified modeling language to define a set of extensible classes in the areas of modeling, analysis, and structural reliability. It is platform-neutral, running mostly on Windows, but also on Linux and MacOS. It includes wrappers for Fortran, a language still in wide use in among civil engineers. The framework's creators admit they have freely "swiped" ideas from the Open Source Initiative, reflecting that philosophy in the short version of the name: OpenSees.

The second challenge for Fenves has been in finding civil engineering students who know enough about computing to take a few courses outside the department and learn about object-oriented design, APIs, and C++. To paraphrase the U.S. Marine tagline: Fenves is looking for a few good programmers. Typically, about half them have come from outside the United States, including Yoshikazu Takahashi, now at Kyoto University, who maintains the Japanese version of the OpenSees website at

"This problem extends through much of science," Fenves says. In the big computational science projects, the software people and the science people come from different planets, and they have to figure out how to work together. Occasionally, someone enters the field with both skills, which, after 25 years, describes Fenves himself. "I like to work at the boundaries between computing and structural engineering—to bring the two together."

Fenves says that C++ is especially daunting for students, but remains the overall best option for software design. At Berkeley's civil engineering department, Matlab is the teaching language of choice. "It's a powerful package put out by The MathWorks, an interpreter set up for mathematical processing. The interpreter makes it a great teaching language but it's too slow for large research programs." Fenves thinks the department should also be teaching Java because of its object-oriented structure. "It's a pretty clean language compared with C++, but others think it will be too confusing for students to learn two languages: Matlab and Java."

OpenSees also uses Tcl, a pre-Java scripting language created by a former Berkeley computer science professor, John Ousterhout that enables engineers to program their models without having to dive into the intricacies of C++. "Tcl executes all the OpenSees constructors. It's a first-class programming language, with objects, lists, data structures and control structures," Fenves says. For OpenSees, Tcl has thus become the research group's interface of choice. Some students have also experimented with GUIs, but Fenves says that this is really the domain of the commercial vendors. "GUI technology changes very rapidly, and students don't have the skills or time to keep up." GUIs are also very OS-specific—making the code difficult to maintain. He hopes that, long-term, that the commercial world will "package" the research models and algorithms by adding a GUI, support, documentation and quality assurance.

Surprisingly, OpenSees lacks a conventional output file with pre-formatted rows and columns showing the analysis results. Fenves had expected to hear a lot of complaints about that (he didn't), but argues that output files don't scale well to bigger models. "Instead, we make use of recorder objects, which are usually just interfaces to a MySQL database. If you are shaking something and want to know the strain, you put in a recorder object and query the data. We are now working on another database repository that is part of a national effort, with recorders that output XML metadata."

OpenSees has now been around long enough for Fenves to assess its influence. "Twice a year, I do a ‘Google metric' to see how many hits we get compared to the commercial networks. Interest has been growing."

posted on October 2006