Deep learning-based simulation model code automatic repair method, device and medium

Abstract

The application discloses a deep learning-based simulation model code automatic repairing method and device and a medium, which comprises the following steps: S1, preprocessing an original model file, and forming a structured abstract syntax tree (AST) and a component dependency graph; using an improved LLM model to perform error detection and repair code generation, wherein the error detection stage is implemented by an improved CodeBERT, and the repair code stage is generated by using a GPT decoder; in the error detection stage, fine tuning is enriched by using auxiliary information, the serialized code text and the structured auxiliary information are simultaneously introduced into a model training process by using a multi-modal fusion mechanism, so that the error detection capability of the model is enhanced, and defect positions of deep relations such as component dependency and equation logic are captured; and in the repair code stage, reinforcement learning fine tuning is used. The application provides an automatic detection and repair scheme for common errors of Modelica model codes, and improves the development efficiency and reliability of complex simulation models in industrial software.

Description

Technical Field

[0001] This invention relates to the field of software repair technology, specifically to a method, device, and storage medium for automatic repair of simulation model code based on deep learning. Background Technology

[0002] Modelica, as a standardized language for modeling and simulating physical systems across multiple domains, has become a core tool for developing simulation models of complex systems due to its non-causal, object-oriented, and modular characteristics. It is widely used in key fields such as aerospace, energy and power, and intelligent manufacturing. However, the dynamic nature and multi-domain coupling of Modelica models present significant challenges to the detection and repair of code errors. These errors are mainly divided into syntax errors and logical errors. Syntax errors can be automatically detected using parsing techniques such as Abstract Syntax Trees (ASTs), while logical errors stem from misunderstandings of the principles of the physical system, the semantic relationships of the model, and parameter constraints. Logical errors require in-depth analysis of the semantic and auxiliary information dependencies in the code, making their detection and repair far more difficult than syntax errors.

[0003] Existing Modelica code error handling tools (such as ESLint) mostly focus on syntax compliance checks and lack effective support for logical errors, making it difficult to meet the quality assurance requirements of complex simulation models. At the same time, these tools require users to have a high level of technical background, including in-depth knowledge of Modelica syntax and code analysis skills, making it difficult for non-professional users (such as domain engineers and simulation modelers) to use them efficiently, thus restricting the efficiency and quality of model development.

[0004] From an industry perspective, software errors have become a key factor restricting project progress and increasing development costs. Currently, code error fixing is still mainly done manually, which is inefficient, costly, and unable to cope with the large number of errors hidden in large-scale, complex Modelica models. Even in mature industrial projects, the problem of known error persistence and propagation remains prominent, further exacerbating project risks. Therefore, achieving rapid, low-cost, and automated repair of Modelica code errors has become a critical issue that urgently needs to be addressed by both industry and academia.

[0005] Automated software repair technology, as a core means of improving code quality, has undergone long-term research and has developed traditional methods such as static analysis and dynamic analysis. However, due to the multi-domain coupling and semantic complexity of Modelica models, traditional methods are unable to accurately capture the deep semantic relationships in the code. As a result, existing automated repair research is mostly limited to the repair of single-line syntax errors in small models, which is difficult to support the logic error repair needs of complex Modelica simulation models and cannot meet the requirements of industrial-grade application scenarios. Summary of the Invention

[0006] The present invention proposes a method, device and storage medium for automatic repair of simulation model code based on deep learning, which can at least solve one of the technical problems in the background art.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] A deep learning-based method for automatic code repair in simulation models involves performing the following steps using a computer device.

[0009] S1. Preprocess the original model files to obtain a dataset structure that facilitates computer lexical and syntactic analysis and LLM training. This includes the following two processing steps:

[0010] Process 1: Generate an Abstract Syntax Tree (AST) and component dependency graph by parsing the model text, transforming the model string into a structured model syntax tree and component relationship graph within the computer.

[0011] Step 2: Mapping to short tokens to simplify the expression of different long phrases in the model, reduce the recognition time of long texts during model training, and improve model training efficiency;

[0012] S2. Use the simplified model obtained in step 2 of S1 to pre-train CodeBERT. The labeled dataset required for training the error correction model contains the original error text and the location of the error code. The dataset is divided into training set, validation set and test set in an 8:1:1 ratio. During the training of the error detection model, the error detection capability of the model is enhanced by introducing the CRFT (Continuous Revision Forwarding) mechanism and using the structured abstract syntax tree (AST) and component dependency graph from S1.

[0013] S3. Using the defect location output by CodeBERT in S2 as the input to the GPT decoder, reinforcement learning fine-tuning (RLFT) is introduced to generate patches to resolve the defects. Through improvements to the reward function, a three-layer automatic verification system of compilability, functional correctness, and safety constraints is used to fine-tune the training process to achieve both physical semantic and functional correctness repair. Furthermore, this invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0014] Furthermore, process one in S1 specifically includes,

[0015] The Cautosim parsing interface is used to generate an Abstract Syntax Tree (AST), extracting component dependency graphs and component relationship graphs to provide structural features for error detection and auxiliary information enhancement.

[0016] Furthermore, process two includes,

[0017] A hybrid approach of "word-level segmentation + domain-specific token mapping" is adopted to replace specific expressions in the original model text with simpler expressions;

[0018] in,

[0019] Fixed tokens include: Modelica keywords and operators, which are mapped to dedicated tokens;

[0020] Dynamic tokens include: mapping long component names to short tokens, reducing sequence length;

[0021] Character-level supplementation: Rare parameter / variable names not included in the list are segmented using character-level tokenization to balance vocabulary size and sequence length;

[0022] The vocabulary includes: tokens, parameter values, component types, and equation symbols.

[0023] Furthermore, S1 also includes data augmentation.

[0024] Synonym substitution: Replace different spellings of Modelica with the same semantics;

[0025] Structural rearrangement: rearrange the order of component definitions and equations without changing the semantics;

[0026] Error mutation: Perform secondary mutations on code that has already been injected with errors to expand the diversity of the dataset.

[0027] Furthermore, the pre-training steps of S2 include,

[0028] Base model selection:

[0029] We selected CodeBERT for error detection; we focused on learning Modelica's syntax rules and obtaining the structural features of its syntax, semantics, and model components.

[0030] Pre-training task design:

[0031] The preprocessed model training data is divided into training set, validation set and test set in a ratio of 8:1:1. The training set is used to train the model, and the validation set is used to validate the trained CodeBERT model and obtain validation evaluation metrics.

[0032] Furthermore, the auxiliary information enrichment and fine-tuning mechanism in S2 includes,

[0033] By using a multimodal fusion mechanism, "error code + additional auxiliary information" is taken as input, allowing CodeBERT to discover defects in the code based on more comprehensive information;

[0034] The auxiliary information enhancement structure uses error code fragments as its core carrier and deeply integrates the auxiliary information unique to Modelica simulation model code to build a complete logical closed-loop reasoning basis, providing comprehensive support for LLM to accurately generate repair patches that conform to physical semantics and equation constraints.

[0035] First, the core attributes of the errors are clearly marked through a standardized labeling system, including typical error types in the Modelica scenario, the specific location of the error in the model, and the root cause. Then, based on the Abstract Syntax Tree (AST) and component dependency graph, the component dependency relationship and equation logical association of the model are supplemented, clearly presenting the connection links between each physical component and the constraint relationship of the equation system. At the same time, key execution details generated during the simulator compilation and solving process are incorporated, including core intermediate data such as equation sorting results, state variable selection list, and algebraic loop detection report.

[0036] To integrate auxiliary information into the training process, a cross-modal attention mechanism is adopted to integrate different information. The AST and dependency graph in the auxiliary information enhancement structure are transformed into graph structures, encoded using graph neural networks, and then the node representations are aligned with the corresponding text token representations, providing feature support with both syntactic depth and physical relevance for subsequent error localization tasks. This mechanism is fully adapted to the "declarative / equation basis" language characteristics of Modelica, effectively making up for the shortcomings of traditional text modeling in capturing deep equation constraints and physical connectivity.

