Intelligent simulation system and method

Abstract

This application relates to an intelligent simulation system and method. The intelligent simulation system includes at least: a simulation configuration specification generation system for generating a simulation configuration specification based on user-input simulation tasks; the simulation configuration specification describes simulation configuration information; a simulation task resource inference system for inferring the computational resources required to execute the simulation task based on the simulation configuration specification; a simulation orchestration system for determining a target solver from multiple solvers based on the simulation configuration specification, so that the target solver executes the simulation task based on the computational resources; and a simulation fault repair system for generating repair instructions and a diagnostic report when the target solver fails to simulate. Through multi-system collaborative coupling, the intelligent simulation system enables users to trigger the simulation workflow through natural language interaction, achieving end-to-end automation from mesh generation to solution analysis. This significantly reduces the user's familiarity with the underlying software operations and enables standardized delivery of simulation expert engineering capabilities.

Description

Technical Field

[0001] This application relates to the field of simulation technology, and in particular to intelligent simulation systems and methods. Background Technology

[0002] In traditional industrial product design and verification processes, simulation software plays a crucial role. However, traditional simulation software delivery models have limitations: software vendors deliver merely a standalone tool, rather than directly usable engineering capabilities. Specifically, in traditional delivery models, users must possess a foundation in simulation theory and spend weeks or even months on specialized training to become proficient in using the tool to complete simulation tasks. This learning curve is steep and heavily reliant on experience; users must understand their product design goals while also mastering the tool's operation and underlying logic. When design changes or problems become complex, users still need to repeatedly experiment and manually interpret the results, making automation and intelligentization of the simulation process difficult. In conclusion, traditional simulation software delivers a tool requiring secondary learning and professional interpretation, rather than directly applicable design assistance and verification capabilities.

[0003] Therefore, how to propose a new tool delivery model to directly deliver experts' simulation engineering capabilities to users has become an urgent technical problem to be solved. Summary of the Invention

[0004] To address or partially address the problems existing in related technologies, this application provides an intelligent simulation system and method. Through the collaborative coupling of multiple systems, users can trigger simulation workflows through natural language interaction, transforming abstract simulation tasks into specific physical logic and numerical expressions. This achieves full-link automation from mesh generation to solution analysis, significantly reducing the user's familiarity with the underlying software operation, and realizing the standardized delivery of simulation expert engineering capabilities. While simplifying the simulation process, it greatly shortens the learning cycle and promotes the evolution of simulation software delivery models from "tool delivery" to "capability delivery".

[0005] The first aspect of this application provides an intelligent simulation system that integrates multiple solvers. The intelligent simulation system includes at least: a simulation configuration specification generation system, a simulation task resource inference system, a simulation orchestration system, and a simulation fault repair system, wherein: The simulation configuration specification generation system is used to generate simulation configuration specifications based on user-input simulation tasks; the simulation configuration specifications are used to describe simulation configuration information. The simulation task resource inference system is used to infer the computing resources required to execute the simulation task based on the simulation configuration specification. The simulation orchestration system is used to determine a target solver from the multiple solvers based on the simulation configuration specification, so that the target solver executes the simulation task based on the computing resources; The simulation fault repair system is used to generate repair instructions and a diagnostic report when the target solver simulation fails; the repair instructions are used to adjust the simulation configuration information in the simulation configuration specification so that the target solver can re-execute the simulation task.

[0006] A second aspect of this application provides an intelligent simulation method applied to an intelligent simulation system. The intelligent simulation system integrates multiple solvers and includes at least: a simulation configuration specification generation system, a simulation task resource inference system, a simulation orchestration system, and a simulation fault repair system. The method includes: The simulation task based on user input generates a simulation configuration specification through the simulation configuration specification generation system; the simulation configuration specification is used to describe simulation configuration information. Based on the simulation configuration specification, the simulation task resource inference system infers the computing resources required to execute the simulation task. Based on the simulation configuration specification, the target solver is determined from the multiple solvers by the simulation orchestration system, so that the target solver executes the simulation task based on the computing resources; When the target solver simulation fails, the simulation fault repair system generates repair instructions and a diagnostic report; the repair instructions are used to adjust the simulation configuration information in the simulation configuration specification so that the target solver can re-execute the simulation task.

[0007] The technical solution provided in this application can include the following beneficial effects: The simulation configuration specification generation system can generate simulation configuration specification objects independent of the solver, facilitating the expansion of multi-solver backends and improving the portability of simulation configuration generation; the simulation task resource inference system can directly infer computational resources based on the simulation configuration specification, improving the accuracy of resource inference, thereby increasing the rationality of resource requests and reducing job submission failure rates; the simulation orchestration system can achieve cross-solver reuse of the same working condition physical semantics, eliminating the need to repeatedly develop instructions and configuration logic for each solver, achieving unified orchestration and seamless switching among multiple solvers; and the simulation fault repair system automatically diagnoses and repairs simulation faults, improving the efficiency of simulation fault repair. Through multi-system collaborative coupling, users can trigger simulation workflows through natural language interaction, transforming abstract simulation tasks into concrete physical logic and numerical expressions. This achieves end-to-end automation from mesh generation to solution analysis, significantly reducing the user's familiarity with the underlying software operation, and realizing the standardized delivery of simulation expert engineering capabilities. While simplifying the simulation process, it greatly shortens the learning cycle and promotes the evolution of simulation software delivery models from "tool delivery" to "capability delivery".

[0008] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0009] The above and other objects, features and advantages of this application will become more apparent from the more detailed description of exemplary embodiments thereof in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments thereof.

[0010] Figure 1 This is a schematic diagram of the structure of the intelligent simulation system shown in the embodiments of this application; Figure 2 This is a flowchart illustrating the intelligent simulation method shown in the embodiments of this application. Detailed Implementation

[0011] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While embodiments of this application are shown in the drawings, it should be understood that this application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to make this application more thorough and complete, and to fully convey the scope of this application to those skilled in the art.

[0012] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used in this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any or all possible combinations of one or more of the associated listed items.

[0013] It should be understood that although the terms "first," "second," "third," etc., may be used in this application to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0014] In traditional industrial product design and verification processes, simulation software plays a crucial role. However, traditional simulation software delivery models have limitations: software vendors deliver merely a standalone tool, rather than directly usable engineering capabilities. Specifically, in traditional delivery models, users must possess a foundation in simulation theory and spend weeks or even months on specialized training to become proficient in using the tool to complete simulation tasks. This learning curve is steep and heavily reliant on experience; users must understand their product design goals while also mastering the tool's operation and underlying logic. When design changes or problems become complex, users still need to repeatedly experiment and manually interpret the results, making automation and intelligentization of the simulation process difficult. In conclusion, traditional simulation software delivers a tool requiring secondary learning and professional interpretation, rather than directly applicable design assistance and verification capabilities.

[0015] Therefore, how to propose a new tool delivery model to directly deliver experts' simulation engineering capabilities to users has become an urgent technical problem to be solved.

[0016] To address the aforementioned issues, this application provides an intelligent simulation system. Through multi-system collaborative coupling, users can trigger simulation workflows via natural language interaction, transforming abstract simulation tasks into concrete physical logic and numerical expressions. This achieves end-to-end automation from mesh generation to solution analysis, significantly reducing the user's familiarity with underlying software operations. It also enables standardized delivery of simulation expert engineering capabilities, simplifying the simulation process while greatly shortening the learning cycle, and promoting the evolution of simulation software delivery models from "tool delivery" to "capability delivery."

[0017] The technical solutions of the embodiments of this application are described in detail below with reference to the accompanying drawings.

[0018] Figure 1 This is a schematic diagram of the structure of the intelligent simulation system shown in the embodiments of this application.

[0019] See Figure 1 The intelligent simulation system 100 integrates multiple solvers and includes at least: a simulation configuration specification generation system 110, a simulation task resource inference system 120, a simulation orchestration system 130, and a simulation fault repair system 140, wherein: The simulation configuration specification generation system 110 is used to generate simulation configuration specifications based on user-input simulation tasks; the simulation configuration specification is used to describe simulation configuration information.

[0020] The intelligent simulation system 100 provided in this application embodiment is a simulation agent, driven collaboratively by five specialized agents: mesh analysis, configuration generation, verification, simulation solving, and reporting. It can be understood as a "digital simulation engineer," integrating solvers for multiple physical domains, including: a simulation configuration specification generation system 110, a simulation task resource inference system 120, a simulation orchestration system 130, and a simulation fault repair system 140. The physical domains of the solvers can include fluid, solid, fluid-structure interaction, thermal-structural interaction, electromagnetic-thermal fields, etc. In practical applications, the intelligent simulation system 100 is equipped with a user interface that allows interaction with the user. The user can input simulation tasks in natural language through the user interface, such as: "Simulate the external flow field of this car." Based on the user-input simulation task, the simulation configuration specification generation system 110 can perform intent parsing and other processing on the simulation task, generating a unified, structured simulation configuration specification SolverSpec. Simultaneously, it can write physical constraint verification and alignment-related data into the SolverSpec to ensure the auditability of the output simulation configuration specification. SolverSpec can be stored in JSON (a lightweight data exchange format), YAML (a format for expressing data serialization), or object model format. SolverSpec is a specification used to describe simulation configuration information, and its fields may include, but are not limited to: physical domain identifier field, boundary condition mapping field, material property field, solver control parameter field, mesh context summary field, and verification trace record field. SolverSpec is not directly bound to specific solver syntax, but rather serves as a unified input for subsequent adapter layers.

