ABAQUS simulation task state matrix diagnosis and closed-loop scheduling method and system, and medium

Abstract

The application relates to an ABAQUS simulation task state matrix diagnosis and closed-loop scheduling method and system and a medium, relates to the technical field of finite element simulation, and the method comprises the following steps: obtaining a task root directory containing one or more ABAQUS simulation packages; reading at least two types of execution products of each simulation package; performing execution readiness judgment on ABAQUS command visibility and license pre-check results, and generating an execution readiness list; generating a package-level state matrix based on the execution products and the execution readiness judgment; generating an iteration strategy according to each row of the package-level state matrix; and outputting a closed-loop scheduling result containing the package-level state matrix, the iteration strategy, planned actions and audit records. The application can improve the recoverability, traceability and automated management efficiency of batch simulation tasks.

Description

Technical Field

[0001] This invention relates to the field of finite element simulation technology, and in particular to an ABAQUS simulation task state matrix diagnosis and closed-loop scheduling method, system and medium. Background Technology

[0002] ABAQUS, a widely used commercial finite element analysis software, undertakes a large number of batch computation tasks in the field of engineering simulation. In automated simulation task scheduling scenarios, ABAQUS's runtime status information is distributed across various execution artifacts, including runtime plans, command environments, pre-qualification results, log files, status files, output databases, result export files, and mesh verification files. Existing technologies cover aspects such as automatic generation of ABAQUS input files, automatic ABAQUS post-processing, generation of ODBs from non-ABAQUS results, and general simulation task scheduling.

[0003] However, traditional batch scripts typically determine task success or failure based solely on exit codes or a few log keywords, making it difficult to distinguish between various states such as permission blocking, command invisibility, solution abort, empty output database, missing standard result mesh, abnormal mesh quality, or insufficient evidence of mesh independence. Furthermore, existing solutions struggle to pre-audit the next steps without immediately executing the actual solution, posing challenges to the recoverability and pre-submission auditability of batch simulation tasks. Summary of the Invention

[0004] In view of the shortcomings of the prior art described above, the purpose of this invention is to provide an ABAQUS simulation task state matrix diagnosis and closed-loop scheduling method, system and medium. By constructing a state matrix, the multi-dimensional execution products of ABAQUS simulation tasks are uniformly diagnosed, which can accurately distinguish various states such as permission blocking, solution abort, database anomaly and insufficient mesh quality, and realize closed-loop scheduling and pre-submission audit of tasks, thereby improving the recoverability, traceability and automated management efficiency of batch simulation tasks.

[0005] To achieve the above objectives, the present invention adopts the following technical solution.

[0006] Firstly, the present invention provides an ABAQUS simulation task state matrix diagnosis and closed-loop scheduling method, which adopts the following technical solution: Obtain the task root directory containing one or more ABAQUS simulation packages; Read at least two types of execution artifacts from the run plan, run list, status file, log file, output database status, standard result grid file, and grid evidence file of each simulation package; Perform execution readiness checks on the visibility and permission pre-check results of ABAQUS commands, and generate an execution ready list; Based on the execution product and the execution readiness judgment, a packet-level state matrix is ​​generated. The packet-level state matrix records the port status, mesh quality status, mesh independence evidence status, and standard result mesh existence status of each simulation packet. An iterative strategy is generated based on each row of the packet-level state matrix. The iterative strategy includes at least one of the following: permission blocking wait, re-solution, result export, mesh verification, mesh independence verification, or acceptance of result. The output includes the packet-level state matrix, the iteration strategy, the planned actions, and the audit logs.

[0007] Furthermore, in the above method, the packet-level state matrix includes simulation packet identifier, port status, mesh quality status, mesh independence evidence status, standard result mesh existence status, and evidence indexes for the run list, status file, mesh file, and result mesh file; The existence status, quality status, and evidence status of the standard result grid are only used as state evidence of the simulation package execution product to determine whether result export, grid verification, grid independence supplementation, or result acceptance is required. The generation algorithm, field mapping rules, or specific physical result evaluation methods of the standard result grid are not limited.

