Earthquake
E ngi n eer i ng S i m u l ati o n
OpenSees: A Framework for
Earthquake Engineering Simulation
Structural engineers face many challenges in attempting to analyze and design structures
that can withstand the devastating effects of earthquakes. The OpenSees software frame­
work seeks to aid in this challenging task by letting earthquake engineers develop finite-
element and finite-element-reliability applications for use in sequential, high-performance,
and distributed processing environments.
A
ccording to Wikipedia,1 earthquake
engineering studies how buildings
and structures behave subject to seis­
mic loading, with the main objects of
• understanding the interaction between the
ground and structures;
• designing, constructing, and maintaining struc­
tures that will perform during earthquakes in
compliance with building codes and expecta­
tions; and
• foreseeing the potential consequences of
strong earthquakes on urban areas and civil
infrastructure.
In the past, structural engineers typically
designed structures to comply with local and
regional building codes—codes that attempted
to ensure that structures would suffer no struc­
tural damage in moderate events and wouldn’t
collapse in major events. There’s a major mis­
conception among building owners, insurers,
lending institutions, and some government
agencies that code-conforming buildings are
“earthquake proof.” They’re not; they’re sim­
ply designed not to collapse. Should a major
1521-9615/11/$26.00 © 2011 IEEE
Copublished by the IEEE CS and the AIP
Frank McKenna
Pacific Earthquake Engineering Research Center
58 This article has been peer-reviewed.
earthquake occur, many structures might not be
resilient.
As a consequence, though loss of life in a ma­
jor earthquake event occurring in an urban re­
gion of the US might be minimal, the economic
losses could be devastating. In recognition of this,
new design procedures and guidelines founded on
performance-based design are being developed by
the Applied Technology Council (ATC) under the
ATC-58 project for inclusion in the building codes.
Here, I present an overview of the complexi­
ties facing structural engineers in analyzing and
designing structures to withstand earthquakes
using performance-based design. I also introduce
Open­Sees, an open source framework that the
earthquake engineering research community uses
to develop finite-element (FE) and FE reliability
applications.
Tools for Earthquake
Engineering Simulation
Currently, more than 75 million Americans in
39 states live in towns and cities at risk of earth­
quake devastation. Researchers have estimated
that should a major earthquake event occur in a
US metropolitan area, loss of life could be mini­
mal but economic losses would be crippling—
upwards of $200 billion.2 Many structures in
such an event, even though they will not collapse,
will undergo significant structural and non­
structural damage. The large economic losses are
a consequence of structures that would have to be
Computing in Science & Engineering
repaired or torn down and rebuilt, with the con­
tents replaced, in a process that would take many
years to achieve. To mitigate these losses, new de­
sign guidelines are being developed for inclusion
in the building codes.
In performance-based design, the engineer de­
signs the structure to meet specific performance
criteria set by the structure’s owners (such as costs
and downtime) and regulators (such as possible
future demands that nature will place on the
structures). Adopting performance-based de­
sign shifts structure design from being primarily
based on empirical formulas to being based on the
accurate prediction of structural response. One of
the premises of performance-based design is that
engineers can analytically predict structure re­
sponse using earthquake input scenarios.
Predicting the damage that an earthquake
will inflict on a structure is difficult. As Figure 1
shows, in addition to damage caused by severe
ground shaking, damage to structures during
earthquakes can be due to soil response (such as
ground cracking, liquefaction, lateral spreading,
and landslides) and to the effects of adjacent struc­
tures, either through direct contact or through
structure-soil-structure interaction.
Predictions Based on the
Finite-Element Method
In the structural engineering field, the FE method
(FEM) is widely used to find the response’s ap­
proximate numerical prediction. The literature
has repeatedly shown that the FEM that soft­
ware structural engineers use can capture the
responses shown in physical experiments and
real-world monitored structures with sufficient
accuracy for performance-based design. How­
ever, this is typically accomplished only after the
modeler has calibrated the model carefully and,
on occasion, added new element and material
routines into the FEM application to model nu­
merically any newly theorized or observed me­
chanical behaviors.
The more powerful and comprehensive com­
mercial FE applications available—such as MSC
Nastran, Abacus Finite-Element Analysis (FEA),
LS DYNA—are frequently used in other indus­
tries and offer many sophisticated material and
ele­ment routines for modeling structure and multi­
phase soil systems. These packages also provide
additional optimization routines for calibrating
input files to observed responses. The simpler and
more widely used FE software, such as SAP2000
and Perform3D, don’t provide these optimization
routines and typically allow for modeling only
July/August 2011 
Liquefaction
Structural failure Structural contact
Landslide
Figure 1. Possible sources of damage to structures. Among the
possible sources are soil response, including ground cracking,
liquefaction, lateral spreading, and landslides, and the effects of
adjacent structures through direct contact or structure-soil-structure
interaction. (Photos courtesy of National Information Service for
Earthquake Engineering/Pacific Earthquake Engineering Research
Center, UC Berkeley.)
the structure itself, with limited (usually elastic)
soils modeling, if they offer any at all.
In recent blind prediction tests, engineers at­
tempted to predict the response of known struc­
tures to prescribed single or multiple earthquake
input motions. The results show that substantial
improvements are needed if engineers are to
predict a priori a structure’s response to earth­
quake forces at the level of accuracy required of
performance-based design. (Figure 2 shows some
results from these tests for a four-story steel
building and a single concrete bridge column.)
Finite-Element Reliability Methods
Although some of the poor predictions from
these blind predictions could be the result of poor
modeling assumptions or the limited ability of
the software used to capture the specimens’ im­
portant mechanics, the major source of discrep­
ancy between prediction and experiment is due to
the choice of model parameters.3 A key problem
structural engineers face is analyzing the high
uncertainty in the large structures they model.
The properties of common materials like soils,
wood, reinforced concrete, and structural steel
are remarkably variable. For example, the yield
strength (strength at onset of nonlinear behavior)
of grade A36 steel commonly used in steel struc­
tures ranges from 36 to 73 kips. Not only does
the yield strength vary among individual beams,
but it also varies along an individual beam’s
length and across its cross-section. For large- and
medium-sized earthquakes where nonlinear be­
havior occurs, the steel beams’ yield strength has
a profound effect on the response of steel build­
ings, bridges, and storage structures.4
59
 800