[0021] In an optional embodiment of this application, the simulation configuration specification generation system 110 includes: The first acquisition module is used to acquire grid metadata and simulation tasks input by the user; The intent parsing module is used to parse the intent of the simulation task and obtain the simulation intent. The alignment module is used to align mesh metadata and simulation intent to obtain at least one candidate simulation region; The target simulation region module is used to determine the target simulation region based on the simulation intent and candidate simulation regions by performing physical constraint verification. The specification generation module is used to generate structured simulation configuration specifications based on the target simulation region and simulation intent.

[0022] In practice, users can upload the geometric model to be simulated in advance. After uploading the geometric model, the mesh analysis agent can read the geometric model, generate a mesh based on the geometric model, and extract the mesh metadata. The mesh metadata includes semantic metadata such as zone name, zone type, region to which it belongs, adjacency relationship, area or volume, etc. Users can input simulation tasks in natural language through the user interface. The first acquisition module in the simulation configuration specification generation system 110 can acquire the mesh metadata and the simulation tasks input by the user.

[0023] The intent parsing module can parse the intent of a simulation task, identifying the task's operating condition type, solution objective, boundary conditions, material information, and solution control requirements to obtain the simulation intent. The simulation intent is a structured slot table where parameters not explicitly specified by the user (such as turbulence model type, fluid density, reference pressure, etc.) can be marked as parameters to be completed.

[0024] The alignment module aligns the mesh metadata and simulation intent based on the mesh metadata and simulation intent through domain dictionary related names, boundary type constraints, topological relationships, and multi-dimensional mapping, thereby obtaining at least one candidate simulation region.

[0025] The target simulation region module can check the consistency between the boundary of the candidate simulation region and the working conditions in the simulation intent based on the simulation intent, so as to perform physical constraint verification and thus determine the target simulation region.

[0026] The specification generation module assembles the target simulation region and simulation intent to generate a unified, structured simulation configuration specification.

[0027] The alignment module includes: The standardization submodule is used to standardize simulation intents based on the domain dictionary, generating standardized simulation intents. The name similarity submodule is used to calculate name similarity based on standardized simulation intent and mesh metadata, and to determine a preliminary set of candidate simulation regions based on name similarity. The coarse-grained screening submodule is used to perform coarse-grained screening of the preliminary candidate simulation region set based on boundary type constraints and topological relationships to determine the candidate simulation regions; The target simulation region module is specifically used for: If multiple candidate simulation regions pass the physical constraint verification, then for each candidate simulation region, fine-grained screening is performed using boundary type constraints and topological relationships to determine the target simulation region.

[0028] The intelligent simulation system 100 of this application incorporates a three-layer knowledge base: a general knowledge base, a private knowledge base, and a historical case base. The first layer, the general knowledge base, primarily includes general physical rules and fundamental knowledge in the field of Computer-Aided Engineering (CAE), as well as rules and knowledge related to the solver. The second layer is the private knowledge base, which contains user-accumulated experience, such as methods for selecting the appropriate model, setting boundary conditions, choosing the corresponding data type, and specifying numerical values ​​in a particular scenario. The third layer is the historical case base, which contains cases accumulated by the simulation agent during operation and maintenance. The simulation agent can extract rules and experiences from these historical cases using a large model. The general knowledge base may also include domain dictionaries at different levels, containing specialized vocabulary from software within that domain.

[0029] The standardization submodule can utilize a domain dictionary to standardize aliases in the user's natural language within the simulation intent, mapping colloquialisms to specialized vocabulary from the relevant software, thereby generating standardized simulation intents to ensure the subsequent solver functions correctly. In one example, the domain dictionary could be a fluid-specific vocabulary, a structure-specific vocabulary, etc.

[0030] The name similarity submodule calculates name similarity based on the standardized simulation intent and related names in the mesh metadata. Name similarity includes string similarity and semantic vector similarity. A preliminary set of candidate simulation regions is determined based on name similarity.

[0031] Furthermore, the coarse-grained screening submodule also performs coarse-grained screening of the initial candidate simulation region set through boundary type constraints and topological relationships. This initial screening identifies meshes that meet the boundary type constraints and topological relationships, thus obtaining candidate simulation regions. Specifically, boundary type constraints eliminate initial candidate simulation regions that do not meet the constraints, resulting in a set of valid candidate simulation regions. Based on the topological relationships of adjacent meshes in the valid candidate simulation region set, unreasonable options are eliminated, and one or more final, compliant candidate simulation regions are precisely located. In the coarse-grained screening process, boundary type constraints primarily match the types of boundaries, while topological relationships primarily verify the validity of relationships between meshes, filtering out various types of meshes.

[0032] In practical implementation, if multiple candidate simulation regions pass the physical constraint verification, the target simulation region module will perform a secondary decision based on boundary type constraints, topological relationships, and historical operating condition similarity. Specifically: for each candidate simulation region that passes the physical constraint verification, fine-grained screening is performed. First, boundary type constraints are applied based on the operating conditions in the simulation intent. Boundary type constraints act as a veto, eliminating candidate boundary types that conflict with the fundamental physical laws of the operating conditions. Second, candidate simulation regions that pass the boundary type constraints can be further screened based on topological relationships. Topological relationships are a continuous mechanism that scores candidate simulation regions that pass the boundary type constraints based on spatial location connection logic, and then sorts them according to the scores. After fine-grained screening, the target simulation region can be determined. If multiple target simulation regions are selected after fine-grained screening, historical cases with similar features to the simulation intent can be retrieved from the third-layer historical case library, such as geometric similarity or business domain similarity. The operating condition similarity between the simulation intent and the historical cases is calculated, and historical cases with similar operating conditions are selected as references to determine the final target simulation region.

[0033] The simulation task resource inference system 120 is used to calculate the computing resources required to execute the simulation task based on the simulation configuration specification.

[0034] The simulation task resource inference system 120 infers the computing resources required to execute the simulation task based on the simulation configuration specification through the resource inference model, and schedules the corresponding computing resources through the scheduling system. The simulation task resource inference system 120 can be coupled to the scheduling system or independent of the scheduling system.

[0035] In an optional embodiment of this application, the simulation task resource inference system 120 includes: The feature extraction module is used to extract structured features related to the solution cost of the simulation task from the simulation configuration specification; the structured features include at least one of physical semantic features, scale features, and resource constraint features; The resource inference module is used to calculate the resource requirement vector of the simulation task based on various structured features using the resource inference model. The scheduling generation module is used to translate resource requirement vectors into job description files that the scheduling system can recognize, and submit the job description files to the scheduling system so that the scheduling system can schedule the computing resources required to execute simulation tasks based on the job description files.

[0036] The simulation configuration specification SolverSpec contains structured features related to the solution cost of the simulation task. These structured features can include at least one of physical semantic features, scale features, and resource constraint features. Therefore, the feature extraction module can directly extract these structured features from the SolverSpec. Among them, physical semantic features are used to describe the physical meaning, computational accuracy, and solution logic of the simulation task; scale features are used to describe the computational scale of the simulation task; and resource constraint features are used to describe the parallel scale and resource constraints of the simulation task.

[0037] The simulation task resource inference system 120 includes a pre-built resource inference model, which can be a machine learning model or an IF-THEN-based rule model. As a mapping medium, the resource inference model enables spatial transformation from the feature domain to the resource domain. The resource inference module calculates relevant resources using this model. Specifically, the resource inference module can input structured features such as physical semantic features, scale features, and resource constraint features into the resource inference model. Based on these features and utilizing preset rules, the resource inference model calculates the resource requirement vector for the simulation task. These preset rules can be pre-defined mapping empirical rules (such as memory empirical rules, parallel scheduling rules, etc.).

[0038] The scheduling generation module can translate the script syntax of the scheduling system (or the target HPC scheduler) into a job description file that the scheduling system can recognize, and then submit the job description file to the scheduling system.

[0039] The job description file is used to declare computing resources, specify execution commands, and automate task queuing and execution to the HPC cluster scheduling system. It is a necessary file for submitting simulation tasks. Therefore, the scheduling system can schedule the computing resources required to execute simulation tasks in the HPC cluster according to the resource declaration in the job description file.

