A method for batch generation and life cycle monitoring for CFD test conditions

Abstract

The application discloses a batch generation and life cycle monitoring method for CFD test working conditions, belongs to the field of CFD test working condition generation and life cycle monitoring, and comprises a batch generation process of CFD test working conditions and a CFD test working condition life cycle monitoring process. The application is aimed at multiple CFD programs, constructs multiple sets of configuration templates according to different parameter files, and based on the configuration information of each set of templates, each type of parameter with variable quantity and value is combined and configured to batch generate test working conditions, so that the automation level and efficiency of complex test working condition configuration and generation are significantly improved. Meanwhile, the state of the working condition in each life stage and the operation state in each test task are set and tracked, an extensible rule set is applied to limit the test task, and the corresponding rule component can be adjusted in real time during the execution process of the test task, so that the normal operation of the test process is ensured, and the risk of data confusion is effectively avoided.

Description

Technical Field

[0001] The present application relates to the field of CFD test condition generation and lifecycle monitoring, and in particular to a method for batch generation and lifecycle monitoring of CFD test conditions. Background Art

[0002] Compared with traditional fluid mechanics research that relies on physical experiments, CFD (computational fluid dynamics) software not only reduces time and economic costs by replacing experiments with computer simulations, but also enables high-precision numerical simulations of complex fluid motion, with higher computational accuracy and scenario adaptability.

[0003] In verification and design optimization, CFD testing often requires configuring a large number of working conditions for calculation. Manually configuring the parameters of each working condition to generate the working condition is time-consuming and error-prone, making it difficult to meet the requirements of efficiency and accuracy. Secondly, for the generated test conditions, the existing system lacks effective monitoring of their life cycle, which will lead to confusion in the working condition data and abnormalities in the test process.

[0004] In the process of generating CFD test conditions, manually configuring the parameters of each condition to generate a large number of conditions is time-consuming and error-prone, making it difficult to meet the requirements of CFD software for efficiently and accurately simulating complex fluid motion.

[0005] The existing data generation technology solution is to quickly complete parameter configuration by constructing parameter files and corresponding configuration files in advance. As described in the patent: Method, equipment and medium for generating batch simulation data of multiple working conditions of buildings (application number: 2024113281219), the main steps of batch data generation in this patent are as follows: (1) Determine the target configuration file according to the batch simulation task. The target configuration file includes: target object, reference source file (determined by the target object), target parameter item and candidate parameter value of the target parameter; (2) Traverse the candidate parameter value of each target parameter item and perform Cartesian product to obtain multiple target parameter adjustment methods; (3) According to the parameter adjustment method and reference source file, the simulation software completes the parameter configuration and generates simulation data in batches.

[0006] Compared with the above patent, the differences of the present patent are as follows: 1. The present patent can not only flexibly adjust the range of configurable parameters through the configuration template, but also consider the configuration of various types of parameters, which has stronger expandability and can generate more complex simulation data. 2. The present patent can quickly complete the configuration of the working condition parameters by importing the parameter file or the test working condition generated by the external test, and has more configuration methods, which significantly improves the automation level and efficiency of test working condition management. 3. The different types of parameters in the present patent can be associated, and the matrix parameters are configured in the form of multi-dimensional combination within the group, outside the group, and between the matrices, which can complete the rapid configuration and generation of large quantities of complex working conditions. In particular, part of the parameters within different matrix groups in the matrix can be configured with the same parameter value, so the present application can quickly complete the configuration and generation of differential working conditions (differential working conditions can better assist verification and optimization).

[0007] After the test working condition is generated, since the test working condition not only stores part of the parameter configuration information in ElasticSearch, but also stores the working condition parameter file on the cluster, the tasks related to the test working condition (creating / importing test, running test calculation, running test post-processing, canceling test running, batch adding / modifying / deleting test working condition) will consume a long time, during which time the user can initiate multiple test tasks. If not limited, the test working condition data (files and database information) reused by each test task will be processed at the same time, causing data confusion. The existing technology limits the test task that reuses data by rules, so that only one task can process the reused data at the same time. For example, as shown in the patent "2024104652559", the steps of the system selecting a commercial vehicle route by rules are as follows: (1) collect data and build all potential route lines (including direct and transfer) from the starting point to the destination; (2) evaluate each potential route based on the set time limit and cost parameters, calculate the attribute score, and select the theoretically optimal route; (3) apply time limit priority rules, carrier balance rules (balance the share of multiple carriers), black list rules, etc. to compare and limit the quantitative results of all potential routes and carriers, and select the actual optimal solution.