5 700 Measured
Engineer prediction

Maximum horizontal
600

displacement (mm)
4 500
Floor 400
3
300
Measured 200
2
Researcher
Practicing engineer 100
1 0
0 100 200 300 400 1 2 3 4 5 6
(a) Maximum relative displacement (mm) (b) Earthquake

Figure 2. Blind prediction test results. (a) E-defense 2007 three-story building test (best of 47 entries). (b) The Pacific
Earthquake Engineering Research Center (PEER) and the George E. Brown Jr. Network for Earthquake Engineering Simulation
(NEES) 2010 single-column prediction test (41 entries). In the tests, engineers attempted to predict the response of known
structures to prescribed single or multiple earthquake-input motions for a four-story steel building and a single concrete
bridge column.

As researchers have pointed out for situations
in which computer predictions can affect our wel­
fare and security—whether in civil engineering
or other fields such as climate modeling, energy,
defense, biology, and medicine—“we must insist
that the predictions include concrete, quantifiable
measures of uncertainty.”5
Structural engineers can use FE reliability
methods to characterize uncertainty.6 These me­
thods let analysts define the input parameters as
random variables to represent the uncertainties
and employ approximate probabilistic methods
to obtain estimates of the response variance/
covariances, sensitivities, and probabilities of
exceed­i ng performance thresholds. Although
there are many FEM analysis packages used by
structural engi­neers today, I’m not aware of any
with non­l inear capabilities that perform these FE
reliability analysis methods directly.
To perform reliability analysis, structural engi­
neers must use other external software packages,
such as CalREL from the University of California,
Berkeley, PredictionProbe’s Unipass, and Sandia
National Laboratories’ Dakota. Because external
software requires additional expertise, practicing
engineers rarely engage in reliability analysis.
OpenSees
None of the commercial software is obviously
made available for researchers wishing to imple­
ment these reliability methods in the application.
Of course, it’s not just the changing of the reli­
ability analysis applications that researchers wish
to explore; all FE software runs on computer
hardware that’s also changing rapidly under our
feet. In a few short years, structural engineers
have gone from the single-processor machines
using a local file system to multicore machines
with GPU processors accessing remote data­
bases. If cloud computing indeed fulfills the
promise of becoming the next computing plat­
form, or if the petascale machines with hundreds
of thousands of processors currently available to
researchers through the US National Science
Foundation (NSF) Teragrid resources—or the
upcoming exascale machines with millions of
processors—become available for structural engi­
neers, today’s FE software will need to change to
take advantage of these changing resources.
For research-oriented FE developers, the ca­
pability to experiment with the FE application’s
lower-level building blocks (data structures, solv­
ers, and algorithms), which affect the numerical
solution’s performance and accuracy, is almost as
important as being able to add new elements and
materials. None of the commercial packages offer
the ability to experiment with these basic building
blocks and none will provide the source code to
researchers wishing to experiment on new archi­
tectures or numerical solution strategies.
To encourage the testing of new routines
needed in nonlinear earthquake engineering
analysis and the communication of new research
among researchers and practicing engineers,
the NSF has sponsored two multi-institutional
research centers, the Pacific Earthquake Engi­
neering Research Center (PEER) and the George
E. Brown Jr. Network for Earthquake Engineer­
ing Simulation (NEES). The PEER mission is to
develop, validate, and disseminate performance-
based seismic design technologies for structures.
The vision of NEES is to shift earthquake en­
gineering research’s emphasis from its current
reliance on physical testing to integrated experi­
mentation, computation, theory, databases, and
model-based simulation.