[0008] Furthermore, in the above method, when the license preflight result indicates that the ABAQUS solution license is unavailable, the port status of the corresponding simulation package is set to license blocking, the iteration strategy is set to license blocking waiting strategy, and the license preflight output summary, historical blocking evidence, and recovery suggestions are recorded in the audit log.

[0009] Furthermore, in the above method, when the port status is solution aborted, timed out, or solution failed, a re-solution strategy is generated, and the original log, status file, and retry identifier are retained in the audit record.

[0010] Furthermore, in the above method, when the port status is completed and the standard result grid file does not exist, a result export strategy is generated. The result export strategy calls the ABAQUS output database export script to generate the standard result grid file, and regenerates the packet-level state matrix after the export is completed.

[0011] Furthermore, in the above method, the closed-loop scheduling result outputs a planned action file in the planning mode without executing the actual solution. The planned action file records the decisions, actions, action status, and next step descriptions for each simulation package, so as to audit the export, rerun, or review actions to be executed before submitting the actual ABAQUS command.

[0012] Furthermore, in the above method, generating a packet-level state matrix based on the execution product and the execution readiness determination includes: Read simulation package identifier, expected input file, expected output database and post-processing script from the run plan; read generated files and run commands from the run list; read incremental completion status, solution abort flag and normal completion flag from the .sta status file; read license error, command error, analysis error, timeout and abnormal termination keywords from the .log log; read whether ODB exists, whether it is empty, whether it can be opened and the number of frames from the output database status; read whether the result mesh exists and the verification status from the standard result mesh file; read mesh quality status and evidence status from the mesh quality file and mesh independence evidence file. When multiple execution product states are inconsistent, the final port state and iteration strategy are determined according to the priority of command not being visible or allowed to be blocked, the actual solution still running, the solution being terminated or failed, the output database not existing or empty, the standard result mesh being missing, the result mesh verification failing, the mesh quality not passing, insufficient evidence of mesh independence, and complete and acceptable evidence. The overwritten secondary state, the corresponding evidence file path, and the reason for the conflict are written into the conflict description field of the state matrix.

[0013] Furthermore, in the above method, the closed-loop scheduling result includes a dynamic feedback mechanism between the planned mode and the actual execution mode: In planning mode, for each planned action, an action identifier, idempotent key, target simulation package, trigger state, expected output, maximum number of retries, preconditions and prohibition conditions are generated. In real execution mode, after executing the planned action, the action result, return code, generated file, log summary and execution time are read and written back to the packet-level state matrix; the retry count, action status and next round iteration strategy are updated according to the write-back result. Repeated runs are prohibited when the same idempotent bond action has successfully generated the expected product; incorrect acceptance of results is prohibited when the standard result grid is missing or the grid evidence fails; and skipping result export is prohibited when the output database has been completed but the result grid is missing. When the number of retries exceeds the threshold or the status remains unchanged for two consecutive rounds, the corresponding simulation package will be marked as requiring manual review, and the reason for stopping will be output in the audit record.

[0014] Secondly, the present invention provides an ABAQUS simulation task state matrix diagnosis and closed-loop scheduling system, which adopts the following technical solution: The task acquisition module is used to obtain the task root directory containing one or more ABAQUS simulation packages; The execution product reading module is used to read at least two types of execution products from each simulation package, including the execution plan, execution list, status file, log file, output database status, standard result grid file, and grid evidence file. The execution readiness judgment module is used to judge the execution readiness of ABAQUS commands based on visibility and permission pre-check results, and generate an execution readiness list; The status matrix generation module is used to extract status fields from the run plan, run list, .sta status file, .log log, output database status, standard result grid file, grid quality file, grid independence evidence file and license pre-inspection results, and merge them into the final port status according to the preset priority when the status is inconsistent, while outputting conflict description and evidence index. The iterative strategy generation module is used to generate at least one of the following strategies based on the final port state, conflict description, number of retries, idempotent key and expected product verification results of the packet-level state matrix: permission blocking wait, re-solution, result export, mesh verification, mesh independence supplementation, manual verification or acceptance of results. The scheduling result output module is used to output closed-loop scheduling results including packet-level state matrix, iteration strategy, planned actions, action write-back records and audit records; in planned mode, it outputs the action file to be audited; in actual execution mode, it executes the action and writes back the return code, generated file, log summary and execution time to drive the next round of matrix update.