[0008] This application sets up working condition states covering all life stages of the test working condition and the working condition operation states when executing each test task. By applying a rule set containing rule components such as test status, test operation status, working condition status, working condition operation status, and post-processing flags, it restricts tasks related to the test working condition (tasks that do not meet the requirements will not be executed), and adjusts the corresponding rule components in real time during the execution of the test task. This not only ensures the normal operation of the test process, but also avoids the problem of confusion in reused working condition data when multiple test tasks are initiated. In addition, this patent also introduces test task thread management and dynamically adjusts the task execution priority by calculating the thread task priority score, further optimizing the resource scheduling capabilities of test task management. Summary of the Invention

[0009] The purpose of this application is: in order to overcome the problems of the existing technology, a method for batch generation and life cycle monitoring of CFD test conditions is disclosed, multiple sets of configuration templates are constructed according to different parameter files, and based on the configuration information of each set of templates, various types of parameters with variable quantity and value are combined and configured to batch generate test conditions, which significantly improves the automation level and efficiency of test condition configuration and generation.

[0010] The purpose of this application is achieved through the following technical solutions:

[0011] A method for batch generation and lifecycle monitoring of CFD test conditions, comprising a batch generation process of CFD test conditions, including:

[0012] S101: selecting a configuration template according to the CFD program required for running the test condition, wherein the configuration template includes three types of parameters: definition parameters, matrix parameters, and supplementary parameters, and reading configuration template information from a database;

[0013] If there are definition parameters associated with the matrix parameters, configure the value of at least one associated definition parameter and its supporting information;

[0014] S102: Divide the matrix and the number of parameter groups in the matrix according to the needs, and configure the data of all matrix parameters in the parameter group in each matrix;

[0015] S103: Associating the matrix with the selected definition parameters, and selecting the value of the associated definition parameter of each parameter group from the configured values ​​of the associated definition parameters, and supplementing all configured parameter values ​​of the configured matrix parameters with supplementary parameters;

[0016] S104: Complete parameter configuration (this step can also be completed by importing parameter configuration files or other test condition configuration information);

[0017] S105: Generate test conditions according to the parameter configuration information, and calculate the number of test conditions generated in batches.

[0018] According to a preferred embodiment, step S101 further includes constructing a corresponding number of configuration templates for different CFD programs according to their parameter files, and storing their configuration information in a database.

[0019] According to a preferred embodiment, the definition parameter includes the value of this parameter and its supporting information, and the definition parameter can be associated with the matrix parameter; the matrix parameter can be associated with the definition parameter in the form of a matrix, each set of configuration templates contains at least one matrix parameter, a matrix can be divided into one or more groups, and each group in the matrix can configure the same matrix parameters, but the configured parameter values ​​and the number of values ​​may be different; the supplementary parameter is the information supplement to the matrix parameter.

[0020] According to a preferred embodiment, step S105 includes:

[0021] If the matrix parameters are associated with the definition parameters, the number of load cases generated in one batch load case generation is:

[0022]

[0023] If the matrix parameters are not associated with definition parameters, the number of load cases generated in one batch load case generation is:

[0024]

[0025] in, is the number of operating conditions generated, is the number of matrix partitions, for the number of groups contained in the matrix, Indicates the matrices, for The number of definition parameters associated with the matrix, Indicates the The matrix The associated defines the number of configured parameter values ​​that the parameter is chosen for, for The number of matrix parameters that the matrix can configure, It means the The matrix In the group The number of parameter values ​​configured by the matrix parameter.

[0026] According to a preferred embodiment, the method for batch generation and lifecycle monitoring of CFD test conditions further includes a CFD test condition lifecycle monitoring process, including:

[0027] S201: Initiate a test task involving a test condition and build a test task thread;

[0028] S202: Restricting submission of some test threads according to the rule set, and submitting unrestricted threads;

[0029] S203: Determine whether the test thread running pool resources are sufficient. If so, proceed to step S204; if not, the thread enters the test thread waiting pool whose execution priority can be dynamically adjusted;

[0030] S204: Start running the thread and execute the test task;

[0031] S205: executing different program processing mechanisms according to the rule set;

[0032] S206: Verify the test task execution status according to the rule set and adjust the value of the corresponding working condition rule component;

[0033] S207: End the test task and release system resources.

[0034] According to a preferred embodiment, the rule set includes a plurality of rules, and each rule is composed of a plurality of rule components.