[0037] The construction of a unified graph structure is a key step in connecting structured data and GAT encoding. The core is to transform the parsed structured data into a feature representation that can be processed by GNN, while retaining the physical semantics specific to Modelica and the location information required for error localization.

[0038] The node feature design follows the three-dimensional fusion principle of "syntax-physical-position" and adopts fixed-dimensional vector encoding: one-hot encoding is used to represent the node type and physical domain attributes, the code line number is converted into a low-dimensional position vector through the embedding layer, additional equation type encoding is introduced for Equation nodes, and error flag features are added for error localization tasks to form a node feature matrix that has both semantic discriminativeness and position anchor points.

[0039] Edge features focus on the semantic representation of relationships between nodes. One-hot encoding is used to distinguish physical connections, equation constraints, and equilateral edge types. An edge feature matrix is ​​constructed by combining physical domain attributes and row number matching information. Finally, a directed graph is constructed based on the node set and edge set, which is transformed into a structured data format according to the graph neural network standard. This realizes the mapping from unstructured parsing results to structured graph data, providing high-quality input for GAT encoding.

[0040] GAT encoding enhances the modeling of relationships between nodes in the Modelica graph structure through graph attention mechanisms, accurately capturing node relationship patterns corresponding to deep errors such as algebraic rings and excessively high indices in differential algebraic equations.

[0041] Considering that Modelica errors often manifest as abnormal associations among local nodes,

[0042] The GAT model adopts a two-layer architecture: the first layer uses multiple attention heads to compute the association weights between nodes in parallel, which enhances the ability to capture the interaction features of local nodes and adapts to association patterns with different types of errors; the second layer concatenates the outputs of the multiple attention heads and maps them to the target dimension to generate a unified node-level representation.

[0043] To improve the quality of node representation, the GAT model is further optimized through pre-training. The pre-training tasks include unsupervised / weakly supervised tasks such as node type classification, edge prediction, and masked node recovery, which enable the model to learn the inherent grammatical rules and physical associations of the Modelica graph, providing more discriminative node representations for subsequent error localization tasks.

[0044] The precise alignment of node representations and text token representations is the core of fusing graph structure semantics and text semantics. Its core logic lies in establishing a mapping relationship between graph nodes and code text tokens to achieve complementary enhancement of the two modal features.

[0045] The mapping relationship is constructed based on the association between code line number and character position: the Modelica code is segmented by code Tokenizers to obtain the start and end positions of characters of each token. Combined with the code line number information of AST nodes, a mapping table of "graph node ID-text token range" is established to clarify the continuous token sequence corresponding to each graph node (such as the token set of a certain line in the code corresponding to the Equation node).

[0046] In the feature fusion stage, based on the mapping relationship, the multiple token features corresponding to a single node are averaged or attention-weighted and fused to transform them into text features that are compatible with the graph node representation dimension. Then, a concatenation or attention fusion strategy is used to fuse the graph node representation with the text features to generate an integrated "graph-text" feature.

[0047] Finally, the fused features are aligned to the corresponding text tokens according to the mapping relationship and added to the input embedding of the LLM, so that the LLM can simultaneously perceive the textual semantics of the code and the semantics of the deep graph structure, thereby enhancing the feature representation capability of the error localization task.

[0048] Furthermore, the S3 patch generation model includes,

[0049] To generate targeted and effective candidate patches, providing high-quality candidates for subsequent verification, this stage uses the GPT decoder to generate patches for code repair.

[0050] During the patch inference process, the local repair focus is based on the accurate error location results output by the previous error detection and localization module. This defines clear and reasonable modification boundaries for the model's repair operations, strictly limiting the model to modify only the confirmed error locations and related code with direct logical connections. The related code includes adjacent lines of code where the error parameter is located, key statements that play a role in logical connection, and equation expressions directly related to the error.

[0051] This localized modification restriction does not constrain the model's repair capabilities, but rather effectively reduces redundant code changes by avoiding global modifications to irrelevant nodes. This improves the computational efficiency of patch generation, prevents the model from wasting computational resources in irrelevant code areas, and preserves the core business logic and implementation architecture that have been verified to be effective in the original code to the greatest extent possible. It also prevents the introduction of new potential errors due to excessive or meaningless modifications, while reducing the verification cost for subsequent patch verification stages, allowing verification work to focus more on the effectiveness and rationality of the repaired areas.

[0052] Building upon the focus on localized repair, the system also includes a patch inference stage. This stage boasts multi-granularity repair support, a core feature that enables comprehensive adaptation to errors of varying types and severity. This multi-granularity repair capability specifically encompasses four complementary and layered repair granularities: parameter modification, connection adjustment, equation correction, and component addition / removal. Parameter modification targets lightweight numerical or definitional errors, requiring no changes to the overall code logic; only adjustments to parameter values, type definitions, or naming conventions are needed for repair. Connection adjustment focuses on logical flow anomalies between code modules and statements, restoring normal code logic by optimizing function call relationships, adjusting logical connectors in conditional statements, and correcting data transmission links. Equation correction specifically targets code snippets containing mathematical calculations and logical expressions, addressing errors in equation derivation, omissions in expression writing, and confusion regarding computational precedence. Precise correction of these specialized errors is common in high-precision code scenarios such as scientific computing and simulation modeling. Component addition / removal, on the other hand, is an important means of dealing with more complex structural errors. For scenarios where necessary functional components are missing or redundant and invalid modules cause logical conflicts, missing functions, classes, or modules are added to complete the core functionality, or redundant and invalid code components are removed to eliminate logical conflicts. These four repair granularities work together to form a complete repair coverage system, ranging from lightweight local numerical adjustments to heavyweight structural refactoring. This system can comprehensively adapt to different types of code errors, ensuring that the patch inference process can output more targeted and effective candidate patches for specific error scenarios, thereby improving the overall coverage and accuracy of automatic code repair.

[0053] Furthermore, the reinforcement learning fine-tuning mechanism in S3 includes,

[0054] To meet the specific requirements of industrial simulation software for high accuracy in generated patch content, patch generation must not only achieve simple text matching and repair, but also achieve correct physical semantics and functional repair. By introducing "Verifiable Reinforcement Learning (RLVR) with verifiable rewards" to optimize the GPT decoder and ensure more stable training performance, the "actual execution effect of the repaired model" is used as a reward to improve the functional correctness of the generated code.

[0055] The candidate patches generated in the patch inference stage are not directly usable. They still need to be screened through a strict and systematic patch verification process to ensure that the patches finally put into use have syntactic validity, functional effectiveness and operational robustness. Automatic verification is used for patch verification. Through a three-layer progressive verification system, a comprehensive and efficient screening of candidate patches is achieved.

[0056] Compilability verification is the first checkpoint in the three-layer automatic verification system and a fundamental step in ensuring the basic usability of patches. Its core objective is to quickly eliminate invalid candidate patches with syntax errors. In this verification step, the system automatically calls the dedicated Cautosim compiler, using the complete code incorporating the candidate patch as compilation input. Following the syntax rules, compilation guidelines, and Cautosim compiler's specific parsing requirements of the corresponding programming language, the system performs line-by-line syntax parsing, symbol verification, and format checks on the repaired code. If syntax errors, undefined symbols, non-standard formatting, or failure to meet compiler parsing requirements occur during compilation, the candidate patch is directly deemed invalid and eliminated without proceeding to subsequent, more complex verification steps. This fundamental checkpoint quickly filters out a large number of obviously invalid candidate patches, significantly improving the execution efficiency of subsequent verification steps. It also lays a solid foundation for subsequent functional correctness and robustness verification, ensuring that candidate patches entering later stages possess basic syntactic validity and can be parsed and run normally.