[0040] Among them, the physical semantic features include at least one of physical domain category, model complexity, time step setting and iteration limit; the scale features include at least one of grid size and grid type; the resource constraint features include parallel constraints; and the resource requirement vector includes at least one of CPU cores, number of nodes, memory capacity, wall clock time, queue type and accelerator requirement. The resource inference module includes: The CPU core count calculation submodule is used to calculate the number of CPU cores required for the simulation task based on the grid size, model complexity, and parallel constraints using a resource inference model; and / or, The node count calculation submodule is used to calculate the number of nodes required for the simulation task based on the mesh size, parallel constraints, and number of CPU cores using a resource inference model; and / or, The memory capacity calculation submodule is used to calculate the memory capacity required for the simulation task based on the mesh size, physical domain type, model complexity, and parallel constraints using a resource inference model; and / or, The wall clock time calculation submodule is used to calculate the wall clock time required for the simulation task based on the time step settings, iteration limit, mesh size, model complexity, mesh type, and parallel constraints using a resource inference model; and / or, The queue type calculation submodule is used to calculate the queue type required for the simulation task based on the wall clock time, CPU cores / nodes, physical domain type, and parallel constraints using a resource inference model; and / or, The accelerator requirement calculation submodule is used to calculate the accelerator requirements of the simulation task based on the physical domain category, model complexity, and parallel constraints using the resource inference model. The job description file includes the main plan; the schedule generation module includes: The job execution constraint parameter acquisition submodule is used to acquire job execution constraint parameters. Job execution constraint parameters include cluster scheduling constraint parameters and execution environment configuration parameters. Cluster scheduling constraint parameters include at least one of cluster resource status, queue scheduling information, and license status. Execution environment configuration parameters include solver path. The fine-tuning submodule is used to fine-tune the main scheme based on various cluster scheduling constraint parameters; The judgment submodule is used to determine whether the execution constraint parameters of each task meet the execution requirements of the fine-tuned main scheme; The first submission submodule is used to submit the fine-tuned main scheme to the scheduling system if the condition is met, so that the scheduling system can schedule the computing resources required to execute the simulation task based on the job description file.

[0041] Physical semantic features can include at least one of the following: physical domain category, model complexity, time step setting, and iteration upper limit. The physical domain category refers to the type of physical problem to be simulated; model complexity refers to the level of detail in the physical model; the time step setting refers to the duration of each step in transient simulation; and the iteration upper limit can cover both steady-state and transient simulations, referring to the maximum number of convergence iterations in steady-state simulations and the upper limit of linear iterations within each time step in transient simulations.

[0042] Scale characteristics may include at least one of mesh size and mesh type. Mesh size refers to the number of mesh cells into which the simulation computational domain is divided, usually measured primarily by the number of cells; mesh type refers to the shape and structure of the mesh.

[0043] Resource constraints can include parallel constraints. Parallel constraints refer to the limitations imposed on simulation tasks during parallel computation, and may include, for example, the maximum number of parallelizable processes, the minimum partition granularity, inter-node communication limits, memory / process binding requirements, and whether multi-node parallelism is supported.

[0044] In addition to physical semantic features, scale features, and resource constraint features, structured features can also include numerical control features. Numerical control features may include, but are not limited to: discrete order, coupled equation algorithms, coupled solution, and residual convergence tolerance.

[0045] The resource requirement vector may include at least one of the following: number of CPU cores, number of nodes, memory capacity, wall clock time, queue type, and accelerator requirements. Specifically, the number of CPU cores refers to the number of physical or logical CPU cores that can be used in parallel during the simulation task's computation; the number of nodes refers to the total number of computing nodes required by the simulation task in the cluster environment; memory capacity refers to the total amount of physical memory required during the simulation task's execution; wall clock time refers to the actual natural time elapsed from the submission and start of the simulation task to the completion of the computation; queue type refers to the category of job queues in the scheduling system based on resource priority, task size, and user permissions; and accelerator requirements refer to whether the simulation task requires hardware accelerators such as GPUs, and their configuration, including the number and memory size.

[0046] The CPU core count calculation submodule uses a resource inference model to calculate the number of CPU cores required for a simulation task based on grid size, model complexity, and parallel constraints.

[0047] The node count calculation submodule can calculate the number of nodes required for the simulation task based on the grid size, parallel constraints, and number of CPU cores using the resource inference model.

[0048] The memory capacity calculation submodule can calculate the memory capacity required for the simulation task based on the grid size, physical domain type, model complexity, and parallel constraints through the resource inference model.

[0049] The wall clock time calculation submodule can calculate the wall clock time required for the simulation task based on the time step setting, iteration limit, grid size, model complexity, grid type and parallel constraints through the resource inference model.

[0050] The queue type calculation submodule uses a resource inference model to calculate the queue type required for the simulation task based on wall clock time, number of CPU cores / nodes, physical domain type, and parallel constraints.

[0051] The accelerator requirement calculation submodule can calculate the accelerator requirements for simulation tasks based on the physical domain category, model complexity, and parallel constraints using the resource inference model.

[0052] It should be noted that the resource inference model does not directly output fixed resource values, but rather outputs the resource demand vectors of the main scheme and the candidate schemes. Therefore, the resource demand vector of the main scheme can be translated into a main scheme that the scheduling system can recognize, and the resource demand vector of the candidate scheme can be translated into a candidate scheme that the scheduling system can recognize. Both the main scheme and the candidate scheme belong to the job description file.

[0053] To further improve the rationality of resource requests, this embodiment of the application can obtain job execution constraint parameters through a job execution constraint parameter acquisition submodule, so as to fine-tune the job description file in conjunction with the job execution constraint parameters. The job execution constraint parameters may include cluster scheduling constraint parameters and execution environment configuration parameters. The cluster scheduling constraint parameters may include at least one of cluster resource status, queue scheduling information, and license status, and the execution environment configuration parameters may include solver paths.

[0054] Among them, cluster resource status is used to characterize the current overall availability of the cluster; queue scheduling information can include user policies and queue policies; queue policies are system-level constraint parameters of the underlying physical resource scheduling system of HPC. User policies serve as a demand boundary pool for resource estimation, and after the resource results are distributed, they will be combined to form queue policies for cluster execution to lock the actual machines; license status is used to characterize the license restrictions of the simulation software, etc.; solver path refers to the path where the simulation execution program is located.

[0055] The fine-tuning submodule can combine cluster resource status, queue priority (belonging to queue policy), license status and user policy to fine-tune the main scheme and obtain the fine-tuned main scheme.

[0056] The decision-making submodule can further refine the adjusted master solution by combining cluster resource status, queue policy (including current queue status), user policy (including user permissions and user priority), license status, and solver path. This secondary decision-making mechanism helps to further improve the rationality of resource requests. If the cluster resource status indicates insufficient real-time cluster resources, it is determined that the cluster resource status does not meet the execution requirements of the refined master solution. If the current queue status indicates that the target queue is busy, the queue is too long, or the queue policy indicates that submission is not allowed, it is determined that the queue policy does not meet the execution requirements of the refined master solution. If user permission / user priority restrictions prevent the master solution from executing, it is determined that the user policy does not meet the execution requirements of the refined master solution. If the license status indicates that the software license is full and no licenses are available, it is determined that the license status does not meet the execution requirements of the refined master solution. If the solver path is inaccessible or the solving environment is abnormal, it is determined that the solver path does not meet the execution requirements of the refined master solution.

[0057] If all job execution constraints meet the execution requirements of the fine-tuned master plan, the first submission submodule can submit the fine-tuned master plan to the scheduling system. This allows the scheduling system to allocate the necessary computing resources for the simulation task within the HPC cluster according to the resource declarations in the fine-tuned master plan, thus avoiding task interruptions due to insufficient resource requests and queuing delays and resource waste due to excessive resource requests. If any job execution constraint does not meet the execution requirements of the fine-tuned master plan, the submission parameters can be switched from the fine-tuned master plan to a candidate plan. The candidate plan can also meet the resource requirements of the current simulation task and can adapt to the current cluster's resource idle status.

[0058] The simulation orchestration system 130 is used to determine the target solver from multiple solvers based on the simulation configuration specification, so that the target solver can perform simulation tasks based on computing resources.

[0059] The simulation orchestration system 130 can maintain registration information for multiple solvers. Based on the simulation configuration specification and registration information, it can determine at least one target solver from among the multiple solvers. The target solver executes the simulation task input by the user based on the computational resources inferred by the simulation task resource inference system 120. Understandably, if the simulation task is a cross-physical domain task, multiple target solvers may need to work together to solve the simulation.

[0060] In an optional embodiment of this application, the simulation orchestration system includes: The standardization module is used to obtain the simulation configuration specification and generate the standard physical specification based on the simulation configuration specification; The solver determination module is used to retrieve the registration information of multiple solvers and determine at least one target solver from the multiple solvers based on the standard physical specification and the registration information. The conversion module is used to convert standard physical specifications into input files that match the target solver, so that the target solver can perform simulation tasks based on computing resources.

[0061] The standardization module can obtain the simulation configuration specification and perform operations such as verification, persistence and adding version identifiers on the simulation configuration specification to generate a standard physical specification as a shared standard input.

[0062] The simulation orchestration system 130 can maintain registration information for multiple solvers. This registration information can include physical domains, license availability, interface types, and deployment environment information. Physical domains include fluid dynamics, solid dynamics, fluid-structure interaction, thermal-structural interaction, and electromagnetic-thermal dynamics. License availability refers to whether a user can legally obtain and use a solver, typically involving license allocation, authorization status, and availability. The solver determination module can determine one or more target solvers from the multiple solvers based on standard physical specifications and registration information. Based on the target solvers, it can determine the simulation execution path corresponding to the simulation configuration specification.