60 Computing in Science & Engineering

Finite element method

Analysis

Domain Convergence Solution

CHandler Numberer Integrator SystemOfEqn
test algorithm

Recorder DataOutputHandler DataBase

Element Node MP_Constraint SP_Constraint LoadPattern TimeSeries

Material
ElementalLoad NodalLoad SP_Constraint

Uniaxial nD Section

Reliability

RandomVariable Random LimitState Correlation Modulating

Spectrum Filter
positioner variable function coefficient function

Probability Search Find MeritFunction

transformation direction DesignPoint check
StepSize
ReliabilityDomain ReliabilityAnalysis
rule
Gfun Find GradG RandomNumber
evaluator curvatures evaluator generator

Figure 3. OpenSees software packages for FEM and reliability analysis. Classes in italics are abstract classes.
Developers can provide their own subclasses to personalize applications.

Both PEER and NEES have supported the
development and maintenance of a new open
source, object-oriented FEM software frame­
work, the Open System for Earthquake Engi­
neering Simulation (OpenSees). Although it has
many industrial users, OpenSees is not intended
as a commercial application and doesn’t have
some of the sophisticated element and material
routines found in the most powerful commercial
applications. The purpose of OpenSees is to pro­
vide a common open source framework in which
researchers can quickly test, experiment with,
and share not only new material and element
routines (a facility provided by most commer­
cial applications) but also new solvers, integra­
tion schemes, nonlinear solution algorithms, and
even lower-level data structures and communica­
tion protocols. Such features are necessary as re­
searchers both improve the modeling capabilities
of the software and as new structural systems,
space-age materials, and mechanical devices
are tested for use in structures to improve their
resilience.
The OpenSees Framework
OpenSees is an open source software framework
for creating applications for the nonlinear analy­
sis of structural and soil systems using either a
standard FEM or an FE reliability analysis. It
is object-oriented by design and—in addition to
achieving computationally efficiency—it’s de­
signed to be flexible, extensible, and portable.
It’s written primarily in C++, but uses consider­
able legacy Fortran code; many C++ wrappers are
provided to interface with external numerical li­
braries written in C or Fortran, such as Lapack,
ScaLapack, Petsc, Mumps, SuperLU, and Arpack.
OpenSees is highly modular. The package dia­
grams in Figure 3 show for the framework’s FEM
and reliability parts. Unlike traditional commer­
cial and research applications, this modularity al­
lows developers to extend the code in the analysis,
reliability, and output specification parts of the
software (in Figure 3, every class in italics is an ab­
stract class and developers can provide their own
subclass to personalize their applications). This is
particularly important in earthquake engineering,