[0015] Thirdly, the present invention provides a readable storage medium, which adopts the following technical solution: A readable storage medium storing computer instructions that, when executed by a processor, implement the method as described in any one of the first aspects above.

[0016] In summary, compared with the prior art, the present invention has at least one of the following beneficial technical effects: This invention reads various execution artifacts, including execution plans, execution lists, status files, log files, output database status, standard result grid files, and grid evidence files. It then combines command visibility and permission pre-check results to generate a packet-level state matrix. This matrix accurately distinguishes various task states such as permission blocking, solution abort, output database anomalies, missing standard result grids, abnormal grid quality, and insufficient evidence of grid independence. Based on the state matrix, it automatically generates corresponding iterative strategies and outputs closed-loop scheduling results containing planned actions and audit logs. This enables multi-dimensional state diagnosis, closed-loop iterative scheduling, and pre-submission auditability for batch simulation tasks, improving the recoverability, traceability, and execution efficiency of automated simulation task management. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart of an embodiment of the ABAQUS simulation task state matrix diagnosis and closed-loop scheduling method of the present invention is shown.

[0019] Figure 2 A schematic diagram of an embodiment of the pre-inspection and audit output structure of the present invention is shown.

[0020] Figure 3 A schematic diagram of an embodiment of the product state matrix structure of the present invention is shown.

[0021] Figure 4 A schematic diagram of an embodiment of the iterative strategy decision tree of the present invention is shown.

[0022] Figure 5 A flowchart illustrating an embodiment of the processing flow for the planned mode and the actual execution mode of the present invention is shown.

[0023] Figure 6 The diagram shows a block diagram of an embodiment of the ABAQUS simulation task diagnosis and closed-loop scheduling system of the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. Furthermore, it should be understood that the specific embodiments described herein are only for illustration and explanation of this application and are not intended to limit this application.

[0025] It should be noted that the order of description of the following embodiments is not intended to limit the preferred order of the embodiments of this application. Furthermore, the descriptions of each embodiment in the following embodiments have their own emphasis; for parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0026] The method steps described in this embodiment of the invention can be executed in the order described in the specific implementation, or the execution order of each step can be adjusted according to actual needs, provided that the technical problem can be solved. These are not listed one by one here.

[0027] The present invention will be further described in detail below with reference to the accompanying drawings.

[0028] Reference Figure 1 This invention provides a method for ABAQUS simulation task state matrix diagnosis and closed-loop scheduling. The method obtains a task root directory containing one or more ABAQUS simulation packages and reads at least two types of execution artifacts from each simulation package's execution plan, execution list, status file, log file, output database status, standard result grid file, and grid evidence file. During the execution environment check phase, the method performs execution readiness judgment on ABAQUS command visibility and permission pre-check results, generating an execution readiness list. Based on the execution artifacts and the execution readiness judgment, a package-level state matrix is ​​generated. The package-level state matrix records the port status, grid quality status, grid independence evidence status, and standard result grid existence status of each simulation package. An iteration strategy is generated according to each row of the package-level state matrix. The iteration strategy includes at least one of permission blocking wait, re-solving, result export, grid verification, grid independence supplementary verification, or result acceptance. The method outputs a closed-loop scheduling result containing the package-level state matrix, the iteration strategy, planned actions, and audit logs.

[0029] like Figure 1 As shown, the main process starts by reading the task root directory and the execution plan, goes through the execution environment and license pre-check, collects logs, status ODB and result grid, generates status matrix and evidence index, and outputs iteration strategy and audit file. Figure 1 The following diagram illustrates the handling branches for four abnormal or special states. When the execution environment and permission pre-check phase detects permission blocking, command invisibility, or timeout states, the port status of the corresponding simulation package is marked as the corresponding abnormal state. When the log collection and status ODB phase detects empty ODBs, missing fields, or solution aborts, the corresponding port abnormal state is recorded in the status matrix. In the status matrix generation phase, mesh quality and mesh independence evidence are assessed for the standard result mesh file. In the output phase, corresponding iteration strategy types are generated based on different status rows in the status matrix, including rerun, result export, mesh verification, or result acceptance.