[0057] Functional correctness verification is the core of the three-layer automated verification system and a key basis for judging whether candidate patches truly resolve core errors and meet business requirements. This step does not rely on a single test case for verification, but rather conducts a comprehensive inspection by running a pre-set complete test suite. This test suite is carefully designed based on the expected business functions, actual application scenarios, and core performance requirements of the code, and includes three core components: diverse pre-set simulation scenarios, clearly quantified output indicator thresholds, and strict security constraints. During the verification process, the system places the repaired model, which incorporates the candidate patch, into various pre-set simulation scenarios and runs them sequentially. It collects the model's output results and runtime logs in real time under different simulation scenarios. Then, it accurately compares the collected output results with the pre-set output indicator thresholds and strictly verifies whether the model's operation meets all pre-set security constraints. Taking simulation modeling code as an example, the verification process focuses on judging whether the repaired model can achieve stable simulation convergence, whether the error of the output results can be strictly controlled within 5%, and whether the operation process meets the pre-set security boundary requirements and has no violations. Only when the repaired model successfully passes all test cases in the test suite and fully meets all preset functional requirements, performance indicators, and security constraints can the candidate patch be deemed functionally correct and effective. Otherwise, it is considered an invalid patch and is eliminated. This verification process is directly related to the core business value of the code, effectively avoiding invalid fixes that are "syntactically valid but functionally ineffective," and ensuring that the repaired code can normally achieve the expected business functions.

[0058] Safety constraints are designed to adapt to code scenarios in simulations that have rigid requirements for physical safety. The core objective of safety constraint verification is to check whether the repaired code strictly meets all preset physical safety constraints. These constraints are derived from the physical laws and safety specifications of actual application scenarios, such as common threshold limits in code like temperature ≤100℃ and pressure ≤5MPa, or the output power boundary of the power system and the structural stress safety threshold. This verification step is not performed in isolation, but rather in conjunction with functional correctness verification. During the simulation run of functional correctness verification, the system synchronously monitors core parameters related to physical safety in real time and dynamically compares them with preset safety constraint thresholds. If the physical safety parameters of the repaired model exceed the threshold in any simulation scenario, even if its functional output indicators meet the requirements, it will be judged as an invalid patch. Only when the model not only achieves the expected function, but also strictly adheres to all physical safety constraints throughout the process, ensuring that the operation will not cause any security risks, can it pass the security constraint verification. This supplementary verification dimension effectively avoids the repair vulnerability of "functionally valid but security-invalid," ensuring that the repaired code not only runs normally, but also adapts to the security requirements of actual application scenarios and has deployable practical value.

[0059] The simplicity-oriented principle, building upon the existing three-layer automatic verification system, aims to optimize both the effectiveness of repairs and code stability. The core criterion for simplicity is defined as the reciprocal of the patch's modification amount relative to the original code. Its goal is to encourage minimal modifications, ensuring a precise and restrained repair process by constraining the model's modification scope. Within the defined modification boundaries of localized repairs, the model does not simply generate arbitrary feasible repair solutions. Instead, it prioritizes solutions with the smallest modification amount that thoroughly resolve the error from multiple granular repair options. For example, when code errors can be resolved by adjusting parameters or fine-tuning connections, the model actively avoids large-scale modifications such as adding / removing components. Even when facing complex errors requiring structural adjustments, the scope of modification is strictly controlled, only modifying the smallest code unit associated with the core error. This simplicity-oriented design not only reduces the uncertainty brought by code modifications and lowers the risk of introducing new potential errors due to excessive modifications, but also maximizes the preservation of the original code's structural integrity and maintainability. This makes the repaired code easier for developers to understand and trace, while also reducing the verification complexity of subsequent patch verification stages and improving the efficiency and reliability of the overall repair process.

[0060] Therefore, the GPT decoder after CRFT fine-tuning not only needs to generate candidate patches, but also incorporates improvements to the reward function (R) to optimize the LLM patch generation strategy through multi-dimensional weighted rewards (weights tuned through the validation set) and the PPO algorithm:

[0061] R=w1 R compile +w2 R func +w3 R safety +w4 R concise

[0062] R compile Compilability bonus (0 / 1, whether the fixed code can be compiled by Cautosim);

[0063] R func Functional correctness reward (0-1, percentage of simulated test cases passing the test suite, such as output error ≤5%, convergence successful);

[0064] R safety Safety constraint reward (0-1, whether all physical safety constraints are met, such as temperature ≤100℃, pressure ≤5MPa);

[0065] R concise Simplicity bonus (0-1, the reciprocal of the patch's modification amount relative to the original code, encouraging minimal modifications);

[0066] Weight settings: (w1=0.2, w2=0.4, w3=0.3, w4=0.1) (Focus on functionality and security).

[0067] PPO training process: Sampling phase: The Agent generates N candidate patches (N=5), performs verification, and calculates the reward for each patch;

[0068] Policy update: The Agent parameters are updated through the PPOclip objective function to control the policy update magnitude (clip threshold = 0.2).

[0069] Value network update: Optimize the value network with mean squared error (MSE) to fit the true reward;

[0070] Number of iterations: 10-15 rounds, monitoring the convergence of average reward.

[0071] In another aspect, the present invention discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0072] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0073] As can be seen from the above technical solution, the deep learning-based automatic repair method for simulation model code of the present invention aims to integrate the semantic understanding capability of deep learning with the domain characteristics of Modelica models to design an efficient and easy-to-use automatic repair system, break through the technical limitations and usage thresholds of existing tools, provide users with an automated detection and repair solution for common errors (especially logical errors) in Modelica code, thereby improving the development efficiency and reliability of complex simulation models and reducing the economic losses caused by errors.

[0074] Specifically, the specific problems that this invention aims to solve are as follows:

[0075] 1. Addressing the characteristics of the Modelica language, such as its "verbose, declarative syntax, and multi-domain coupling," this paper solves the problems of high error detection rate and poor compilability of patches in traditional code repair methods.

[0076] 2. It addresses the pain point of "insufficient reasoning basis" when fixing Modelica code using general LLM, and makes up for the deficiency that it is difficult to capture deep relationships such as component dependencies and equation logic by relying solely on code snippets.

[0077] 3. Address the core requirement of "difficulty in balancing functional correctness and safety constraints" in industrial-grade Modelica model repair, and avoid the problem that although the repaired code can be compiled, the simulation fails to converge and physical safety constraints are violated.

[0078] 4. Improve the current situation of difficult error location and low repair efficiency in Modelica model development, and alleviate the dilemma that manual repair requires professional domain knowledge and is time-consuming and labor-intensive.

[0079] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0080] 1. Significantly improved repair accuracy and reliability: Through dual-path fine-tuning (auxiliary information enhancement + execution / security reward reinforcement learning) and a dedicated error detection module, it achieves accurate location and repair of four types of errors: syntax, logic, simulation, and security. The patch compileability rate is ≥95%, and the functional correctness accuracy rate is ≥90%, meeting the requirements of industrial-grade applications.

[0081] 2. Significantly improved repair efficiency: The end-to-end automated process, from error detection to outputting a plausible patch, greatly reduces the time and cost of manual troubleshooting and repair, and is especially suitable for the rapid iteration needs of complex multi-domain coupled models.

[0082] 3. Safety and robustness assurance: Physical safety constraints are incorporated into the reinforcement learning reward function and robustness is verified under multiple input conditions to reduce equipment risks or simulation failures caused by model errors in industrial scenarios.

[0083] 4. High adaptability and ease of use: It is compatible with open source libraries and industrial-grade custom models, can be integrated into the Modelica development environment, and outputs repair explanations, taking into account both the needs of professional engineers for efficient use and learners for understanding the modeling logic.