[0035] According to a preferred embodiment, the rule components involved in the rule set include: test status, test running status, working condition status, working condition operation status, and post-processing flag.

[0036] According to a preferred embodiment, the batch generation and lifecycle monitoring method for CFD test conditions also includes completing the scheduling of test tasks for operating test conditions by managing test threads, and adjusting the sizes of the running pool and the waiting pool in real time according to the actual load conditions of the system, wherein the running pool includes threads running simultaneously, and the waiting pool includes threads to be run stored when the running pool is full.

[0037] According to a preferred embodiment, the thread tasks in the waiting pool are prioritized based on the task priority score, and the task priority score is calculated as follows:

[0038]

[0039] Among them, C is the thread task priority score, α, β, γ, δ, and η are the weight coefficients of the five influencing factors: task submission time, task type, number of working conditions involved in the task, average number of working condition parameters involved in the task, and weighted score of the priority type of working condition parameters involved in the task. The sum of the weight coefficients of the five influencing factors is 1; For the current moment, Submit the task time, The maximum waiting time for the thread task. The score is between 0 and 1. Score the thread task type, Indicates the total number of working conditions to be processed by the thread task, Indicates the average number of parameters contained in multiple working conditions involved in the thread task, m indicates the total number of working condition parameters involved in the current thread task, Indicates the weight of the i-th working condition parameter involved in the current thread task, is the maximum possible sum of weights set.

[0040] According to a preferred embodiment, the thread task type score The score interval is [0,1];

[0041] The task priority score is calculated as follows: The reciprocal function is used for smoothing, which means that the greater the total number of working conditions, the lower the score;

[0042] The weight of the i-th working condition parameter involved in the current thread task The value range is [0,1], It is the normalization processing of the weighted scores of the priority types of the working condition parameters.

[0043] The aforementioned main solution of this application and its further options can be freely combined to form multiple solutions, all of which can be adopted and protected by this application. After understanding the solution of this application, those skilled in the art will understand that there are many combinations based on existing technology and common knowledge, all of which are technical solutions to be protected by this application, and these are not exhaustive here.

[0044] Beneficial effects of this application:

[0045] (1) This application not only allows for flexible adjustment of the range of configurable parameters through configuration templates, but also takes into account the combination of various types of parameters, enabling the generation of more complex simulation data.

[0046] (2) This application can quickly complete the configuration of working condition parameters by importing parameter files or test conditions generated by external tests. The configuration methods are more diversified, which significantly improves the automation level and efficiency of test condition management.

[0047] (3) Different types of parameters can be associated with each other in this application, and matrix parameters can be configured in a multi-dimensional combination within a group, outside a group, and between matrices, which can quickly configure and generate a large number of complex working conditions. In particular, some parameters within different matrix groups in the matrix can be configured with the same parameter values. Therefore, this application can quickly complete the configuration and generation of a large number of different working conditions, which can better adapt to the calculation work of CFD software (different working conditions can better assist verification and optimization work).

[0048] (4) This application monitors the working condition life cycle. This application sets the working condition status covering each life stage of the test working condition and the working condition operation status when executing each test task. By applying an extensible rule set including rule components such as test status, test operation status, working condition status, working condition operation status, and post-processing flags, the tasks involving the test working condition are restricted. Since the execution status of the previous test task may affect the execution of subsequent test tasks, this application supports real-time adjustment of the rule components of the corresponding working condition during the execution of the test task, which not only ensures the normal operation of the entire test task process, but also avoids the problem of confusion in reused working condition data when multiple test tasks are initiated.

[0049] (5) This application schedules various tasks of the operating test conditions by introducing test thread management, which not only avoids problems such as response delays and progress loss caused by the long execution time of test tasks, but also dynamically adjusts the task execution priority by calculating the test task priority score, thereby optimizing the resource scheduling capability of the test task management. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 This is a schematic diagram of the batch configuration and generation process of test conditions in the batch generation and lifecycle monitoring method for CFD test conditions in this application;

[0051] Figure 2 This is a schematic diagram of the test task execution process in the batch generation and lifecycle monitoring method for CFD test conditions in this application;

[0052] Figure 3 This is the life cycle status flow diagram of this application's working condition. DETAILED DESCRIPTION

[0053] The following describes the embodiments of the present application through specific examples. Those skilled in the art can easily understand the other advantages and effects of the present application from the content disclosed in this specification. The present application can also be implemented or applied through other different specific embodiments. The details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present application. It should be noted that the following embodiments and features in the embodiments can be combined with each other unless they conflict.

