Draft OpenSees input with AI — then prove it with a solver and a human

Why this matters

OpenSees is a deterministic engine: given an input model, it applies numerical methods you chose. A language model is not that engine. The useful pattern is narrow. Let a chat draft boilerplate. Let a person own the mechanics. Let OpenSees run. Let a second method argue with the result.

If you skip the human or the independent check, you have typesetting, not structural analysis.

Prerequisites

You should already be able to state, without a chatbot:

• what kinematics you want (ndm / ndf);
• what the supports are meant to do;
• whether the question is static, eigenvalue, or time-history;
• what an independent check would look like for a stripped version of the same problem.

If those answers are missing, do not generate Tcl or Python yet. Read a first elastic-model tutorial and a dynamics reference first. This article assumes that sequence. It does not teach OpenSees from zero.

Core idea

Treat the model as three artifacts with different authors:

Artifact	Who produces it	What “done” means
Draft commands	Optional AI suggestion	Compiles as text, not as truth
Analysis model	Human	Geometry, sections, constraints, and analysis options match the intended mechanics
Result	OpenSees	A replayable run with a saved log
Evidence	Human + independent method	Disagreement would be noticed

The engine never reviews the prompt. The prompt never integrates the equations of motion.

A pedagogical skeleton — incomplete on purpose

The block below is not a design model. Several essential objects are omitted so it cannot be mistaken for a ready file. Use it as a reminder of what a reviewer looks at, not as something to analyze and stamp.

# ILLUSTRATIVE SKELETON — not a complete model and not a design.
# Fill every omitted object yourself. Then run OpenSees. Then check independently.

from openseespy.opensees import *

wipe()
model("basic", "-ndm", 2, "-ndf", 3)

# Human must define: units, node coordinates, masses, materials,
# sections, geometric transformation, elements, constraints, and loads.

# Example of a checkable declaration (values are placeholders, not recommendations):
# node(1, 0.0, 0.0)
# fix(1, 1, 1, 1)

# After the human owns the model:
# eigen(nModes) or static analyze(...)
# print or recorder output for the quantities you will check by another method

A generated file that “looks full” is more dangerous than this stub. Completeness of syntax is not completeness of mechanics.

Human checklist before the first analyze

Work this list on the edited file, not on the chat transcript.

1. Units. One system, written at the top of the file. Gravity, density, and force must agree. AI drafts often mix millimetres, metres, and kips.
2. Kinematics. Two-dimensional vs three-dimensional; truss vs beam vs shell. ndf must match the element type you think you used.
3. Geometry. Node coordinates from your drawing or a reduced study geometry you can sketch by hand. Do not accept invented spans.
4. Constraints. Supports that match the intended mechanism. Watch for missing fixes (rigid-body modes) and accidental releases.
5. Elements and transformation. elasticBeamColumn is not a fiber hinge. Linear is not PDelta is not Corotational. The generated name is often the wrong physics.
6. Mass (if dynamics). What is lumped, what is consistent, whether rotational mass is intended, whether mass is on the right DOF. Eigenvalues without mass are a different problem than the one you asked.
7. Loads and patterns. Direction, combination, and whether gravity is present. A static drift check with no gravity is a different model than a P-Delta check.
8. Analysis. Eigenvalue vs static vs transient; integrator; convergence test. A run that hits analyze warnings is information, not an inconvenience to hide.
9. Output. You cannot validate a quantity you did not record.

If the language model filled any of these without a source you can point to, delete that part and write it yourself.

What the solver is for

After the checklist, run OpenSees (or OpenSeesPy) on the human-owned file. Save:

• the input you actually ran (not the first generated draft);
• the version of the interpreter and, if you track it, the OpenSees build;
• logs, including warnings;
• the specific results you will check (periods, reactions, a displacement at a named node).

That run is a deterministic calculation of the model you supplied. It is not proof that the model is the structure, and it is not a code check.

Validation evidence (the step AI cannot take)

Pick a check that does not reuse the generated deck:

• Reduce the problem to a SDOF or a single-bay portal you can solve with stiffness method or a textbook frequency.
• Compare elastic periods or static displacements to a second independent model (another engine, or a much simpler OpenSees file you typed yourself).
• For dynamics theory and what “reasonable” modal behaviour looks like in linear systems, use a reference such as Chopra — as theory, not as a substitute for your numbers.

Agreement to three digits with a chatbot paraphrase of your own output is not independent. If the two methods disagree, believe neither until you understand the model.

Common mistakes

• Prompting “write a 3D building in OpenSees” and treating the file as a digital twin.
• Leaving generated wipe() / model() boilerplate untouched while the rest of the file describes a different ndm.
• Using nonlinear materials because the prompt said “pushover,” then reading the first-step displacement as if it were linear.
• Skipping Rayleigh damping, mass source, or constraints, then comparing periods to a code approximate formula as if that were validation.
• Publishing a notebook that calls an API for Tcl and never shows a human diff.

Limitations

OpenSees is a research and professional analysis framework with a large element library. This article does not document that library, does not select elements for seismic design, and does not address soil-structure interaction, geometric nonlinearity strategy, or performance-based assessment.

The skeleton is intentionally incomplete. Any numbers you might obtain by filling it in are your calculation, not this site’s.

Language models will keep improving at syntax. Syntax is the cheap part. Units, intended kinematics, and independent checks remain expensive. Those costs do not disappear because the draft arrived faster.

Professional context

A replayable OpenSees model can be excellent documentation of an analysis, if a competent person owns it. It still is not a substitute for the design standard that governs the project, and it is not a stamp. Students should use this workflow to learn how easy it is to get a fluent, wrong model. Practitioners should keep AI drafts out of the signed set until the checklist and the independent check exist in the project file.

References

• OpenSees documentation — opensees.github.io/OpenSeesDocumentation.
• OpenSeesPy — follow the interpreter and command docs shipped with the version you actually run. Command names and defaults change; do not trust a generated import path without checking that version.
• Chopra, A. K. Dynamics of Structures. Independent check material for linear dynamics, not a substitute for your OpenSees numbers.

Evaluation and limitations

Treat the notes below as evaluation context, not as a verified calculation or code check.

Judge an AI-assisted OpenSees workflow by artifacts, not by fluency of the generated file: a human-owned input, a solver log, and an independent check (reduced-order hand calc, textbook frequencies, or a second model). If any of those is missing, you still have a suggestion. This page does not verify OpenSees, OpenSeesPy, or any prompt.