[0084] 5. Excellent scalability: Based on domain pre-training and modular design, it can quickly adapt to new domain Modelica models (such as new energy and aerospace), and can expand error correction types by expanding the dataset, and has continuous optimization capabilities. Attached Figure Description

[0085] Figure 1 This is an architecture diagram of the system of the present invention. Detailed Implementation

[0086] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are some embodiments of the present invention, but not all embodiments.

[0087] like Figure 1 As shown in this embodiment, the deep learning-based automatic code repair method for simulation models achieves high-precision and high-reliability automatic repair of code errors in the Modelica language (especially complex multi-domain coupled models).

[0088] The core solution addresses four types of errors: syntax errors (such as mismatched brackets, undefined components), logic errors (such as incorrect component connections, incorrect equation derivation), simulation errors (such as failure to converge due to parameter range exceeding limits), and safety errors (such as violation of physical constraints, exceeding operational boundaries).

[0089] The core ideas of this invention include:

[0090] Drawing on the traditional three-stage framework of "training-inference-verification" for code repair, this paper focuses on the core mechanism of domain-adaptive pre-training + dual-path fine-tuning:

[0091] 1. Basic pre-training: Enables CodeBERT to master the syntax rules, semantic logic, and multi-domain coupling characteristics of the Modelica language;

[0092] 2. Dual-path fine-tuning:

[0093] Reinforcement Learning Fine-Tuning (RLFT): By introducing "Reinforcement Learning with Verifiable Rewards (RLVR)" to optimize the GPT decoder to ensure more stable training performance, the "actual performance of the repaired model" (compileability + functional correctness + safety constraints) is used as a reward to improve the functional correctness of the generated code;

[0094] Enriched Context-Based Fine-Tuning (CRFT): Utilizing a multimodal fusion mechanism, the improved CodeBERT takes "error code (text information) + additional auxiliary information (graph structure information)" as input, allowing it to discover defects in the code based on more comprehensive information;

[0095] 3. End-to-end collaboration: Combining the declarative features of the Modelica language (component connection, equation-driven), we design dedicated parsing, detection, and verification modules to form an end-to-end repair system.

[0096] System overall architecture:

[0097] The system follows a closed-loop process of "parsing-detection-repair-verification," and its core is divided into three major stages and four major modules, with the architecture as follows: Figure 1 As shown in the diagram;

[0098] The implementation steps of this invention are as follows:

[0099] S1. Preprocess the original model files to obtain a dataset structure that facilitates computer lexical and syntactic analysis and LLM training. This includes the following two processing steps:

[0100] Process 1: Generate an Abstract Syntax Tree (AST) and component dependency graph by parsing the model text, transforming the model string into a structured model syntax tree and component relationship graph within the computer.

[0101] Step 2: Mapping to short tokens to simplify the expression of different long phrases in the model, reduce the recognition time of long texts during model training, and improve model training efficiency;

[0102] S2. Use the simplified model obtained in step 2 of S1 to pre-train CodeBERT. The labeled dataset required for training the error correction model contains the original error text and the location of the error code. The dataset is divided into training set, validation set and test set in an 8:1:1 ratio. During the training of the error detection model, the error detection capability of the model is enhanced by introducing the CRFT (Continuous Revision Forwarding) mechanism and using the structured abstract syntax tree (AST) and component dependency graph from S1.

[0103] S3. Using the defect locations output by CodeBERT in S2 as input to the GPT decoder, reinforcement learning fine-tuning (RLFT) is introduced to generate patches that resolve the defects. Through improvements to the reward function, a three-layer automatic verification system—compilability, functional correctness, and safety constraints—is used to fine-tune the training process to achieve both physical semantic and functional correctness repair. The following details the specific steps:

[0104] I. Data Preprocessing and Dataset Construction:

[0105] The dataset is the foundation for LLM to learn the features of the Modelica language and the error correction logic. It needs to be processed in accordance with the principles of "redundancy removal, semantic preservation, and domain-specific support" and combined with the declarative and multi-domain coupled characteristics of Modelica.

[0106] (I) Design of Multi-Dimensional Data Sources

[0107] The datasets are divided into two categories: "correct datasets (no errors)" and "error datasets (error-patch pairs)," balancing the general applicability of open source with the specificity for industrial scenarios.

[0108] 1. Correct dataset (no errors):

[0109] Open source standard library: Select core models that have been verified by simulation from libraries such as Modelica Standard Library (MSL), ThermoPower (thermal engineering), and Vehicle Dynamics (vehicle dynamics), and prioritize the retention of systems in automotive simulation scenarios (such as battery SOC differential equations and engine torque-speed algebraic equations) to ensure that the sample covers typical structures of "differential equations + algebraic equations" coupling.

[0110] GitHub open source projects: Select Modelica repositories with ≥10 stars, verify them through OpenModelica compilation + simulation (not only must they be compileable, but they must also complete 100 short time step solutions), and eliminate models that are only syntactically correct but whose equations are unsolvable, covering multi-domain coupled scenarios such as chassis, motor, and cooling circuit.

[0111] Industrial-grade data anonymization case: Integrating our own error-free Modelica model (anonymized), focusing on models used in actual applications by automotive manufacturers, multi-domain coupled equation systems (such as electrical equations + mechanical transmission equations + thermal management equations), and supplementing industrial-grade model structures missing from open-source data.

[0112] 2. Error dataset (error-patch pairs):

[0113] Real-world error examples: Real-world error samples were collected from GitHub Issues, official OpenModelica user feedback, and the StackOverflow Modelica section. Error types (such as parameter out of bounds, component connection mismatch, and unsolvable DAE equations) and corresponding fixes were manually labeled to form a triplet of "error code - fix patch - error cause".

[0114] Error injection generation: Based on the correct dataset, four types of core errors (syntax and semantic errors, physical constraint errors, component connection errors, and DAE solution errors) are injected according to the common error patterns of the Modelica code for automotive simulation. The error distribution patterns in industrial scenarios are strictly followed (e.g., parameter out-of-bounds errors account for 30%, and component connection errors account for 25%) to build large-scale, highly realistic error-patch pairs.

[0115] Table 1. Modelica Error Types and Injection Methods

[0116]

[0117] Data preprocessing workflow:

[0118] 1. Code simplification: Remove irrelevant and redundant information from the Modelica code (Annotation{...}, graph configuration, position information, comments), and retain the core compilable parts (component definitions, connect connections, equations, parameter configurations);

[0119] 2. AST Construction and Feature Extraction: Using Cautosim's parsing interface to generate an Abstract Syntax Tree (AST), this approach overcomes the limitations of traditional text analysis, focusing on extracting the mathematical structural features of the system within the model (distinct from the lexical and syntactic structural features of traditional code).

[0120] Equation-Variable Correlation Matrix: Construct a bipartite graph of "variable nodes-equation edges" using graph theory methods, calculate the number of equation constraints for each variable, and identify structural singularities;

[0121] Model structural features: Extracting differential / algebraic variable classifications and equation linear / nonlinear attributes to provide a mathematical basis for subsequent error detection;

[0122] Intermediate features of simulation: The simulation kernel is called in advance to complete "flattening + equation sorting", and the "equation sorting results and state variable selection list" output by the simulation kernel are extracted to record the solution priority of the equations.

[0123] 3. Simplified model text:

[0124] To simplify the string representation of the model and improve training efficiency, a hybrid approach of "word-level segmentation + domain-specific token mapping" is adopted to replace specific expressions in the original model text with simpler expressions.

[0125] Fixed tokens: Modelica keywords (model, block, connect, equation) and operators (=, +, *) are mapped to dedicated tokens;

[0126] Dynamic tokens: Long component names (such as Modelica.Mechanics.Rotational.Sensors.AngleSensor) are mapped to short tokens (such as ROT_ANGLE_SENSOR) to reduce sequence length;

