Agentic LLMs for Automated Structural Analysis of 3D Frame Systems

8 min read

Source Snapshot

  • Origin: Agentic Large Language Models for Automated Structural Analysis of 3D Frame Systems
  • Type: Paper
  • Author / org: Ziheng Geng, Ian Franklin, Santiago Martinez, Jiachen Liu, Yunhe Zhao, and Minghui Cheng; University of Miami and HBC Engineering Company.
  • One-line takeaway: Reliable engineering automation comes from structured representations, specialized agents, deterministic checkpoints, and executable tools rather than asking one general-purpose model to generate an entire analysis model.

Garden Card

This paper presents a multi-agent pipeline that converts a structured natural-language description of an irregular 3D frame into an executable SAP2000 model. Its most reusable contribution is architectural: simplify the geometry into stable intermediate representations, assign narrow responsibilities to specialized agents, validate every handoff, and reserve engineering software for deterministic analysis.

1. Executive Summary

The paper introduces an agentic LLM framework for generating SAP2000 scripts for irregular 3D frame systems. Instead of generating a thousand-line engineering script in one pass, the system converts a matrix-of-number-of-stories representation into floor layouts, nodes, girders, slabs, columns, supports, loads, and finally executable SAP2000 commands.

Across ten benchmark frames and ten repeated trials per frame, the framework reports 90% average accuracy. A trial counts as accurate only when every monitored structural response differs from the manually constructed reference model by less than 1%. Direct single-model baselines using GPT-5.4 and Gemini-3.1 Pro achieve 0% accuracy under the paper’s test setup.

  • Main idea: Decomposition is not merely an orchestration preference; it is the mechanism that makes long-horizon engineering generation tractable.

  • Why now: Engineering copilots can generate plausible code, but industrial value requires valid topology, strict software syntax, traceable assumptions, and reproducible solver results.

  • Where it applies: Assisted structural modeling, model setup automation, engineering-software integration, simulation workflow orchestration, and controlled design-analysis pilots.

Decision Signal

Do not ask one model to own the entire engineering workflow. Build a governed pipeline in which each agent produces a typed artifact, every transition has a deterministic check, and the final model remains subject to engineer approval.

2. Key Technical Terms

  • Matrix of Number of Stories, MNS: A 2D matrix whose cell value defines how many stories occupy that plan region. A zero represents a void; larger values define vertical extrusion.

  • Floor decomposition: Conversion of a 3D occupancy problem into a stack of binary 2D floor plans.

  • Topological consistency: Assurance that nodes, member endpoints, slab corners, and inter-story connections reference valid and coherent geometry.

  • Structured intermediate representation: Typed JSON artifacts used to pass geometry, supports, loads, and assignments between agents.

  • SAP2000 .s2k script: Table-based text representation that SAP2000 can import to construct and analyze a structural model.

  • Checkpoint: A deterministic validation step that blocks invalid intermediate artifacts before downstream processing.

3. Core Notes

3.1 Problem

Manual finite-element model construction requires engineers to define coordinates, connectivity, sections, supports, materials, and loads through repetitive software operations. For irregular 3D frames, automation is difficult because a model must preserve spatial meaning, shared topology, software-specific syntax, and long-range consistency across many generated commands.

The paper identifies three core barriers:

  • Irregular geometry is difficult to describe unambiguously in natural language.

  • Nodes, girders, slabs, and columns must remain consistently connected within and across floors.

  • Complete SAP2000 scripts create a long-horizon generation problem where small errors accumulate.

3.2 Mechanism

The framework uses three stages: problem interpretation, modeling-information inference, and code translation.

  1. The problem analysis agent extracts gridlines, MNS, story heights, support conditions, load patterns, and material properties into JSON.
  2. The floor decomposition agent converts the MNS into one occupancy map per floor.
  3. Node, girder, and slab agents run in parallel to generate in-plane components.
  4. The column agent connects matching X-Y node coordinates between adjacent stories.
  5. Deterministic checkpoints reject duplicate nodes, undefined endpoints, invalid slab corners, disconnected nodes, and inconsistent columns.
  6. Support and load agents map boundary and loading descriptions to target components.
  7. The geometry translation agent produces SAP2000 geometry commands.
  8. The code compilation agent assembles geometry, sections, supports, loads, and analysis configuration into an executable .s2k script.

3.3 Evidence

The evaluation uses ten irregular 3D frame cases with height variation, plan asymmetry, setbacks, voids, and L-, U-, or cross-shaped layouts. Grid sizes range from 3 x 3 to 4 x 6, with zero to seven stories per cell. Boundary conditions, loads, and materials are held constant across the cases.