[0063] The conversion module can convert standard physical specifications into input files such as scripts, dictionaries, input cards, or API (Application Programming Interface) call sequences that are acceptable to the corresponding solver through dedicated adapters for each target solver. The target solver can then perform simulations based on the computational resources according to the corresponding input files, where the input files are specific format files corresponding to the target solver.

[0064] The solver determination module includes: The filtering submodule is used to perform preliminary hard constraint filtering on multiple solvers based on standard physical specifications and registration information to obtain the first candidate solver; The solver determination submodule is used to determine at least one target solver based on the working condition characteristics in the standard physical specification and the solution capability information of the first candidate solver. The solver determination submodule includes: The reading unit is used to read the working condition characteristics in the standard physical protocol and the capability support matrix of the first candidate solver; The comparison unit is used to compare each dimension feature in the working condition features with the matrix entries of the capability support matrix for each first candidate solver in turn; The determination unit is used to determine the first candidate solver as the target solver if each dimension feature is within the range of the matrix entries.

[0065] The filtering submodule performs preliminary hard filtering constraints based on the physical domain, license availability, and deployment environment in the standard physical specification and registration information, directly excluding solvers that do not cover the physical domain, have unavailable licenses, or do not match the deployment environment, thus obtaining the first candidate solver.

[0066] The solver determination submodule determines at least one target solver based on the operating condition characteristics in the standard physical specification and the solver capability information of the first candidate solver.

[0067] Specifically, the operating condition characteristics in the standard physical specification and the capability support matrix of the first candidate solver can be read through the reading unit. The operating condition characteristics describe the requirements of the current simulation task, representing the "demand side" of the task. These characteristics mainly include: physical domain type, solution type (steady-state / transient), whether complex models such as hypersonic / multiphase flow / combustion / large deformation are involved, mesh size and resource requirements, user-specified solver preferences, and license and deployment environment requirements. When deploying solvers, administrators can pre-configure the capability support matrix. This matrix reflects the "supply side" of each solver and is compiled by administrators based on the official documentation and practical experience of each solver, recording the support status of each solver across various feature dimensions.

[0068] The comparison unit performs a weighted score on each first-choice solver that passes the hard constraint filtering. Specifically, scores are given based on dimensions such as physical domain coverage, resource matching, and user preference (e.g., preference for commercial / open-source solvers), and the scores are weighted and summed. The highest-scoring solver path is selected as the primary solver path, and the second-highest-scoring solver path is selected as a candidate solver path. Following the order of scores, each dimension of the working condition features is compared with each entry of the solver's capability support matrix.

[0069] If every dimension of the operating condition features falls within the support range of the matrix entries in the capability support matrix, then the operating condition features are considered to fall entirely within the capability support matrix of a certain solver. The determining unit can then identify that solver as the target solver and automatically distribute the current simulation task to the execution path of that target solver. If any dimension of the features does not fall within the support range of the matrix entries in the capability support matrix, then the weight is reduced or the solver is directly excluded.

[0070] The simulation fault repair system 140 is used to generate repair instructions and diagnostic reports when the target solver simulation fails. The repair instructions are used to adjust the simulation configuration information in the simulation configuration specification so that the target solver can re-execute the simulation task.

[0071] If the target solver fails during the simulation task, the simulation fault repair system 140 can automatically analyze the fault, generate corresponding repair instructions and diagnostic reports, and automatically adjust the simulation configuration information in the simulation configuration specification according to the repair instructions, so that the target solver can re-execute the simulation task.

[0072] In an optional embodiment of this application, the simulation fault repair system 140 includes: The data acquisition module is used to collect simulation data from the target solver during the execution of simulation tasks; The first judgment module is used to extract fault data from the simulation data when the simulation fails, determine the fault type based on the fault data, and determine whether the preset fault scenario covers the fault type. The module is used to build prompt information based on fault data and simulation configuration specifications if the preset fault scenario does not cover the fault type; The inference module is used to diagnose the agent's reasoning based on the prompts, generate repair instructions and diagnostic reports; the repair instructions are used to adjust the simulation configuration information in the simulation configuration specification so that the target solver can re-execute the simulation task.

[0073] During the execution of simulation tasks, the data acquisition module can continuously collect multi-source heterogeneous signals to obtain simulation data, such as solution logs, residual curves, iteration status, time step information, and system operation indicators.

[0074] This application embodiment constructs a failure taxonomy for the simulation field, organizing failure phenomena into a computable category system, and providing structured definitions for problems such as divergence, backflow, CFL (Courant-Friedrichs-Lewy number, convergence condition judgment number, i.e., Courant number) exceeding the limit, and convergence stagnation. If the solver malfunctions during simulation and the simulation fails, the first judgment module can extract fault data based on the simulation data, such as log error segments and the shape of continuously oscillating residual curves. By analyzing the fault data, the fault type can be determined based on the failure taxonomy. The fault type is identified by matching the features and patterns of the fault data.

[0075] In this embodiment, preset fault scenarios can be defined in advance. These scenarios are typically highly deterministic, such as conflicts between continuous backflow alarms and outlet pressure settings, or continuous CFL exceeding limits and excessive time steps. When a simulation fails, the fault type is first determined based on the fault data, and then it is prioritized to determine whether the preset fault scenarios can cover the fault type.

[0076] If the preset fault scenarios cannot cover the fault types, the construction module can build prompt information based on the fault data and simulation configuration specifications. Specifically, it can stitch together the collected fault data and the simulation configuration specifications containing physical property parameters, selected physical models, boundary conditions, and other configuration information into a high-density prompt information.

[0077] After generating the prompt information, it can be input into the diagnostic agent (i.e., the inference module). Upon receiving the prompt information, the diagnostic agent compares the simulation configuration specification with the fault data to perform inference, generating repair instructions and a diagnostic report. For example, if the fault data indicates "the solver reports incompressibility and non-convergence," and the simulation configuration specification reveals "a supersonic condition of Mach 2.0 is set at the boundary inlet," the failure logic "the weakly compressible solver cannot handle extremely high Mach numbers" can be deduced. Further, repair instructions for the fault data can be generated based on the inference results. A diagnostic report can then be generated based on the fault cause and repair instructions, and the diagnostic report can be returned. The simulation configuration information in the simulation configuration specification is automatically adjusted according to the repair instructions, such as automatically adjusting solver parameters, boundary conditions, discretization format, or restart strategy, triggering a new round of solving so that the solver re-executes the simulation task. This embodiment reduces manual troubleshooting workload, improves the autonomy of batch simulation tasks, and provides a structured foundation for accumulating trainable diagnostic samples.

[0078] In an optional embodiment of this application, the simulation fault repair system 140 further includes: The target fault scenario module is used to match fault data with the preset fault scenarios to determine the target fault scenario if the preset fault scenarios cover the fault types. The preset fault scenarios include at least the scenario of missing boundary parameters, the scenario of divergence at the start, and the scenario of hardware exceeding the limit. The repair instruction determination module is used to determine the repair instruction corresponding to the target fault scenario based on the target fault scenario; wherein the preset fault scenario and the repair instruction are pre-bound. The reasoning module includes: The extraction submodule is used to extract fault symptoms based on fault data and extract operating condition features based on simulation configuration specifications. The comparison submodule is used to compare operating condition characteristics with fault symptoms to identify points of discrepancy. The derivation submodule is used to deduce the cause of the fault based on the contradiction points and generate repair instructions based on the cause of the fault. The diagnostic report submodule is used to generate diagnostic reports based on the cause of the fault and repair instructions.

[0079] The preset fault scenarios are high-deterministic scenarios, including scenarios with missing boundary parameters, scenarios with divergence at start-up, and hardware out-of-bounds scenarios. Judgment rules can be set for high-deterministic scenarios. The judgment rules are based on a hard-coded deterministic logic tree (IF-THEN rule engine). The target fault scenario module determines the target fault scenario covering the fault type by matching the fault data with specific condition thresholds in the preset fault scenarios.

[0080] Each high-determinism scenario (i.e., a preset fault scenario) has a corresponding repair instruction pre-bound in the rule base. After determining the target fault scenario that the fault type matches, the repair instruction determination module directly reads and executes the repair instruction corresponding to the target fault scenario. Specifically, this includes: 1. Scenario Matching: The rule engine compares the current fault data with the parameters in the simulation configuration specification to match a unique high-determinism scenario; 2. Reading Repair Instructions: Retrieves the pre-bound repair instruction for this scenario from the rule base; 3. Outputting Executable Instructions: Translates the repair action into the specific operation of the current solver, writes it back to the simulation task configuration, and triggers a recalculation.

[0081] During inference, the extraction submodule first extracts the semantic summary of the abnormal phenomenon from the fault data to obtain the fault symptoms, and reads the operating condition features related to the current simulation task from the simulation configuration specification.

[0082] The comparison submodule cross-compares the fault symptoms with the operating condition characteristics to find contradictions between the fault symptoms and the operating condition characteristics, and finds combinations that are inconsistent or beyond the applicable range, thereby determining the contradiction points.