[0127] Character-level supplement: Rare parameter / variable names not included in the list are segmented using character-level tokenization to balance vocabulary size and sequence length.

[0128] Vocabulary: Includes tokens, parameter values, component types, and equation symbols.

[0129] 4. Data Augmentation:

[0130] Synonym substitution: Substitution of different syntaxes with the same semantics in Modelica (e.g., connect(a, b) vs. connect(b, a), parameter assignment p=5 vs. p:=5);

[0131] Structural rearrangement: rearrange the order of component definitions and equations without changing the semantics;

[0132] Error mutation: Perform secondary mutations on code that has been injected with errors (such as adjusting the error location or modifying the error type) to expand the diversity of the dataset.

[0133] II. Error Detection and Repair Code Generation – LLM Pre-training and Dual-Path Fine-tuning:

[0134] The basic LLM needs to go through "domain-adaptive pre-training + dual-path fine-tuning" to master the declarative features of Modelica and the error detection logic of automotive simulation scenarios, and generate high-accuracy error patches.

[0135] In the error detection phase, to help the model master Modelica's syntax, semantics, and structured features, the focus shifts from traditional "imperative / procedural" code processing logic (C language, Python) to learning its "declarative / component connection / equation" modeling process. The method employs an improved CodeBERT for code error detection. During the basic pre-training phase, to further familiarize the model with Modelica's language characteristics, the auxiliary information enhancement structure in the dual-path fine-tuning mechanism is specifically designed for the characteristics of Modelica's modeling language. A multimodal fusion mechanism is used to apply structured model information, such as deep equation constraints and physical connection relationships, to error detection, thereby improving the accuracy of error detection.

[0136] The patch inference phase, a core execution stage in the automated code repair process, aims to generate targeted and effective candidate patches, providing high-quality alternatives for subsequent verification. This stage uses the defect locations output by CodeBERT as input to the GPT (Generative Pre-trained Transformer) decoder to generate patches for code repair. During patch inference, focusing on localized repair is a crucial principle for ensuring both efficiency and quality. This principle is based on the accurate error localization results output by the earlier error detection and localization module, defining clear and reasonable modification boundaries for the model's repair operations. It strictly limits the model to modifying only confirmed error locations and related code with direct logical connections. These related codes include adjacent lines of code containing the error parameters, key statements providing logical connections, and equations directly related to the error. This localized modification restriction does not constrain the model's repair capabilities, but rather effectively reduces redundant code changes by avoiding global modifications to irrelevant nodes. This improves the computational efficiency of patch generation, prevents the model from wasting computational resources in irrelevant code areas, and preserves the core business logic and implementation architecture that have been verified to be effective in the original code to the greatest extent possible. It also prevents the introduction of new potential errors due to excessive or meaningless modifications, while reducing the verification cost for subsequent patch verification stages, allowing verification work to focus more on the effectiveness and rationality of the repaired areas.

[0137] Building upon its focus on localized repair, the patch inference process also boasts a core feature: multi-granularity repair support. This enables comprehensive adaptation to errors of varying types and severity. This multi-granularity repair capability encompasses four complementary and layered repair granularities: parameter modification, connection adjustment, equation correction, and component addition / removal. Parameter modification targets lightweight numerical or definitional errors, requiring no changes to the overall code logic; only adjustments to parameter values, type definitions, or naming conventions are needed for repair. Connection adjustment focuses on logical flow anomalies between code modules and statements, restoring normal code logic by optimizing function call relationships, adjusting logical connectors in conditional statements, and correcting data transmission links. Equation correction specifically targets code snippets containing mathematical calculations and logical expressions, precisely correcting professional errors such as equation derivation errors, expression omissions, and confusion in computational precedence. This type of repair granularity is commonly found in scientific computing and simulation. This system addresses code scenarios requiring high precision, such as those involving modules. Component addition / removal is a crucial means of handling more complex structural errors. For scenarios involving missing essential functional components or redundant / invalid modules causing logical conflicts, the system supplements core functionality by adding missing functions, classes, or modules, or removes redundant / invalid code components to eliminate logical conflicts. These four repair granularities work together to form a complete repair coverage system, ranging from lightweight local numerical adjustments to heavyweight structural refactoring. This system comprehensively adapts to different types of code errors, ensuring that the patch inference process can output more targeted and effective candidate patches for specific error scenarios, thereby improving the overall coverage and accuracy of automatic code repair.

[0138] 1) Basic pre-training

[0139] The model's pre-training focuses on optimizing CodeBERT for error detection. It emphasizes learning Modelica's grammar rules and obtaining structural features of the syntax, semantics, and model components. The preprocessed model training data is divided into training, validation, and test sets in an 8:1:1 ratio. The training set is used for model training, while the validation set validates the trained CodeBERT model and yields validation evaluation metrics.

[0140] 2) Dual-path fine-tuning

[0141] The pre-trained model needs to be further optimized through "Reinforcement Learning Fine-tuning (RLFT) + Auxiliary Information Enrichment Fine-tuning (CRFT)".

[0142] 2.1) CRFT (Continuous Reinforcement Theory): Enhancing the Basis of Reasoning

[0143] Core idea: By using a multimodal fusion mechanism, "error code + additional auxiliary information" is used as input, allowing CodeBERT to discover defects in the code based on more comprehensive information.

[0144] 1. Auxiliary information enhancement structure:

[0145] The auxiliary information enhancement structure uses error code fragments as its core carrier and deeply integrates the auxiliary information unique to Modelica simulation model code to build a complete logical closed-loop reasoning basis, providing comprehensive support for LLM to accurately generate repair patches that conform to physical semantics and equation constraints. This structure first clarifies the core attributes of errors through a standardized labeling system, including typical error types in Modelica scenarios (such as algebraic rings, excessively high DAE indexes, and simulation errors such as mismatch between component port physical domains), the specific location of the error in the model (such as the specified line number of the equation block, the name of key parameters), and the root cause (such as parameters exceeding the automotive industry standard range, and structural singularities caused by a mismatch between the number of equations and the number of variables). Then, based on the Abstract Syntax Tree (AST) and component dependency graph, it supplements the component dependency relationships and equation logical connections of the model, clearly presenting the connection links between various physical components (such as the electrical connection between the motor and the battery, and the matching of the fluid ports of the cooling circuit) and the constraint relationships of the equation system (such as the coupling logic between differential equations and algebraic equations). At the same time, it incorporates key execution details generated during the simulator's compilation and solving process, including core intermediate data such as equation sorting results, state variable selection lists, and algebraic ring detection reports. This information is a unique key reference under Modelica's declarative / equation base characteristics, which is different from the execution logs of traditional imperative code.

[0146] To integrate auxiliary information into the training process, a cross-modal attention mechanism is employed to combine different information. The AST and dependency graph in the auxiliary information enhancement structure are transformed into graph structures, encoded using graph neural networks (such as GAT), and then the node representations are aligned with the corresponding text token representations. This provides feature support with both syntactic depth and physical relevance for subsequent error localization tasks. This mechanism fully adapts to the "declarative / equation basis" language characteristics of Modelica, effectively compensating for the shortcomings of traditional text modeling in capturing deep equation constraints and physical connectivity relationships.

[0147] The construction of a unified graph structure is a crucial step in bridging structured data and GAT encoding. Its core lies in transforming the parsed structured data into a feature representation that GNNs can process, while preserving Modelica's unique physical semantics and the location information needed for error localization. Node feature design follows a three-dimensional fusion principle of "syntax-physical-location," employing fixed-dimensional vector encoding: one-hot encoding represents node type and physical domain attributes; embedding layers convert line numbers into low-dimensional location vectors; additional equation type encoding is introduced for Equation nodes; and error flag features are added for error localization, forming a node feature matrix that combines semantic discriminative power with location anchors. Edge features focus on the semantic representation of relationships between nodes, using one-hot encoding to distinguish physical connections, equation constraints, and equilateral edge types; and combining physical domain attributes and line number matching information to construct an edge feature matrix. Finally, a directed graph is constructed based on the node and edge sets, transforming it into a structured data format standard for graph neural networks. This achieves the mapping from unstructured parsed results to structured graph data, providing high-quality input for GAT encoding.