[0054] It should be noted that similar reference numerals and letters denote similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings.

[0055] Example 1

[0056] refer to Figures 1 to 3 As shown in the figure, a batch generation and life cycle monitoring method for CFD test conditions is shown, and the batch generation and life cycle monitoring method for CFD test conditions includes a batch generation process of CFD test conditions and a life cycle monitoring process of CFD test conditions.

[0057] Preferably, the batch generation process of CFD test conditions includes the following steps.

[0058] Step S101: Select a configuration template based on the CFD program required for the test condition. Different configuration templates support different configuration parameters. Configuration templates contain three types of parameters: definition parameters, matrix parameters, and supplementary parameters. Configuration template information is read from a database. If there are definition parameters associated with matrix parameters, the value of at least one associated definition parameter and its supporting information are configured.

[0059] Preferably, step S101 further includes constructing a corresponding number of configuration templates for different CFD programs according to their parameter files, and storing their configuration information in a database.

[0060] Preferably, the definition parameters usually include the value of this parameter and its supporting information (such as the rudder deviation parameter also includes supporting information such as the grid path and grid type), and the definition parameters can be associated with matrix parameters; the matrix parameters can be divided into multiple matrices for configuration, each matrix can contain multiple parameter groups, each group can configure multiple parameters, and the matrix parameters can be associated with the definition parameters in the form of a matrix, and each set of templates contains at least one matrix parameter; the supplementary parameters are information supplements to the matrix parameters (such as the Mach parameter can supplement the calculation height, wall temperature, turbulence model and other information). The template may not have supplementary parameters, or it can supplement information for multiple matrix parameters.

[0061] Step S102: Divide the matrix and the number of parameter groups in the matrix as needed, and configure the data of all matrix parameters in the parameter group in each matrix.

[0062] Specifically, when setting matrix parameters, the matrix parameters are divided into one or more matrices, each matrix contains one or more groups, each group contains one or more matrix parameters, and each group in the matrix can configure the same matrix parameters, but the configured parameter values ​​and the number of values ​​may be different.

[0063] Step S103: associate the matrix with the selected definition parameters, and select the value of the associated definition parameter of each parameter group from the configured values ​​of the associated definition parameters, and supplement all configured parameter values ​​of the configured matrix parameters with supplementary parameters.

[0064] Specifically, matrix parameters can be associated with zero to multiple definition parameters in the form of a matrix, that is, the definition parameters associated with groups within the same matrix are the same, and the associated definition parameter values ​​can only be selected from the configured definition parameter values. However, the value and number of definition parameters that can be associated with each group in the matrix may be different (for example, if the definition parameter steering bias is configured with values ​​1 and 2, if a certain matrix is ​​associated with the definition parameter steering bias, then its internal groups A and B will both be associated with the value of the definition parameter steering bias, but group A can be associated with values ​​1 and 2, and group 2 can only be associated with value 2). Supplementary parameters supplement all configured parameter values ​​of zero to multiple configured matrix parameters with multiple supplementary parameters.

[0065] Step S104: Complete parameter configuration (this step can also be completed by importing parameter configuration files or other test operating condition configuration information).

[0066] Step S105: Generate test conditions according to the parameter configuration information, and calculate the number of test conditions generated in batches.

[0067] Preferably, step S105 includes: if the matrix parameter is associated with the definition parameter, the number of working conditions generated by one batch working condition generation is:

[0068]

[0069] If the matrix parameters are not associated with definition parameters, the number of load cases generated in one batch load case generation is:

[0070]

[0071] in, is the number of operating conditions generated, is the number of matrix partitions, for the number of groups contained in the matrix, Indicates the matrices, for The number of definition parameters associated with the matrix, Indicates the The matrix The associated defines the number of configured parameter values ​​that the parameter is chosen for, for The number of matrix parameters that the matrix can configure, It means the The matrix In the group The number of parameter values ​​configured by the matrix parameters;

[0072] Therefore, the batch generation process of CFD test conditions in this application can not only realize the rapid generation of large quantities of conditions through multi-dimensional combination configuration, but is also compatible with condition parameters containing supporting information and supplementary information, and can simulate more complex test operation scenarios; and because the parameter configuration information can be flexibly adjusted, the number and value of the configuration parameters are different, and the generated conditions are different, so the results of the test operation conditions can better assist in verification and optimization work. In addition, this application also supports the import of parameter configuration files or other test configured condition information to complete the configuration and batch generation process of the conditions in one go, significantly improving the automation level and efficiency of test condition management.