[0030] Reference Figure 2 The embodiments of the present invention also provide a structure for performing pre-inspection and audit output. Figure 2 The left side contains three inputs: ABAQUS command discovery, license preflight check, and historical blocking evidence. ABAQUS command discovery detects whether ABAQUS commands are visible in the current execution environment; license preflight checks the availability of ABAQUS solver licenses before executing the actual solver; and historical blocking evidence scans for license blocking artifacts generated during previous executions. These three inputs are sent to the execution readiness list processing flow.

[0031] The execution readiness check includes command discovery, license preflight command return status, timeout status, historical license blocking artifact scanning, and readiness suggestion generation. The execution readiness list contains four status indicators: ready to execute (execution ready), blocked_by_license (license blocked), command_not_found (command not found), and timeout (timeout status). In some implementations, the execution readiness check also includes parsing the license preflight command return status code and scanning historical license blocking artifacts to obtain previous blocking records.

[0032] The output of the execution readiness list processing flow includes three items: a readiness.json file, a readiness.csv file, and an iteration strategy input. The readiness.json and readiness.csv files record the execution readiness status judgment results for each simulation package in JSON and CSV formats, respectively. The iteration strategy input passes the status judgment results from the execution readiness list to the subsequent iteration strategy generation flow, serving as one of the bases for generating the iteration strategy.

[0033] When the pre-qualification result indicates that the ABAQUS solver license is unavailable, the port status of the corresponding simulation package is set to license blocking, and the iteration strategy is set to a license blocking wait strategy. The audit log records a summary of the pre-qualification output, historical blocking evidence, and recovery suggestions. The pre-qualification output summary includes the return status and output information of the pre-qualification command; historical blocking evidence includes license blocking records generated during previous execution; and recovery suggestions include recommendations such as restoring a valid license, reducing concurrency, or delaying retries. In some implementations, the license blocking wait strategy generates license recovery and delayed retry strategies as a concrete implementation of the iteration strategy, so that the solver task can be automatically resubmitted after license recovery.

[0034] Reference Figure 3This invention also provides a structure for the execution product state matrix. The package-level state matrix includes six core fields used to record the multi-dimensional state information and evidence index of each simulation package. The first field, `package_dir`, represents the simulation package identifier, used to uniquely identify each simulation package directory under the task root directory. The second field, `portstatus`, represents the port status, used to record the solution execution status of the simulation package, including status types such as completed, permission blocked, command not visible, solution aborted, timeout, or solution failed. The third field, `mesh_status`, represents the mesh quality status, used to record the mesh quality check results of the standard result mesh file. The fourth field, `mesh_independence`, represents the mesh independence evidence status, used to record whether the simulation package has a mesh independence evidence file. The fifth field, `has_result_mesh`, represents the standard result mesh existence status, used to record whether the standard result mesh file exists in the simulation package directory. The sixth field, `artifact_paths`, represents the evidence index, used to record the path information of various evidence files.

[0035] It should be noted that the standard result grid existence state, grid quality state, and grid independence evidence state in the packet-level state matrix are used to express whether the execution product meets the conditions for continued scheduling. The objects processed are file existence, verification conclusion, evidence index, and state conflict. No restrictions are placed on the calculation rules of physical evaluation indicators such as the internal field mapping of the standard result grid, the output database structure discovery process, or interface stress.

[0036] In one state fusion example, a license error occurred in the .log file of a simulation package, and the standard result mesh file was missing. The system determined the final port state to be blocked_by_license and wrote result_mesh_missing as the overridden secondary state in the conflict description. Another simulation package's .sta file showed normal completion and the ODB could be opened, but the standard result mesh was missing. The system determined the final port state to be export_required and generated a result export strategy instead of resolving or directly accepting the result.

[0037] The evidence index field of the package-level state matrix includes path indexes for the run manifest, state file, mesh file, and result mesh file. The evidence index for the run manifest points to the run manifest file in the simulation package directory, the evidence index for the state file points to the state file in the simulation package directory, the evidence index for the mesh file points to the mesh quality file in the simulation package directory, and the evidence index for the result mesh file points to the standard result mesh file in the simulation package directory. In some implementations, the evidence index field also includes a path index for the mesh independence evidence file.

