Paper deep dive
Automating Structural Analysis Across Multiple Software Platforms Using Large Language Models
Ziheng Geng, Jiachen Liu, Ian Franklin, Ran Cao, Dan M. Frangopol, Minghui Cheng
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 96%
Last extracted: 4/14/2026, 1:56:58 AM
Summary
This paper presents a two-stage multi-agent architecture using Large Language Models (LLMs) to automate structural frame analysis across multiple finite element analysis (FEA) platforms, specifically ETABS, SAP2000, and OpenSees. Stage 1 uses GPT-OSS 120B to interpret user input into a unified JSON representation, while Stage 2 uses Llama-3.3 70B Instruct Turbo to translate this JSON into platform-specific executable scripts, achieving over 90% accuracy.
Entities (6)
Relation Signals (3)
GPT-OSS 120B → performsstage1 → Input Interpretation and Semantic Reasoning
confidence 95% · GPT-OSS 120B is used for reasoning tasks
Llama-3.3 70B Instruct Turbo → performsstage2 → Code Translation
confidence 95% · Llama-3.3 70B Instruct Turbo performs code translation
Multi-agent architecture → supportsplatforms → ETABS, SAP2000, OpenSees
confidence 95% · automating frame structural analysis across multiple software platforms
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Recent advances in large language models (LLMs) have shown the promise to significantly accelerate the workflow by automating structural modeling and analysis. However, existing studies primarily focus on enabling LLMs to operate a single structural analysis software platform. In practice, structural engineers often rely on multiple finite element analysis (FEA) tools, such as ETABS, SAP2000, and OpenSees, depending on project needs, user preferences, and company constraints. This limitation restricts the practical deployment of LLM-assisted engineering workflows. To address this gap, this study develops LLMs capable of automating frame structural analysis across multiple software platforms. The LLMs adopt a two-stage multi-agent architecture. In Stage 1, a cohort of agents collaboratively interpret user input and perform structured reasoning to infer geometric, material, boundary, and load information required for finite element modeling. The outputs of these agents are compiled into a unified JSON representation. In Stage 2, code translation agents operate in parallel to convert the JSON file into executable scripts across multiple structural analysis platforms. Each agent is prompted with the syntax rules and modeling workflows of its target software. The LLMs are evaluated using 20 representative frame problems across three widely used platforms: ETABS, SAP2000, and OpenSees. Results from ten repeated trials demonstrate consistently reliable performance, achieving accuracy exceeding 90% across all cases.
Tags
Links
- Source: https://arxiv.org/abs/2604.09866v1
- Canonical: https://arxiv.org/abs/2604.09866v1
Trouble viewing inline? Open PDF directly →
Full Text
54,466 characters extracted from source content.
Expand or collapse full text
AUTOMATING STRUCTURAL ANALYSIS ACROSS MULTIPLE SOFTWARE PLATFORMS USING LARGE LANGUAGE MODELS Ziheng Geng 1 , Jiachen Liu 2 , Ian Franklin 1 , Ran Cao 3 , Dan M. Frangopol 4 , Minghui Cheng 1,5† 1 Department of Civil and Architectural Engineering, University of Miami, Coral Gables, FL 33146, USA 2 HBC Engineering Company, Miami, FL 33178, USA 3 College of Civil Engineering, Hunan University, Changsha, 410082, China 4 Department of Civil and Environmental Engineering, Lehigh University, Bethlehem, PA 18015, USA 5 School of Architecture, University of Miami, Coral Gables, FL 33146, USA † Corresponding author: minghui.cheng@miami.edu April 14, 2026 ABSTRACT Recent advances in large language models (LLMs) have shown the promise to significantly accelerate the workflow by automating structural modeling and analysis. However, existing studies primarily focus on enabling LLMs to operate a single structural analysis software platform. In practice, structural engineers often rely on multiple finite element analysis (FEA) tools, such as ETABS, SAP2000, and OpenSees, depending on project needs, user preferences, and company constraints. This limitation restricts the practical deployment of LLM-assisted engineering workflows. To address this gap, this study develops LLMs capable of automating frame structural analysis across multiple software platforms. The LLMs adopt a two-stage multi-agent architecture. In Stage 1, a cohort of agents collaboratively interpret user input and perform structured reasoning to infer geometric, material, boundary, and load information required for finite element modeling. The outputs of these agents are compiled into a unified JSON representation. In Stage 2, code translation agents operate in parallel to convert the JSON file into executable scripts across multiple structural analysis platforms. Each agent is prompted with the syntax rules and modeling workflows of its target software. The LLMs are evaluated using 20 representative frame problems across three widely used platforms: ETABS, SAP2000, and OpenSees. Results from ten repeated trials demonstrate consistently reliable performance, achieving accuracy exceeding 90% across all cases. Keywords: Large language models, Multi-agent architecture, Automated structural analysis; Finite element analysis software 1 Introduction Powered by billions of parameters, state-of-the-art large language models (LLMs), such as GPT-5 (OpenAI, 2025), Gemini 3 (Google DeepMind, 2025), and DeepSeek V3 (Liu et al., 2024a), have demonstrated strong generalization capabilities across tasks including code generation (Jiang et al., 2024; Joel et al., 2024; Dong et al., 2025b), long-context reasoning (Bai et al., 2025; Chung et al., 2025; Ling et al., 2025), and tool calling (Liu et al., 2024b; Shen, 2024; Lu et al., 2025). This technological leap offers a unique opportunity to leverage these capabilities to automate intricate workflows and accelerate the efficiency of civil engineers. Initial explorations into LLM applications have successfully employed these models for tasks such as building code interpretation (Joffe et al., 2025; Zhu et al., 2024; Chen and Bao, 2025), construction report generation (Pu et al., 2024; Chen et al., 2025; Xia et al., 2026), and visual damage assessment (Zhang et al., 2025; Jiang et al., 2025, 2026). Collectively, these studies underscore the transformative potential of LLMs to augment human expertise and assist in complex engineering tasks. arXiv:2604.09866v1 [cs.SE] 10 Apr 2026 A PREPRINT - APRIL 14, 2026 Within civil engineering, structural modeling and analysis is one of the cornerstones for the design and assessment of civil infrastructure systems. In contemporary practice, the finite element analysis (FEA) has become indispensable to analyze structural behavior under complex geometric, loading, and material conditions. A broad range of FEA software platforms have been widely adopted by engineers, including commercial software such as ETABS (Computers and Structures, Inc., 2025a) and SAP2000 (Computers and Structures, Inc., 2025b), as well as open-source frameworks such as OpenSees (McKenna, 2011). In practice, using FEA software is largely manual and time-consuming. While LLMs possess the potential to automate these workflows, they lack the native ability to interact iteratively with external computational environments. To bridge this gap, recent research has shifted toward the development of LLMs capable of using domain software. Liu et al. (2026) and Geng et al. (2025, 2026) adapted lightweight Llama 3.3 70B Instruct models to generate OpenSeesPy code to automate structural analysis of beam and frame structures. Liang et al. (2025a,b) proposed domain-specific prompt design for structural engineering problems and demonstrated their approach through frame analysis and racking system design. Focusing on the design, Chen and Bao (2026) developed LLMs that automate ABAQUS operations to identify optimal design solutions of ultra-high-performance concrete beams. In addition, Deng et al. (2025) and Du et al. (2026) trained LLMs to use building information modeling softwre to construct simple 3D building models from natural language instructions and conceptual sketches. While existing studies are pushing the boundary in training LLMs to use engineering software, there is a lack of research in developing capabilities to operate different software platforms. In practice, engineering workflows rarely rely on a single tool, and multiple FEA platforms (such as ETABS, SAP2000, and OpenSees) are commonly used within the structural engineering community depending on the project needs and constraints. Therefore, developing LLMs capable of operating multiple platforms is essential for practical LLM-assisted engineering. Otherwise, separate LLMs would need to be trained for each software environment, significantly limiting scalability and adoption. To bridge this gap, this study develops LLMs to automate structural analysis across software silos using a multi-agent architecture, as illustrated in Fig. 1. The general concept behind the architecture is that the overall task of structural modeling and analysis is decomposed into two subtasks: (i) reasoning from user input to derive the information required for finite element modeling, and (i) translating the derived information into executable scripts tailored to specific software platforms. Following this concept, the multi-agent architecture has two stages. In Stage 1, a group of reasoning agents interprets user input and derives geometry, materials, boundary conditions, and loads, which are compiled into a unified JSON representation. In Stage 2, code translation agents convert this representation into executable scripts for different platforms. GPT-OSS 120B is used for reasoning tasks, while Llama-3.3 70B Instruct Turbo performs code translation. The system is evaluated on 20 representative frame problems across OpenSees, SAP2000, and ETABS, demonstrating reliable script generation and significantly outperforming state-of-the-art general-purpose LLMs. Fig 1. Fragmented software ecosystem within the Architecture, Engineering, and Construction (AEC) industry. The AEC Software Ecosystem Bottleneck Project: 2D Frame Structural Analysis Software Silos 1. OpenSees (CLI) Workflow: Fully script-based modeling without a GUI 2. SAP 2000 (GUI) Workflow: Individual point-and- click definition for all components 3. ETABS (GUI) Workflow: Story-based assignment from predefined base components .tcl file .mdb file .s2k file .edb file .e2k file Output: The AEC Software Ecosystem Project: Frame Structural Analysis Multi-Agent Large Language Models for Automated Structural Analysis across Platforms 1. OpenSees (CLI) Workflow: Fully script-based modeling without a GUI 2. SAP 2000 (GUI) Workflow: Individual point-and- click definition for all components 3. ETABS (GUI) Workflow: Story-based assignment from predefined base components .tcl file.s2k file.e2k fileOutput: Fig. 1: Development of LLMs capable of operating multiple software platforms for automated structural analysis. 2 A PREPRINT - APRIL 14, 2026 Fig 2. A benchmark dataset comprising twenty representative 2D frame structural analysis problems Point load: 50 kN Distributed load: 10 kN/m 6 m6 m6 m 5 m 4 m 5 m 6 m6 m6 m 4 m 5 m 4 m 4 m 6 m6 m6 m 3 m 5 m 5 m 3 m 6 m6 m6 m 3 m 5 m 5 m 3 m 4 m 6 m6 m6 m 4 m 5 m 4 m 5 m 4 m 6 m6 m6 m 4 m 5 m 4 m 6 m6 m6 m6 m6 m 4 m 5 m 4 m 6 m6 m6 m6 m6 m 4 m 5 m 4 m 6 m6 m 6 m6 m6 m 4 m 5 m 3 m 6 m6 m6 m6 m6 m 4 m 5 m 3 m 6 m6 m 2 m 1 m 6 m6 m6 m 4 m 5 m 3 m 6 m6 m 2 m 1 m 6 m6 m6 m 4 m 5 m 6 m6 m 5 m 3 m 6 m6 m6 m 4 m 5 m 4 m 6 m6 m 2 m 3 m 6 m6 m6 m 4 m 5 m 3 m 6 m6 m 3 m 3 m 6 m6 m6 m 4 m 5 m 4 m 6 m6 m 4 m 3 m 6 m6 m6 m 4 m 5 m 4 m 6 m6 m 4 m 3 m 6 m6 m6 m 4 m 5 m 4 m 6 m6 m 4 m 3 m 6 m6 m6 m 4 m 5 m 6 m6 m 5 m 3 m 5 m 6 m6 m6 m 4 m 5 m 4 m 6 m6 m 5 m 3 m 6 m6 m6 m 4 m 5 m 4 m 6 m6 m 6 m 3 m Fig. 2: A benchmark dataset comprising twenty representative frame structural analysis problems (adapted from Geng et al., 2025). 3 A PREPRINT - APRIL 14, 2026 2 Benchmark Dataset To demonstrate how automating structural analysis across multiple software platforms using LLMs can be realized in practice, this study selects frame structural analysis as a representative case study for implementation and validation. Accordingly, a benchmark dataset comprising 20 representative frame analysis problems is adapted from previous work (Geng et al., 2025) and used as the evaluation testbed, as illustrated in Fig. 2. The dataset encompasses a broad spectrum of geometric configurations with irregular topologies. It is generated by varying bay counts, story numbers, bay widths, and story heights to reflect realistic design scenarios. Consistent loading patterns are applied across all benchmark cases: each frame is subjected to a combination of concentrated and distributed loads, including lateral point loads applied at each floor level from the left side and a uniformly distributed gravity load applied to all beam elements. Boundary conditions and material properties are also prescribed consistently. Specifically, all base nodes are restrained to simulate fixed supports, and structural members are assumed to be linear elastic. Distinct cross-sectional properties are assigned to beams and columns, respectively. Together, these test cases serve as a systematic testbed for assessing the accuracy, robustness, and generality of the proposed LLMs. For each benchmark problem, a structured textual description is constructed to encode the engineering intent underlying the graphical representation, following the approach proposed by Wan et al. (2025). The template organizes problem definition into four modules: geometric configuration, boundary conditions, loading patterns, and material properties, as illustrated in Fig. 3. The geometric configuration module specifies the structural topology, including the number of bays and stories, along with corresponding bay widths and story heights. Boundary conditions are defined by specifying support types and their nodal locations. Loading patterns are described in terms of load types, magnitudes, spatial directions, and application points. Material properties are prescribed through constitutive parameters required for stiffness matrix formulation, such as Young’s modulus, cross-sectional areas, and moments of inertia. Once the structured problem description is formulated, an additional instruction is appended to indicate the target structural analysis software (e.g., OpenSees, SAP2000, or ETABS). These textual inputs are then provided to the proposed system,which automatically generates executable structural analysis scripts. To account for the inherent stochasticity of LLM generation, each benchmark problem is evaluated through ten independent runs. The reliability is quantified by the proportion of trials that yield error-free analysis scripts. Fig. 3. Textual template for problem description in 2D frame structural analysis. [Geometry]: The frame has three bays, each with a span of 6 meters. The first bay has three stories with heights of 7 m, 6 m, and 7 m, respectively. The second bay has two stories with heights of 7 m and 6 m. The third bay has three stories with heights of 7 m, 6 m, and 7 m, respectively. [Boundary Conditions]: All supports are fixed at the base. [Load Patterns]: A uniformly distributed load of 10 kN/m is applied downward along each beam. At the leftmost bay, a rightward point load of 50 kN is applied at the top of each story. [Material Properties]: The frame is assumed to be elastic with a Young’s modulus of 2 × 10 11 Pa. The columns have a cross- sectional area of 2 × 10⁻³ m² and a moment of inertia of 1.6 × 10⁻⁵ m⁴, while the beams have a cross-sectional area of 6 × 10⁻³ m² and a moment of inertia of 5.4 × 10⁻⁵ m⁴. Graphical Problem RepresentationStructured Textual Template 6 m6 m6 m 7 m 6 m 7 m 50 kN 50 kN 50 kN 10 kN/m 10 kN/m10 kN/m 10 kN/m Translate to Text Fig. 3: Textual template for problem description in frame structural analysis. 3 A Multi-Agent Architecture for Automated Structural Analysis across Software Platforms 3.1 Overall architectural design Fig. 4 illustrates the overall architecture design of the proposed multi-agent LLMs to automate structural analysis across multiple software platforms. The architecture has two stages that decouples high-level semantic reasoning from platform-specific code generation. Specifically, Stage 1 focuses on input interpretation and semantic reasoning. The process begins with the problem analysis agent and the construction planning agent, which extract key modeling parameters from the users’ problem description and formulate a stepwise assembly logic for the frames. Subsequently, the node agent and element agent derive node coordinates, support conditions, and element connectivity, whereas the load assignment agent interprets and assigns load patterns to the corresponding structural components. The backbone LLM underpinning these agents is GPT-OSS 120B model, selected for its strong semantic reasoning capability (Agarwal 4 A PREPRINT - APRIL 14, 2026 et al., 2025; Bi et al., 2025). Collectively, these agents produce a unified and platform-agnostic JSON representation that encapsulates all information required for finite element modeling of frame structures. Stage 2 performs parallel code translation from the unified JSON representation to multiple structural analysis platforms, including OpenSees, SAP2000, and ETABS. For OpenSees and SAP2000, the geometry translation agent converts the structured geometric definitions into executable commands consistent with each platform’s modeling syntax. Then, the code compilation agent assembles geometric, boundary, load, and configuration modules into complete and executable scripts. These agents are powered by the Llama-3.3 70B-Instruct Turbo model due to its robust instruction-following performance (Dong et al., 2025a; Yan et al., 2025). In contrast, ETABS requires an additional simple semantic mapping agent to bridge the gap between generic structural definitions and the modeling logic inherent to the software itself. This agent is powered by GPT-OSS 120B model due to its emphasis on semantic reasoning task. The outputs of this stage are executable code files tailored to each software (e.g., .tcl, .s2k, and .e2k), thereby enabling automated structural analysis across software platforms. User Input:Thisis a frame structural analysis problem ... STAGE 1: Input Interpretation & Semantic Reasoning Extract key parameters from users’ textual input and organizes them into a structured JSON format Problem Analysis Agent Formulate a stepwise plan for assembling the geometry of the frame, bay-by-bay and story-by-story Construction Planning Agent NodeAgent Derive node IDs, coordinates, and support types ElementAgent Derive element IDs, types, and end coordinates Load AssignmentAgent Interpret and assign load patterns to corresponding structural components, such as nodes and elements Unified JSON Representation Agents powered by GPT-OSS 120BAgents powered by Llama-3.3 70B Instruct Turbo STAGE 2: Parallel Code Translation across Platforms .tcl file Geometry Translation Agent (OpenSees) Code Compilation Agent (OpenSees) .s2k file Geometry Translation Agent (SAP 2000) Code Compilation Agent (SAP 2000) Geometry Translation Agent Translate geometric data expressed in natural language into executable code Code Compilation Agent Compile geometric, load, and config modules into a complete script Map model definitions from JSON file to story-level structural components Semantic Mapping Agent .e2k file Geometry Translation Agent (ETABS) Code Compilation Agent (ETABS) Semantic Mapping Agent (ETABS) Fig. 4. Multi-agent system architecture for automated 2D frame structural analysis across FEM platforms. Fig. 4: Multi-agent system architecture for automated frame structural analysis across FEA platforms. 3.2 Stage 1: Interpretation and reasoning Stage 1 transforms users’ problem description into a structured representation that can be directly used by FEA workflows. As illustrated in Fig. 5, this stage consists of five specialized agents: a problem analysis agent, a construction planning agent, a node agent, an element agent, and a load assignment agent. Specifically, the problem analysis agent 5 A PREPRINT - APRIL 14, 2026 performs semantic parsing to extract key structural parameters from natural language input. These parameters include geometry, supports, material properties, and loads. The geometry section records the global structural configuration, such as the total number of bays and stories, as well as bay-level attributes including span lengths, story counts, and story heights. The support section captures the type and location of boundary conditions, including fixed, pinned, and roller supports. The material section stores mechanical and sectional properties, including Young’s modulus, cross-sectional area, and moment of inertia. Multiple values are permitted for each parameter, allowing distinct material and sectional properties to be assigned to individual structural members. The load section identifies load types, such as concentrated or distributed, and their application locations. All extracted parameters are organized into a structured JSON format to support downstream processing. Fig. 5. Multi-agent system architecture for automated 2D frame structural analysis across FEM platforms. Problem Analysis Agent "Geometry": "Total_bays": <int>, "Total_stories": <int>, "Bays": [ "Bay_id": <int>, "Span": <float>, "Story_count": <int>, "Heights": [<float>, ...] // Additional bays omitted], "Supports": "Type": <string>, "Location": <string>, "Material": "E": <float>, "A_col": <float>, "A_gir": <float>, "I_col": <float>, "I_gir": <float>, "Loads": "Type": <string>, "Description": <string> Construction Planning Agent Step 3 Step 1 Step 2 Step 5 Step 4 Step 8 Step 6 Step 7 Left to right Bottom to top Load Assignment Agent "Point_Loads": "Node_id": <int>, "Direction": <string>, "Magnitude": "Value": < float >, "Unit": <string> "Distributed_Loads": "Element_id": <int>, "Direction": <string>, "Magnitude": "Value": < float >, "Unit": <string> Node Agent Element Agent "Elements": "Element_id": <int>, "Type": <string>, "Coord_i": [<float>, [<float>], "Coord_j": [<float>, [<float>], "Description": <string> "Nodes": "Node_id": <int>, "X": < float >, "Y": < float >, "Support": <string>, "Description": <string> Unified JSON Representation NodesElementsSupportsMaterial PropertiesLoads "Node_id": <int>, "X": < float >, "Y": < float >, "Description": <string> "Node_id": <int>, " Type": < float >, " Description": <string> "Element_id ": <int>, "Type": <string>, "Node_i": <int>, "Node_j": <int>, "Description": <string> "E": <float>, "A_col": <float>, "A_gir": <float>, "I_ col": <float>, "I_ gir": <float> "Component_id": <int>, "Direction": <string>, "Magnitude": "Value": < float >, "Unit": <string> Fig. 5: Workflow of Stage 1, where multiple agents interpret user input and perform semantic reasoning to generate a unified JSON representation for FEA analysis. Following parameter extraction, a construction planning agent infers a stepwise assembly sequence using a bottom-to- top, left-to-right heuristic. This sequence provides a deterministic topology assembly logic, ensuring that the structural model is constructed in a consistent and well-defined order. Building upon the inferred assembly logic, the node agent and element agent operate in parallel to incrementally construct the structural geometry. At each construction step, the node agent determines the required nodes and computes their spatial coordinates based on bay spans and story heights, while assigning supports in accordance with the specified boundary conditions. In parallel, the element agent defines structural members, such as columns and girders, and establishes their connectivity by linking the corresponding end nodes. After completing all construction steps, the node agent outputs a JSON file containing node identifiers, spatial 6 A PREPRINT - APRIL 14, 2026 coordinates, supports, and descriptions, whereas the element agent produces a JSON file that records element identifiers, types, end node coordinates, and descriptions. Subsequently, the load assignment agent maps external forces onto the generated structural geometry by assigning concentrated and distributed loads to the appropriate nodes and elements. Each load entry records the target identifier, load direction, magnitude, and unit. Finally, the outputs of all agents are integrated into a unified, software-agnostic JSON representation that encodes nodes, supports, elements, material properties, and loads. To ensure compatibility with standard FEA modeling conventions, an auxiliary Python function is defined to convert element connectivity from end node coordinates to end node identifiers. Together, these steps complete the interpretation and reasoning process required for FEA analysis of frame structures. 3.3 Stage 2: Parallel code translation Stage 2 translates the unified JSON representation generated in Stage 1 into executable structural analysis scripts across multiple FEA platforms. As demonstrated in Fig. 4, this stage adopts a multi-agent architecture comprising a geometry translation agents, a code compilation agent, and, when required, a semantic mapping agent. The use of OpenSees and SAP2000 generally involves defining objects such as nodes, elements, material properties, and loads and defines the relations between these objects (e.g., assigning two nodes to a line element). This modeling logic is similar to how the unified JSON representation is set up. Therefore, it is natural to translate each object in the JSON file (e.g., a node, a support, and an element) to a line of code in the script file for OpenSees and SAP2000. Specifically, the translation workflow is performed by two sequential agents, as shown in Fig. 6. First, the geometry translation agent converts the geometric information encoded in the JSON file, including nodes, supports, elements, and material properties, into modeling commands consistent with the target platform. This process produces an intermediate code segment that defines the structural geometry. Subsequently, the code compilation agent translates load definitions from the JSON file into corresponding commands and integrates geometric, load, and analysis configuration modules into a complete executable script. The resulting files can be directly imported and executed in the target platforms, such as .tcl files for OpenSees and .s2k files for SAP2000. Fig. 6. Multi-agent system architecture for automated 2D frame structural analysis across FEM platforms. .tcl file Geometry Translation AgentCode Compilation Agent Parsed Inputs: Nodes Supports Elements Material properties Command Syntax: # Material properties set E 2.0e11 set A 0.002 set I 1.6e-05 # Node definition nodenode_idx y # Support definition fix node_id c1 c2 c3 # Element definition element elasticBeamColumn OpenSees Code: set E 2.0e11 set A 0.002 set I 1.6e-05 node 1 0.0 0.0 node 2 6.0 0.0 node 3 0.0 5.0 node 4 6.0 5.0 fix 1 1 1 1 fix 2 1 1 1 geomTransf Linear 1 element elasticBeamColumn 1 1 3 $A $E $I 1 element elasticBeamColumn 2 2 4 $A $E $I 1 element elasticBeamColumn 3 3 4 $A $E $I 1 Generate OpenSees code to define material properties, nodes, supports, and elements Inputs: Loads (JSON) Command Syntax: # Load definition timeSeries Constant 1 pattern Plain 1 1 # Static analysis: constraints Transformation numberer RCM system BandGeneral algorithm Linear integrator LoadControl 1.0 analysis Static analyze 1 Geometry Code Complete Code: wipe model BasicBuilder set E 2.0e11 set A 0.002 set I 1.6e-05 node 1 0.0 0.0 node 2 6.0 0.0 node 3 0.0 5.0 node 4 6.0 5.0 fix 1 1 1 1 fix 2 1 1 1 geomTransf Linear 1 ... algorithm Linear analysis Static analyze 1 Compile geometric, load, and configuration modules into a complete script Fig. 6: Workflow of Stage 2, where geometry translation agent and code compilation agent transform the JSON representation into an executable structural analysis script. ETABS, primarily for building structures, adopts a different modeling logic from OpenSees and SAP2000. It first sets up the stories and then assigns the objects (e.g., columns, beams) to different stories. Specifically, nodes at the base elevation are identified as base nodes, and base elements, including columns and girders, are constructed by establishing connectivity among these nodes. These base elements are assigned to corresponding story levels to form the structural geometry. Similarly, boundary and load conditions are defined by associating them with the appropriate base nodes and elements and assigning them to their respective stories. This modeling logic is different from the that of the JSON representation. Therefore, Stage 2 introduces a semantic mapping agent, as illustrated in Fig. 7, to bridge the gap of modeling logic between the JSON representation and ETABS. Essentially, the semantic mapping agent defines the stories and assign the objects to corresponding stories. Following semantic mapping, the resulting story-level representation is passed to the geometry translation and code compilation agents tailored for ETABS, which generate an executable .e2k file. Notably, Stage 2 adopts a parallel execution strategy, in which translation pipelines for different 7 A PREPRINT - APRIL 14, 2026 platforms operate independently. This design not only improves computational efficiency but also facilitates scalability, as it allows additional platforms to be integrated by introducing dedicated translation agents without affecting existing workflows. Fig. 7. Semantic mapping process that converts object-level JSON representation into a story-level structural model. Task: Map model definitions in JSON file to story-level representation Semantic Mapping Agent Nodes: Defined by spatial coordinates (e.g., x, y) Loads: Applied to structural components via their IDs Supports: Defined at specific nodes to represent restraints Elements: Defined by connectivity between end node IDs Input: JSON FileOutput: Story-Level Representation Base Nodes and Supports: Defined at the base level Base Girders and Columns: Defined by connecting base nodes Story Assignments: Girders and columns assigned to corresponding story levels Load Assignments: Defined by base nodes/elements and corresponding story level Fig. 7: Semantic mapping agent that converts JSON files into story-level representations. 4 Results and Discussion 4.1 Performance of the proposed LLMs The performance of the proposed multi-agent LLMs is evaluated on a set of structural analysis tasks of frames across three widely adopted software platforms, including OpenSees, SAP2000, and ETABS, as illustrated in Fig. 8. For each task, the accuracy is quantified as the success rate over ten repeated trials to account for the stochastic variability inherent in the generation processes of LLMs. Generally, the proposed LLMs achieve consistently strong performance across all platforms, with each question achieving an accuracy exceeding 90%. These results indicate that the LLMs enable reliable and consistent structural model generation across FEA environments characterized by diverse modeling logic and command syntax. This consistently high accuracy also validates the effectiveness of the underlying design of the multi-agent architecture, in which high-level semantic reasoning is decoupled from script translation for individual FEA platforms. Among the evaluated platforms, SAP2000 exhibits the highest level of consistency, achieving perfect accuracy for all questions across all trials. Minor performance variations are observed for a small subset of questions, particularly for OpenSees and ETABS. Specifically, ETABS maintains perfect accuracy for 18 out of 20 questions, with slight reductions to an accuracy of 90% for questions 15 and 17. OpenSees shows relatively greater variability, with accuracy decreasing to 90% for five questions (6, 10, 12, 15, and 18). These deviations are primarily attributed to differences in syntax requirements across platforms. Importantly, the observed performance variations are limited in magnitude and do not exhibit bias toward any specific platform, underscoring the robustness of the proposed multi-agent architecture. Collectively, these results demonstrate that the proposed LLMs achieve cross-platform consistency and high reliability. 4.2 Integration with Existing Workflows The proposed LLMs are designed to be integrated seamlessly with existing structural analysis workflows by generating executable scripts that can be directly imported into the FEA softwares. Users provide natural language descriptions of structural analysis problems, and the system automatically produces input files compatible with the target platforms. Rather than replacing existing software environments or analysis pipelines, the proposed approach introduces an input interface that complements current engineering practice. This design allows practitioners to retain their expertise with familiar software tools while leveraging automation to reduce manual modeling effort, minimize syntactic errors, and improve overall modeling efficiency. For OpenSees, the system generates a .tcl file that can be directly executed for structural analysis. To facilitate result interpretation and post-processing, the analysis outputs are visualized using STKO (ASDEA Software Technology, 2026), as illustrated in Fig. 9. The visualizations include structural deformation as well as internal force diagrams, such as axial force, shear force, and bending moment diagrams. This integration mitigates the manual workload and steep learning curve associated with TCL scripting. For commercial FEA platforms such as SAP2000 and ETABS, the 8 A PREPRINT - APRIL 14, 2026 Fig 8. Performance of the proposed multi-agent system for automated 2D frame structural analysis across three platforms OpenSeesSAP 2000ETABS 0.0 0.2 0.4 0.6 0.8 1.0 1234567891011121314151617181920 Accuracy across ten repeated trials Question number Fig. 8: Performance of the proposed multi-agent LLMs across three structural analysis platforms. Axial force diagramShear force diagramBending moment diagram Fig 9. Visualization of structural analysis results from OpenSees using STKO. Axial force diagram Shear force diagramBending moment diagram Deformed shape Fig. 9: Visualization of structural analysis results from OpenSees using STKO. 9 A PREPRINT - APRIL 14, 2026 proposed LLMs output .s2k and .e2k files, respectively, which can be directly imported into the corresponding software. Upon import, the native GUIs allow users to inspect the automatically generated structural models, including geometry, applied loads, boundary conditions, and assigned material properties, as shown in Fig. 10 and Fig. 11. After verification, analyses can be executed using the built-in solvers, and results can be visualized in standard forms, including deformed shapes and internal force diagrams. This workflow ensures that engineers remain actively involved in the inspection and validation of structural models, thereby supporting human-in-the-loop decision-making and enhancing transparency in the generated models. Using the proposed architecture, the LLMs further enable direct comparison of structural analysis results across multiple platforms, including OpenSees, SAP2000, and ETABS. Such cross-platform consistency checks are routinely adopted in engineering practice to confirm the robustness of analysis results under different modeling assumptions, thereby enhancing confidence in engineering decisions. Fig. 10. Visualization of the structural analysis results from SAP2000. Frame geometryLoad patterns Deformed shape Axial force diagramShear force diagramBending moment diagram Fig. 10: Visualization of structural analysis results from SAP2000. Fig. 11. Visualization of the structural analysis results from ETABS. Frame geometryLoad patterns Deformed shape Bending moment diagramAxial force diagramShear force diagram Fig. 11: Visualization of structural analysis results from ETABS. 10 A PREPRINT - APRIL 14, 2026 4.3 Comparison with state-of-the-art LLMs To validate the practical value of the proposed LLMs, the performance is benchmarked against two state-of-the-art general-purpose LLMs, namely GPT-5.2 and Gemini-3-Pro. The evaluation involves a two-stage prompting strategy. First, the LLMs are provided with a textual description of a frame structural analysis problem, consistent with the specification format described in Fig. 3. Second, the LLMs are instructed to generate a complete and executable structural analysis script. To minimize ambiguity, the required output format is explicitly specified for each target platform, including .tcl for OpenSees, .s2k for SAP2000, and .e2k for ETABS. For each benchmark problem, ten independent trails are conducted for each of the three target platforms. The generated scripts are imported into the corresponding software environments, where internal force diagrams are produced and compared against the reference solution. An output is considered correct only if the resulting internal force diagrams are consistent with the ground truth. This evaluation protocol provides quantitative insights into the performance of leading general-purpose LLMs within practical structural engineering workflows. The performance of GPT-5.2 on the benchmark dataset is illustrated in Fig. 12. Generally, GPT-5.2 demonstrates limited capability in generating correct structural analysis scripts. The average accuracy across 20 problems is 18% for OpenSees, while performance on SAP2000 and ETABS is 0%. For OpenSees, three key observations are identified. First, the performance exhibits significant variability across problems. While certain cases such as question 10 achieve accuracy of up to 60%, most problems yield zero accuracy across all ten trials. This instability highlights a high risk of hallucinations when LLMs are used for code generation in structural analysis workflows. Second, the successful rate of executing the generated OpenSees scripts reaches 51%. This suggests that GPT-5.2 possesses syntactic knowledge of this open-source platform. Scripts that fail to execute are primarily affected by (i) duplicate node definitions, (i) undefined or missing elements, and (i) incompatible variable formats. Third, a notable gap exists between executability (51%) and correctness (18%). This discrepancy indicates that, although GPT-5.2 can generate syntactically valid commands, it struggles with the semantic reasoning that translates abstract structural descriptions into detailed modeling definitions. Fig. 13 shows these limitations using a 3-2-4 frame as a illustrative example. In case 1, a beam is incorrectly defined to span from the leftmost to the rightmost column, neglecting the reduced story count in the second bay. Case 2 shows an error in which elements are incorrectly connected between support nodes. Case 3 omits critical nodes required to assemble the structure, resulting in an incomplete structural model. 0.0 0.2 0.4 0.6 0.8 1.0 1234567891011121314151617181920 Accuracy across ten repeated trials Question number OpenSeesSAP 2000ETABS Fig 12. Performance of GPT-5.2 on 2D frame structural analysis across three platforms Fig. 12: Performance of GPT-5.2 on frame structural analysis tasks across three FEA platforms For the commercial software platforms SAP2000 and ETABS, GPT-5.2 fails on all benchmark problems. These failures attribute to the rigorous syntax requirements and specific modeling logics that the general-purpose LLM cannot consistently capture. In the case of SAP2000, errors arise from two primary sources. First, GPT-5.2 frequently produces non-canonical table names. For example, the correct table identifier TABLE: "LOAD PATTERN DEFINITIONS" is often replaced by TABLE: "LOAD PATTERNS". Because SAP2000 relies on strict string matching during file import, 11 A PREPRINT - APRIL 14, 2026 such minor deviations prevent key definitions from being recognized and result in immediate import errors. Second, SAP2000 scripts require a two-step procedure for element definition, in which element connectivity is defined first and section properties are assigned subsequently. GPT-5.2 commonly merges these steps into a single definition, producing syntactically invalid or unreadable scripts. For ETABS, the failure mode reflects a fundamental incompatibility in modeling logic. Specifically, ETABS adopts a story-based modeling logic, where base objects (nodes and elements) are first defined and then assigned across stories through explicit story definitions. In contrast, GPT-5.2 persists in using a logic similar to that of OpenSees, explicitly defining each node and element in global coordinates. This mismatch in modeling logic prevents the successful import of generated .e2k files. Fig 13. Performance of GPT-5.2 on 2D frame structural analysis across three platforms OpenAI GPT-5.2 Ground Truth Case 1Case 2Case 3 Compare Fig. 13: Illustrative examples of semantic reasoning errors in OpenSees scripts generated by GPT-5.2. Fig 14. Performance of Gemini-3-Pro on 2D frame structural analysis tasks across three FEM platforms 0.0 0.2 0.4 0.6 0.8 1.0 1234567891011121314151617181920 Accuracy across ten repeated trials Question number OpenSeesSAP 2000ETABS Fig. 14: Performance of Gemini-3-Pro on frame structural analysis tasks across three FEA platforms The performance of Gemini-3-Pro is better than GPT-5.2 in using OpenSees, as shown in Fig. 14. Gemini-3-Pro achieves an average accuracy of 79% across the 20 benchmark problems. Notably, results also show that all executable scripts produce correct internal force diagrams. This consistency suggests that Gemini-3-Pro possesses strong semantic reasoning capabilities in translating structural descriptions into definitions of geometry, materials, loads, and boundary conditions. For the small subset of OpenSees scripts that fail to execute, errors are primarily from syntactic issues, including (i) invalid command names, (i) duplicate node or element definitions, and (i) incompatible variable formats. In contrast, Gemini-3-Pro fails on all benchmark problems for the commercial platforms SAP2000 and ETABS. Similar to GPT-5.2, these failures stem from the strict syntax requirements and modeling logic. For SAP2000, although table headers are defined correctly, frequent syntax errors occur in the definitions of material properties, node coordinates, and distributed loads. In particular, it hallucinates for variable names. For example, it replaces XorR, Y, and Z with GlobalX, GlobalY, and GlobalZ, which violates SAP2000’s input grammar and leads to import failures. For ETABS, Gemini-3-Pro exhibits the same fundamental logical incompatibility observed in GPT-5.2. Together, these results 12 A PREPRINT - APRIL 14, 2026 indicate that leading general-purpose LLMs remain unreliable for end-to-end structural modeling across FEA platforms. This limitation underscores the practical value of the LLMs developed in this study. 4.4 Runtime and costs To further evaluate the practical feasibility of the proposed multi-agent LLMs, the computational runtime and associated costs are examined. These statistics are collected over the 20 benchmark problems across ten repeated trials. Specifically, the average runtime required to generate structural analysis scripts is 113.54 seconds for OpenSees, 127.56 seconds for SAP2000, and 144.41 seconds for ETABS, respectively. The relatively shorter runtime for OpenSees can be attributed to its concise command syntax, whereas the longer runtime observed for ETABS primarily results from the additional semantic mapping agent. Compared with general-purpose LLMs, the LLMs in this study exhibit a higher runtime. For reference, GPT-5.2 generates scripts with an average runtime ranging from 32.80 to 43.94 seconds, while Gemini-3-Pro requires 80.61 to 94.95 seconds. However, as demonstrated in Section 4.3, these shorter runtimes do not guarantee the reliability or correctness of the generated scripts. From the perspective of practical engineering, the absolute runtime of the proposed LLMs remains highly efficient. The executable scripts for OpenSees, SAP2000, and ETABS can be generated in parallel within approximately two minutes. This capability substantially reduces manual modeling effort and provides engineers with flexibility for multi-platform structural analysis. In addition to runtime efficiency, the economic feasibility of the proposed LLMs is evaluated based on token consumption and API pricing. While the multi-agent architecture incurs higher token usage due to inter-agent communication, the LLMs are cost-effective by leveraging lightweight open-source backbone models including GPT-OSS-120B and Llama-3.3-70B-Instruct-Turbo. According to the API pricing provided by Together AI (in 2026 US$), GPT-OSS-120B is priced at $0.15 per million input tokens and $0.60 per million output tokens, while Llama-3.3-70B-Instruct-Turbo is priced at $0.88 per million tokens for both input and output. Under these rates, the total cost of the proposed LLMs range from $0.012 to $0.025 per benchmark problem per platform. For comparison, the costs of state-of-the-art general-purpose LLMs are also calculated. GPT-5.2 is priced at $1.75 per million input tokens and $14.00 per million output tokens, while Gemini-3-Pro is priced at $2.00 per million input tokens and $12.00 per million output tokens. Under the same benchmark settings, these models consume approximately $0.05 and $0.04 per problem, respectively. These results demonstrate that the proposed multi-agent LLMs deliver a cost-effective solution for frame structural analysis, exhibiting strong potential for scalability in real-world engineering applications. 5 Summary and Conclusions This paper proposes a multi-agent architecture for large language models (LLMs) to automate frame structural analysis across software platforms. The LLMs adopt a two-stage architecture. In the first stage, five specialized agents, including problem analysis agent, construction planning agent, node agent, element agent, and load assignment agent, are employed to reason over the information required for structural modeling from user inputs. Specifically, the problem analysis agent extracts key parameters from user input and organizes them into a structured JSON format. The construction planning agent formulates a stepwise plan for assembling the frame geometry. The node and element agents derive node coordinates and element connectivity to construct the structural topology. The load assignment agent interprets and assigns load patterns to the corresponding structural components. All information generated in Stage 1 is compiled into a unified JSON representation. In the second stage, the JSON file is translated in parallel into executable scripts for multiple platforms, including OpenSees, SAP2000, and ETABS. For OpenSees and SAP2000, this process is accomplished through a geometry translation agent and a code compilation agent. The geometry translation agent converts geometric and topological information into code commands, while the code compilation agent integrates geometric, loading, and configuration modules into a complete executable script. For ETABS, an additional semantic mapping agent is introduced to transform object-based model definitions into the story-based representation required by the software. The proposed multi-agent architecture leverages lightweight LLM backbones tailored to different stages of the workflow, employing GPT-OSS-120B for semantic reasoning in Stage 1, and Llama-3.3-70B-Instruct-Turbo for code generation in Stage 2. The performance of the proposed LLMs is evaluated using a benchmark dataset comprising 20 representative frame structural analysis problems. The main findings are summarized below: •The proposed multi-agent LLMs demonstrate highly reliable and consistent performance across the benchmark dataset. Over ten repeated trials, each benchmark problem achieves an accuracy exceeding 90%. The average accuracies across the 20 benchmark problems reach 98% for OpenSees, 100% for SAP2000, and 99% for ETABS, confirming the robustness of the LLMs across software platforms. •The proposed LLMs substantially outperform leading general-purpose LLMs, including GPT-5.2 and Gemini- 3-Pro. For open-source platform OpenSees, the average accuracies of GPT-5.2 and Gemini-3-Pro are 18% and 79%, respectively, while the proposed LLMs are 98%. For commercial platforms SAP2000 and ETABS, both 13 A PREPRINT - APRIL 14, 2026 general-purpose models fail across all benchmark problems due to their inability to follow rigorous syntax requirements and specific modeling logics, while the proposed LLMs are more than 99%. •The proposed LLMs deliver an efficient and economically viable solution for automated structural analysis. Executable scripts can be generated in parallel within approximately two minutes, while the cost remains low, ranging from $0.012 to $0.025 per benchmark problem per platform. This balance of accuracy, efficiency, and cost highlights the practical value of the proposed LLMs for real-world structural engineering workflows. • Despite the strong performance of the proposed LLMs, the current implementation is limited to rectangular frame configurations with vertical columns and horizontal beams. Future work should extend the scope to support complex structural typologies such as bracing systems and cantilevered members. Additionally, the present evaluation relies on a predefined textual description template. Future work should incorporate more real-world use cases to assess the system’s robustness, generalizability, and functional coverage. Data Availability Statement Some or all data, models, or code that support the findings of this study are available from the corresponding author upon reasonable request. References Agarwal, S., Ahmad, L., Ai, J., Altman, S., Applebaum, A., Arbus, E., Arora, R. K., Bai, Y., Baker, B., Bao, H., et al. 2025. “gpt-oss-120b & gpt-oss-20b model card.” arXiv preprint arXiv:2508.10925. ASDEA Software Technology 2026. “STKO: Scientific toolkit for opensees,<https://w.stko.net/>. Version: 4.1.0 (accessed 2026-01-19). Bai, Y., Tu, S., Zhang, J., Peng, H., Wang, X., Lv, X., Cao, S., Xu, J., Hou, L., Dong, Y., et al. 2025. “Longbench v2: Towards deeper understanding and reasoning on realistic long-context multitasks.” Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 3639–3664. Bi, Z., Zhang, D., Song, J., and Tseng, C.-Y. 2025. “Is gpt-oss all you need? benchmarking large language models for financial intelligence and the surprising efficiency paradox.” arXiv preprint arXiv:2512.14717. Chen, G., Alsharef, A., Ovid, A., Albert, A., and Jaselskis, E. 2025. “Meet2mitigate: An llm-powered framework for real-time issue identification and mitigation from construction meeting discourse.” Advanced Engineering Informatics, 64: 103068. Chen, J. and Bao, Y. 2025. “Chatcivic: A domain-specific large language model (llm) for design code interpretation.” Available at SSRN 5172919. Chen, J. and Bao, Y. 2026. “Multi-agent coordination of data-driven and physics-based models for automated design of ultra-high-performance concrete beams.” Advanced Engineering Informatics, 71: 104297. Chung, A., Zhang, Y., Lin, K., Rawal, A., Gao, Q., and Chai, J. 2025. “Evaluating long-context reasoning in llm-based webagents.” arXiv preprint arXiv:2512.04307. Computers and Structures, Inc. 2025a. ETABS: Integrated Building Design Software. Computers and Structures, Inc., Walnut Creek, CA. https://w.csiamerica.com/products/etabs. Computers and Structures, Inc. 2025b. SAP2000: Integrated Software for Structural Analysis and Design. Computers and Structures, Inc., Walnut Creek, CA. urlhttps://w.csiamerica.com/products/sap2000. Deng, Z., Du, C., Nousias, S., and Borrmann, A. 2025. “Bimgent: Towards autonomous building modeling via computer-use agents.” arXiv preprint arXiv:2506.07217. Dong, J., Zhang, Y., Liu, Y., Zhong, Z., Wei, T., Zhang, C., and Qiu, H. 2025a. “Revisiting the reliability of language models in instruction-following.” arXiv preprint arXiv:2512.14754. Dong, Y., Jiang, X., Qian, J., Wang, T., Zhang, K., Jin, Z., and Li, G. 2025b. “A survey on code generation with llm-based agents.” arXiv preprint arXiv:2508.00083. Du, C., Esser, S., Nousias, S., and Borrmann, A. 2026. “Text2bim: Generating building models using a large language model-based multiagent framework.” Journal of Computing in Civil Engineering, 40 (2): 04025142. Geng, Z., Liu, J., Cao, R., Cheng, L., Frangopol, D. M., and Cheng, M. 2026. “A novel multi-agent architecture to reduce hallucinations of large language models in multi-step structural modeling.” arXiv preprint arXiv:2603.07728. Geng, Z., Liu, J., Cao, R., Cheng, L., Wang, H., and Cheng, M. 2025. “A lightweight large language model-based multi-agent system for 2d frame structural analysis.” arXiv preprint arXiv:2510.05414. 14 A PREPRINT - APRIL 14, 2026 Google DeepMind 2025. “Gemini 3 pro model card. Accessed: 2026-01-06. Jiang, J., Wang, F., Shen, J., Kim, S., and Kim, S. 2024. “A survey on large language models for code generation.” arXiv preprint arXiv:2406.00515. Jiang, Y., Wang, J., Shen, X., and Dai, K. 2025. “Large language model for post-earthquake structural damage assessment of buildings.” Computer-Aided Civil and Infrastructure Engineering, 40 (31): 6324–6342. Jiang, Y., Wang, J., Shen, X., Dai, K., and Ge, Q. 2026. “Multitask unified large vision-language model for post- earthquake structural damage assessment of buildings.” Automation in Construction, 182: 106720. Joel, S., Wu, J., and Fard, F. 2024. “A survey on llm-based code generation for low-resource and domain-specific programming languages.” ACM Transactions on Software Engineering and Methodology. Joffe, I., Felobes, G., Elgouhari, Y., Talebi Kalaleh, M., Mei, Q., and Chui, Y. H. 2025. “The framework and implementation of using large language models to answer questions about building codes and standards.” Journal of Computing in Civil Engineering, 39 (4): 05025004. Liang, H., Kalaleh, M. T., and Mei, Q. 2025a. “Integrating large language models for automated structural analysis.” arXiv preprint arXiv:2504.09754. Liang, H., Zhou, Y., Kalaleh, M. T., and Mei, Q. 2025b. “Automating structural engineering workflows with large language model agents.” arXiv preprint arXiv:2510.11004. Ling, Z., Liu, K., Yan, K., Yang, Y., Lin, W., Fan, T.-H., Shen, L., Du, Z., and Chen, J. 2025. “Longreason: A synthetic long-context reasoning benchmark via context expansion.” arXiv preprint arXiv:2501.15089. Liu, A., Feng, B., Xue, B., Wang, B., Wu, B., Lu, C., Zhao, C., Deng, C., Zhang, C., Ruan, C., et al. 2024a. “Deepseek-v3 technical report.” arXiv preprint arXiv:2412.19437. Liu, J., Geng, Z., Cao, R., Cheng, L., Bocchini, P., and Cheng, M. 2026. “A large language model-empowered agent for reliable and robust structural analysis.” Structure and Infrastructure Engineering, 1–16. Liu, W., Huang, X., Zeng, X., Hao, X., Yu, S., Li, D., Wang, S., Gan, W., Liu, Z., Yu, Y., et al. 2024b. “Toolace: Winning the points of llm function calling.” arXiv preprint arXiv:2409.00920. Lu, J., Holleis, T., Zhang, Y., Aumayer, B., Nan, F., Bai, H., Ma, S., Ma, S., Li, M., Yin, G., et al. 2025. “Toolsandbox: A stateful, conversational, interactive evaluation benchmark for llm tool use capabilities.” Findings of the Association for Computational Linguistics: NAACL 2025, 1160–1183. McKenna, F. 2011. “Opensees: a framework for earthquake engineering simulation.” Computing in Science & Engineering, 13 (4): 58–66. OpenAI 2025. “Update to gpt-5 system card: Gpt-5.2. Accessed: 2026-01-06. Pu, H., Yang, X., Li, J., and Guo, R. 2024. “Autorepo: A general framework for multimodal llm-based automated construction reporting.” Expert Systems with Applications, 255: 124601. Shen, Z. 2024. “Llm with tools: A survey.” arXiv preprint arXiv:2409.18807. Wan, Q., Wang, Z., Zhou, J., Wang, W., Geng, Z., Liu, J., Cao, R., Cheng, M., and Cheng, L. 2025. “Som-1k: A thousand-problem benchmark dataset for strength of materials.” arXiv preprint arXiv:2509.21079. Xia, Z., Zhong, B., Zhang, S., Zhao, T., and Skibniewski, M. J. 2026. “Graph-driven embedding reinforcement and traceable llm agent for reliable element alignment in construction report generation.” Automation in Construction, 183: 106816. Yan, K., Guo, H., Shi, X., Xu, J., Gu, Y., and Li, Z. 2025. “Codeif: Benchmarking the instruction-following capabilities of large language models for code generation.” arXiv preprint arXiv:2502.19166. Zhang, Y., Wei, S., Huang, Y., Su, Y., Lu, S., Jiang, K., and Li, H. 2025. “Sdiglm: leveraging large language models and multimodal chain of thought for structural damage identification.” Structural Health Monitoring, 14759217251348275. Zhu, X., Ma, J., Chen, W., and Tan, Y. 2024. “Llm-based regulation query system for textual and tabular information in building codes.” Available at SSRN 5033360. 15