[0083] The derivation submodule can determine the physical mechanism of the failure of a contradiction point through the contradiction point. For example, a supersonic inlet may induce a shock wave, and the incompressible solver may be unable to handle density jumps, leading to residual divergence. The diagnostic agent organizes its language according to the confirmed contradiction point as the core, following the order of "phenomenon → physical mechanism → cause of failure". The three-layer logic chain is automatically connected by the chain-like reasoning of the diagnostic agent. The cause of failure is deduced based on the physical mechanism. For example, if the phenomenon of the contradiction point is "residual divergence" and the physical mechanism is "the supersonic flow field generates a shock wave, causing density discontinuity", then the cause of failure can be deduced as "the selected incompressible solver does not support density jumps".

[0084] The diagnostic report submodule can further generate corresponding repair instructions based on the cause of the failure. Finally, a diagnostic report is generated based on the cause of the failure and the diagnostic recommendations. The cause of failure and the diagnostic recommendations in the diagnostic report are ultimately output in a forced JSON format, with fields including: failure class, root cause, confidence, repair action, and specific parameters or configuration items to be modified (repair target).

[0085] In an optional embodiment of this application, the intelligent simulation system 100 further includes a simulation configuration specification processing system, which includes: The second acquisition module is used to acquire the old version of the first simulation configuration specification and the new version of the second simulation configuration specification; The second judgment module is used to determine whether the first simulation configuration specification and the second simulation configuration specification are compatible; The difference node extraction module is used to extract the difference nodes between the first simulation configuration specification and the second simulation configuration specification when they are not fully compatible. The patch module is used to generate a patch for the first simulation configuration specification if the difference nodes do not affect the preset solution objective, so as to update the first simulation configuration specification. The warning module is used to generate warning messages for the first simulation configuration specification if the difference nodes affect the solution objective, so that the user can supplement the first simulation configuration specification.

[0086] As the intelligent simulation system 100 expands from a single physics field to multiple physics fields such as fluid-structure interaction, thermal-structure interaction, and electromagnetic-thermal interaction, the intermediate specifications carrying the simulation configuration will also continuously evolve. The structure and physical semantics of fields in the new and old versions of the specifications may be incompatible. If the simulation agent is updated to the latest version, but the user retrieves the older version of the first simulation configuration specification during simulation, the second acquisition module can obtain both the older version of the first simulation configuration specification and the new version of the second simulation configuration specification corresponding to the current simulation agent, for comparison. It is understandable that a version identifier (including major and minor versions) can be written into each version of the simulation configuration specification to identify different versions. During solver registration, the physical domain is used to maintain the field list, field constraints, and default value rules.

[0087] The second judgment module can determine whether the first simulation configuration specification has missing fields, renamed fields, changed types, or changed constraints by comparing the first simulation configuration specification with the current second simulation configuration specification, based on aspects such as missing fields, field naming, field types, and constraints. This allows the module to determine whether the structures of the first and second simulation configuration specifications are compatible.

[0088] If the structural level is not fully compatible, the difference node extraction module can extract the difference nodes between the first simulation configuration specification and the second simulation configuration specification, and analyze whether the difference nodes affect the solution objective by combining the user simulation task and coupling dependencies. If the structural level is fully compatible, the first simulation configuration specification can be used directly, and the current business process can be directly entered.

[0089] The core solution objective of the simulation task can be extracted based on the user-input simulation task. If it is determined that the difference nodes do not affect the solution objective, the patching module can generate a patch for the first simulation configuration specification, thereby updating the first simulation configuration specification.

[0090] If a difference node affects the solution objective, the warning module can intercept the current process, report a version compatibility conflict warning, and generate warning information for the first simulation configuration specification. Users can supplement the first simulation configuration specification based on the warning information.

[0091] The second judgment module includes: The structural verification submodule is used to perform structural verification on the first simulation configuration specification based on the second simulation configuration specification. The compatibility determination submodule is used to determine incomplete compatibility when the structural verification fails. The extraction module includes: The difference tree submodule is used to compare the first simulation configuration specification with the second simulation configuration specification and generate a difference tree; The difference node submodule is used to extract difference nodes based on the difference tree; The simulation configuration specification processing system also includes: The third judgment module is used to determine whether the difference nodes affect the solution objective based on the preset multiphysics element dependency graph. The first determination module is used to determine whether the difference nodes affect the solution objective if they are not applied to the solution objective. The second determination module is used to determine the impact of the difference nodes on the solution objective if they are applied to the solution objective.

[0092] Structure validation primarily involves verifying the syntax and format of the simulation configuration specification. In practice, the structure validation submodule can use a strongly typed data description framework to perform programmatic structure validation of the first simulation configuration specification based on the second simulation configuration specification. In one example, the data description framework can include JSON data format (JSONSchema), Pydantic (a parsing library), or XML data format (XML Schema, a standard language for defining and validating the structure and data types of XML documents). During the validation process, the data description framework of the second simulation configuration specification can be obtained to quickly check whether the field tree of the first simulation configuration specification is complete, whether the data types are illegal, the nesting level, and whether the enumeration values ​​fall within the legal range, thereby determining whether the first simulation configuration specification conforms to the data description framework.

[0093] If one or more of the first simulation configuration specifications do not conform to the data description framework, the first simulation configuration specification fails the structural verification. The compatibility determination submodule can determine that the first simulation configuration specification and the second simulation configuration specification are not fully compatible.

[0094] If incompatibility is not fully achieved, the difference tree submodule can compare the first simulation configuration specification with the second simulation configuration specification to generate a difference tree (Diff tree) between them. A difference tree is an algorithm or data structure used to compare the differences between two tree structures. In this embodiment, the module can receive the respective data "trees" of the first and second simulation configuration specifications, compare them, locate any information loss, hierarchy degradation, or definition differences, and generate a difference tree.

[0095] The difference node submodule can extract the difference nodes between the first simulation configuration specification and the second simulation configuration specification based on the difference tree.

[0096] In a complex multiphysics coupled system, a multiphysics dependency graph can be used to describe the interdependencies and interactions between different physical quantities (i.e., "elements"). This multiphysics dependency graph is pre-drawn by domain experts based on the physical governing equations and engineering experience, and stored in a built-in private knowledge base, dynamically generated independently of specific tasks. The multiphysics dependency graph can be understood as a "parameter influence map," where each node represents a simulation parameter, arrows between nodes indicate the direction of influence, and cross-physical domain coupling dependencies are also reflected in the graph.

[0097] The third judgment module takes the solution objective as the core target and uses the multiphysics dependency graph to traverse paths starting from the difference nodes. It determines whether the difference nodes directly or indirectly pass to the parameters of the solution objective through the governing equations, physical property parameters, or boundary fluxes. In one example, if the difference node represents a field with a difference, it can start from the "missing or changed field" of the difference node and trace along the arrows in the multiphysics dependency graph to see if it can reach the solution objective of this simulation. If the solution objective is not reached, it means that the difference node does not affect the solution objective, and the first determination module can determine that the difference node does not affect the solution objective. If the solution objective can be reached, it means that the difference node affects the solution objective, and the second determination module can determine that the difference node affects the solution objective.

[0098] The simulation configuration specification processing system can ensure both structural and physical semantic compatibility between new and old versions of simulation configuration specifications, and supports smooth upgrades and stable playback in multi-physics scenarios. This reduces the cost for users to adapt solvers and improves the reusability and evolution efficiency of simulation configuration specifications.

[0099] In an optional embodiment of this application, the intelligent simulation system 100 further includes a simulation licensing evaluation system, which includes: The information acquisition module is used to acquire the static authorization information of the simulation orchestration system recorded when the license is issued, as well as the dynamic authorization information of the simulation orchestration system collected during operation; the static authorization information includes basic license characteristics, and the dynamic authorization information includes host environment characteristics and business behavior characteristics; The evaluation and decision-making module is used to evaluate the authorization status of the simulation orchestration system based on basic license characteristics, host environment characteristics, and business behavior characteristics. The execution module is used to control measures that match the triggering and authorization status of the simulation orchestration system.

[0100] The simulation licensing evaluation system includes an information acquisition module. This module retrieves static licensing information of the simulation orchestration system recorded during license issuance, as well as dynamic licensing information collected during operation. Static licensing information includes basic license characteristics, while dynamic licensing information includes host environment characteristics and business behavior characteristics. Specifically, the information acquisition module can include an authorization registration module, an environment acquisition module, and a behavior acquisition module. The authorization registration module records the static licensing information of the simulation orchestration system during license issuance; the environment acquisition module continuously monitors the host environment characteristics of the simulation orchestration system during its operation; and the behavior acquisition module continuously collects the business behavior characteristics of the simulation orchestration system during its operation. Basic license characteristics are static licensing information that does not change with the operation of the simulation orchestration system, while host environment status and business behavior characteristics are dynamic licensing information that can change with the operation of the simulation orchestration system.

[0101] The evaluation and decision-making module can integrate basic licensing characteristics with host environment characteristics and business behavior characteristics to form a multi-dimensional authorization evaluation vector, so as to perform trust evaluation on the authorization status of the simulation orchestration system based on the multi-dimensional authorization evaluation vector.

[0102] The action execution module can implement tiered responses to the simulation orchestration system based on the evaluation results (i.e., authorization status) output by the evaluation decision module. Specifically, in this embodiment, multiple control measures can be pre-configured. The action execution module can determine the control measure that matches the current authorization status of the simulation orchestration system from among the multiple control measures, and then issue the control measure to the simulation orchestration system so as to dynamically adjust the capabilities of the simulation orchestration system.