[0148] The Graph Attention Network (GAT) encoding enhances the modeling of relationships between nodes in the Modelica graph structure through graph attention mechanisms, accurately capturing node relationship patterns corresponding to deep errors such as algebraic rings and excessively high indexes of differential algebraic equations (DAEs). Considering that Modelica errors often manifest as abnormal relationships between local nodes, the GAT model employs a two-layer architecture: the first layer uses multiple attention heads to compute relationship weights between nodes in parallel, enhancing the ability to capture local node interaction features and adapting to relationship patterns of different error types; the second layer concatenates the outputs of the multiple attention heads and maps them to the target dimension, generating a unified node-level representation. To improve the quality of node representations, the GAT model can be further optimized through pre-training. Pre-training tasks include unsupervised / weakly supervised tasks such as node type classification, edge prediction, and masked node recovery, enabling the model to learn the inherent grammatical rules and physical relationship patterns of the Modelica graph, providing more discriminative node representations for subsequent error localization tasks.

[0149] Precise alignment of node representations with text token representations is crucial for fusing graph structure semantics and text semantics. Its core logic lies in establishing a mapping relationship between graph nodes and code text tokens, achieving complementary enhancement of features from both modalities. The mapping relationship is constructed based on the association between code line numbers and character positions: Modelica code is segmented using code tokenizers to obtain the start and end positions of each token's characters. Combined with the code line number information of the AST nodes, a mapping table of "graph node ID - text token interval" is established, clarifying the continuous token sequence corresponding to each graph node (e.g., the token set corresponding to a certain line of code for an Equation node). In the feature fusion stage, based on the mapping relationship, multiple token features corresponding to a single node are fused using mean pooling or attention-weighted fusion, transforming them into text features compatible with the graph node representation dimension. Subsequently, concatenation or attention fusion strategies are used to fuse the graph node representation and text features, generating an integrated "graph-text" feature. Finally, the fused features are aligned to the corresponding text tokens according to the mapping relationship and added to the LLM input embedding, enabling the LLM to simultaneously perceive the text semantics of the code and the deep graph structure semantics, strengthening the feature representation capability of the error localization task.

[0150] 2.2) Reinforcement Learning Fine-Tuning (RLFT): Fine-tuning with the goal of achieving correct generation functionality.

[0151] Core idea: To meet the specific requirements of industrial simulation software for high accuracy in generated patch content, patch generation must not only achieve simple text matching and repair, but also achieve correct physical semantics and functional repair. By introducing "Reinforcement Learning with Verifiable Rewards" to optimize the GPT decoder and ensure more stable training performance, the "actual execution effect of the repaired model" is used as the reward, thereby improving the functional correctness of the generated code.

[0152] The candidate patches generated in the patch inference process are not directly usable. They still need to be screened through a strict and systematic patch verification process to ensure that the patches finally put into use have syntactic validity, functional effectiveness and operational robustness. Automatic verification, as the core implementation method of patch verification, achieves comprehensive and efficient screening of candidate patches through a three-layer progressive verification system.

[0153] Compilability verification is the first checkpoint in the three-layer automatic verification system and a fundamental step in ensuring the basic usability of patches. Its core objective is to quickly eliminate invalid candidate patches with syntax errors. In this verification stage, the system automatically calls the dedicated Cautosim compiler, using the complete code incorporating the candidate patch as compilation input. Following the syntax rules, compilation guidelines, and Cautosim compiler's specific parsing requirements of the corresponding programming language, the system performs line-by-line syntax analysis, symbol verification, and format checks on the repaired code. If syntax errors, undefined symbols, non-standard formatting, or failure to meet compiler parsing requirements occur during compilation, the candidate patch is directly deemed invalid and eliminated without proceeding to subsequent, more complex verification stages. This fundamental checkpoint quickly filters out a large number of obviously invalid candidate patches, significantly improving the efficiency of subsequent verification stages. It also lays a solid foundation for subsequent functional correctness and robustness verification, ensuring that candidate patches entering later stages possess basic syntactic validity and can be parsed and run correctly.

[0154] Functional correctness verification is the core of the three-layer automated verification system and a key basis for determining whether candidate patches truly resolve core errors and meet business requirements. This step does not rely on a single test case for verification; instead, it conducts a comprehensive inspection by running a pre-designed complete test suite. This test suite is meticulously designed based on the code's expected business functions, actual application scenarios, and core performance requirements, and includes three core components: diverse pre-designed simulation scenarios, clearly quantified output indicator thresholds, and strict security constraints. During verification, the system places the repaired model, incorporating the candidate patch, into various pre-designed simulation scenarios and runs it sequentially. It collects core data such as output results and runtime logs in real time under different simulation scenarios. The collected output results are then precisely compared with pre-designed output indicator thresholds, while strictly verifying whether the model's execution process meets all pre-designed security constraints. Taking simulation modeling code as an example, the verification process focuses on determining whether the repaired model can achieve stable simulation convergence, whether the error of the output results can be strictly controlled within 5%, and whether the execution process meets pre-designed security boundary requirements and is free of violations. Only when the repaired model successfully passes all test cases in the test suite and fully meets all preset functional requirements, performance indicators, and security constraints can the candidate patch be deemed functionally correct and effective. Otherwise, it is considered an invalid patch and is eliminated. This verification process is directly related to the core business value of the code, effectively avoiding invalid fixes that are "syntactically valid but functionally ineffective," and ensuring that the repaired code can normally achieve the expected business functions.

[0155] Safety constraints are designed to adapt to code scenarios in simulations with rigid physical safety requirements. The core objective of safety constraint verification is to check whether the repaired code strictly meets all preset physical safety constraints. These constraints stem from the physical laws and safety specifications of real-world application scenarios, such as common threshold limits in code like temperature ≤100℃ and pressure ≤5MPa, or output power boundaries and structural stress safety thresholds for power systems. This verification step is not performed in isolation but rather in conjunction with functional correctness verification: during the simulation run of functional correctness verification, the system synchronously monitors core parameters related to physical safety in real time and dynamically compares them with preset safety constraint thresholds. If the repaired model exhibits physical safety parameters exceeding the thresholds in any simulation scenario, even if its functional output indicators meet the requirements, it will be deemed an invalid patch. Only when the model not only achieves the expected function but also strictly adheres to all physical safety constraints throughout the entire process, ensuring that the operation will not cause safety risks, can it pass the safety constraint verification. This addition to the verification dimension effectively avoids the vulnerability of "functionally legitimate but security-ineffective" in the repair process, ensuring that the repaired code not only runs normally but also meets the security requirements of real-world application scenarios and has practical deployable value.

[0156] The simplicity-oriented principle, building upon the existing three-layer automatic verification system, aims to optimize both the effectiveness of code fixes and code stability. The core criterion for simplicity is defined as the reciprocal of the patch modification amount relative to the original code. Its goal is to encourage minimal modifications, ensuring a precise and restrained repair process by constraining the model's modification scope. Within the modification boundaries defined by localized repair focus, the model does not simply generate arbitrary feasible repair solutions. Instead, it prioritizes solutions with the smallest modification amount that thoroughly resolve the error from multiple granular repair options. For example, when a code error can be resolved by adjusting parameters or fine-tuning connections, the model actively avoids large-scale modifications such as adding / removing components. Even when faced with complex errors requiring structural adjustments, it strictly controls the scope of modification, only modifying the smallest code unit associated with the core error. This simplicity-oriented design not only reduces the uncertainty brought by code changes and lowers the risk of introducing new potential errors due to excessive modifications, but also maximizes the preservation of the original code's structural integrity and maintainability. This makes the repaired code easier for developers to understand and trace, while also reducing the verification complexity of subsequent patch verification stages and improving the efficiency and reliability of the overall repair process.