July/August 2011  61
 where researchers are studying new algorithms
and integration schemes, such as for collapse anal­
ysis and hybrid testing.
In addition to being highly modular, Open­
Sees makes extensive use of object composition,
as shown in the use of aggregation (diamond sym­
bols) in Figure 3’s package diagrams. This offers
a superior software design compared to the more
common use of class inheritance for the FEM’s
analysis part, as it lets users combine components
in ways that are simply not available in commer­
cial or other research codes.7
In designing the classes and their interfaces,
heavy use was made software design patterns to
identify the relationships between classes and
organize communication among system compo­
nents. This has reduced communication overhead
among the objects and resulted in only minor
changes to the class interfaces as new developers
used the framework and extended it in areas not
originally envisioned, such as in hybrid simulation
and reliability analysis.
There are currently more than 1,000 classes in
the framework, with contributions from more than
100 developers in the engineering community.
Applications
Developers use software frameworks to cre­
ate applications. Because  the core OpenSees
development team’s  domain is structural and
geotechnical engineering, we decided to release
several interpreted applications that utilized the
framework and thereby encourage the use of
OpenSees.
Currently, these applications are all extensions
of the Tcl interpreters, tclsh and wish. In addition
to providing users access to the features of a com­
plete programming language, these interpreted
applications provide low-level access to the frame­
work. By low-level, we mean that the user at the
command level can create new objects from the
framework’s available classes and invoke methods
on certain objects that they’ve constructed.
In addition to the low-level access to the frame­
work’s existing code, the interpreters also let
users introduce new classes at runtime using
shared objects or dynamic link libraries. The abi­
lity to add new classes dynamically to the inter­
preters has proven to be an important ingredient
for these research-oriented applications. This is
because it reduces compile time for developers
and also lets them test and share their ideas with
others without having to share code, which is
useful in our highly competitive and funding-
depleted research area. From our viewpoint as
62
framework maintainers, it also has the advantage
of limiting the branching of the code.
Using existing interpreters allowed us to
quickly provide applications that let users test the
framework’s classes. It also gave engineers—who
are used to either fixed file format input programs
or GUIs—a new programmable interface for
building models and performing analysis. Ulti­
mately, it’s proven to be a highly useful format
for researchers exploring the nuances of nonlin­
ear analysis and performance-based design (once
some of them overcame the initial shock of having
to learn a programming language).
The disadvantage of providing only interpreted
applications to users is that it has limited the
framework’s usage, particularly among practic­
ing engineers. The most requested feature in our
surveys (40 percent) is always a GUI. The effort
to produce one that would satisfy the user base,
however, greatly exceeds our allocated resources;
it would also offer limited research opportunities
for academics in our field, who are the primary
contributors to the framework’s development.
However, as our user base swells, commercial
GUIs that use OpenSees are now becoming avail­
able from several small software companies, such
as nvStructural from Novel CAE Solutions and
CDS Win from Software Tecnico Scientifico.
OpenSees and HPC
At the outset of OpenSees, we recognized that
users in the performance-based analysis field
might need to analyze large models with more
100,000 degrees-of-freedom (dof ) and that they
might need to perform many thousands of analyses
on these large models with varying inputs and
model parameters.
Today, on a single processor or dual-core
machine, the computation required of a compre­
hensive performance-based design or a regional
simulation could take weeks, months, even years,
to complete. This is, of course, unacceptable.
However, by the time performance-based engi­
neering does come to fruition, the HPC resources
available to academics today will be available to
practicing engineers, either directly on their
local machines or through some cloud service
accessible through their desktop. The frame­
work contains many classes available for paral­
lel processing, which has allowed researchers to
build specific applications for large models8 and
regional simulation.9 To encourage and promote
the use of HPC among engineers, we provide two
parallel, interpreted applications, OpenSeesSP
and OpenSeesMP.
Computing in Science & Engineering
 Channel

MovableObject

sendSelf(Channel, int)
TCP UDP MPI Database
recvSelf(Channel, int,..)