[0103] In an optional embodiment of this application, the basic licensing features include at least one of the following: the authorizing entity, the scope of permitted functions, the resource limit, the license period, and the signature information; the host environment features include at least one of the following: hardware fingerprint, container identifier, network topology change, time offset, and virtualization features; and the business behavior features include at least one of the following: task scheduling behavior, solver calling behavior, functional module calling behavior, multi-agent collaborative behavior, knowledge base operation behavior, spatial distribution features, and task attribute features. The evaluation and decision-making module includes: The authorization deviation calculation submodule is used to calculate the authorization deviation of the simulation orchestration system based on basic license characteristics, host environment characteristics, and business behavior characteristics. The authorization status evaluation submodule is used to evaluate the authorization status of the simulation orchestration system by comparing the authorization deviation degree with a preset deviation threshold. Authorization status includes at least one of normal authorization status, suspicious authorization status, and unauthorized authorization status. Preset deviation thresholds include a first deviation threshold and a second deviation threshold, where the first deviation threshold is less than the second deviation threshold. The authorization status assessment submodule includes: The normal authorization status determination unit is used to evaluate the authorization status of the simulation orchestration system as normal authorization status if the authorization deviation is less than a first deviation threshold; or, The suspicious authorization status determination unit is used to assess the authorization status of the simulation orchestration system as suspicious if the authorization deviation is greater than or equal to a first deviation threshold and less than a second deviation threshold; or, The unauthorized authorization status determination unit is used to evaluate the authorization status of the simulation orchestration system as unauthorized authorization status if the authorization deviation is greater than or equal to the second deviation threshold.

[0104] The authorization deviation calculation submodule can integrate basic licensing features with host environment features and business behavior features to form a multi-dimensional authorization evaluation vector, so as to calculate the authorization deviation of the simulation orchestration system based on the multi-dimensional authorization evaluation vector.

[0105] Authorization deviation is a metric used to quantify the degree of inconsistency between the actual operating environment and behavior of a simulation orchestration system and the scope of the license agreement. It uses the license issued to the system as a baseline constraint and integrates multi-dimensional environmental characteristics such as hardware fingerprints, container identifiers, and network topology changes, as well as multi-dimensional behavioral characteristics such as task scheduling, function calls, resource usage, proxy collaboration, and environment migration. It calculates the degree to which the actual operating environment and behavior deviate from the license agreement to determine whether the simulation orchestration system has unauthorized behaviors such as unauthorized use, excessive calls, unauthorized migration, and abnormal access. The larger the authorization deviation, the greater the difference between the actual operating environment or behavior of the simulation orchestration system and the license agreement, and the higher the risk of authorization violation and the degree of unauthorized use.

[0106] In one embodiment, the basic licensing features include at least one of the following: the authorizing entity, the scope of permitted functions, the resource limit, the license period, and signature information; the host environment features include at least one of the following: hardware fingerprint, container identifier, network topology change, time offset, and virtualization features; and the business behavior features include at least one of the following: task scheduling behavior, solver invocation behavior, functional module invocation behavior, multi-agent collaborative behavior, knowledge base operation behavior, spatial distribution features, and task attribute features.

[0107] Basic license characteristics may include, but are not limited to: the authorizing entity, permitted functional scope, resource limits, license term, and signature information. The authorizing entity refers to the unit or individual that obtains a legal license to use the simulation orchestration system; it is the party to whom the license belongs. Permitted functional scope refers to the functional modules, business capabilities, or operational permissions that the simulation orchestration system grants to users under the license. Resource limits refer to the maximum amount of resources the system can use as stipulated in the license agreement. The license term refers to the start and end time during which the simulation orchestration system license is legally valid. Signature information refers to the legality verification information of the license file generated by the software vendor using encryption algorithms.

[0108] Host environment characteristics may include, but are not limited to: hardware fingerprints, container identifiers, network topology changes, time offsets, and virtualization characteristics. Hardware fingerprints refer to the unique identification information of hardware devices. Container identifiers refer to the unique identification information assigned to each container instance at runtime. Network topology changes refer to the dynamic changes in the network structure where the current host / container resides. Time offset refers to the difference between the current time of the simulation orchestration system and the standard time. Virtualization characteristics are used to determine whether the current simulation orchestration system is running in a virtual machine, container, cloud host, or simulator.

[0109] Business behavior characteristics may include, but are not limited to: task scheduling behavior, solver invocation behavior, functional module invocation behavior, multi-agent collaboration behavior, knowledge base operation behavior, spatial distribution characteristics, and task attribute characteristics. Specifically, task scheduling behavior refers to the temporal patterns, frequency characteristics, and scheduling modes of task initiation, submission, queuing, distribution, and execution during the simulation orchestration system's operation. Solver invocation behavior refers to the invocation methods, frequency, distribution, and usage patterns of solvers within the simulation orchestration system. Functional module invocation behavior refers to the invocation sequence, frequency, and usage distribution characteristics of each functional module within the simulation orchestration system, reflecting whether multi-agent collaborative work exceeds the authorized node range and collaboration rules. Knowledge base operation behavior refers to the operational characteristics of accessing the knowledge base within the simulation orchestration system, such as batch reading, data querying, and exporting. Spatial distribution characteristics refer to the distribution and migration characteristics of simulation tasks, computing nodes, and runtime environments in the physical or logical domain. Task attribute characteristics refer to the inherent attributes of the simulation task itself, such as its type, scale, complexity, business scenario, and resource requirements.

[0110] Furthermore, task scheduling behavior may include, but is not limited to: request frequency, task issuance mode, task submission frequency and temporal distribution, abnormally high-frequency task issuance, and task submission rhythm characteristics. Solver invocation behavior may include, but is not limited to: SolverSpec invocation mode, SolverSpec invocation distribution, reduction invocation distribution characteristics, and solver usage mode characteristics. Functional module invocation behavior may include, but is not limited to: module usage distribution, functional module invocation sequence characteristics, and functional module invocation mode characteristics. Multi-agent collaboration behavior may include, but is not limited to: agent invocation sequence, agent collaboration mode characteristics, agent invocation order, and agent invocation frequency. Knowledge base operation behavior may include, but is not limited to: knowledge base access rhythm, knowledge base batch access behavior, and data export behavior characteristics. Spatial distribution characteristics may include, but are not limited to: cross-environment migration and physical domain distribution characteristics. Task attribute characteristics may include, but are not limited to: simulation task type. Here, simulation task type refers to the business type, scenario type, and computation type to which the simulation task belongs.

[0111] The basic licensing characteristics positively correlated with authorization deviation can include: the authorizing entity, resource limits, and signature information. The basic licensing characteristics negatively correlated with authorization deviation can include: the permitted functional scope and license duration. The host environment characteristics positively correlated with authorization deviation can include: hardware fingerprints, container identifiers, network topology changes, time offsets, and virtualization characteristics. The business behavior characteristics positively correlated with authorization deviation can include: request frequency, task distribution patterns, task submission frequency and timing distribution, abnormally high-frequency task distribution, task submission rhythm characteristics, SolverSpec call patterns, SolverSpec call distribution, reduction call distribution characteristics, solver usage pattern characteristics, module usage distribution, functional module call sequence characteristics, functional module call pattern characteristics, agent call sequence, agent collaboration pattern characteristics, agent call order, agent call frequency, knowledge base access rhythm, knowledge base batch access behavior, data export behavior characteristics, cross-environment migration, and physical domain distribution characteristics.

[0112] The authorization status assessment submodule compares the authorization deviation with a preset deviation threshold to evaluate the authorization status of the simulation orchestration system based on the comparison result. The authorization status includes at least one of normal authorization status, suspicious authorization status, and illegal authorization status. The preset deviation threshold includes a first deviation threshold and a second deviation threshold, wherein the first deviation threshold is less than the second deviation threshold.

[0113] If the authorization deviation is less than the first deviation threshold, it means that during the operation of the simulation orchestration system, its multi-dimensional environmental characteristics and multi-dimensional behavioral characteristics strictly comply with the authorization scope agreed in the license, and there is no unauthorized, excessive or abnormal behavior. The authorization deviation is in the extremely low or normal threshold range, and the system operating environment and behavior are highly consistent with the license. Then the normal authorization status determination unit will evaluate the authorization status of the simulation orchestration system as a normal authorization status.

[0114] If the first deviation threshold ≤ authorized deviation < second deviation threshold, it indicates that some environmental or behavioral characteristics of the simulation orchestration system are slightly abnormal. The authorized deviation exceeds the normal baseline but does not reach the clear violation threshold. It cannot be directly judged as compliant, but it does not constitute a clear overreach of authority. Further verification, monitoring and early warning are required. In this case, the suspicious authorization status judgment unit will evaluate the authorization status of the simulation orchestration system as a suspicious authorization status.

[0115] If the second deviation threshold is less than or equal to the authorized deviation, it means that the actual operating environment and behavior of the simulation orchestration system significantly exceed the scope agreed upon in the license, the authorized deviation reaches or exceeds the violation judgment threshold, and there are clear problems such as authorization abuse / environment migration / mirror copying / abnormal concurrency / unauthorized calls. In this case, the illegal authorization status judgment unit will evaluate the authorization status of the simulation orchestration system as an illegal authorization status.

