🤖 AI

Automating Structural Analysis Across Multiple Software Platforms Using Large Language Models

This study introduces a two-stage multi-agent large language model framework that automates frame structural analysis by collaboratively interpreting user inputs and translating them into executable scripts across multiple software platforms (ETABS, SAP2000, and OpenSees), achieving over 90% accuracy in generating valid models.

Original authors: Ziheng Geng, Jiachen Liu, Ian Franklin, Ran Cao, Dan M. Frangopol, Minghui Cheng

Published 2026-04-14

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Ziheng Geng, Jiachen Liu, Ian Franklin, Ran Cao, Dan M. Frangopol, Minghui Cheng

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are an architect who needs to build a bridge. In the real world, you might use three different types of blueprints: one for a wooden model, one for a steel model, and one for a concrete model. Each blueprint has its own weird language, symbols, and rules. If you want to check if your bridge is safe, you have to manually redraw the same bridge three times, once for each language. It's tedious, prone to errors, and takes forever.

This paper introduces a super-smart AI team that does this redrawing for you, instantly, and perfectly, no matter which "language" (software) you need.

Here is how they did it, broken down into simple concepts:

1. The Problem: The "Language Barrier"

Engineers use powerful computer programs (like ETABS, SAP2000, and OpenSees) to simulate how buildings handle earthquakes, wind, and heavy loads.

The Issue: These programs don't speak the same language. One uses a specific code format, another uses a different one, and a third uses a completely different logic.
The Old Way: Previously, AI could only learn one of these languages. If you wanted to switch software, you had to train a whole new AI. It was like having a translator who only speaks French but not Spanish or German.

2. The Solution: The "Specialized AI Team"

Instead of one giant AI trying to do everything, the researchers built a Multi-Agent System. Think of this not as a single robot, but as a construction crew with different specialists, all working together.

They split the job into two main phases:

Phase 1: The "Architects" (Understanding the Plan)

Before anyone starts building, someone has to understand what you want.

The Input: You type a simple description: "Build a 3-story frame, 6 meters wide, with a heavy weight on the roof."
The Team:
- The Analyst: Reads your text and pulls out the numbers.
- The Planner: Decides the order of construction (bottom-up, left-to-right).
- The Node & Element Agents: They figure out exactly where every beam and column goes.
- The Load Agent: Decides where the wind and gravity push.
The Output: Instead of writing code for a specific software yet, they create a Universal Blueprint (a JSON file). Think of this as a "Master Recipe" that lists ingredients and steps without specifying which brand of oven you are using.