[0157] Therefore, the GPT decoder after CRFT fine-tuning not only needs to generate candidate patches, but also incorporates improvements to the reward function (R) to optimize the LLM patch generation strategy through multi-dimensional weighted rewards (weights tuned through the validation set) and the PPO algorithm:

[0158] R=w1 R compile +w2 R func +w3 R safety +w4 R concise

[0159] R compile Compilability bonus (0 / 1, whether the fixed code can be compiled by Cautosim);

[0160] R func Functional correctness reward (0-1, percentage of simulated test cases passing the test suite, such as output error ≤5%, convergence successful);

[0161] R safety Safety constraint reward (0-1, whether all physical safety constraints are met, such as temperature ≤100℃, pressure ≤5MPa);

[0162] R concise Simplicity bonus (0-1, the reciprocal of the patch's modification amount relative to the original code, encouraging minimal modifications);

[0163] Weight settings: (w1=0.2, w2=0.4, w3=0.3, w4=0.1) (Focus on functionality and security).

[0164] PPO training process:

[0165] Sampling phase: The GPT decoder generates N candidate patches (N=5), performs verification, and calculates the reward for each patch;

[0166] Policy update: The GPT decoder parameters are updated through the PPOclip objective function to control the policy update magnitude (clip threshold = 0.2).

[0167] Value network update: Optimize the value network with mean squared error (MSE) to fit the true reward;

[0168] Number of iterations: 10-15 rounds, monitoring the convergence of average reward.

[0169] In summary, the technical innovations of this invention are as follows:

[0170] 1. Modelica domain LLM dual-path fine-tuning: Integrating CRFT (Assistive Information Enhancement) and RLFT (Execution / Security Reward) to solve the problem of "insufficient reasoning basis" while ensuring "correct repair function";

[0171] 2. Verifiable Reward-Based Reinforcement Learning (RLVR): For the first time, Modelica's compilability, functional correctness, and safety constraints are incorporated into the reward system, adapting to the reliability requirements of industrial-grade models;

[0172] 3. Cross-modal attention mechanism: The serialized model text information and the graph structure model abstract syntax tree (AST) and component dependency graph are used for the training of the neural network, which effectively makes up for the shortcomings of traditional declarative language code repair models in capturing deep equation constraints and physical connection relationships.

[0173] 4. Hybrid word segmentation and pointer copying mechanism: Balances vocabulary size and sequence length, improves the processing capability of rare domain terms, and ensures patch compilability.

[0174] In summary, this invention proposes an LLM-based error repair framework—combining domain-adaptive pre-training with dual-path fine-tuning—to address the unique characteristics of the Modelica language. This framework enhances inference capabilities through enriched auxiliary information, ensures functional and safety correctness through reinforcement learning, and, combined with dedicated parsing, detection, and verification modules, achieves high-precision and highly reliable automatic Modelica code repair. The solution balances industrial-grade practicality with technological innovation, effectively solving the error repair challenges in Modelica model development.

[0175] In another aspect, the present invention also discloses a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the method described above.

[0176] In another aspect, the present invention also discloses a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor performs the steps of the method described above.

[0177] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the deep learning-based simulation model code automatic repair methods described in the above embodiments.

[0178] It is understood that the systems, devices, and storage media provided in the embodiments of the present invention correspond to the methods provided in the embodiments of the present invention, and the explanations, examples, and beneficial effects of the relevant content can be referred to the corresponding parts of the above methods.

[0179] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0180] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0181] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0182] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for automatic code repair of simulation models based on deep learning, characterized in that, Includes the following steps, S1. Preprocess the original model files to obtain a dataset structure that facilitates computer lexical and syntactic analysis and LLM training. This includes the following two processing steps: Process 1: Generate an Abstract Syntax Tree (AST) and component dependency graph by parsing the model text, transforming the model string into a structured model syntax tree and component relationship graph within the computer. Step 2: Map to short tokens to simplify the expression of different long phrases in the model; S2. Use the simplified model obtained in step 2 of S1 to pre-train CodeBERT, and use the labeled dataset required to train the error correction model, which contains the location of the original error text and error code. During the training of the error detection model, enrich the fine-tuning mechanism by introducing auxiliary information, and use the structured abstract syntax tree (AST) and component dependency graph in step 1 of S1 to enhance the model's error detection capability. The auxiliary information-rich fine-tuning mechanism in S2 includes, By using a multimodal fusion mechanism, "error code + additional auxiliary information" is taken as input, allowing CodeBERT to discover defects in the code based on more comprehensive information; The auxiliary information enhancement structure uses error code fragments as its core carrier, deeply integrates auxiliary information from the Modelica simulation model code, and constructs a complete reasoning basis for a logical closed loop, providing comprehensive support for LLM to accurately generate repair patches that conform to physical semantics and equation constraints. S3 uses the defect location output by CodeBERT in S2 as the input to the GPT decoder and introduces reinforcement learning to fine-tune the generation of patches to solve the defects; by improving the reward function, the training process is fine-tuned using a three-layer automatic verification system of compilability, functional correctness, and safety constraints to achieve physical semantics + functional correctness repair.

2. The method for automatic code repair of simulation models based on deep learning according to claim 1, characterized in that: The specific steps in S1 include: The Cautosim parsing interface is used to generate an Abstract Syntax Tree (AST), extracting component dependency graphs and component relationship graphs to provide structural features for error detection and auxiliary information enhancement.

3. The method for automatic code repair of simulation models based on deep learning according to claim 2, characterized in that: Process two includes, Fixed tokens: Modelica keywords and operators are mapped to dedicated tokens; Dynamic tokens: Long component names are mapped to short tokens, reducing sequence length; Character-level supplementation: Rare parameter / variable names not included in the list are segmented using character-level tokenization to balance vocabulary size and sequence length; The vocabulary includes: tokens, parameter values, component types, and equation symbols.

4. The method for automatic code repair of simulation models based on deep learning according to claim 3, characterized in that: S1 also includes data augmentation. Synonym substitution: Replace different spellings of Modelica with the same semantics; Structural rearrangement: rearrange the order of component definitions and equations without changing the semantics; Error mutation: Perform secondary mutations on code that has already been injected with errors to expand the diversity of the dataset.

5. The method for automatic repair of simulation model code based on deep learning according to claim 4, characterized in that: The pre-training steps for S2 include, Base model selection: Select CodeBERT for error detection; Learn the syntax rules of Modelica and acquire the syntactic, semantic, and structural features of model components; Pre-training task design: The preprocessed model training data is divided into training set, validation set and test set in a ratio of 8:1:

1. The training set is used to train the model, and the validation set is used to validate the trained CodeBERT model and obtain validation evaluation metrics.