[0073] That is, the present application can not only flexibly adjust the range of configurable parameters through the configuration template, but also take into account the combination of various types of parameters, and can generate more complex simulation data. And by importing parameter files or test conditions generated by external tests, the configuration of condition parameters can be quickly completed. The configuration method is more diversified, which significantly improves the automation level and efficiency of test condition management. Different types of parameters in the present application can be associated, and matrix parameters are configured in a multi-dimensional combination of within-group, outside-group, and between matrices, which can complete the rapid configuration and generation of large quantities of complex conditions. In particular, some parameters within different matrix groups in the matrix can be configured with the same parameter values. Therefore, the present application can quickly complete the configuration and generation of large quantities of differential conditions, and can better adapt to the calculation work of CFD software (differential conditions can better assist verification and optimization work).

[0074] Preferably, the CFD test condition life cycle monitoring process includes the following steps: Figure 2 shown.

[0075] Step S201: Initiate a test task involving test conditions and construct a test task thread; Step S202: Restrict the submission of some test threads according to the rule set, and submit unrestricted threads; Step S203: Determine whether the test thread running pool resources are sufficient, if so, proceed to step S204; if not, the thread enters the test thread waiting pool whose execution priority can be dynamically adjusted; Step S204: Start running the thread and execute the test task; Step S205: Execute different program processing mechanisms according to the rule set; Step S206: Verify the test task execution status according to the rule set, and adjust the value of the corresponding working condition rule component; Step S207: End the test task and release system resources.

[0076] Preferably, the rule set includes several rules, each rule is composed of several rule components. The rule components involved in the rule set include: test status, test running status, working status, working operation status, and post-processing flag.

[0077] The CFD test condition lifecycle monitoring process of this application sets the condition status of each life stage of the test condition and the condition operation status in the test task, and applies an extensible rule set (a rule set can contain multiple rules, and each rule can be composed of multiple rule components) that includes rule components such as test status, test operation status, condition status, condition operation status, and post-processing flags to restrict tasks involving the test condition (tasks that do not meet the requirements will not be processed). During the execution of the test task, this application can also adjust the values ​​of various rule components of the corresponding condition in real time, while ensuring the normal operation of the test process, and avoiding the problem of confusion in reused condition data when multiple test tasks are initiated.

[0078] Specifically, the state flow diagram of the working condition life cycle of this application is as follows: Figure 3 As shown, it shows the flow of working conditions at various stages of the life cycle. Table 1 lists the existing working condition status, working condition operation status (hereinafter referred to as operation status), test status and its locking flag included in the method described in this application. This application can express the life cycle stage of the working condition to the user in a concise and effective manner by setting a smaller number of working condition statuses, and also facilitate the user's experience of filtering working conditions by status. By setting a larger number of working condition operation statuses, it can not only express in detail the test tasks and operation steps being performed by the working condition, but also effectively support the recording of working condition operation logs. The working condition life cycle can be divided into the following stages, during which the values ​​of rule components such as working condition status, working condition operation status, test status, and post-processing flags will flow and change with the execution of test tasks and the application of rule sets (if the changes in the corresponding status and flags are not mentioned, the original status remains unchanged):

[0079] (1) When the user imports a test or creates a test, a batch of working conditions will be generated, the newly generated working condition state is "initialization", and the operation state undergoes changes from "creating" to "creation success" (a working condition that fails to be generated will not exist working condition information); after the newly generated working condition is verified by the rule for the working condition state and the operation state, the post-processing flags of the working condition are all set to "no post-processing" (running test post-processing requires the existence of a running test solution success working condition); and the test state will undergo changes from "queuing" (application rule judges that the test task is in the thread pool queuing queue) to "creating" to "initialization" / "creation failure", after the test is successfully created, once the test starts running, the test state will remain "in progress" and will not change until it is deleted (during which the test can run multiple times and be modified); in addition, the created test can (batch) add test working conditions after being verified by the rule for the test state, the state, operation state and post-processing flag of the added working condition have the same flow as the above-mentioned imported test or created test, and the test state remains unchanged during this period.

