When an engineer writes this today:
import openseespy.opensees as opsit is easy to think OpenSees is simply another Python library for structural analysis.
It is not.
Behind that line sits almost three decades of research in earthquake engineering, nonlinear analysis, finite elements, scientific computing, and open software.
OpenSees was not born as a commercial program with a graphical interface, nor as a tool designed to compete directly with ETABS, SAP2000, or Abaqus.
It was born from a much more fundamental question:
How do you build a simulation platform flexible enough that researchers can implement new models, elements, algorithms, and analysis methods without writing a finite-element program from scratch every time?
The answer would become OpenSees — Open System for Earthquake Engineering Simulation.
Before OpenSees: the problem of earthquake-engineering software
Through the 1970s, 1980s, and much of the 1990s, a large share of structural-analysis tools had been built around relatively specific models, algorithms, and capabilities.
That created several problems.
Researchers could develop a new:
- constitutive model,
- finite element,
- solution algorithm,
- integration method,
- plasticity model,
- dynamic analysis procedure,
but to test it they had to embed it in some existing program or build additional computational infrastructure.
A large share of university software also ended up tied to a doctoral dissertation or an individual project.
When the researcher left the university, the code could go unmaintained.
The project that would become OpenSees set out to solve exactly that problem: create a shared, extensible infrastructure for computational research in earthquake engineering.
1997: the dissertation that laid OpenSees’ foundations
The starting point can be traced to Frank McKenna’s doctoral work at the University of California, Berkeley.
In 1997 McKenna presented his dissertation:
Object-Oriented Finite Element Programming: Frameworks for Analysis, Algorithms and Parallel Computing.
His advisor was Gregory L. Fenves, who would later play a fundamental role in the development of OpenSees.
The central idea was to use object-oriented programming to build a modular finite-element architecture.
Instead of writing one enormous monolithic program, the system could be split into independent components.
For example:
Domain
├── Nodes
├── Elements
├── Materials
├── Constraints
└── Loads
Analysis
├── Constraint Handler
├── DOF Numberer
├── Algorithm
├── Integrator
├── Linear System
└── SolverEach component would have a concrete responsibility and could be replaced by another.
That looks ordinary today.
In the 1990s it was an extremely important architectural decision for a scientific program of this kind.
OpenSees development documentation notes that, although many classes and capabilities were added later, the fundamental architecture set out in that dissertation has changed relatively little.
That stability is one of the keys to understanding why OpenSees has survived for so long.
From the dissertation to G3
Before it was called OpenSees, the framework was known as G3.
The name was tied to one of the groups at the Pacific Earthquake Engineering Research Center (PEER) charged with developing simulation platforms for performance-based earthquake engineering.
PEER had been created as a multi-institutional research center led from UC Berkeley.
Its goal was not simply to compute forces in structures.
The vision was much broader: develop tools to study how infrastructure behaves under earthquakes, including phenomena such as:
- nonlinear structural behavior,
- geotechnical behavior,
- soil–structure interaction,
- foundations,
- liquefaction,
- uncertainty,
- damage and performance.
That was exactly the kind of problem for which a modular architecture made sense.
1999–2000: OpenSees is born
In the late 1990s the project began to consolidate as an independent platform.
Historical source files carry University of California copyrights from 1999, while one of the project’s traditional academic citations is:
McKenna, F., Fenves, G. L., and Scott, M. H. (2000). Open System for Earthquake Engineering Simulation.
Around 2000 the name appeared formally:
OpenSees
Open System for Earthquake Engineering Simulation
The change of name reflected an important idea.
OpenSees was not meant to be merely a program for running analyses.
It was meant to be an open system for building earthquake-engineering simulations.
Why “Open System”?
The word Open has several implications.
OpenSees was developed under a collaborative philosophy in which researchers could add new components to the framework.
A researcher could implement:
- a new material,
- a new element,
- an integrator,
- a solution algorithm,
- a recorder,
- an analysis method,
- a simulation technique.
And those components could be reused by other researchers.
That philosophy solved a very common problem in academic research: stopping every group from having to rebuild the entire numerical infrastructure needed to test a new idea.
In other words:
OpenSees turned the finite-element program into a research platform.
C++ at the heart of OpenSees
The OpenSees core was developed mainly in C++.
That was not accidental either.
C++ made it possible to combine:
- high performance,
- object-oriented programming,
- explicit memory management,
- integration with numerical libraries,
- extensibility.
The architecture could represent engineering concepts directly as objects.
For example:
Node
Element
Material
Section
Domain
Integrator
Algorithm
Solver
RecorderEach class could implement one part of the problem.
This structure enabled something fundamental: composition.
A structural model did not have to depend on a single algorithm or solver.
It could combine different implementations.
Decades later, that philosophy would be described formally in the 2010 paper:
Nonlinear Finite-Element Analysis Software Architecture Using Object Composition.
The idea of composition explains a large part of the flexibility that still characterizes OpenSees.
Tcl: the first major interface for users
Even with the engine written in C++, requiring every engineer to recompile the program in order to create a model would have limited adoption enormously.
The solution was to add an interpreter.
For many years the main OpenSees interface was Tcl — Tool Command Language.
A model could be written like this:
model BasicBuilder -ndm 2 -ndf 3
node 1 0.0 0.0
node 2 0.0 3.0
fix 1 1 1 1
uniaxialMaterial Steel01 1 355.0 200000.0 0.01Tcl had several advantages at the time:
- it was lightweight,
- it could be integrated easily with C/C++ applications,
- it allowed scripting,
- it avoided recompiling the core,
- it was widely used in engineering tools and scientific software.
That is how one of OpenSees’ most important ideas appeared:
C++ → computational engine
Tcl → scripting interfaceThat separation is still fundamental to understanding OpenSees today.
OpenSees was not only structural analysis
One of PEER’s goals was to integrate different areas of earthquake engineering.
That is why OpenSees began to incorporate geotechnical capabilities from an early stage.
In May 2000 a specific project began to develop geotechnical capabilities inside OpenSees.
In 2001 PEER published the report:
Development of Geotechnical Capabilities in OpenSees.
Among the capabilities studied were:
- soil constitutive models,
- solid–fluid formulations,
- soil–foundation–structure interaction,
- visualization,
- quality-control tools.
That set OpenSees apart from many programs focused exclusively on structures.
The goal was to be able to study complete systems.
Soil
↓
Foundation
↓
Structure
↓
Seismic responseAll inside the same simulation environment.
OpenSees and performance-based earthquake engineering
OpenSees grew in parallel with Performance-Based Earthquake Engineering, or PBEE.
The question stopped being only:
Does the structure resist the code forces?
And began to become:
How will the structure actually behave under different levels of earthquake?
That requires studying phenomena such as:
- formation of plastic hinges,
- stiffness degradation,
- strength degradation,
- cyclic effects,
- large displacements,
- nonlinear dynamic response,
- collapse,
- soil–structure interaction.
OpenSees was especially well prepared for this class of problems.
That is why it began to be used widely in advanced seismic research.
The NEES era: distributed simulation and advanced computing
During the 2000s, OpenSees was also part of the U.S. research ecosystem known as NEES — Network for Earthquake Engineering Simulation.
OpenSees was adopted as one of the simulation components of the NEESgrid project.
The program’s modular architecture made it easier to integrate with:
- parallel computing,
- databases,
- visualization,
- hybrid experimentation,
- distributed simulation.
That mattered because earthquake engineering was beginning to combine physical experiments and numerical simulation.
For example:
Part of the structure
↓
a real physical test
↕
OpenSees
↓
the rest of the structure simulatedThis kind of procedure is known as hybrid simulation.
The growth of a community
OpenSees gradually stopped being a project developed only inside Berkeley.
Researchers at different universities began to contribute:
- new elements,
- materials,
- geotechnical models,
- algorithms,
- analysis tools.
Among the institutions historically associated with important contributions are:
- University of California, Berkeley,
- Oregon State University,
- University of California, San Diego,
- University of Washington,
- Stanford University,
- plus researchers from many other institutions.
Among the developers who appear in the official documentation are names such as:
- Frank McKenna,
- Gregory L. Fenves,
- Filip C. Filippou,
- Silvia Mazzoni,
- Michael H. Scott,
- Ahmed Elgamal,
- Zhaohui Yang,
- Pedro Arduino,
- Gregory G. Deierlein,
- Kincho Law.
The consequence was important:
OpenSees began to accumulate decades of models developed and used inside academic research.
2006: the Command Language Manual
As OpenSees grew, so did the need to document its commands.
In 2006 one of the best-known historical references appeared:
Mazzoni, S., McKenna, F., Scott, M. H., and Fenves, G. L.
OpenSees Command Language Manual.
For many years this manual was one of the main references for learning:
- model definition,
- nodes,
- materials,
- sections,
- elements,
- loads,
- analysis,
- recorders.
For an entire generation of researchers, learning OpenSees meant learning Tcl and consulting this manual.
2010: the OpenSees architecture is formalized in the literature
In 2010 Frank McKenna, Michael H. Scott, and Gregory L. Fenves published:
Nonlinear Finite-Element Analysis Software Architecture Using Object Composition.
The paper describes one of the essential ideas behind the software:
object composition
Instead of building a program in which every analysis is rigidly wired to a specific set of components, OpenSees lets you assemble different objects.
For example:
Model
+
Constraint Handler
+
DOF Numberer
+
Solution Algorithm
+
Integrator
+
Equation System
+
SolverChanging one component does not necessarily force you to rebuild the rest.
That philosophy is one of the reasons OpenSees can support such a wide variety of analysis procedures.
The Tcl problem
Tcl worked extraordinarily well for OpenSees for many years.
But the scientific ecosystem changed.
Python began to become the dominant language for:
- scientific computing,
- data analysis,
- machine learning,
- automation,
- visualization,
- optimization.
Tools such as:
NumPy
SciPy
Matplotlib
Pandas
Jupytertransformed the way researchers and engineers worked.
In that context it was inevitable to ask:
Why not control OpenSees directly from Python?
OpenSeesPy: OpenSees enters the Python ecosystem
OpenSeesPy appeared from that need.
OpenSeesPy does not replace the OpenSees engine.
It is a Python interface for using the framework’s capabilities.
The relationship can be understood like this:
┌──────────────┐
Tcl scripts ───────►│ │
│ OpenSees │
Python ────────────►│ C++ │
│ Engine │
└──────────────┘The principal developer of OpenSeesPy is Minjie Zhu, affiliated with Oregon State University.
A model that had historically been written with Tcl commands could now be written in Python.
For example:
import openseespy.opensees as ops
ops.model("basic", "-ndm", 2, "-ndf", 3)
ops.node(1, 0.0, 0.0)
ops.node(2, 0.0, 3.0)
ops.fix(1, 1, 1, 1)
ops.uniaxialMaterial(
"Steel01",
1,
355.0,
200000.0,
0.01
)The difference looks small.
Conceptually it was enormous.
OpenSees could now integrate directly with the entire scientific Python ecosystem.
What Python changed
OpenSeesPy made it possible to use OpenSees inside much broader workflows.
For example:
Pandas
↓
model generation
↓
OpenSeesPy
↓
parametric analysis
↓
NumPy
↓
Matplotlib
↓
visualizationIt also opened the door to:
- structural optimization,
- large-scale analyses,
- Monte Carlo,
- automatic processing of results,
- machine learning,
- reproducible notebooks,
- procedural model generation.
That changed the ergonomics of OpenSees profoundly.
The program was no longer limited to scripts in a relatively specialized language and began to live alongside one of the world’s largest scientific-computing ecosystems.
From earthquakes to other hazards
Although the name remains:
Open System for Earthquake Engineering Simulation
the use of OpenSees has grown beyond earthquakes.
Modern documentation points to applications related to:
- earthquake,
- fire,
- wind,
- tsunami,
- storm surge,
as well as general problems of structural and geotechnical response.
That is possible because the program’s core is not conceptually restricted to a single load.
It is, in essence, a nonlinear finite-element simulation framework with an enormous collection of components developed around civil-engineering problems.
OpenSees and parallel computing
Another feature present from the original architecture was an interest in parallel computing.
Nonlinear analyses can be extremely expensive.
That becomes even more important in:
- parametric analyses,
- probabilistic studies,
- large models,
- dynamic analyses,
- collapse research.
OpenSees developed variants and mechanisms to take advantage of multiple processes and computational resources.
That has made it possible to run simulations from:
Laptop
↓
Workstation
↓
Cluster
↓
HPC
↓
CloudThe same ecosystem can scale toward considerably larger problems.
OpenSees on DesignSafe and modern infrastructure
After the NEES era, U.S. research infrastructure evolved toward platforms such as DesignSafe-CI, inside the NHERI ecosystem.
OpenSees remains available there as a simulation tool.
That shows something important about its history.
OpenSees survived several generations of scientific infrastructure around it.
The platforms changed.
The languages changed.
Computational capabilities changed.
But the conceptual core of the framework continued to be useful.
OpenSees in 2026
As of September 2026, OpenSees remains in active development.
The official UC Berkeley site lists OpenSees 3.8.0, published in February 2026.
OpenSeesPy also distributes modern versions for Linux, Windows, and macOS.
In other words, this is a project whose architectural roots can be traced to 1997 and that is still active almost thirty years later.
That is uncommon in scientific software.
Why has OpenSees survived so long?
There is probably no single reason.
But several are especially important.
1. Its architecture
OpenSees was designed as a framework, not merely as an application.
That made it possible to add capabilities without rebuilding the entire system.
2. The accumulated academic code
Decades of research produced:
- elements,
- materials,
- algorithms,
- examples,
- validations,
- publications.
Recreating all of that knowledge from scratch would be extraordinarily difficult.
3. A real scientific community
OpenSees became shared infrastructure among researchers.
When a tool becomes part of the scientific process, its value no longer depends only on its interface.
4. The focus on nonlinear analysis
OpenSees specialized in precisely one of the hardest areas of structural engineering:
the simulation of nonlinear behavior.
It did not try to simplify the problem to make it look easy.
It exposed directly many of the components that actually control a numerical analysis.
5. Python rejuvenated the ecosystem
OpenSeesPy made it possible to connect an engine developed decades earlier with modern tools.
The result was an especially powerful combination:
mature C++
+
models accumulated over decades
+
Python
+
automation
+
scientific computingOpenSees is not merely a program
Perhaps the best way to understand OpenSees is to stop comparing it directly with traditional programs.
ETABS, SAP2000, or Robot Structural Analysis are designed mainly as engineering applications.
OpenSees was born mainly as a:
Simulation framework
That means its strength is not necessarily providing the simplest interface.
Its strength is allowing extremely specific simulations to be built.
A researcher can control:
- the material,
- the element,
- the algorithm,
- the integrator,
- the solver,
- convergence,
- the recorders,
- the analysis procedure.
That level of control is precisely what can make OpenSees seem difficult at first.
It also explains why it is still used in advanced research.
From G3 to OpenSeesPy
If we summarize almost thirty years of evolution, the history can be seen like this:
1997
Frank McKenna’s dissertation
Object-Oriented Finite Element Programming
↓
G3
PEER experimental framework
↓
1999–2000
OpenSees
↓
Tcl
Scripting for users
↓
2000s
structures + geotechnics + NEES
↓
2006
Command Language Manual
↓
2010
architecture formalized through object composition
↓
OpenSeesPy
Python as the interface
↓
DesignSafe / HPC / Cloud
↓
2026
OpenSees 3.8What is interesting is that the fundamental concept did not change very much.
The project still revolves around the same idea:
create an open, extensible infrastructure where the engineering community can implement and share advanced simulation models.
What does this mean for an engineer today?
Learning OpenSees today does not mean studying old software.
It means learning to use a scientific infrastructure that has accumulated almost three decades of knowledge.
And OpenSeesPy changes the barrier to entry considerably.
An engineer who already knows Python can combine:
OpenSeesPy
+
NumPy
+
Pandas
+
Matplotlib
+
SciPy
+
Jupyterto build workflows that twenty years ago would have required much more development.
In addition, the appearance of AI agents and tools that can execute code opens a new stage.
Instead of using OpenSees only by hand, it is possible to imagine systems in which an agent can:
- generate a model;
- run OpenSees;
- check convergence;
- modify parameters;
- process results;
- generate plots;
- compare alternatives;
- document the analysis.
In that context, OpenSees may end up being even more relevant than before.
Because a programmable, automatable, extensible engine fits especially well inside the new AI-assisted engineering workflows.
Conclusion
OpenSees was born long before Python dominated scientific computing and long before we talked about artificial-intelligence agents.
Its origin is a 1997 doctoral dissertation on object-oriented architecture for finite elements.
Then it became G3.
Then OpenSees.
It was integrated with Tcl.
It grew inside PEER.
It incorporated structures, geotechnics, soil–structure interaction, parallel computing, and hybrid simulation.
It survived the NEES era.
It entered the Python ecosystem through OpenSeesPy.
And almost thirty years later it is still being developed.
The most interesting lesson is perhaps not exclusively about structural engineering.
It is also a lesson in software architecture.
When a scientific engine is well designed, modular, and lets a community build on it, it can survive for decades.
And that is probably one of the reasons OpenSees remains one of the most important platforms for advanced simulation in structural and earthquake engineering.
References
-
McKenna, F. (1997). Object-Oriented Finite Element Programming: Frameworks for Analysis, Algorithms and Parallel Computing. Ph.D. dissertation, University of California, Berkeley.
-
McKenna, F., Fenves, G. L., & Scott, M. H. (2000). Open System for Earthquake Engineering Simulation. University of California, Berkeley.
-
Jeremić, B. (2001). Development of Geotechnical Capabilities in OpenSees. PEER Report 2001-12, Pacific Earthquake Engineering Research Center, University of California, Berkeley.
-
Mazzoni, S., McKenna, F., Scott, M. H., & Fenves, G. L. (2006). OpenSees Command Language Manual. University of California, Berkeley.
-
McKenna, F., Scott, M. H., & Fenves, G. L. (2010). “Nonlinear Finite-Element Analysis Software Architecture Using Object Composition.” Journal of Computing in Civil Engineering, 24(1), 95–107.
-
Pacific Earthquake Engineering Research Center. OpenSees.
-
OpenSees — University of California, Berkeley. opensees.berkeley.edu.
-
DesignSafe-CI. OpenSees Overview.
Evaluation and limitations
Treat the notes below as evaluation context, not as a verified calculation or code check.
Use it as open finite-element infrastructure for nonlinear structural, geotechnical, and seismic simulation. Check official documentation for versions and installation, and cite the papers behind specific materials, elements, or models.