[0116] When the authorization status is normal, it indicates that the authorization evaluation result of the simulation orchestration system is normal and there is no abnormal deviation. Therefore, the simulation orchestration system is allowed to continue operating normally. When the authorization status is questionable, it indicates that the authorization evaluation result of the simulation orchestration system has a slight abnormality or is questionable. Therefore, the simulation orchestration system undergoes a secondary verification (or mandatory review), confirming its legality through manual or automatic review to avoid misjudgment or minor overreach. Alternatively, the simulation orchestration system may be rate-limited. When the authorization status is illegal, it indicates that the authorization evaluation result of the simulation orchestration system has a severe abnormality. Therefore, the simulation orchestration system may be downgraded (e.g., restricting some advanced functions), such as retaining basic simulation functions. Alternatively, the simulation orchestration system may be locked, for example, directly stopping the operation and service calls of critical modules to prevent the spread of risk. The trust evaluation of the authorization status of the simulation orchestration system in this application embodiment is continuous, supporting dynamic adjustment of the authorization status and control measures of the simulation orchestration system during its operation. For example, when the authorization deviation drops to the normal threshold range (i.e., authorization deviation < first deviation threshold), the evaluation system can adjust the authorization status from suspicious authorization status / illegal authorization status to normal authorization status in order to speed up / upgrade / unlock the simulation orchestration system.

[0117] The simulation-based authorization evaluation system, by introducing host environment characteristics and business behavior characteristics (which are dynamic authorization information that can change as the simulation orchestration system runs) on top of basic license characteristics (which are static authorization information), can adapt to virtual machine, container, and cluster migration scenarios. Even if the authorization subject does not change the hardware environment, it can effectively identify abnormal calls, unauthorized use, and other situations, thereby improving the robustness of authorization in private delivery environments and enhancing the ability to identify abnormal usage behaviors.

[0118] This application provides an intelligent simulation system. A simulation configuration specification generation system can generate solver-independent simulation configuration specification objects, facilitating the expansion of multi-solver backends and improving the portability of simulation configuration generation. A simulation task resource inference system directly infers computational resources based on simulation configuration specifications, improving resource inference accuracy and thus enhancing the rationality of resource requests and reducing job submission failure rates. A simulation orchestration system enables cross-solver reuse of the same working condition's physical semantics, eliminating the need for repetitive development of instructions and configuration logic for each solver, achieving unified orchestration and seamless switching among multiple solvers. Through multi-system collaborative coupling, users can trigger simulation workflows through natural language interaction, transforming abstract simulation tasks into concrete physical logic and numerical expressions. This achieves end-to-end automation from mesh generation to solution analysis, significantly lowering the user's familiarity threshold with underlying software operations, and realizing standardized delivery of simulation expert engineering capabilities. While simplifying the simulation process, it greatly shortens the learning cycle and promotes the evolution of simulation software delivery models from "tool delivery" to "capability delivery."

[0119] Corresponding to the aforementioned application function implementation system embodiments, this application also provides a corresponding embodiment of an intelligent simulation method.

[0120] Figure 2 This is a flowchart illustrating the intelligent simulation method shown in the embodiments of this application.

[0121] See Figure 2 This method is applied to intelligent simulation systems, which integrate multiple solvers. The intelligent simulation system includes at least: a simulation configuration specification generation system, a simulation task resource inference system, a simulation orchestration system, and a simulation fault repair system. The method includes: Step 210: Based on the simulation task input by the user, a simulation configuration specification is generated by the simulation configuration specification generation system; the simulation configuration specification is used to describe the simulation configuration information.

[0122] The intelligent simulation system features a user interface that allows interaction with the user, enabling them to input simulation tasks in natural language. Based on the user-input simulation tasks, the simulation configuration specification generation system performs intent parsing and other processing to generate a unified, structured simulation configuration specification, SolverSpec.

[0123] Step 220: Based on the simulation configuration specification, infer the computing resources required to execute the simulation task through the simulation task resource inference system.

[0124] The simulation task resource inference system infers the computing resources required to execute the simulation task based on the simulation configuration specification through the resource inference model, and schedules the corresponding computing resources through the scheduling system. The simulation task resource inference system can be coupled to the scheduling system or independent of the scheduling system.

[0125] Step 230: Based on the simulation configuration specification, the target solver is determined from multiple solvers through the simulation orchestration system so that the target solver can perform simulation tasks based on computing resources.

[0126] The simulation orchestration system can maintain registration information for multiple solvers. Based on the simulation configuration specification and registration information, at least one target solver can be determined from the multiple solvers. The target solver infers the computational resources inferred by the system based on the simulation task resources and executes the simulation task input by the user. Understandably, if the simulation task is a cross-physical domain task, multiple target solvers may need to work together to solve the simulation.

[0127] Step 240: When the target solver simulation fails, a repair instruction and a diagnostic report are generated through the simulation fault repair system. The repair instruction is used to adjust the simulation configuration information in the simulation configuration specification so that the target solver can re-execute the simulation task.

[0128] If the target solver encounters a fault during the execution of the simulation task and the simulation fails, the simulation fault repair system can automatically analyze the fault, generate corresponding repair instructions and diagnostic reports, and automatically adjust the simulation configuration information in the simulation configuration specification according to the repair instructions, so that the target solver can re-execute the simulation task.

[0129] This application provides an intelligent simulation method applied to an intelligent simulation system. Through multi-system collaborative coupling, it enables users to trigger simulation workflows via natural language interaction, transforming abstract simulation tasks into concrete physical logic and numerical expressions. This achieves end-to-end automation from mesh generation to solution analysis, significantly reducing the user's familiarity with underlying software operations. It also enables standardized delivery of simulation expert engineering capabilities, simplifying the simulation process while greatly shortening the learning cycle, and promoting the evolution of simulation software delivery models from "tool delivery" to "capability delivery."

[0130] Regarding the methods in the above embodiments, the specific manner in which each step is performed has been described in detail in the embodiments of the relevant system, and will not be elaborated further here.

[0131] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. An intelligent simulation system, characterized by, The intelligent simulation system integrates multiple solvers and includes at least: a simulation configuration specification generation system, a simulation task resource inference system, a simulation orchestration system, and a simulation fault repair system, wherein: The simulation configuration specification generation system is used to generate simulation configuration specifications based on user-input simulation tasks; the simulation configuration specifications are used to describe simulation configuration information. The simulation task resource inference system is used to infer the computing resources required to execute the simulation task based on the simulation configuration specification. The simulation orchestration system is used to determine a target solver from the multiple solvers based on the simulation configuration specification, so that the target solver executes the simulation task based on the computing resources; The simulation fault repair system is used to generate repair instructions and a diagnostic report when the target solver simulation fails; the repair instructions are used to adjust the simulation configuration information in the simulation configuration specification so that the target solver can re-execute the simulation task.

2. The intelligent simulation system of claim 1, wherein, The simulation configuration specification generation system includes: The first acquisition module is used to acquire grid metadata and the simulation task input by the user; The intent parsing module is used to parse the simulation task to obtain the simulation intent; An alignment module is used to align the mesh metadata and the simulation intent to obtain at least one candidate simulation region; The target simulation region module is used to determine the target simulation region based on the simulation intent and the candidate simulation regions by performing physical constraint verification. The specification generation module is used to generate a structured simulation configuration specification based on the target simulation region and the simulation intent.

3. The intelligent simulation system according to claim 2, characterized in that, The alignment module includes: The standardization submodule is used to standardize the simulation intent based on the domain dictionary and generate a standardized simulation intent. The name similarity submodule is used to calculate the name similarity based on the standardized simulation intent and the mesh metadata, and to determine a preliminary set of candidate simulation regions based on the name similarity. The coarse-grained screening submodule is used to perform coarse-grained screening on the preliminary candidate simulation region set through boundary type constraints and topological relationships to determine the candidate simulation regions; The target simulation region module is specifically used for: If multiple candidate simulation regions pass the physical constraint verification, then for each candidate simulation region, fine-grained screening is performed using boundary type constraints and topological relationships to determine the target simulation region.

4. The intelligent simulation system of claim 1, wherein, The simulation task resource inference system includes: The feature extraction module is used to extract structured features related to the solution cost of the simulation task from the simulation configuration specification; the structured features include at least one of physical semantic features, scale features, and resource constraint features; The resource inference module is used to calculate the resource requirement vector of the simulation task based on the structured features described in the resource inference model. The scheduling generation module is used to translate the resource requirement vector into a job description file that can be recognized by the scheduling system, and submit the job description file to the scheduling system so that the scheduling system can schedule the computing resources required to execute the simulation task based on the job description file.