File MySQL Oracle

Element Node MP_Constraint SystemOfEqn

Figure 4. Movable object and channel class hierarchy. Because every instantiable class is a descendent of
the MovableObject class, users can move the objects in the domain from one partition to another during
partitioning.

350
Total execution time (minute)

300
250
200
150
100
50
0
0 2 4 6 8 10 12 14 16 18
Number of processors

Figure 5. OpenSeesSP model of the Humboldt Bay Middle Channel Bridge. The 100,000-plus degree-of-
freedom model uses implicit integration and the Mumps direct solver.

OpenSeesSP facilitates the analysis of large
models. In it, we’ve followed the traditional
approach for parallelizing the FEM—that of
using domain-decomposition, load-balancing
techniques, and parallel equation solvers. In
OpenSeesSP, domain-decomposition is achieved
by partitioning the domain at analysis time using
Metis. To move the objects in the domain from
one partition to another during partitioning,
we make use of the fact that every instantiable
class is a descendent of the MovableObject class
(see Figure 4). As a result, each class must provide
two methods, sendSelf() and recvSelf(),
so that the object and any contained objects can
move from one process’s address space to another
using the Channel class interface. Adding an extra
integer tag in these two methods lets us use
these methods for sending and receiving the
application’s state to and from a database for back­
up and restore purposes by including the Data-
base class as a subclass of the Channel class.
To solve equations, users can choose from
four parallel equation solvers: Mumps, SuperLU,
Petsc, and Diagonal. OpenSeesSP’s scalability is
highly dependent on the choice of solver. Struc­
tural engineers tend to use direct solvers and
implicit integration techniques, which typically
limits the application’s scalability to 16 or 32 pro­
cessors, depending on the model’s size and non­
linearity (see Figure 5, which shows a model of the
Humboldt Bay Middle Channel Bridge, which has
more than 100,000 dof10). For engineers willing to
use either explicit integration schemes and direct
solvers or iterative solvers, the scalability is much
better. We’ve seen perfect scalability up to 6,000
processors using a diagonal solver and a central

July/August 2011  63

Figure 6. Simple performance-based example using OpenSeesMP.
With 113 records, four intensities, and three hours per record,
this would have previously taken 1,356 hours, or 56.5 days. Using
OpenSeesMP, we ran the example on a Teragrid’s 452 processors in
less than five hours.
Simulation B
Database
User
Simulation A
Experiment
Module server
Figure 7. Distributed applications of OpenSees. Among the many
common uses of the OpenSees facilities are to build distributed finite-
element applications and to use the low-level TCP/IP communication
protocols for hybrid simulation.12
difference method on models with more than
70 million dof.11
OpenSeesMP is an interpreted parallel applica­
tion that facilitates the analysis of many models
subjected to many scenarios. To the commands
available to the sequential interpreters, we’ve
added a small set of commands for the mes­
sage-passing paradigm. These commands allow
64
engineers to modify their scripts, so that when
scripts run on a parallel machine, the computation
can be done in parallel using the message-passing
paradigm. The commands we added— send,
recv, barrier, getNP, and getPID—are similar
to the basic ones found in any message-passing
library. They simply allow running processes to
communicate at the scripting level. To date, this
has proven the more popular parallel application
due to the amount of time it’s saving researchers.
For example, with as few as six additional lines of
code in the script, a number of developers have
obtained months of computational work in a few
hours; Figure 6 shows an example for a concrete
building study (one of many such studies carried
out within PEER and NEES).
Distributed Computing
The OpenSees framework contains several
classes—some of which are shown in Figure 5—
for interfacing with processes running remotely
over the Internet. Common distributed interfaces
provide access to remote database and Web server
applications using client-side database and URL li­
braries and low-level communication protocols such
as TCP/IP. As Figure 7 shows, OpenSees deve­
lopers commonly use these facilities in several ways.
First, developers use the facilities to build dis­
tributed FE applications, in which—as in parallel
applications—part of the FE is in one process and
part is in another process. Unlike the typical par­
allel application, the two processes can be from
different FE applications, such as OpenSees and
LS_DYNA. This allows engineers to combine
one software application’s modeling capabilities
and features with those of OpenSees. Second,
developers send results from the simulation or
save the application’s state to a database so they
can use the database software to manipulate
the results or later restart the application from
some check-pointed state. Third, developers in­
terface the running application with databases
to obtain information such as ground motion
records. Fourth, they obtain external application
routines from Web servers, downloading them
over the Internet and loading them into the
applications address space.
Finally, OpenSees developers use the low-level
TCP/IP communication protocols for hybrid
simulation.12 In hybrid simulation, the parts of
the structure that can be modeled with confidence
numerically are simulated numerically in the FE
application; those parts of the structure that can’t
be modeled are physically tested experimentally
in single or multiple remote laboratories.
Computing in Science & Engineering
 Hybrid simulation has several advantages, in­