[0038] When generating the package-level state matrix, a root directory evidence inheritance mechanism is used to handle mesh independence evidence. When a mesh independence evidence file exists in the task root directory but not in a single simulation package directory, the mesh independence evidence file in the task root directory is used as the matrix evidence index for that simulation package. This inheritance mechanism allows multiple simulation packages to share a common mesh independence evidence file in the task root directory, avoiding the duplication of the same mesh independence evidence in each simulation package directory. In some implementations, when a mesh independence evidence file exists in a simulation package directory, it is preferentially used as the matrix evidence index for that simulation package.

[0039] Reference Figure 4 This invention also provides the structure of an iterative strategy decision tree. The iterative strategy decision tree starts with reading the rows of the state matrix and generates corresponding iterative strategies based on the port state, mesh quality state, mesh independence evidence state, and standard result mesh existence state of each row in the packet-level state matrix. The decision tree branches downwards from the nodes of the read state matrix rows into five branches, each corresponding to one of five different state combinations and their corresponding processing strategies.

[0040] The first branch of the decision tree corresponds to the blocked_by_license state. When the port state is blocked, the iteration strategy is set to restore a valid license, reduce concurrency, or delay retries. This branch handles cases where the license preflight result indicates that the ABAQUS solution license is unavailable. It retains a summary of the license preflight output and historical blocking evidence in the audit log so that the solution task can be automatically resubmitted after the license is restored.

[0041] The second branch of the decision tree corresponds to the solver aborted state. When the port status is solver aborted, timed out, or solver failed, a re-solver strategy is generated, and the original logs, status file, and retry flag are retained in the audit log. The processing actions of this branch are to retain the log, correct the blocking factors, and rerun the task package. In some implementations, when the port status is result export failed, a re-solver strategy is generated, and the original logs, status file, and retry flag are retained in the audit log to trace the reason for the export failure and re-execute the solver after correction.

[0042] The third branch of the decision tree corresponds to a completed but missing result_mesh state. When the port state is completed and the standard result mesh file does not exist, a result export strategy is generated. The result export strategy calls the ABAQUS output database export script to generate the standard result mesh file and regenerates the packet-level state matrix after the export is complete. The processing action of this branch is to perform result export and reconstruct the state matrix, so that subsequent iterations can continue closed-loop scheduling based on the updated state matrix.

[0043] The fourth branch of the decision tree corresponds to the insufficient grid evidence state. When the port status is completed and the standard result grid file exists, but the grid quality status fails, a grid review strategy is generated, and the grid quality file to be checked and recommended review actions are output. The processing action of this branch is grid review and generation of refinement tasks. In some implementations, when the grid independence evidence status does not meet preset conditions, a grid independence supplementation strategy is generated, requiring the supplementation of grid independence evidence files.

[0044] The fifth branch of the decision tree corresponds to the "evidence complete, accepted" state. When the standard result mesh file, mesh quality status, and mesh independence evidence all meet the preset acceptance criteria, the iteration strategy of the corresponding simulation package is set to accept the results and proceed to downstream verification. The processing action of this branch is to enter the downstream result verification process, indicating that the solution results of the simulation package have passed all status checks and are ready to enter the subsequent engineering analysis or report generation stage.

[0045] Reference Figure 5 This invention also provides processing flows for planned mode and actual execution mode. The processing flow begins by reading the packet-level state matrix, then proceeds to a judgment node to determine the current running mode. The judgment node determines whether it is in planned mode based on the running parameters; planned mode is a mode in which the actual solution is not executed.

[0046] When the judgment result indicates that the system is in planning mode, the closed-loop scheduling result outputs a planned action file in planning mode without executing the actual solution. The planned action file records the decision, action, action status, and next step description for each simulation package. The decision field records the iterative strategy type generated based on the package-level state matrix; the action field records the specific operation to be executed; the action status field records the current state of the action; and the next step description field records guidance information for subsequent processing. In some implementations, the planned action file also records whether each simulation package has been executed, indicating whether the planned action of that simulation package has been completed in a previous execution cycle.