[0080] (2) The created working condition can submit a running test solution task (running a test solution can batch submit multiple working conditions for running), before submitting the running test solution task, the rule will be applied to verify whether the test is locked (the test state lock flag in Table 1 is 0) and whether the working condition is cross-locked (the working condition state lock flag in Table 1 is 0 or the operation state lock flag is 0), the locked test and working condition cannot run the test solution; when the running test solution task is submitted, the working condition state is set to "submitting", the operation state is set to "solving", and the test running state is set to "initialization". The running test solution task may capture exceptions through rules before the task is submitted to the cluster, or the task is successfully submitted to the cluster but the cluster fails to submit the to-be-solved job, at this time the working condition state is set to "submission failure", the operation state is set to "solution failure", and the test running state is set to "failure". After the test solution task is successfully submitted, the test running state is set to "running", if the cluster resources are sufficient to support the test working condition running solution, the working condition state is modified to "running", if the cluster resources are insufficient, the working condition state is modified to "queuing" (the test working condition in the queue will start running when the cluster resources are sufficient, and the working condition state will be modified to "running"). Except for the cancellation of the running test solution, when the running test solution ends, the rule is applied to verify the working condition running result, and the value of the corresponding rule component is adjusted, the working condition state of the running success is modified to "success", the working condition operation state is modified to "solution completed", and the post-processing flag is modified to "post-processing"; the working condition state of the running failure is modified to "failure", and the working condition operation state is "solution failure" (the test working condition that ends the solution task can run the solution task again); when all the working conditions running solution fail, the test running state is set to "failure", otherwise the test running state is set to "success".

[0081] (3) After the post-processing flag is verified by the rules, the test conditions that are "capable of post-processing" can be submitted to the test post-processing task. During the test post-processing task, the flow of the working condition status and the test operation status is completely consistent with the test solution. The timing of the operation status change is consistent with the test solution, but the content is different (the operation status of "post-processing", "post-processing completed", and "post-processing failed" in the test post-processing corresponds to the operation status of "solving", "solving completed", and "solving failed" in the test solution). When the test post-processing operation is completed, the test post-processing flag maintains its original status (the test condition that has completed the post-processing task can run the solution / post-processing task again).

[0082] (4) During the running of the test solution / post-processing task, after the test running status is verified by the rules, the user can cancel the operation. When canceling, the working condition status remains unchanged, the operation status is changed to "canceling", and the test running status is set to "canceling". At the end of the cancellation task, the rules are applied to verify the cancellation result. If the working condition is successfully canceled, the working condition status is changed to "interrupted" and the operation status is changed to "cancelled successfully"; if the working condition fails to cancel, the working condition status remains unchanged and the operation status is changed to "cancelled failed"; if all running working conditions are successfully canceled, the test running status is set to "cancelled".

[0083] In addition to the several stages in the above-mentioned working condition life cycle, the values ​​of rule components such as working condition operation status and post-processing flags will also change when performing test tasks such as (batch) modifying test conditions and (batch) deleting test conditions:

[0084] (1) Before executing (batch) modification of test conditions, the rule set is used to verify whether the test is locked (the locking logic is the same as the running test solution) and whether the condition is cross-locked (the locking logic is the same as the running test solution). Locked tests and conditions cannot modify the condition information. When (batch) modifying test conditions, the operation status is changed to "Modifying"; at the end of the test condition modification task, the rules are applied to verify the modification results. If the test condition modification is successful, the operation status is set to "Modification Successful" and the post-processing flag is set to "Cannot Post-Process". If the test condition modification fails, the operation status is set to "Modification Failed" and the post-processing flag remains unchanged.

[0085] (2) Before executing (batch) deletion of test conditions, the rule set is used to verify whether the test is locked (the locking logic is the same as the running test solution) and whether the condition is cross-locked (the locking logic is the same as the running test solution). Locked tests and conditions cannot delete the condition information. When (batch) deleting test conditions, the operation status changes to "deleting"; at the end of the test condition deletion task, the rules are applied to verify the deletion results. If the test condition deletion fails, the operation status changes to "deletion failed"; if the test condition deletion is successful, the condition information including all states and flags is deleted.

[0086] The above-mentioned rule set described in this application can flexibly expand rules and rule components according to application scenarios. For example, when automatically initiating a test resubmission task when solving a timed-out test condition, the rules can be expanded to verify the test status, test operation status, and working condition status. The resubmission flag rule component can also be expanded to determine whether the test resubmission task can be executed.

[0087] This application sets and monitors rule components such as working condition status, working condition operation status, test status and post-processing flags covering the entire life cycle of the working condition, thereby limiting operations such as running test solution during test creation / import, modifying / deleting test conditions during test creation / import, modifying / deleting test conditions that are running solution / post-processing, and directly running post-processing for successfully modified test conditions. It also ensures that the test conditions that have successfully / failed in running the solution can be run again, the test conditions that have successfully run the solution can be run again, the test conditions that have successfully / failed in running the test post-processing can be run again for test solution / post-processing, and the test conditions that can run post-processing can be initiated again even if the modification of the working condition fails. The process can operate normally.