cluding cost savings. It also allows structures

Software
databse
that, from a practical viewpoint, can’t be placed es
tin
on shaking tables and studied in the laboratory. r ou del
st o s
te m er
The advantage of using OpenSees for these ap­ La and met
ra
plications is that the numerical analysis can be pa
performed using high-performance computers. Drawings and Location
Thus, the specimen (or multiple experiments

Federal database
soil data FEM software EQ motions
using the geographically distributed NEES adjacent soil data
facilities) can be shaken in real-time using special Results Adjacent
integrators (which aren’t available in commercial structures
applications). Also, finely tuned TCP/IP settings Su
bm ed
et
ensure optimal communication costs for these it f pl s
or m ng
ap Co awi
sometimes time-sensitive experiments. pr
ov Local d r
al building
department

A
s performance-based seismic design
replaces existing prescriptive-based
design methods, new workflows built
upon sophisticated analytical tools
such as OpenSees are becoming possible.
Figure 8 shows one possible design scenario.
The process would start with digitized engineer­
ing drawings and soil borehole data. The applica­
tion would build the FEM model of the structure
from the drawings. Based on the structure loca­
tion and performance requirements, the appli­
cation would select from a database of loading
scenarios and augment the FEM model to include
a soil model, and possibly models for adjacent
buildings. Results from a probabilistic structural
analysis, which would include the earthquake
scenarios but also distributions for material and
element properties, would be visually presented
to the engineer, who could then evaluate and im­
prove the structure. Once accepted and submit­
ted for full design review, the structural plans
and borehole data would be submitted to a central
database so that adjacent property owners could
review the design for the impact on their build­
ings. Before final approval, as-built structural
drawings, material tests, and borehole data would
be submitted to a federally maintained database.
Such a scenario would also allow existing build­
ings to be reevaluated. This could occur using
new analysis techniques or instruments for struc­
tural system identification or if existing modeling
assumptions or analysis programs are discovered
to be incorrect or inadequate. In addition, at the
federal level, this scenario would allow earthquake
scenarios (simulated forecast scenarios based on
either a future event’s likelihood or, if processing
capabilities exist, based on an actual occurring
event) to be used to determine system weaknesses
and vulnerabilities using regional simulations.
w
FEM vie
Re
software
Figure 8. A possible workflow for earthquake engineering in the future.
Starting with digitized engineering drawings and soil borehole data,
the application builds a finite-element model of the structure. Based
on the location and the performance requirements, the application
chooses an appropriate loading scenario and augments the FEM
model to include a soil model and (possibly) models for adjacent
buildings. Results from a probabilistic structural analysis are then
visually presented to the engineer for evaluations and improvements.
Realizing such a future requires application–
database interfaces, automatic model generation,
reliability analysis, large-scale analysis, better el­
ement and material modeling capabilities, better
algorithms and integration schemes, and federal
action. There’s much to be done. Can we hope
to make the necessary advances? If we don’t, the
earthquake engineering community will continue
simply reacting to major events as they unearth
hidden flaws in our designs and software, which
our limited experimentation and prior earthquake
experience failed to illuminate. We’ll also conti­
nue to hunt down buildings whose details—later
shown experimentally or in earthquake response
to be poor—are buried in drawings in the archives
and hidden behind partition walls and plaster.
We hope to continue the advancement of
OpenSees through contributions from those in
our own community as well as through the direct
or indirect help of those in the mathematical and
computer science disciplines. 
Acknowledgments
OpenSees development and maintenance has been
supported by the Pacific Earthquake Engineering Re­
search Center under US National Science Foundation
grant no. EEC-9701568 and the George E. Brown Jr.

