OpenSees#
OpenSees was conceptualized, designed, and developed with parallel computing as a core objective. Parallel computing means leveraging multiple processors to work simultaneously — not only on independent tasks but also on tightly coupled problems where processors exchange information during execution.
From these design principles grew three major OpenSees applications (plus one Python interface), each optimized for different computational strategies and user needs:
OpenSees (Sequential / Single-Core)
OpenSeesSP (Shared Memory Parallel)
OpenSeesMP (Distributed Memory Parallel)
OpenSeesPy (Python Interface)
Which OpenSees to run on DesignSafe?#
There are a few main applications, each with its own use case.
Sequential Application:
OpenSees is the simplest application:
Regular OpenSees
Single core and is easy to use.
Best for testing models, debugging, or smaller problems.
It’s your starting place and can easily meet most project needs.
Parallel Applications:
OpenSeesSP is the Single Parallel Interpreter application:
Runs on a single node using multiple processors.
The single processor distributes a large model to the remaining processors for faster solution strategies. – Shared-Memory Parallel
This application allows you to run very large models with ease because it automates the model decomposition with no need for input from the user.
Efficient for models that scale well with shared memory.
This application may not be available on OpenSeesPy
OpenSeesMP is the Multiple Parallel Interpreters application:
It is the most versatile parallel application.
Runs across multiple nodes using MPI (message passing).
It runs all the processors in parallel, each executing the same script containing individual instructions for each processor.
This is the most powerful OpenSees application by giving the user full control of the job.
Two types of parallelization:
Manual Model Decomposition (automated in OpenSeesSP) – Shared-Memory Parallel
Distributed parametric analyses. – Distributed-Memory Parallel
Best for very large simulations that require distributed computing power.
Improve efficiency with Load Balancing (inter-processor communication)
kinda-Both
OpenSeesPy (Python Interface)
Provides a Pythonic interface to the OpenSees kernel.
Allows seamless integration with Python libraries (NumPy, SciPy, pandas, matplotlib, etc.), making it easier to script, postprocess, and automate workflows.
OpenSeesPy has been added to the DesignSafe Web Portal and Tapis Applications.
You can run OpenSeesPy in both Sequential or Parallel environment.
There are several ways to run OpenSeesPy in the parallel environment.
Running OpenSeesSP in OpenSeesPy requires some verification since it is environment-dependent. This is beyond the scope of this traning content.
Domain decomposition “should be possible” in OpenSeesPy.
Quick-Decision Matrix for OpenSees Applications#
Model Size |
Analysis Parameters |
Sequential OpenSees |
Shared-Memory Parallel |
Distributed-Memory Parallel |
|---|---|---|---|---|
small–medium |
none–few |
✅ Recommended |
🚩 Element Robustness |
⏳ Extra time to set up the script |
small–medium |
many |
⏳ Wait Time |
🚩 Element Robustness |
✅ Recommended |
medium–large |
none–few |
⛔ Too Slow |
✅ Recommended |
✅ Recommended + ⚠️ Manual Scripting |
medium–large |
many |
⛔ Too Slow |
🚩 Element Robustness + ⛔ Too Slow |
✅ Recommended + ⚠️ Manual Scripting |
very large |
none–few |
⛔ Too Slow |
✅ Recommended |
✅ Recommended + ⚠️ Manual Scripting |
very large |
many |
⛔ Too Slow |
✅ Recommended 1 analysis/job |
✅ Recommended + ⚠️ Manual Scripting |
Legend:
✅ Recommended solution
⏳ Additional wait time due to HPC queue makes it a weak solution
🚩 Requires ensuring element robustness in OpenSeesSP (weak solution)
⚠️ Manual domain decomposition requires extra scripting effort
⛔ Additional run time due to single-threaded execution makes it a bad solution