A multi-strategy progressive automatic diagnosis and iterative repair method and system for solving failure of CFD agent
Patent Information
- Application Number
- CN202611092716.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-22
- Publication Date
- 2026-10-13
AI Technical Summary
[0006]本发明要解决的技术问题是:现有CFD求解失败处理方法依赖人工经验、效率低下,而基于大语言模型的智能体方法缺乏数值稳定性硬约束校验、渐进式修复策略、修复振荡检测和历史知识复用机制,容易出现修复方案违反物理约束、修复过程反复振荡或重复诊断已知错误的问题
[0060]1.本发明将CFD工程师的求解失败诊断经验系统化为结构化流程,从错误日志中自动识别失败类型,结合专业规则库检索修复策略,显著降低了对工程师调参经验的依赖。
Smart Images

Figure CN122904780A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the fields of computational fluid dynamics and artificial intelligence, specifically relating to a multi-strategy progressive automatic diagnosis and iterative repair method for solution failures of CFD agents. Background Technology
[0002] In CFD (Computational Fluid Dynamics) simulation, the rationality of the solver parameter configuration directly determines whether the calculation can converge stably. In engineering practice, CFD solution failure is a high-frequency problem, mainly manifested in the following typical situations: (1) The CFL number is too large, resulting in numerical overflow and the flow field variables exceeding the physical range; (2) The flux scheme is not matched with the flow conditions, such as using the center scheme in transonic flow with shock waves, which makes it impossible to capture the shock waves; (3) The turbulence model and boundary condition configuration are inconsistent, such as selecting an inviscid model but not turning off the turbulence equation; (4) The multigrid parameters are not properly configured, and the coarse grid CFL ratio is too high, resulting in coarse level divergence; (5) The boundary condition type is not matched with the solution variables.
[0003] Current methods for handling CFD solution failures primarily rely on manual diagnosis by engineers. Engineers determine the cause of failure by analyzing residual curves, checking log error messages, and comparing flow field distributions, then gradually adjust parameters based on their personal experience. This approach is inefficient, time-consuming, highly dependent on experience, and different engineers may have significantly different parameter tuning strategies.
[0004] In recent years, large language models have been introduced into CFD agents to assist in parameter configuration and error diagnosis. However, large language models have the following shortcomings when generating repair schemes: (1) They lack deterministic checks on hard constraints of CFD numerical stability, which may generate parameters that violate CFL stability conditions; (2) They lack progressive repair strategies, which may involve large-scale parameter modifications during the first repair, introducing new instabilities; (3) They lack a repair oscillation detection mechanism, which may lead to repeated switching on the same parameters, forming a repair dead loop; (4) They lack a mechanism for accumulating and reusing historical repair experience, which requires re-diagnosis for recurring error types each time.
[0005] Therefore, there is a need for an automated diagnosis and iterative repair method that can systematize CFD domain knowledge, numerical stability constraints, and historical repair experience, so that when CFD agents face solution failures, they can automatically complete the diagnosis and repair according to the incremental parameter tuning approach in engineering practice. Summary of the Invention
[0006] The technical problem to be solved by this invention is that existing CFD solution failure handling methods rely on human experience and are inefficient, while intelligent agent methods based on large language models lack numerical stability hard constraint verification, progressive repair strategies, repair oscillation detection and historical knowledge reuse mechanisms, which easily lead to problems such as repair schemes violating physical constraints, repeated oscillations during the repair process, or repeated diagnosis of known errors.
[0007] To address the aforementioned technical problems, this invention proposes a multi-strategy progressive automatic diagnosis and iterative repair method for CFD agents to address solution failures. After the CFD solver returns a failure signal, this method automatically collects the solution context, extracts error signatures from the log, retrieves matching repair strategies from the historical repair library and parameter constraint rule library, generates a structured repair plan from the diagnostic decision model, progressively escalates the repair range from the smallest parameter perturbation according to the progressive strategy, performs numerical stability hard constraint verification on the repair plan, detects oscillations in the repair parameters and applies monotonic constraints, and writes the experience into the knowledge base after successful repair to achieve knowledge self-evolution.
[0008] The technical solution adopted by the present invention to solve the above-mentioned technical problems is as follows:
[0009] A multi-strategy progressive automatic diagnosis and iterative repair method for solution failures in CFD agents includes the following steps:
[0010] S1. Automatic collection of solution failure context
[0011] When the CFD solver returns a non-zero exit code or times out, the error information at the end of the solver's runtime log is automatically extracted, the complete contents of the current solver parameter configuration file and boundary condition configuration file are read, and the iteration steps and solver return code at the time of failure are recorded to form a structured solution failure context.
[0012] S2. Error signature extraction and historical repair database matching
[0013] Error feature codes are extracted from the solver log according to a predefined CFD error feature keyword pattern. These error feature codes represent the type of CFD solution failure. Historical repair solutions that match the current error feature code are retrieved from the historical repair knowledge base. If a historical solution with a high success rate exists, it is reused first.
[0014] S3, CFD parameter repair rule retrieval
[0015] The search tags are dynamically expanded based on the keywords in the error log. The parameter repair strategies that match the current error are retrieved from the repair class rules of the CFD parameter constraint rule base, including numerical stability repair rules, flux format switching rules, turbulence model repair rules and boundary condition repair rules. At the same time, the list of numerical stability hard constraints that must be followed is obtained.
[0016] S4. Solving Failure Diagnosis and Structured Repair Scheme Generation
[0017] The solution failure context, repair rule context, and hard constraint list are input into the diagnostic decision model, which outputs a structured repair scheme, including failure cause diagnosis, repair target parameters, and target values.
[0018] S5, Gradual Repair and Upgrade Strategy Execution
[0019] The repair level is determined based on the current repair round. The first level is minimum parameter perturbation, the second level is related parameter adjustment, and the third level is solution strategy reconstruction. The scope of modification of the diagnostic decision model is limited to the parameter set allowed at the current level.
[0020] S6. Implementation of Repair Plan and Verification of Hard Constraints
[0021] The parameters in the repair plan are modified and written into the configuration file. The hard constraints on numerical stability are verified one by one. If there are parameters that violate the hard constraints, the violating parameters are automatically rolled back to the safe values specified by the hard constraints.
[0022] S7, Repair anti-oscillation detection
[0023] The current repair plan is compared with the previous repair history to detect whether there is an oscillation pattern in which a certain parameter repeatedly switches between two values; if oscillation is detected, the current repair plan is skipped, the repair level is upgraded, or a monotonic constraint is applied to the oscillation parameter to break out of the oscillation cycle.
[0024] S8. Re-solution and Iteration Judgment
[0025] Clean up the intermediate result files from the previous round and re-execute the CFD solver with the modified configuration; if the residuals converge to the target accuracy and the force coefficients are stable, the solution is considered successful and the iteration is terminated; if the solution still fails and the maximum repair round has not been reached, return to step S1; if the maximum repair round has been reached, terminate and retain all diagnostic repair logs for engineers to review.
[0026] S9, Expanding the rule base
[0027] When a repair is successful, the error signature, repair solution, and operating parameters are written into the historical repair rules and knowledge base as new repair experience. The cumulative success rate statistics of the error signature are updated so that the successful solution can be directly reused when the same type of solution fails in the future.
[0028] Preferably, in step S1, the solution failure context includes: a failure stage identifier, N lines of text at the end of the solver log, the complete content of the current parameter configuration file, the content of the current boundary condition configuration file, mesh file metadata, and the solver return code.
[0029] Preferably, in step S2, the method for extracting the error feature code is as follows: matching predefined CFD feature error patterns from the solver log, the patterns including numerical overflow, convergence stall, solver crash, and boundary condition error; the error feature code contains an error type identifier and a set of feature keywords.
[0030] Preferably, in step S2, the historical repair database matching uses the Jaccard similarity of error signatures for retrieval, and the retrieval formula is:
[0031] (1)
[0032] in, This is the current error signature. The error signature of the k-th record in the historical repair database; and These are the feature keyword sets for both sets, including error type identifiers, solver error keywords, and operating condition range labels; ∩ represents the intersection of the sets, and ∪ represents the union of the sets. The closer to 1, the more applicable the historical repair experience is to the current error; historical repair solutions that match the current error's feature code are retrieved from the historical repair knowledge base, and those with the highest similarity and a success rate exceeding the confidence threshold are reused first.
[0033] Preferably, in step S4, the error complexity score is used to assist in diagnostic decision-making and determine the initial level of the repair strategy. The calculation formula for the diagnostic decision-making model is as follows:
[0034] (2)
[0035] in, Score the error complexity; The base score is based on the error type: 1 point for numerical overflow, 2 points for convergence stagnation, and 3 points for solver crash. This is the normalized value of the frequency of occurrence of the error signature in the historical repair database; The number of cascaded layers of parameters involved in the error; , , Let be the weighting coefficient, satisfying + + =1, The higher the value, the more complex the error, and the higher the initial repair level may be.
[0036] Preferably, in the progressive repair strategy of step S5, the repair level is automatically upgraded with each iteration round, and the formula for determining the level of the progressive repair upgrade strategy is:
[0037] (3)
[0038] Where L(n) is the level of the nth round of repair, and n is the current repair round, which increases from 1. The number of duration rounds for each level, for example =2 means that each level will automatically upgrade after lasting 2 rounds; The maximum repair level is usually set to 3; the first level is the minimum parameter perturbation, which only allows modification of the CFL value and relaxation factor; the second level is the correlation parameter adjustment, which allows changing the flux scheme and limiter; the third level is the solution strategy reconstruction, which allows changing the turbulence model and reconstructing the solution strategy.
[0039] Preferably, in step S6, the numerical stability hard constraint verification includes at least the CFL stability constraint:
[0040] (4)
[0041] Where u is the local characteristic velocity or maximum wave velocity. For time step, For grid feature scale, This represents the upper limit of stability determined jointly by the time-progression scheme, the spatial discretization scheme, and the safety margin; in the Runge-Kutta time-progression scheme, The value is usually no more than 2.0, and the safety value for engineering projects is generally taken as 1.0 to 1.5.
[0042] The numerical stability hard constraint verification also includes CFL growth flag constraint, transonic entropy correction switch constraint, and turbulence model and viscous flux consistency constraint.
[0043] Preferably, in step S7, the oscillation detection method is:
[0044] (5)
[0045] Where Osc(p, H) indicates whether parameter p oscillates in the repair history H; τ represents the change in parameter p during the i-th round of repair; τ is the oscillation judgment threshold, usually taken as 2; when the number of alternating flips of the parameter change direction in adjacent rounds reaches τ, it is determined that the parameter has oscillation, and it is locked to the current value or subjected to monotonic constraints in subsequent repairs.
[0046] Preferably, in step S9, the success rate statistical formula for the expansion and repair rules and the knowledge base is as follows:
[0047] (6)
[0048] Where SR(f) is the cumulative success rate of the error signature f; This represents the cumulative number of successful fingerprint repairs. The cumulative number of repair attempts (cumulative number of fingerprint repair attempts); when SR(f) exceeds the confidence threshold, the historical best solution is directly reused, skipping the large language model diagnosis stage.
[0049] A multi-strategy progressive automatic diagnosis and iterative repair system for solution failures in CFD agents includes:
[0050] The solver monitoring module is used to monitor the execution status of the CFD solver and trigger a diagnostic process when a failure occurs.
[0051] The error context acquisition module is used to extract structured failure information from solver logs and configuration files;
[0052] The error signature extraction and matching module is used to extract error features and search for existing solutions in the historical repair database.
[0053] The repair rule retrieval module is used to retrieve a list of matching repair strategies and hard constraints from the rule base;
[0054] The diagnostic decision module is used to generate structured repair solutions based on context and rules;
[0055] The progressive repair upgrade module is used to control the automatic upgrade of repair levels;
[0056] The hard constraint verification module is used to perform numerical stability constraint checks and safety rollbacks on the repair scheme;
[0057] An oscillation detection module is used to detect and process parameters to repair oscillations.
[0058] The knowledge evolution module is used to write successful repair experiences into the historical knowledge base.
[0059] The beneficial effects of this invention are as follows:
[0060] 1. This invention systematizes the CFD engineer's experience in diagnosing solution failures into a structured process, automatically identifies failure types from error logs, and combines professional rule bases to retrieve repair strategies, significantly reducing the reliance on the engineer's experience in parameter tuning.
[0061] 2. The incremental repair strategy of this invention follows the engineering practice of CFD parameter tuning, and gradually upgrades from the smallest changes, avoiding the risk of introducing new problems by making a large-scale modification at once.
[0062] 3. The hard constraint forced verification mechanism of this invention ensures that the repair scheme itself will not violate the numerical stability condition.
[0063] 4. The anti-oscillation detection mechanism of this invention solves the dead loop problem of repeated parameter switching in iterative repair.
[0064] 5. The self-evolutionary knowledge repair mechanism of this invention allows the system to accumulate experience as it is used, and successful solutions can be directly reused for known error types.
[0065] 6. This invention is particularly suitable for aerospace aerodynamic simulation, airfoil / wing / aircraft flow simulation, engine internal flow simulation, and other CFD applications that require high robustness of solutions. It can serve as a core module for automatic solution failure repair in CFD intelligent systems. Attached Figure Description
[0066] Figure 1 This is the overall flowchart of the CFD solution failure automatic diagnosis and iterative repair method described in this invention. Detailed Implementation
[0067] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. After reading the present invention, any modifications of the present invention in various equivalent forms by those skilled in the art will fall within the scope defined by the appended claims.
[0068] Specific Implementation Method 1: A multi-strategy progressive automatic diagnosis and iterative repair method for solution failures in CFD agents, such as... Figure 1 As shown, it includes the following steps:
[0069] S1. Automatic Acquisition of Solution Failure Context: When the CFD solver returns a non-zero exit code or times out, the system automatically triggers a diagnostic process. The collected information includes: the last N lines of text in the solver's runtime log (typically N=100 to 500), the complete content of the current solver parameter configuration file (e.g., parameter.xml), the content of the boundary condition configuration file (e.g., boundary.xml), mesh file metadata (number of nodes, number of elements, dimensions), the solver return code, and the number of iterations at the time of failure. This information constitutes a structured solution failure context.
[0070] S2. Error Feature Code Extraction and Historical Repair Database Matching: Error feature codes are extracted from the solver log according to predefined CFD error feature keyword patterns. The keyword patterns include: numerical overflow (matching variable is error, NaN detected, beyond maxvalue, etc.), convergence stall (matching convergence stalled, residual plateau, etc.), solver crash (matching segmentation fault, memory overflow, solver crashed, etc.), and boundary condition error (matching boundary mismatch, inlet / outlet conflict, etc.). The extracted error feature codes contain error type identifiers and feature keyword sets. Then, matching records are retrieved from the historical repair database according to formula (1). If there is a historical solution with a success rate SR(f) higher than the confidence threshold, it is reused first.
[0071] S3. CFD Parameter Repair Rule Retrieval. Based on keywords in the error log, the search tags are dynamically expanded to retrieve parameter repair strategies matching the current error from the repair rules in the CFD parameter constraint rule base. Repair rules in the rule base include: numerical stability repair rules (e.g., reducing CFL to 50% of its current value when it is too high), flux scheme switching rules (e.g., switching to Roe or AUSM upwind scheme when the central scheme diverges), turbulence model repair rules (e.g., trying the SST model when the SA model does not converge), boundary condition repair rules (e.g., changing the pressure outlet to the mass flow outlet), and multigrid repair rules (e.g., reducing the number of coarse grid layers or lowering the coarse grid CFL ratio). A list of mandatory numerical stability constraints is also retrieved during the search.
[0072] S4. Solution Failure Diagnosis and Structured Repair Scheme Generation. The solution failure context, repair rule context, and hard constraint list are input into the diagnostic decision model. The diagnostic decision model can be a large language model, whose input prompts include structured error information, retrieved repair strategies, and a list of hard constraints; its output is a structured repair scheme in JSON format, containing a textual description of the diagnostic cause, the target file type (parameter or boundary), the specific parameter label names and target values for repair, and a repair confidence score.
[0073] S5. Implementation of the incremental repair and upgrade strategy. The current repair level L(n) is determined according to formula (3). The first level is minimal parameter perturbation: only the CFL value can be modified (reduced by 20% to 50%), the relaxation factor can be adjusted, or the convergence accuracy can be modified, without changing the flux format and turbulence model; the second level is related parameter adjustment: the flux format can be changed (e.g., from CENTRAL to ROE), the limiter can be changed (e.g., from VENKATAKRISHNAN to NONE_LIMITER), the number of multigrid layers can be adjusted, and the related parameters can be modified synchronously along the constraint propagation graph; the third level is solution strategy reconstruction: the turbulence model can be changed, the boundary condition type can be modified, and the accelerated convergence strategy can be reconstructed. The scope of modification of the diagnostic decision model is limited to the parameter set allowed at the current level.
[0074] S6. Execution of the Repair Scheme and Verification of Hard Constraints. The system parses the parameter tag name and target value of each modification instruction in the repair scheme, locates the corresponding tag node in the configuration file, and replaces the content with the target value. After the replacement is completed, the hard constraint rules are verified one by one, including at least the CFL stability constraint of formula (4), variableFlag equal to 0 (prohibiting CFL adaptive growth), entropyFixFlag equal to 1 under transonic conditions, and consistency between the turbulence model and the viscous flux opening and closing. If there are parameters in the repair scheme that violate the hard constraints, the violating parameters will be automatically rolled back to the safe value specified by the hard constraints.
[0075] S7. Repairing anti-oscillation detection. The system maintains a parameter modification history stack, recording the parameter label name modified in each round of repair and its values before and after modification. Check whether each parameter has oscillation according to formula (5). If oscillation is detected, lock the parameter (keep the current value unchanged) or apply a monotonic constraint (allow only monotonic adjustment in one direction), and automatically upgrade the repair level, forcing the diagnostic decision model to find repair solutions in other parameter dimensions.
[0076] S8. Re-solution and Iteration Judgment. Clean up the intermediate result files and residual records from the previous round, and re-execute the CFD solver with the modified configuration. If the residuals converge to the target accuracy and the force coefficients (such as lift coefficients and drag coefficients) remain stable in the last few steps, the solution is considered successful, and the iteration is terminated. If the solution still fails and the current round n has not reached the maximum repair round Nmax, return to step S1 to continue collecting new failure contexts. If Nmax has been reached, terminate the repair and retain all diagnostic repair logs for engineer review.
[0077] S9. Expanding the rule base. After a successful repair, the system writes the current error signature, repair solution, and operating condition parameters (Mach number, Reynolds number, angle of attack, turbulence model, mesh scale) as new repair experience into the historical repair knowledge base. The cumulative success rate statistic for this error signature is updated according to Equation (6). When the success rate exceeds the confidence threshold (e.g., 80%), when the same type of solution failure is encountered subsequently, the system can directly reuse the historical optimal repair solution without invoking the large language model for re-diagnosis, reducing the typical repair time from the minute level to the second level. Second specific implementation mode:
[0079] Taking the FeiLian CFD solver as an example, the simulation case is transonic flow around the RAE2822 airfoil, with a incoming flow Mach number Ma=0.729, Reynolds number Re=6.5×10^6, angle of attack 2.31°, and the Spalart-Allmaras turbulence model is selected.
[0080] Scenario 1: Numerical overflow caused by excessive CFL. In the initial configuration, CFL=2.5 (exceeding the stability safety margin of RK4), and the flux scheme is ROE. The solver reports an error at the 15th step: variable is error at cell 23456, and the return code is non-zero. The system automatically collects the context and extracts the error signature as the numerical overflow type. No matching record is found in the historical repair base. The rule retrieval hits the repair rule: when numerical overflow occurs, reduce the CFL to 50% of the current value, with a hard constraint that the CFL shall not exceed 1.5. The repair level of the first round L(1)=1, only adjusting the CFL from 2.5 to 1.25. Hard constraint check: CFL=1.25 < CFLmax=1.5, passed. Re-solve: 3000 steps converge to a residual of 1e-7, CL=0.803, CD=0.0168, and the repair is successful. Knowledge evolution: write the repair record.
[0081] Scenario 2: Continuous divergence caused by improper flux scheme. Initial configuration: CFL=1.25, flux scheme is CENTRAL (the central scheme lacks shock capturing capability in transonic flow). First round of repair (level 1): reduce the CFL to 0.6, but divergence still occurs at the 80th step. Second round of repair (level 1): CFL=0.6 is low enough, the first-level repair is invalid, and the level is automatically upgraded to level 2. Third round of repair (level 2): rule retrieval suggests replacing with an upwind scheme for transonic flow. The diagnostic decision model suggests changing CENTRAL to ROE, and synchronously enabling entropyFixFlag=1 along the constraint propagation graph. Re-solving is successful. Knowledge evolution writing: the fingerprint of beyondmaxvalue + CENTRAL scheme, the repair is to switch to ROE + enable entropy correction.
[0082] Scenario 3: Repairing Oscillation Detection. Initial CFL = 2.0, in the first round it decreases to 1.0 (still diverging), in the second round it increases to 1.5 (still diverging), and in the third round it decreases to 0.8 (still diverging). Parameter modification direction: decrease, increase, decrease, the number of alternating direction reversals = 2 ≥ τ = 2, triggering oscillation detection. CFL is locked at 0.8, the repair level is upgraded to level two, and the diagnostic decision model is forced to search for repair solutions on parameters such as flux format and multigrid.
[0083] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Those skilled in the art can make various improvements, substitutions, or combinations to the above embodiments without departing from the concept of the present invention, and all such improvements, substitutions, or combinations should fall within the protection scope of the present invention.
Claims
1. A multi-strategy progressive automatic diagnosis and iterative repair method for solution failures in CFD agents, characterized in that, Includes the following steps: S1. Automatic collection of solution failure context When the CFD solver returns a non-zero exit code or times out, the error information at the end of the solver's runtime log is automatically extracted, the complete contents of the current solver parameter configuration file and boundary condition configuration file are read, and the iteration steps and solver return code at the time of failure are recorded to form a structured solution failure context. S2. Error signature extraction and historical repair database matching Error feature codes are extracted from the solver log according to a predefined CFD error feature keyword pattern. These error feature codes represent the type of CFD solution failure. Historical repair solutions that match the current error feature code are retrieved from the historical repair knowledge base. If a historical solution with a high success rate exists, it is reused first. S3, CFD parameter repair rule retrieval The search tags are dynamically expanded based on the keywords in the error log. The parameter repair strategies that match the current error are retrieved from the repair class rules of the CFD parameter constraint rule base, including numerical stability repair rules, flux format switching rules, turbulence model repair rules and boundary condition repair rules. At the same time, the list of numerical stability hard constraints that must be followed is obtained. S4. Solving Failure Diagnosis and Structured Repair Scheme Generation The solution failure context, repair rule context, and hard constraint list are input into the diagnostic decision model, which outputs a structured repair scheme, including failure cause diagnosis, repair target parameters, and target values. S5, Gradual Repair and Upgrade Strategy Execution The repair level is determined based on the current repair round. The first level is minimum parameter perturbation, the second level is related parameter adjustment, and the third level is solution strategy reconstruction. The scope of modification of the diagnostic decision model is limited to the parameter set allowed at the current level. S6. Implementation of Repair Plan and Verification of Hard Constraints The parameters in the repair plan are modified and written into the configuration file. The hard constraints on numerical stability are verified one by one. If there are parameters that violate the hard constraints, the violating parameters are automatically rolled back to the safe values specified by the hard constraints. S7, Repair anti-oscillation detection Compare the current repair plan with the previous repair history to detect whether there is an oscillation pattern in which a certain parameter repeatedly switches between two values; If an oscillation is detected, skip the current repair plan, upgrade the repair level, or apply a monotonic constraint to the oscillation parameters to break out of the oscillation cycle; S8. Re-solution and Iteration Judgment Clean up the intermediate result files from the previous round and re-execute the CFD solver with the modified configuration; if the residuals converge to the target accuracy and the force coefficients are stable, the solution is considered successful and the iteration is terminated; if the solution still fails and the maximum repair round has not been reached, return to step S1; if the maximum repair round has been reached, terminate and retain all diagnostic repair logs for engineers to review. S9, Expanding the rule base When a repair is successful, the error signature, repair solution, and operating parameters are written into the historical repair rules and knowledge base as new repair experience. The cumulative success rate statistics of the error signature are updated so that the successful solution can be directly reused when the same type of solution fails in the future.
2. The method for progressive automatic diagnosis and iterative repair of solution failures for CFD agents according to claim 1, characterized in that: In step S1, the solution failure context includes: failure stage identifier, N lines of text at the end of the solver log, the complete content of the current parameter configuration file, the content of the current boundary condition configuration file, mesh file metadata, and solver return code.
3. The method for progressive automatic diagnosis and iterative repair of solution failures for CFD agents according to claim 1, characterized in that: In step S2, the method for extracting the error feature code is as follows: matching predefined CFD feature error patterns from the solver log, the patterns including numerical overflow, convergence stagnation, solver crash, and boundary condition error; the error feature code contains an error type identifier and a set of feature keywords.
4. The method for progressive automatic diagnosis and iterative repair of solution failures for CFD agents according to claim 1, characterized in that: In step S2, the historical repair database matching uses the Jaccard similarity of error signatures for retrieval, and the retrieval formula is as follows: (1) in, This is the current error signature. The error signature of the k-th record in the historical repair database; and These are the feature keyword sets for both; historical solutions with the highest similarity and a success rate exceeding the confidence threshold are reused first.
5. The method for progressive automatic diagnosis and iterative repair of solution failures for CFD agents according to claim 1, characterized in that: In step S4, the error complexity score is used to assist in diagnostic decision-making, and the calculation formula is as follows: (2) in, Score the error complexity; The base score is based on the error type; This is the normalized value of the frequency of occurrence of the error signature in the historical repair database; The number of cascaded layers of parameters involved in the error; , , These are the weighting coefficients.
6. The method for progressive automatic diagnosis and iterative repair of solution failures for CFD agents according to claim 1, characterized in that: In step S5, the formula for determining the level of the progressive repair and upgrade strategy is as follows: (3) Where L(n) represents the level of the nth round of repair; The number of duration rounds for each level; The maximum repair level is defined as follows: Level 1 only allows modification of CFL values and relaxation factors; Level 2 allows changing flux schemes and limiters; and Level 3 allows changing turbulence models and reconstructing solution strategies.
7. The method for progressive automatic diagnosis and iterative repair of solution failures for CFD agents according to claim 1, characterized in that: In step S6, the numerical stability hard constraint verification includes at least the CFL stability constraint: (4) Where u is the local characteristic velocity. For time step, For grid feature scale, This represents the upper limit of stability.
8. The multi-strategy progressive automatic diagnosis and iterative repair method for solution failure of a CFD agent according to claim 1, characterized in that: In step S7, the oscillation detection method is as follows: (5) Where Osc(p, H) indicates whether parameter p oscillates in the repair history H; τ represents the change in parameter p during the i-th round of repair; τ is the oscillation judgment threshold; the oscillation parameter is locked to its current value or subjected to monotonic constraints in subsequent repairs.
9. The method for progressive automatic diagnosis and iterative repair of solution failures for CFD agents according to claim 1, characterized in that: In step S9, the success rate statistical formula for the expansion and repair rules and the knowledge base is as follows: (6) Where SR(f) is the cumulative success rate of the error signature f; This is the cumulative number of successful repairs; The cumulative number of repair attempts is used; when SR(f) exceeds the confidence threshold, the historical best solution is directly reused.
10. A multi-strategy progressive automatic diagnosis and iterative repair system for solution failures in CFD agents, characterized in that, include: The solver monitoring module is used to monitor the execution status of the CFD solver and trigger a diagnostic process when a failure occurs. The error context acquisition module is used to extract structured failure information from solver logs and configuration files; The error signature extraction and matching module is used to extract error features and search for existing solutions in the historical repair database. The repair rule retrieval module is used to retrieve a list of matching repair strategies and hard constraints from the rule base; The diagnostic decision module is used to generate structured repair solutions based on context and rules; The progressive repair upgrade module is used to control the automatic upgrade of repair levels; The hard constraint verification module is used to perform numerical stability constraint checks and safety rollbacks on the repair scheme; An oscillation detection module is used to detect and process parameters to repair oscillations. The knowledge evolution module is used to write successful repair experiences into the historical knowledge base.