[0047] The output of the action plan file allows users to audit the export, rerun, or review actions to be performed before submitting actual ABAQUS commands. By auditing the action plan file, users can pre-check whether the iteration strategy and planned actions for each simulation package meet expectations, thereby reducing the risk of accidentally triggering the actual solution. In some implementations, the action plan file is output in JSON or CSV format for integration with external auditing tools or workflow management platforms.

[0048] When the judgment result indicates that it is in real execution mode, the processing flow directly submits real ABAQUS commands. In real execution mode, the corresponding export, rerun, or verification operations are performed according to the iteration strategy of each simulation package in the package-level state matrix. In some implementations, the package-level state matrix is ​​regenerated after the real execution mode is completed, so that the next iteration can continue closed-loop scheduling based on the updated state.

[0049] After an action is completed in the real execution mode, the system checks whether the action has been successfully executed based on the action identifier and idempotent key. If the same idempotent key has already generated and passed the verification of the standard result mesh, the action is marked as skipped_already_done (completed, skipped). If the port status is still solver_aborted (solver aborted) after two consecutive rounds of resolving, it is updated to manual_review_required (requires manual review) and automatic retry is stopped. If a standard result mesh is generated after the exported action is completed, the packet-level state matrix is ​​regenerated and the mesh quality and mesh independence evidence judgment is entered.

[0050] In summary, the ABAQUS simulation task state matrix diagnosis and closed-loop scheduling method provided in this embodiment of the invention obtains the task root directory and reads various execution products such as the execution plan, execution list, state file, log file, output database status, standard result grid file, and grid evidence file. It combines ABAQUS command visibility and permission pre-check results to generate an execution ready list, and then constructs a packet-level state matrix containing port status, grid quality status, grid independence evidence status, and standard result grid existence status. Based on the state combination of each row in the state matrix, it generates iterative strategies such as permission blocking and waiting, resolving, result export, grid verification, grid independence supplementary verification, or result acceptance through a decision tree. Finally, it outputs a closed-loop scheduling result containing the state matrix, iterative strategies, planned actions, and audit records. It also supports outputting planned action files in planned mode to achieve pre-submission auditing, thereby realizing multi-dimensional state diagnosis, closed-loop iterative scheduling, and traceable management of batch simulation tasks.

[0051] Reference Figure 6This invention also provides an ABAQUS simulation task state matrix diagnosis and closed-loop scheduling system 600. System 600 includes a task acquisition module 602, an execution product reading module 604, an execution readiness judgment module 606, a state matrix generation module 608, an iterative strategy generation module 610, and a scheduling result output module 612.

[0052] The task acquisition module 602 is used to acquire the task root directory containing one or more ABAQUS simulation packages. The task acquisition module 602 receives the user-specified task root directory path and scans all simulation package directory structures under that path. In some embodiments, the task acquisition module 602 also verifies the validity of the task root directory to ensure that the directory structure conforms to a preset simulation package organization specification.

[0053] The execution product reading module 604 is used to read at least two types of execution products from each simulation package, including the run plan, run list, status file, log file, output database status, standard result grid file, and grid evidence file. The execution product reading module 604 obtains a list of simulation package directories from the task acquisition module 602 and traverses each simulation package directory to read the corresponding execution product files. In some embodiments, the execution product reading module 604 performs format verification and integrity checks on the read execution products.

[0054] The execution readiness assessment module 606 is used to assess the visibility of ABAQUS commands and the results of the license preflight check, generating an execution readiness list. The execution readiness assessment module 606 detects whether ABAQUS commands are visible in the current execution environment and calls the license preflight check command to check the availability of ABAQUS solution licenses. The execution readiness assessment module 606 also scans historical blocking evidence to obtain license blocking records generated during previous executions. In some implementations, the execution readiness assessment module 606 outputs the execution readiness list to a specified directory in JSON and CSV formats.

[0055] The state matrix generation module 608 generates a packet-level state matrix based on the execution products and execution readiness criteria. The packet-level state matrix records the port status, mesh quality status, mesh independence evidence status, and standard result mesh existence status of each simulation packet. The state matrix generation module 608 receives execution product data from the execution product reading module 604 and the execution readiness list from the execution readiness criteria module 606, and combines the above information to generate the packet-level state matrix. In some embodiments, the state matrix generation module 608 uses a root directory evidence inheritance mechanism to handle mesh independence evidence. When the simulation packet directory does not contain a mesh independence evidence file, the mesh independence evidence file in the task root directory is used as the matrix evidence index for that simulation packet.