6. The method for automatic code repair of simulation models based on deep learning according to claim 5, characterized in that: The auxiliary information-rich fine-tuning mechanism in S2 specifically includes the following: First, the core attributes of the errors are clearly marked through a standardized labeling system, including typical error types in the Modelica scenario, the specific location of the error in the model, and the root cause. Then, based on the Abstract Syntax Tree (AST) and component dependency graph, the component dependency relationship and equation logical association of the model are supplemented, presenting the connection links between various physical components and the constraint relationship of the equation system. At the same time, key execution details generated during the simulator compilation and solving process are incorporated, including core intermediate data such as equation sorting results, state variable selection list, and algebraic loop detection report. To incorporate auxiliary information into the training process, a cross-modal attention mechanism is used to integrate different information. The AST and dependency graph in the auxiliary information enhancement structure are transformed into graph structures, encoded using graph neural networks, and then the node representations are aligned with the corresponding text token representations, providing feature support with both syntactic depth and physical relevance for subsequent error localization tasks. The construction of the unified graph structure lies in transforming the parsed structured data into a feature representation that can be processed by GNN, while retaining the physical semantics specific to Modelica and the location information required for error localization; The node feature design follows the three-dimensional fusion principle of "syntax-physical-position" and adopts fixed-dimensional vector encoding: one-hot encoding is used to represent the node type and physical domain attributes, the code line number is converted into a low-dimensional position vector through the embedding layer, equation type encoding is introduced for Equation nodes, and error flag features are added for error localization tasks to form a node feature matrix that has both semantic discriminativeness and position anchor. Edge features focus on the semantic representation of relationships between nodes. One-hot encoding is used to distinguish physical connections, equation constraints, and equilateral edge types. An edge feature matrix is ​​constructed by combining physical domain attributes and row number matching information. Finally, a directed graph is constructed based on the node set and edge set, which is transformed into a structured data format according to the graph neural network standard. This realizes the mapping from unstructured parsing results to structured graph data, providing high-quality input for GAT encoding. GAT encoding enhances the modeling of relationships between nodes in the Modelica graph structure through graph attention mechanisms, accurately capturing node relationship patterns corresponding to deep errors such as algebraic rings and excessively high indices in differential algebraic equations. The GAT model adopts a two-layer architecture: the first layer uses multiple attention heads to compute the association weights between nodes in parallel, which enhances the ability to capture the interaction features of local nodes and adapts to association patterns with different types of errors; the second layer concatenates the outputs of the multiple attention heads and maps them to the target dimension to generate a unified node-level representation. To improve the quality of node representation, the GAT model is further optimized through pre-training. The pre-training tasks include unsupervised / weakly supervised tasks such as node type classification, edge prediction, and masked node recovery, which enable the model to learn the inherent grammatical rules and physical associations of the Modelica graph, providing more discriminative node representations for subsequent error localization tasks. The precise alignment logic between node representation and text token representation lies in establishing a mapping relationship between graph nodes and code text tokens, thereby achieving complementary enhancement of the two modal features; The mapping relationship is constructed based on the association between code line number and character position: the Modelica code is segmented by code Tokenizers to obtain the start and end positions of each token, and combined with the code line number information of AST nodes, a mapping table of "graph node ID-text token range" is established to clarify the continuous token sequence corresponding to each graph node. In the feature fusion stage, based on the mapping relationship, the multiple token features corresponding to a single node are averaged or attention-weighted and fused to transform them into text features that are compatible with the graph node representation dimension. Then, a concatenation or attention fusion strategy is used to fuse the graph node representation with the text features to generate an integrated "graph-text" feature. Finally, the fused features are aligned to the corresponding text tokens according to the mapping relationship and added to the input embedding of the LLM, so that the LLM can simultaneously perceive the textual semantics of the code and the semantics of the deep graph structure, thereby enhancing the feature representation capability of the error localization task.

7. The method for automatic code repair of simulation models based on deep learning according to claim 6, characterized in that: S3 includes the repair patch generation model, the steps of which are as follows. The GPT decoder is used to generate patches for fixing the code; During the patch inference process, the local repair focus is based on the accurate error location results output by the previous error detection and localization module. This defines clear and reasonable modification boundaries for the model's repair operations, strictly limiting the model to modify only the confirmed error locations and related code with direct logical connections. The related code includes adjacent lines of code where the error parameter is located, key statements that play a role in logical connection, and equation expressions directly related to the error. Building upon the focus on localized repair, the system also includes a patch inference stage. This stage supports multi-granularity repair, encompassing four complementary and layered repair granularities: parameter modification, connection adjustment, equation correction, and component addition / removal. Parameter modification addresses lightweight numerical or definitional errors, requiring no changes to the overall code logic; only adjustments to parameter values, type definitions, or naming conventions are needed for repair. Connection adjustment focuses on logical flow anomalies between code modules and statements, achieved by optimizing function call relationships and adjusting conditional judgment logic. Methods such as word concatenation and data transmission linking restore the normal flow of the code's logical architecture; equation correction is specifically designed for code snippets containing mathematical calculations and logical expressions, precisely correcting professional errors such as equation derivation errors, expression omissions, and confusion of operation priorities; for scenarios where the code lacks necessary functional components or has redundant and invalid modules causing logical conflicts, it completes the core functionality by adding missing functions, classes, or modules, or removes redundant and invalid code components to eliminate logical conflicts. The four repair granularities work together to form a complete repair coverage system, ranging from lightweight local numerical adjustments to heavyweight structural refactoring.

8. The method for automatic repair of simulation model code based on deep learning according to claim 7, characterized in that: S3 includes a reinforcement learning fine-tuning mechanism, the steps of which are as follows: By introducing "Verifiable Reinforcement Learning RLVR" to optimize the GPT decoder, the "actual performance of the repaired model" is used as the reward, thereby improving the functional correctness of the generated code. The candidate patches generated in the patch inference process are not directly usable. They still need to be screened through a rigorous and systematic patch verification process. Automated verification is used for patch verification. Through a three-layer progressive verification system, a comprehensive and efficient screening of candidate patches can be achieved. Compilability verification is the first step in the three-layer automatic verification system. In this verification stage, the system automatically calls the dedicated Cautosim compiler, takes the complete code with the candidate patch as the compilation input, and performs line-by-line syntax parsing, symbol verification, and format checking according to the syntax specifications, compilation rules, and Cautosim compiler's specific parsing requirements of the corresponding programming language. If syntax errors, undefined symbols, non-standard formatting, or failure to meet compiler parsing requirements occur during the compilation process, the code is directly eliminated. Functional correctness verification is the core of the three-layer automated verification system and a key basis for judging whether candidate patches truly solve core errors and meet business requirements. It is carried out by running a set of preset complete test suites for comprehensive verification. The test suites include three core components: diverse preset simulation scenarios, clearly quantified output indicator thresholds, and strict security constraints. During the verification process, the system will place the repaired model with the candidate patch into various preset simulation scenarios and run them in sequence. It will collect the model's output results and running logs in real time under different simulation scenarios. Then, it will accurately compare the collected output results with the preset output indicator thresholds and strictly check whether the model's running process meets all preset security constraints. The core objective of security constraint verification is to check whether the repaired code strictly meets all preset physical safety constraints. These constraints are derived from the physical laws and safety specifications of the actual application scenario. This verification step works in conjunction with functional correctness verification: during the simulation run of functional correctness verification, the system will synchronously monitor the core parameters related to physical safety in real time and dynamically compare them with preset safety constraint thresholds. If the repaired model has physical safety parameters that exceed the threshold in any simulation scenario, even if its functional output indicators meet the requirements, it will be judged as an invalid patch. Only when the model not only achieves the expected function, but also adheres to all physical safety constraints throughout the process, ensuring that the operation will not cause security risks, can it pass the security constraint verification. The simplicity-oriented principle, based on the original three-layer automatic verification system, aims to achieve dual optimization of repair effectiveness and code stability. The core evaluation criterion for simplicity is defined as the reciprocal of the proportion of patch modification amount to original code. Within the modification boundary defined by local repair focus, the model does not simply generate any feasible repair solution, but will prioritize the solution with the smallest modification amount and that can completely solve the error among the optional paths of multi-granularity repair. Therefore, the GPT decoder after CRFT fine-tuning not only needs to generate candidate patches, but also needs to add multi-dimensional weighted rewards to the reward function, including: Compilability bonus, functional correctness bonus, security constraint bonus, and simplicity bonus.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it causes the processor to perform the steps of the method as described in any one of claims 1 to 8.

10. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the computer program is executed by the processor, it causes the processor to perform the steps of the method as described in any one of claims 1 to 8.

Images