July/August 2011  65
Network for Earthquake Engineering Simulation under
NSF grant no. NEES-4101-35704. My colleagues and
I are grateful to the visionaries, particularly Dean
Gregory L. Fenves, and the many developers who
have contributed to the OpenSees framework.
References
1. J. Bielak et al., “Simulation for Determining the
Seismic Performance of Urban Regions,” Proc. 6th
Euro. Conf. Structural Dynamics, C. Soize and G. I.
Schuëller, eds., Millpress, 2005, pp. 1479–1485.
2. A. Elgamal et al., “Three Dimensional Seismic
Response of Humboldt Bay Fridge-Foundation-
Ground System,” J. Structural Eng., vol. 134, no. 7,
2008, pp. 165–1176.
3. T. Haukass and M.H. Scott, “Shape Sensitivities in
the Reliability Analysis of Nonlinear Frame Struc-
tures,” Computers and Structures, vol. 84, no. 15,
2006, pp. 964–977.
4. Y. Huang et al., “Coupling FE Software
through Adapter Elements: A Novel Use of
User-Defined Elements,” Proc. 10th Int’l LS-DYNA
Users Conf., DynaLook, 2008; www.dynalook.com/
international-conf-2008/SimulationTechnology1-4.pdf.
5. B. Jeremic’ and G. Jie, “Parallel Soil–Foundation–
Structure Interaction Computations,” Progress in
Computational Structural Dynamics and Earthquake
Eng., M. Papadrakakis et al., eds., 2008, CRC Press
6. P.L. Liu and A. Der Kiureghian, “Finite Element
Reliability of Geometrically Nonlinear Uncertain
Structures,” ASCE J. Eng. Mechanics, vol. 117, no. 8,
1991, pp. 1806–1825.
7. F. McKenna, M.H. Scott, and G.L. Fenves, “Nonlinear
Finite Element Analysis Software Architecture Using

NBHB[JOFT‰0OF
TPVSDF
t
FREE articles on hot topics
t
#MPHT

QPEDBTUT


NPSF
http://computingnow.computer.org
Object Composition,” J. Computing in Civil Eng.,
vol. 24, no. 1, 2010, pp. 95–107.
8. T. Oden, R. Moser, and O. Ghattas, Computer Predic­
tions with Quantified Uncertainty, tech. report 10-39,
Inst. Computational Eng. and Sciences, Univ. Texas,
Austin, Oct. 2010.
9. A. Pavan, Blind Prediction of a Full-Scale 3D Steel Frame
Tested Under Dynamic Conditions, master’s disserta-
tion, Inst. Advanced Studies, Univ. Pavia, May 2008.
10. G. Petropoulos and G.L. Fenves, “Interprocessor
Communication for High Performance, Explicit Time
Integration,” Eng. with Computers, vol. 26, no. 2,
2010, pp. 149–157.
11. Y. Takahashi and G.L. Fenves, “Software Frame-
work for Distributed Experimental-Computational
Simulation of Structural Systems,” Earthquake Eng.
and Structural Dynamics, vol. 35, no. 3, 2006,
pp. 267–291.
12. US Congressional Senate Committee on Research,
The National Earthquake Reductions Program: Past,
Present and Future, 108th Congress, session 1, 8 May
2003, US Gov. Printing Office, 2010.
13. Wikipedia, “Earthquake Engineering,” Wikimedia,
25 Oct. 2010; http://en.wikipedia.org/wiki/
Earthquake_engineering.
Frank McKenna is a research engineer in the Pacific
Earthquake Engineering Research Center. His re­
search interests include earthquake engineering and
computational engineering. McKenna has a PhD in
civil engineering from the University of California,
Berkeley. He is a member of ACM and the American
Society of Civil Engineers. Contact him at fmckenna@
ce.berkeley.edu.