5. The intelligent simulation system of claim 4, wherein, The physical semantic features include at least one of physical domain category, model complexity, time step setting and iteration limit; the scale features include at least one of grid size and grid type; the resource constraint features include parallel constraints; and the resource requirement vector includes at least one of CPU core count, number of nodes, memory capacity, wall clock time, queue type and accelerator requirement. The resource inference module includes: The CPU core count calculation submodule is used to calculate the number of CPU cores required for the simulation task based on the grid size, the model complexity, and the parallel constraints using the resource inference model; and / or, The node count calculation submodule is used to calculate the number of nodes required for the simulation task based on the grid size, the parallel constraints, and the number of CPU cores using the resource inference model; and / or, The memory capacity calculation submodule is used to calculate the memory capacity required for the simulation task based on the grid size, the physical domain type, the model complexity, and the parallel constraints using the resource inference model; and / or, The wall clock time calculation submodule is used to calculate the wall clock time required for the simulation task based on the time step settings, the iteration limit, the grid size, the model complexity, the grid type, and the parallel constraints, using the resource inference model; and / or, The queue type calculation submodule is used to calculate the queue type required for the simulation task based on the wall clock time, the number of CPU cores / number of nodes, the physical domain category, and the parallel constraints, using the resource inference model; and / or, The accelerator requirement calculation submodule is used to calculate the accelerator requirements of the simulation task based on the physical domain category, the model complexity, and the parallel constraints using the resource inference model. The job description file includes a master scheme; the scheduling generation module includes: The job execution constraint parameter acquisition submodule is used to acquire job execution constraint parameters. The job execution constraint parameters include cluster scheduling constraint parameters and execution environment configuration parameters. The cluster scheduling constraint parameters include at least one of cluster resource status, queue scheduling information and license status. The execution environment configuration parameters include solver path. The fine-tuning submodule is used to fine-tune the main scheme according to the cluster scheduling constraint parameters described above; The judgment submodule is used to determine whether all the execution constraint parameters of each job meet the execution requirements of the fine-tuned main scheme; The first submission submodule is used to submit a fine-tuned master plan to the scheduling system if the condition is met, so that the scheduling system can schedule the computing resources required to execute the simulation task based on the job description file.

6. The intelligent simulation system of claim 1, wherein, The simulation orchestration system includes: A standardization module is used to obtain simulation configuration specifications and generate standard physical specifications based on the simulation configuration specifications; A solver determination module is used to retrieve the registration information of the multiple solvers and determine at least one target solver from the multiple solvers based on the standard physical specification and the registration information. The conversion module is used to convert the standard physical specification into an input file that matches the target solver, so that the target solver can perform the simulation task based on the computing resources.

7. The intelligent simulation system according to claim 6, characterized in that, The solver determination module includes: The filtering submodule is used to perform preliminary hard constraint filtering on multiple solvers based on the standard physical specification and the registration information to obtain the first candidate solver; The solver determination submodule is used to determine at least one target solver based on the working condition characteristics in the standard physical specification and the solution capability information of the first candidate solver. The solver determination submodule includes: The reading unit is used to read the working condition characteristics in the standard physical specification and the capability support matrix of the first candidate solver; The comparison unit is used to compare each dimension feature in the working condition features with the matrix entries of the capability support matrix in turn for each first candidate solver. A determining unit is configured to determine the first candidate solver as the target solver if each dimension feature falls within the range of the matrix entries.

8. The intelligent simulation system of claim 1, wherein, The simulation fault repair system includes: The data acquisition module is used to collect simulation data of the target solver during the execution of the simulation task; The first judgment module is used to extract fault data based on the simulation data when the simulation fails, determine the fault type based on the fault data, and determine whether the preset fault scenario covers the fault type. A construction module is used to construct prompt information based on the fault data and the simulation configuration specification if the preset fault scenario does not cover the fault type; The inference module is used to diagnose the agent by inferring based on the prompt information, generating repair instructions and a diagnostic report; the repair instructions are used to adjust the simulation configuration information in the simulation configuration specification so that the target solver can re-execute the simulation task.

9. The intelligent simulation system according to claim 8, characterized in that, The simulation fault repair system also includes: The target fault scenario module is used to match the fault data with the preset fault scenario to determine the target fault scenario if the preset fault scenario covers the fault type; the preset fault scenario includes at least the boundary parameter missing scenario, the start-up divergence scenario, and the hardware out-of-bounds scenario. A repair instruction determination module is used to determine a repair instruction corresponding to the target fault scenario based on the target fault scenario; wherein the preset fault scenario is pre-bound to the repair instruction. The reasoning module includes: The extraction submodule is used to extract fault symptoms based on the fault data and extract operating condition features based on the simulation configuration specification. The comparison submodule is used to compare the operating condition characteristics with the fault symptoms to determine the points of inconsistency. The deduction submodule is used to deduce the cause of the fault based on the contradiction points and generate repair instructions based on the cause of the fault. The diagnostic report submodule is used to generate the diagnostic report based on the cause of the fault and the repair instructions.

10. The intelligent simulation system of claim 1, wherein, The intelligent simulation system also includes a simulation configuration specification processing system, which includes: The second acquisition module is used to acquire the old version of the first simulation configuration specification and the new version of the second simulation configuration specification; The second judgment module is used to determine whether the first simulation configuration specification and the second simulation configuration specification are compatible; The difference node extraction module is used to extract the difference nodes between the first simulation configuration specification and the second simulation configuration specification when they are not fully compatible. The patch module is used to generate a patch for the first simulation configuration specification if the difference node does not affect the preset solution objective, so as to update the first simulation configuration specification. The warning module is used to generate warning information for the first simulation configuration specification if the difference node affects the solution objective, so that the user can supplement the first simulation configuration specification.

11. The intelligent simulation system according to claim 10, characterized in that, The second judgment module includes: The structural verification submodule is used to perform structural verification on the first simulation configuration specification based on the second simulation configuration specification. The compatibility determination submodule is used to determine incomplete compatibility when the structural verification fails. The difference node extraction module includes: The difference tree submodule is used to compare the first simulation configuration specification with the second simulation configuration specification and generate a difference tree; The difference node submodule is used to extract difference nodes based on the difference tree; The simulation configuration specification processing system also includes: The third judgment module is used to determine whether the difference node acts on the solution objective based on the preset multiphysics element dependency graph. The first determining module is used to determine that the difference node does not affect the solution objective if it is not applied to the solution objective. The second determining module is used to determine whether the difference node affects the solution objective if it is applied to the solution objective.

12. The intelligent simulation system of claim 1, wherein, The intelligent simulation system also includes a simulation licensing evaluation system, which includes: The information acquisition module is used to acquire the static authorization information of the simulation orchestration system recorded when the license is issued, and to acquire the dynamic authorization information of the simulation orchestration system collected during operation; the static authorization information includes basic license characteristics, and the dynamic authorization information includes host environment characteristics and business behavior characteristics; The evaluation and decision-making module is used to evaluate the authorization status of the simulation orchestration system based on the basic license characteristics, the host environment characteristics, and the business behavior characteristics. The execution module is used to trigger control measures that match the authorized state in the simulation orchestration system.

13. The intelligent simulation system of claim 12, wherein, The basic licensing features include at least one of the following: authorizing entity, permitted functional scope, resource limit, license period, and signature information; the host environment features include at least one of the following: hardware fingerprint, container identifier, network topology change, time offset, and virtualization features; and the business behavior features include at least one of the following: task scheduling behavior, solver invocation behavior, functional module invocation behavior, multi-agent collaboration behavior, knowledge base operation behavior, spatial distribution features, and task attribute features. The evaluation and decision-making module includes: The authorization deviation calculation submodule is used to calculate the authorization deviation of the simulation orchestration system based on the basic license characteristics, the host environment characteristics, and the business behavior characteristics. The authorization status evaluation submodule is used to evaluate the authorization status of the simulation orchestration system by comparing the authorization deviation with a preset deviation threshold. The authorization status includes at least one of normal authorization status, suspicious authorization status, and unauthorized authorization status; the preset deviation threshold includes a first deviation threshold and a second deviation threshold, wherein the first deviation threshold is less than the second deviation threshold; the authorization status evaluation submodule includes: A normal authorization status determination unit is used to evaluate the authorization status of the simulation orchestration system as the normal authorization status if the authorization deviation is less than the first deviation threshold; or, A suspicious authorization status determination unit is configured to assess the authorization status of the simulation orchestration system as the suspicious authorization status if the authorization deviation is greater than or equal to the first deviation threshold and less than the second deviation threshold; or... The unauthorized authorization status determination unit is used to evaluate the authorization status of the simulation orchestration system as the unauthorized authorization status if the authorization deviation is greater than or equal to the second deviation threshold.

14. An intelligent simulation method, characterized by, The intelligent simulation method is applied to an intelligent simulation system, which integrates multiple solvers. The intelligent simulation system includes at least: a simulation configuration specification generation system, a simulation task resource inference system, a simulation orchestration system, and a simulation fault repair system. The method includes: The simulation task based on user input generates a simulation configuration specification through the simulation configuration specification generation system; the simulation configuration specification is used to describe simulation configuration information. Based on the simulation configuration specification, the simulation task resource inference system infers the computing resources required to execute the simulation task. Based on the simulation configuration specification, the target solver is determined from the multiple solvers by the simulation orchestration system, so that the target solver executes the simulation task based on the computing resources; When the target solver simulation fails, the simulation fault repair system generates repair instructions and a diagnostic report; the repair instructions are used to adjust the simulation configuration information in the simulation configuration specification so that the target solver can re-execute the simulation task.

Images