[0088] Table 1 Working status, working operation status, test status and their locking signs

[0089]

[0090] The batch generation and lifecycle monitoring method for CFD test conditions in this application also includes: managing the test thread scheduling operation test tasks of the test conditions to avoid response delays, progress loss, resource waste and other problems caused by the long time-consuming test tasks.

[0091] The thread information of this application includes thread identification, thread status, thread type (i.e. the type of test task being executed), associated tests and other information, and a running pool (threads running simultaneously) and a waiting pool (storing threads to be run when the running pool is full) are configured for the test threads. The size of the running pool and the waiting pool can be adjusted in real time according to the actual load of the system.

[0092] Preferably, for test tasks that take a long time, this application divides the five influencing factors into task submission time, task type, number of working conditions involved in the task, average number of working condition parameters involved in the task, and weighted score of the priority type of working condition parameters involved in the task, as well as their weights and score calculation methods, and calculates the priority score of each thread task in the thread waiting pool. The higher the score, the thread task will be adjusted to a higher priority in the waiting pool queue.

[0093] Since the results of the preliminary test tasks in this application may affect the execution of subsequent test tasks, the three influencing factors of the subsequent test tasks, namely the number of working conditions involved in the tasks, the number of average working condition parameters involved in the tasks, and the weighted scores of the priority types of working condition parameters involved in the tasks, will change in real time with the execution of each test task. Therefore, dynamic adjustment of thread task priorities is achieved, which further optimizes the resource scheduling capabilities of test management and improves the resource utilization of test condition data.

[0094] Preferably, each thread task in the waiting pool is prioritized based on the task priority score, and the task priority score is calculated as follows:

[0095]

[0096] Among them, C is the thread task priority score, α, β, γ, δ, and η are the weight coefficients of the five influencing factors: task submission time, task type, number of working conditions involved in the task, average number of working condition parameters involved in the task, and weighted score of the priority type of working condition parameters involved in the task. The sum of the weight coefficients of the five influencing factors is 1. For the current moment, Submit the task time, The maximum waiting time for a thread task (if the time exceeds this, the task will be cancelled). The score is between 0 and 1, which means that the earlier the submission time, the higher the priority score. Score the thread task type (thread tasks are divided into categories according to priority, and thread tasks of different categories have different scores, with a score range of [0,1]). Indicates the total number of working conditions to be processed by the thread task, A reciprocal function is used for smoothing, which means that the greater the total number of working conditions, the lower the score. Indicates the average number of parameters contained in multiple working conditions involved in the thread task. Its processing method is the same as the total number of working conditions. The more the total number of average working condition parameters involved in the task, the lower the score. m represents the total number of working condition parameters involved in the current thread task. Indicates the weight of the i-th working condition parameter involved in the current thread task (this application sets a weight dictionary based on the priority categories of all working condition parameters that may be involved in the invention, and the weight value range is [0,1], for example: {'Priority Category A': 1.0, 'Priority Category B': 0.8, ...}), is the maximum possible sum of weights, It is the normalization processing of the weighted scores of the priority types of the working condition parameters.

[0097] This application schedules various tasks of the operating test conditions by introducing test thread management, which not only avoids problems such as response delays and progress loss caused by the long execution time of test tasks, but also dynamically adjusts the task execution priority by calculating the test task priority score, thereby optimizing the resource scheduling capabilities of test task management.