EvidenceReported resultDecision meaning
Full multi-agent framework90% mean accuracy; all cases above 80%Structured decomposition can be reliable within the benchmark
GPT-5.4 direct script generation0% accuracy; 4% average import successGeneral coding strength does not guarantee engineering-software validity
Gemini-3.1 Pro direct script generation0% accuracy; 47% average import successImportable syntax still does not guarantee correct topology or analysis
Remove floor decomposition20-50% accuracy on three ablation casesFloor-level intermediate representations carry essential spatial semantics
Merge node, girder, and slab agents50-70% accuracyNarrow geometry responsibilities improve consistency
Merge translation and compilation0% accuracyThousand-line code generation needs staged assembly
RuntimeAbout 175 seconds per caseParallel narrow agents can keep latency operationally reasonable
CostUSD 0.193 average per caseLightweight models can reduce inference cost for structured subtasks

The most common framework failures are incorrect section assignments and missing, extra, or misplaced loads. These failures occur where long geometric contexts must be mapped back to specific structural components.

3.4 Boundary

The reported 90% accuracy is a benchmark result, not evidence of autonomous production approval.

  • The dataset contains only ten author-designed cases, although each is repeated ten times.

  • Floor plans must be discretized into orthogonal rectangular cells; nonorthogonal and curved geometries are unsupported.

  • The framework covers static structural analysis and excludes dynamic response, seismic behavior, wind-induced response analysis, shear walls, and bracing systems.

  • Loads, supports, and materials are mostly standardized across benchmark cases, limiting evidence for broader requirement diversity.

  • The paper evaluates response agreement, but does not establish regulatory compliance, model certification, or safety-case governance.

  • Supporting data, models, and code are available only upon reasonable request, reducing immediate reproducibility.

Engineering Boundary

Generated SAP2000 models must remain draft engineering artifacts until an authorized engineer verifies geometry, units, sections, loads, combinations, solver settings, response outputs, and applicable design-code requirements.

4. Concept Map

flowchart LR
  A["Natural-Language Engineering Brief"] --> B["Problem Analysis Agent"]
  B --> C["Typed JSON Contract"]
  C --> D["Floor Decomposition"]
  D --> E["Parallel Geometry Agents"]
  E --> F["Topology Checkpoints"]
  F --> G["Support and Load Agents"]
  G --> H["Translation and Compilation"]
  H --> I["SAP2000 Model"]
  I --> J["Engineer Verification"]
  J --> K["Structural Analysis"]

The system succeeds by converting one difficult reasoning problem into a chain of bounded transformations with explicit data contracts.

5. Enterprise Operating Pattern

The paper’s architecture can be generalized beyond SAP2000. An enterprise engineering agent should separate intent capture, domain representation, artifact generation, deterministic validation, software execution, and human approval.

engineering_automation:
  input_contract:
    - geometry
    - materials
    - boundary_conditions
    - loads
    - analysis_scope
  agents:
    - problem_interpretation
    - spatial_decomposition
    - component_generation
    - assignment_mapping
    - software_translation
  deterministic_controls:
    - schema_validation
    - identifier_integrity
    - topology_checks
    - unit_validation
    - load_balance_checks
    - solver_import_test
    - response_comparison
  required_records:
    - source_requirements
    - intermediate_artifacts
    - model_and_prompt_versions
    - generated_script
    - solver_version
    - validation_results
    - engineer_approval

The operational gain is not simply faster script generation. It is a controlled digital thread from engineering intent to executable model, with enough evidence to diagnose failures and reproduce decisions.

6. Adoption Readiness

CapabilityReadinessRecommended use
Structured natural-language intakeEmerging but practicalControlled templates and assisted requirement capture
Orthogonal 3D frame generationStrong benchmark evidenceSandbox pilots with known reference models
SAP2000 script generationPromising with checkpointsDraft model creation and repetitive setup automation
Automatic structural analysisTool-ready after importRun only after deterministic and human verification
Irregular real-world buildingsLimitedExtend representation and benchmark before deployment
Safety-critical autonomous approvalNot readyKeep licensed engineer sign-off mandatory

Pilot Path

Start with one recurring frame family that already has trusted SAP2000 reference models. Run the agent in shadow mode, compare every generated model against the approved baseline, classify failure modes, and automate only the stages that consistently meet an agreed validation threshold.

7. My Take

This paper strengthens the case that bounded agents are more valuable for industrial engineering than unconstrained general-purpose assistants. The decisive design choice is not the number of agents; it is the presence of explicit intermediate representations and deterministic acceptance criteria at each boundary.

  • What changed my thinking: A geometric representation such as MNS can be as important as the model itself because it converts spatial complexity into a contract the agent can reliably manipulate.

  • What I may do next: Use this architecture as a reference pattern for engineering-agent pilots: typed input, narrow agents, parallelizable subtasks, deterministic checkpoints, and human release authority.

  • What still needs verification: Reproducibility on independent data, robustness to requirement variation, unit and load validation, dynamic analysis, nonorthogonal geometry, solver-version compatibility, and compliance workflows.

Strategic Takeaway

The path to trustworthy engineering AI is not larger prompts. It is better domain representations, smaller reasoning scopes, executable validation, and accountable human approval.

References

Graph View