[0056] The iterative strategy generation module 610 generates an iterative strategy based on each row of the packet-level state matrix. The iterative strategy includes at least one of the following: permission blocking wait, resolving, result export, mesh verification, mesh independence verification, or result acceptance. The iterative strategy generation module 610 receives the packet-level state matrix from the state matrix generation module 608 and generates a corresponding iterative strategy based on the combination of port states, mesh quality states, mesh independence evidence states, and standard result mesh existence states for each row. In some implementations, the iterative strategy generation module 610 uses a decision tree structure to automatically generate the iterative strategy.

[0057] The scheduling result output module 612 outputs closed-loop scheduling results, including a package-level state matrix, iteration strategy, planned actions, and audit logs. The scheduling result output module 612 receives the iteration strategy from the iteration strategy generation module 610 and outputs the closed-loop scheduling results to a specified directory. In planning mode, the scheduling result output module 612 outputs a planned action file, recording the decisions, actions, action states, and next steps for each simulation package, so as to audit the export, rerun, or review actions to be executed before submitting the actual ABAQUS commands. In actual execution mode, the scheduling result output module 612 submits actual ABAQUS commands according to the iteration strategy to execute the corresponding operations.

[0058] In system 600, the modules are connected sequentially in the following order: task acquisition module 602, execution product reading module 604, execution readiness judgment module 606, state matrix generation module 608, iteration strategy generation module 610, and scheduling result output module 612, forming a complete data stream from task acquisition to scheduling result output. The output of task acquisition module 602 is passed to execution product reading module 604. The output of execution product reading module 604 and the output of execution readiness judgment module 606 are jointly passed to state matrix generation module 608. The output of state matrix generation module 608 is passed to iteration strategy generation module 610. The output of iteration strategy generation module 610 is passed to scheduling result output module 612.

[0059] This invention also discloses a readable storage medium.

[0060] A computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any of the above embodiments. The computer-readable storage medium may include any entity or device capable of carrying a computer program, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc. The computer program includes computer program code. The computer program code may be in the form of source code, object code, an executable file, or some intermediate form, etc. The computer-readable storage medium may include any entity or device capable of carrying computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), and a software distribution medium, etc.

[0061] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0062] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a system including a processing module or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

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

Claims

1. A method for ABAQUS simulation task state matrix diagnosis and closed-loop scheduling, characterized in that, Includes the following steps: Obtain the task root directory containing one or more ABAQUS simulation packages; Read at least two types of execution artifacts from the run plan, run list, status file, log file, output database status, standard result grid file, and grid evidence file of each simulation package; Perform execution readiness checks on the visibility and permission pre-check results of ABAQUS commands, and generate an execution ready list; Based on the execution product and the execution readiness judgment, a packet-level state matrix is ​​generated. The packet-level state matrix records the port status, mesh quality status, mesh independence evidence status, and standard result mesh existence status of each simulation packet. An iterative strategy is generated based on each row of the packet-level state matrix. The iterative strategy includes at least one of the following: permission blocking wait, re-solution, result export, mesh verification, mesh independence verification, or acceptance of result. The output includes the packet-level state matrix, the iteration strategy, the planned actions, and the audit logs.

2. The method according to claim 1, characterized in that, The packet-level state matrix includes simulation packet identifier, port status, mesh quality status, mesh independence evidence status, standard result mesh existence status, and evidence indexes for the run list, status file, mesh file, and result mesh file; The existence status, quality status, and evidence status of the standard result grid are only used as state evidence of the simulation package execution product to determine whether result export, grid verification, grid independence supplementation, or result acceptance is required. The generation algorithm, field mapping rules, or specific physical result evaluation methods of the standard result grid are not limited.

3. The method according to claim 1, characterized in that, When the license preflight result indicates that the ABAQUS solution license is unavailable, the port status of the corresponding simulation package is set to license blocking, the iteration strategy is set to license blocking waiting strategy, and the license preflight output summary, historical blocking evidence, and recovery suggestions are recorded in the audit log.