[0098] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent replacements and improvements made within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A method for batch generation and lifecycle monitoring of CFD test conditions, characterized in that: The method for batch generation and lifecycle monitoring of CFD test conditions includes a batch generation process of CFD test conditions, including: S101: selecting a configuration template according to the CFD program required for running the test condition, wherein the configuration template includes three types of parameters: definition parameters, matrix parameters, and supplementary parameters, and reading configuration template information from a database; If there are definition parameters associated with the matrix parameters, configure the value of at least one associated definition parameter and its supporting information; S102: Divide the matrix and the number of parameter groups in the matrix according to the needs, and configure the data of all matrix parameters in the parameter group in each matrix; S103: Associating the matrix with the selected definition parameters, and selecting the value of the associated definition parameter of each parameter group from the configured values ​​of the associated definition parameters, and supplementing all configured parameter values ​​of the configured matrix parameters with supplementary parameters; S104: Complete parameter configuration; S105: Generate test conditions according to the parameter configuration information, and calculate the number of test conditions generated in batches; The method for batch generation and lifecycle monitoring of CFD test conditions also includes a CFD test condition lifecycle monitoring process, including: S201: Initiate a test task involving a test condition and build a test task thread; S202: Restricting submission of some test threads according to the rule set, and submitting unrestricted threads; S203: Determine whether the test thread running pool resources are sufficient. If so, proceed to step S204; if not, the thread enters the test thread waiting pool whose execution priority can be dynamically adjusted; S204: Start running the thread and execute the test task; S205: executing different program processing mechanisms according to the rule set; S206: Verify the test task execution status according to the rule set and adjust the value of the corresponding working condition rule component; S207: End the test task and release system resources.

2. The method for batch generation and lifecycle monitoring of CFD test conditions according to claim 1, characterized in that: Step S101 also includes constructing a corresponding number of configuration templates for different CFD programs according to their parameter files, and storing their configuration information in a database.

3. The method for batch generation and lifecycle monitoring of CFD test conditions according to claim 1, characterized in that: A definition parameter contains the value of this parameter and its supporting information, and the definition parameter can be associated with a matrix parameter. A matrix parameter can be associated with a definition parameter in the form of a matrix. Each configuration template contains at least one matrix parameter. A matrix can be divided into one or more groups. Each group in the matrix can configure the same matrix parameters, but the configured parameter values ​​and the number of values ​​may differ. Supplementary parameters are information supplementary to the matrix parameters.

4. The method for batch generation and lifecycle monitoring of CFD test conditions according to claim 1, characterized in that: Step S105 includes: If the matrix parameters are associated with the definition parameters, the number of load cases generated in one batch load case generation is: If the matrix parameters are not associated with definition parameters, the number of load cases generated in one batch load case generation is: in, is the number of operating conditions generated, is the number of matrix partitions, for the number of groups contained in the matrix, Indicates the matrices, for The number of definition parameters associated with the matrix, Indicates the The matrix The associated defines the number of configured parameter values ​​that the parameter is chosen for, for The number of matrix parameters that the matrix can configure, It means the The matrix In the group The number of parameter values ​​configured by the matrix parameter.

5. The method for batch generation and lifecycle monitoring of CFD test conditions according to claim 1, characterized in that: The rule set includes a plurality of rules, and each rule is composed of a plurality of rule components.

6. The method for batch generation and lifecycle monitoring of CFD test conditions according to claim 1, characterized in that: The rule components involved in the rule set include: test status, test running status, working condition status, working condition operation status, and post-processing flag.

7. The method for batch generation and lifecycle monitoring of CFD test conditions according to claim 1, characterized in that: The batch generation and lifecycle monitoring method for CFD test conditions also includes completing the scheduling of test tasks for the operating test conditions by managing test threads, and adjusting the sizes of the running pool and the waiting pool in real time according to the actual load conditions of the system, wherein the running pool includes threads running simultaneously, and the waiting pool includes threads to be run stored when the running pool is full.

8. The method for batch generation and lifecycle monitoring of CFD test conditions according to claim 7, characterized in that: The thread tasks in the waiting pool are prioritized based on their task priority scores. The task priority score calculation expression is: Among them, C is the thread task priority score, α, β, γ, δ, and η are the weight coefficients of the five influencing factors: task submission time, task type, number of working conditions involved in the task, average number of working condition parameters involved in the task, and weighted score of the priority type of working condition parameters involved in the task. The sum of the weight coefficients of the five influencing factors is 1; For the current moment, Submit the task time, The maximum waiting time for the thread task. The score is between 0 and 1. Score the thread task type, Indicates the total number of working conditions to be processed by the thread task, Indicates the average number of parameters contained in multiple working conditions involved in the thread task, m indicates the total number of working condition parameters involved in the current thread task, Indicates the weight of the i-th working condition parameter involved in the current thread task, is the maximum possible sum of weights set.

9. The method for batch generation and lifecycle monitoring of CFD test conditions according to claim 8, characterized in that: Thread task type score The score interval is [0,1]; The task priority score is calculated as follows: The reciprocal function is used for smoothing, which means that the greater the total number of working conditions, the lower the score; The weight of the i-th working condition parameter involved in the current thread task The value range is [0,1], It is the normalization processing of the weighted scores of the priority types of the working condition parameters.

Images