Phase 2: The "Translators" (Speaking the Software's Language)

Now that the Master Recipe is ready, the team splits up to translate it into the specific "dialects" of the three software programs.

The Translators: These agents take the Universal Blueprint and rewrite it into the specific code required by OpenSees, SAP2000, or ETABS.
The Magic: Because they are specialized, they know the tiny, annoying rules of each software (like "OpenSees hates duplicate names" or "ETABS requires you to define stories first").
The Result: In about two minutes, you get three ready-to-run files, one for each software, all describing the exact same building.

3. The Analogy: The "Universal Translator" vs. The "Specialist Crew"

Imagine you are ordering a complex meal.

Old AI (General Purpose): It's like a single chef who tries to cook Italian, Japanese, and Mexican food all at once. They might know the basics, but they often mess up the specific spices or cooking times, resulting in a burnt or weird-tasting dish.
This New System: It's like a kitchen brigade.
- One person (The Architect) listens to your order and writes a clear list of ingredients.
- Three different chefs (The Translators) take that list. One is a master of Italian, one of Japanese, and one of Mexican. They each cook their version perfectly because they only focus on their specific style.

4. The Results: Speed, Accuracy, and Savings

The researchers tested this on 20 different building designs.

Accuracy: The new system got it right 90% to 100% of the time.
The Competition: They tested the "Old AI" (like GPT-5 or Gemini) against this system. The Old AI got it right less than 20% of the time for some software and 0% for others. It kept making silly mistakes, like forgetting to connect a beam or using the wrong math.
Cost: It's incredibly cheap. Running this AI team costs about 2 cents per building design.
Speed: It takes about 2 minutes to generate all three versions of the analysis.

Why This Matters

This isn't just about saving time; it's about trust.
In engineering, if you make a mistake in the math, a building could fail. By using this "AI Crew," engineers can:

Stop manual typing: No more copying and pasting data between programs.
Double-check work: They can instantly run the same design in three different programs to make sure the results match.
Focus on design: Engineers can spend less time fighting with software syntax and more time designing better, safer structures.

In short: This paper built a "Swiss Army Knife" for structural engineers. Instead of carrying three different tools and learning three different languages, they now have one smart team that speaks all of them fluently, instantly, and correctly.

1. Problem Statement

While Large Language Models (LLMs) have shown promise in automating civil engineering workflows, existing research is limited to operating a single structural analysis software platform. In professional practice, structural engineers frequently utilize multiple Finite Element Analysis (FEA) tools (e.g., ETABS, SAP2000, OpenSees) depending on project constraints, user preferences, and specific modeling requirements.

The Gap: Current LLM applications lack the capability to bridge these "software silos." Training separate LLMs for every software environment is inefficient and limits scalability.
The Challenge: Different FEA platforms have distinct modeling logics (e.g., node-based vs. story-based) and syntax requirements. A single general-purpose LLM often fails to generate error-free, executable scripts across these diverse environments due to hallucinations, syntax errors, and logical mismatches.

2. Methodology

The authors propose a Two-Stage Multi-Agent Architecture designed to decouple high-level semantic reasoning from platform-specific code generation. The system utilizes a hybrid of LLM backbones: GPT-OSS 120B for semantic reasoning and Llama-3.3 70B Instruct Turbo for code translation.

Stage 1: Input Interpretation & Semantic Reasoning

This stage converts unstructured natural language descriptions of structural problems into a unified, platform-agnostic JSON representation. It employs five specialized agents:

Problem Analysis Agent: Extracts key parameters (geometry, supports, materials, loads) from user input.
Construction Planning Agent: Formulates a stepwise assembly logic (bottom-to-top, left-to-right) to ensure deterministic topology construction.
Node Agent: Derives node IDs, spatial coordinates, and support conditions.
Element Agent: Defines structural members (beams/columns) and their connectivity.
Load Assignment Agent: Maps concentrated and distributed loads to specific nodes and elements.

Output: A structured JSON file containing all necessary modeling data, independent of the target software.

Stage 2: Parallel Code Translation

This stage translates the unified JSON into executable scripts for specific platforms. The agents operate in parallel pipelines:

OpenSees & SAP2000: These platforms use a node/element-based logic similar to the JSON structure.
- Geometry Translation Agent: Converts JSON geometry data into platform-specific commands.
- Code Compilation Agent: Assembles geometry, loads, and analysis configurations into complete scripts (.tcl for OpenSees, .s2k for SAP2000).
ETABS: This platform uses a unique story-based modeling logic (defining stories first, then assigning objects).
- Semantic Mapping Agent: A specialized agent bridges the gap by mapping the JSON object definitions into the story-level hierarchy required by ETABS.
- Translation Agents: Convert the story-level representation into an executable .e2k file.

3. Key Contributions

Cross-Platform Automation: The first framework capable of automating frame structural analysis across three distinct FEA platforms (OpenSees, SAP2000, ETABS) simultaneously from a single natural language input.
Multi-Agent Architecture: A novel design that separates semantic reasoning from code generation, allowing the system to handle the unique modeling logics of different software without retraining the core reasoning model.
Semantic Mapping for Diverse Logics: The introduction of a specific "Semantic Mapping Agent" to handle the fundamental logical differences between node-based (OpenSees/SAP2000) and story-based (ETABS) modeling paradigms.
Cost-Effective Implementation: The use of lightweight, open-source backbone models (GPT-OSS and Llama-3.3) significantly reduces API costs compared to proprietary state-of-the-art models.

4. Results

The system was evaluated on a benchmark dataset of 20 representative frame problems with irregular topologies, subjected to 10 repeated trials each.

Proposed System Performance:
- SAP2000: 100% accuracy (perfect across all trials).
- ETABS: 99% average accuracy (18/20 problems at 100%, 2 at 90%).
- OpenSees: 98% average accuracy (minor variability in 5 problems, dropping to 90%).
- Overall: Consistently exceeded 90% accuracy across all platforms.
Comparison with State-of-the-Art (GPT-5.2 and Gemini-3-Pro):
- GPT-5.2: Average accuracy of 18% for OpenSees and 0% for SAP2000/ETABS. It struggled with semantic reasoning (incorrect topology) and strict syntax requirements.
- Gemini-3-Pro: Average accuracy of 79% for OpenSees but 0% for SAP2000/ETABS. It failed due to hallucinated variable names and inability to adapt to story-based modeling logic.
- Conclusion: The proposed multi-agent system significantly outperforms general-purpose LLMs, proving that specialized architecture is necessary for reliable engineering automation.
Efficiency & Cost:
- Runtime: Scripts are generated in parallel within ~2 minutes (113s–144s per platform).
- Cost: Approximately $0.012 –$ 0.025 per problem per platform, compared to ~ $0.04–$ 0.05 for general-purpose models.

5. Significance

This study demonstrates that LLM-assisted engineering workflows can be practically deployed across diverse software ecosystems, not just in isolated environments.

Workflow Integration: The system generates executable files (.tcl, .s2k, .e2k) that can be directly imported into commercial software, allowing engineers to verify models via GUIs before running analyses.
Reliability: By achieving >90% accuracy, the system minimizes the risk of "hallucinated" structural models, a critical barrier to adopting AI in safety-critical civil engineering.
Scalability: The modular architecture allows for the easy integration of new software platforms by adding specific translation agents without retraining the entire system.
Future Outlook: While currently limited to rectangular frames, this approach provides a blueprint for automating complex structural typologies (bracing, cantilevers) and integrating real-world, unstructured design documents.