4. The method according to claim 1, characterized in that, When the port status is a solution aborted, timed out, or failed, a re-solution strategy is generated, and the original log, status file, and retry identifier are retained in the audit record.

5. The method according to claim 1, characterized in that, When the port status is completed and the standard result grid file does not exist, a result export strategy is generated. The result export strategy calls the ABAQUS output database export script to generate the standard result grid file, and regenerates the packet-level state matrix after the export is completed.

6. The method according to claim 1, characterized in that, The closed-loop scheduling results are output as a planned action file in the planning mode without executing the actual solution. The planned action file records the decisions, actions, action status and next steps of each simulation package, so as to audit the export, rerun or review actions to be executed before submitting the actual ABAQUS command.

7. The method according to claim 1, characterized in that, The step of generating a packet-level state matrix based on the execution product and the execution readiness determination includes: Read simulation package identifier, expected input file, expected output database and post-processing script from the run plan; read generated files and run commands from the run list; read incremental completion status, solution abort flag and normal completion flag from the .sta status file; read license error, command error, analysis error, timeout and abnormal termination keywords from the .log log; read whether ODB exists, whether it is empty, whether it can be opened and the number of frames from the output database status; read whether the result mesh exists and the verification status from the standard result mesh file; read mesh quality status and evidence status from the mesh quality file and mesh independence evidence file. When multiple execution product states are inconsistent, the final port state and iteration strategy are determined according to the priority of command not being visible or allowed to be blocked, the actual solution still running, the solution being terminated or failed, the output database not existing or empty, the standard result mesh being missing, the result mesh verification failing, the mesh quality not passing, insufficient evidence of mesh independence, and complete and acceptable evidence. The overwritten secondary state, the corresponding evidence file path, and the reason for the conflict are written into the conflict description field of the state matrix.

8. The method according to claim 1, characterized in that, The closed-loop scheduling result includes a dynamic feedback mechanism between the planned mode and the actual execution mode: In planning mode, for each planned action, an action identifier, idempotent key, target simulation package, trigger state, expected output, maximum number of retries, preconditions and prohibition conditions are generated. In real execution mode, after executing the planned action, the action result, return code, generated file, log summary and execution time are read and written back to the packet-level state matrix; Update the retry count, action state, and next iteration strategy based on the write-back results; Repeated runs are prohibited when the same idempotent bond action has successfully generated the expected product; incorrect acceptance of results is prohibited when the standard result grid is missing or the grid evidence fails; and skipping result export is prohibited when the output database has been completed but the result grid is missing. When the number of retries exceeds the threshold or the status remains unchanged for two consecutive rounds, the corresponding simulation package will be marked as requiring manual review, and the reason for stopping will be output in the audit record.

9. An ABAQUS simulation task state matrix diagnosis and closed-loop scheduling system, characterized in that, include: The task acquisition module is used to obtain the task root directory containing one or more ABAQUS simulation packages; The execution product reading module is used to read at least two types of execution products from each simulation package, including the execution plan, execution list, status file, log file, output database status, standard result grid file, and grid evidence file. The execution readiness judgment module is used to judge the execution readiness of ABAQUS commands based on visibility and permission pre-check results, and generate an execution readiness list; The status matrix generation module is used to extract status fields from the run plan, run list, .sta status file, .log log, output database status, standard result grid file, grid quality file, grid independence evidence file and license pre-inspection results, and merge them into the final port status according to the preset priority when the status is inconsistent, while outputting conflict description and evidence index. The iterative strategy generation module is used to generate at least one of the following strategies based on the final port state, conflict description, number of retries, idempotent key and expected product verification results of the packet-level state matrix: permission blocking wait, re-solution, result export, mesh verification, mesh independence supplementation, manual verification or acceptance of results. The scheduling result output module is used to output closed-loop scheduling results, including packet-level state matrix, iteration strategy, planned actions, action write-back records, and audit records. In planned mode, the auditable action file is output. In actual execution mode, the action is executed and the return code, generated file, log summary and execution time are written back to drive the next round of matrix update.

10. A readable storage medium, characterized in that, The readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1-8.

Images