Standardize the method of storing CFD verification and validation case data

Abstract

The method disclosed in the present invention for standardizing the storage of CFD verification and confirmation case data includes case data organization, case data collation standards, and case data storage standards; the case data collation standards include case data naming standards, case description file compilation standards, self-description file definition standards, computational grid data collation standards, computational result data collation standards, and test result data collation standards; the case data storage standards are based on the data output by the case data collation standards, using a hierarchical tree-like organizational structure that is convenient for domestic users to use, and enter the case database from the perspectives of newly created cases, basic properties, case descriptions, comparable data, extraction tools, and related documents. The technical solution provided by the present invention standardizes and ensures the quality of submitted case data, solving the problem of incomplete case data and lack of availability during the construction of a CFD verification and confirmation case library.

Description

Technical Field

[0001] The present invention relates to the field of data processing and storage, and in particular to a method for standardizing CFD verification and validation case data storage. Background Art

[0002] A verification and validation case library is a specialized case library established for the purpose of computational fluid dynamics (CFD) verification and validation. Developed countries abroad have established a number of databases based on different focuses to support CFD software verification and validation, such as the NPARC Consortium's Verification and Validation Database, the European Space Agency's Hypersonic Aerothermodynamics Engineering Database, and the AGARD series of CFD validation experimental datasets. To establish a CFD verification and validation case library for engineering applications, it is necessary to first address the standards for case data entry, focusing on data completeness and availability, establishing case solutions that can effectively support the credibility evaluation of typical numerical wind tunnel software, and finalizing the development of case entry standards. However, currently, China has not established entry standards that effectively support CFD software verification and validation case databases. Summary of the Invention

[0003] In view of this, the present invention provides a method for standardizing the storage of CFD verification and confirmation case data, which overcomes the current problem in China of lacking a verification and confirmation case storage standard that can effectively support the development of case database work.

[0004] A method for standardizing the storage of CFD verification and validation case data, suitable for the storage of aviation experiment or test data, characterized in that:

[0005] S101: Acquire historical aviation test data;

[0006] S102: Determine a calculation example data sorting standard, wherein the calculation example data sorting standard is based on the type or classification of aviation historical test data;

[0007] S103: Organizing the calculation case data, wherein the calculation case data is organized into categories according to preset rules and then cached.

[0008] S104: Determine the standard for storing the example data, delete the cached data and store the duplicate data;

[0009] S105: Obtain parameter data of the current test and match it with the stored data. If they match, the test or experimental data corresponding to the data is obtained. If they do not match, feedback is given.

[0010] S106: After the parameter data of the current test is tested or experimentally determined, repeat steps S102 to S104 to update the database.

[0011] The technical beneficial effects of the present invention are:

[0012] The present invention forms a database standard for calculation case data from the perspective of accuracy, completeness, and standardization. This standard can effectively support the credibility analysis and evaluation of numerical wind tunnel (CFD) software, facilitate the overall integration of calculation case data, and effectively organize historical data to avoid duplication with current experiments and waste of experimental costs and time. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0014] Figure 1 It is the logical model for organizing and managing the calculation data of the present invention;

[0015] Figure 2 It is a schematic diagram of the data organization of the example of the present invention;

[0016] Figure 3 It is the self-describing file definition specification of the present invention;

[0017] Figure 4 It is the content stored in the example database of the present invention;

[0018] Figure 5 This is the example database storage process of the present invention. DETAILED DESCRIPTION

[0019] The embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0020] The following describes the embodiments of the present disclosure through specific examples, and those skilled in the art can easily understand other advantages and effects of the present disclosure from the contents disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all of the embodiments. The present disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed in various ways based on different viewpoints and applications without departing from the spirit of the present disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in the present disclosure, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present disclosure.

[0021] It should be noted that various aspects of the embodiments within the scope of the appended claims are described below. It should be apparent that the aspects described herein can be embodied in a wide variety of forms, and any specific structure and / or function described herein is merely illustrative. Based on this disclosure, it should be understood by those skilled in the art that an aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects described herein can be used to practice the method. In addition, other structures and / or functional practices other than one or more of the aspects described herein can be used.

[0022] The method for storing standardized CFD verification and validation case data provided by the present invention is applicable to the storage of aviation experiment or test data, and the method comprises:

[0023] S101: Obtain historical aviation test data, determined based on existing specifications, test or experimental conditions, parameters, processes and results;

[0024] S102: Determine the standard for arranging the example data. The standard for arranging the example data is based on the type or classification of the historical aviation test data. Specifically:

[0025] Determining the case data organization standards at least includes determining the case data naming specifications. The case data naming specifications at least include case directory naming, geometric configuration naming, computational grid naming, computational result naming, and test data naming. The case directory naming includes the identification of the case type, case name, geometric / application domain characteristics, and a serial number corresponding to a historical aviation test.

[0026] Furthermore, determining the case data compilation standards also includes determining the case description file compilation specifications, which include case identification, case description, test description, calculation description, comparable data and references;

[0027] S103: Organizing the calculation case data. The calculation case data organization includes classifying the aviation historical test data according to preset rules and caching them. Specifically, determining the calculation case data organization standard also includes determining the calculation grid data organization standard, the calculation result data organization standard, and the test result data organization standard, wherein:

[0028] The computational grid data organization standards include grid-related geometric models, grid types, grid names, grid descriptions, grid files, grid quality, and boundary conditions;

[0029] The data collation standards of calculation results include: flow state, calculation parameters, force coefficient data, curve data and image data;

[0030] The test result data collation standards include: basic information, test status, force measurement data and pressure measurement data;

[0031] The case data is managed through a flat tree-like hierarchical model. The bottom layer of the flat tree-like hierarchical model is the verification and confirmation case library, the first layer is the case information or project information, the second layer is the geometric shape and calculation results and test results, and they are cached in a tree-like storage manner.

[0032] S104: Determine the standard for storing the example data, delete the cached data and store the duplicate data, specifically:

[0033] The case data storage standard is based on the data produced by the case data organization standard. It adopts a hierarchical tree-like organizational structure and enters the case database from the perspectives of new cases, basic properties, case descriptions, comparable data, extraction tools, and related documents.

[0034] Use comparison functions to filter out duplicate and identical data and store them after filtering.

[0035] S105: Obtain parameter data of the current test and match it with the stored data. If it matches, the data corresponds to the test or experimental data. If it does not match, feedback is given;

[0036] S106: After the parameter data of the current test is tested or experimentally determined, steps S102 to S104 are repeated to update the database.

[0037] See also Figure 1 and Figure 2 The bottom layer of the flat tree-like hierarchical structure model is the verification and confirmation case library. Different verification and confirmation case libraries can be established according to different purposes. The first layer is the case information or project information, and the second layer is the geometric shape. Parallel to the geometric shape are the calculation results and test results, which are used to store the corresponding result data under the corresponding flow state.

[0038] The calculation example data organization standards of this embodiment include: calculation example data naming standards, calculation example description file compilation standards, self-description file definition standards, calculation grid data organization standards, calculation result data organization standards and test result data organization standards.

[0039] The example data naming conventions of this embodiment include: example directory naming and other file naming. For example, example directory naming follows the principle of "name and meaning", and the general naming rule is: "example type identifier" + "_example name" + "_geometry / application field characteristics" + "_example serial number"; for example, other file naming includes: geometric configuration naming, computational grid naming, computational result naming, and test data naming.

[0040] The example description file compilation specifications of this embodiment include: example identification, example description, test description, calculation description, comparable data and references. In actual work, content-specific example description standards will also be formulated to standardize and ensure the quality of submitted data.

[0041] See also Figure 3 The self-describing file definition specification of this embodiment includes: title description and example description; wherein the title description includes the example name, example description, creator, creation time, version information and update information; the example description includes geometric data, mesh data, flow state, comparable data and document data.

[0042] The computational grid data organization standards of this embodiment include: grid-related geometric models, grid types, grid names, grid descriptions, grid files, grid quality, and boundary conditions.

[0043] The calculation result data sorting standards of this embodiment include: flow state, calculation parameters, force coefficient data, curve data and image data.

[0044] The test result data sorting standards of this embodiment include: basic information, test status, force measurement data and pressure measurement data.

[0045] See also Figure 4 The example data storage standard of this embodiment is based on the data produced by the example data organization standard, and adopts a hierarchical tree-like organizational structure that is convenient for domestic users to use. The example database is entered from the perspectives of new examples, basic attributes, example descriptions, comparable data, extraction tools, and related documents.

[0046] See also Figure 5 The example data storage standard of this embodiment is to ensure the normal operation of the example data in the database. The entered example needs to go through the processes of data inspection, data update, data approval, data storage, data correctness test and data out of the database before it can be completed.

[0047] To implement the above-mentioned data standardization method, the main idea of ​​the present invention is to sequentially provide example data organization, example data organization standards, and example data storage standards from the three sequential processes of collecting, organizing, and storing CFD verification and validation examples. The embodiment of this application is carried out according to the following steps:

[0048] S1. For the CFD verification and validation cases to be stored, first give the organization of the case data. Figure 2 The file directory is organized and managed in a classified manner;

[0049] The specific case data is divided into different types such as calculation data, test data, geometric data, calculation grid data, reference data, auxiliary tools, etc., and included in the corresponding file packages for management. At the same time, a separate case description file (*.mht) and a separate metadata description file (*.xml) are provided. The case description file gives the main information of the case in accordance with the prescribed standards, which is convenient for users to verify and track data; the metadata description file is a self-describing file that provides communal basic data information and is a small "database". At the same time, the entire case library will also provide a separate metadata description file (*.xml) to implement indexing of all cases. According to the example organization method described above, each case includes a set of complete directories and supporting data, namely:

[0050] (1) Computational: stores the complete calculation result file and related data of the example;

[0051] (2) Experimental: stores the complete test result file and related data of the example;

[0052] (3) Geometries: stores the original geometry file data corresponding to the case;

[0053] (4) Grid: stores the data related to the computational grid file corresponding to the example;

[0054] (5) Input (optional): stores the data related to the state parameter input file of the calculation example;

[0055] (6) References (optional): stores the reference document data of the example;

[0056] (7) Utilities (optional): stores data related to the data processing tools used for this example;

[0057] (8) Self-describing files in XML format: store shared data and facilitate database software reading;

[0058] (9) Case description file: A file that describes case information according to a unified template.

[0059] S2. For CFD verification and validation cases containing various types of data, organize the data in accordance with the case data organization standards;

[0060] The case data organization standards are divided into: case data naming standards, case description file compilation standards, self-description file definition standards, calculation grid data organization standards, calculation result data organization standards and test result data organization standards.

[0061] The example data naming convention is divided into: example directory naming and other file naming; see Figure 3 The naming of the example directory follows the principle of "name and meaning", and the general naming rule is: "example type identifier" + "_example name" + "_geometry / application field characteristics" + "_example serial number"; in specific implementation, the naming rule of "example type identifier" is: A represents verification example, which corresponds to a series of examples used for method verification, and is specifically divided into three types: inviscid, laminar, and turbulent. The corresponding specific type identification numbers are AInvisicd, ALaminar, and ATurbulent respectively; B represents confirmation example, which corresponds to a series of standard examples used for simulation confirmation of basic flow problems, and is specifically divided according to flow velocity. There are five types: low, subsonic, transonic, supersonic, and hypersonic, with corresponding type identifiers: BLowspeed, BSubsonic, BTransonic, BSupersonic, and BHypersonic. C represents an application case, which corresponds to a series of standard cases used to confirm engineering application capabilities. Specifically, they are divided into five types based on application domain: bomber transport, combat, missile, rotorcraft, and hypersonic aircraft. The corresponding type identifiers are CTransport, CMilitary, CMissiles, CRotocopter, and CHypvech. The "Case Name" is user-defined, generally using the "camel case" method, with a maximum of 12 characters. The "Geometry / Application Domain Features" name should be named according to the case type. The corresponding naming rule is: for cases identified as type A (Verification Case) and B (Confirmation Case), the geometry feature name should be used or not named. When naming based on geometric features, the principle of "names that are self-explanatory" should be followed, such as airfoil, wing, body, and wingbody. For examples with type identifier C (application examples), the naming should generally be based on the application domain characteristics, including aeroforce, aeroheat, dynamics, sepstore, and aeroelast. The "example number" should be a three-digit number, starting with "001," to distinguish easily confused examples.

[0062] See also Figure 2, and the naming of other files is divided into: geometric configuration naming, computational grid naming, computational result naming, and test data naming. In the specific implementation, the geometric configuration naming rule is: model.iges, where model is the name of the example. According to the principle of "name and meaning", it is identified with an abbreviated English name. The definition of model in the following file naming is the same. The computational grid naming rule is: in general problems, the structural grid is named model_str.cgns, and the unstructured grid is named model_unstr.cgns. For multi-body separation, the static model uses model1_str.cgns, and the motion model uses model2_str.cgns. For aeroelasticity, the modal data format is model_mode1.dat, model_mode2.dat, etc.; the structural property computational grid format is model.bdf. The computational result naming rule is: the structural grid computation result is named model_cal_result_str.dat, and the unstructured grid computation result is named model_cal_result_unstr.dat, where result is identified according to the specific data category. The naming rule of the experimental data is: model_exp_result.dat, and the result definition is the same as the calculation result naming.

[0063] In the specific implementation, the compilation specifications of the case description file are shown in Table 1:

[0064]

[0065]

[0066] See also Figure 3 The self-describing file definition specification is divided into: title description and case description; the title description includes the case name, case description, creator, creation time, version information and update information; the case description includes geometric data, mesh data, flow state, comparable data and document data.

[0067] In specific implementation, the calculation grid data collation standard is shown in Table 2:

[0068]

[0069] Table 2

[0070] See also Figure 3 The self-describing file definition specification is divided into: title description and case description; the title description includes the case name, case description, creator, creation time, version information and update information; the case description includes geometric data, mesh data, flow state, comparable data and document data.

[0071] In specific implementation, the calculation grid data sorting standards are shown in Table 3:

[0072]

[0073] Table 3

[0074] Computational grid arrangement example:

[0075] 1. Geometric shape processing

[0076] The actual geometry of an aircraft is often created using CAD software (such as CATIA, UG, and PRO / E). Directly importing this geometry into mesh generation software (such as ICEM CFD and Gridgen) can create a mesh with data additions and subtractions, and the model surface can contain gaps, holes, and duplicate points, lines, and surfaces. This data does not meet the requirements of mesh generation. Therefore, before mesh generation, the geometry model should be inspected for geometric defects such as gaps, holes, and duplicate points, lines, and surfaces. Furthermore, it is important to evaluate which geometric features can be omitted or simplified during the integrated calculation.

[0077] The main tasks involved in geometric shape processing include repairing gaps and holes in the model, removing unnecessary geometric components, deleting duplicate points, lines, and surfaces, reconstructing lost model data, determining the intersection lines of connected model components (fuselage-wing intersection, fuselage-tail intersection, wing-pylon intersection, pylon-pod intersection, etc.), and trimming geometric surfaces. Through geometric processing, the processed geometric shape curves are guaranteed to be consistent with the original data description.

[0078] 2. General principles of grid quality assessment

[0079] By evaluating computational mesh quality, analyzing the consistency between the computational mesh and flow field characteristics, and analyzing the compatibility between the computational mesh and the solver, we have developed a set of CFD computational mesh quality analysis methods. The goal is to improve mesh quality and solution accuracy, and effectively evaluate the credibility of CFD software. The following provides mesh generation recommendations for typical configurations.

[0080] 3. Wing Mesh Generation Suggestions (Cruise Configuration)

[0081] The wing grid adopts a CO-type grid topology. The grid spacing at the leading and trailing edges of the wing is 0.1% of the local chord length. The grid spacing ratio along the rest of the flow direction is no more than 1.25, and the transition is smooth.

[0082] The grid spacing between the wing root and wingtip is 0.1% of the wing half span, and the maximum grid spacing along the span is 1% of the half span. The grid spacing ratio is no more than 1.4, and the transition is smooth.

[0083] The wingtip grid adopts O-shaped grid topology embedding, with the number of embedded grid points not less than 9 grid points; the trailing edge of the wing with thickness has not less than 9 grid points;

[0084] The first layer of grid points in the wing boundary layer is 1.0E-06, the grid spacing ratio is 1.2, and the number of boundary layer layers is not less than 33. Ensure that the grid lines of the boundary layer are orthogonal to the wing surface, and the inclination angle is preferably not less than 40 degrees.

[0085] 4. Wing-body assembly grid generation suggestion (cruise configuration)

[0086] The wing-body combination grid topology is recommended to adopt an outer wrapped O-type grid topology, or an H-type topology for the fuselage and an O-type topology for the wing;

[0087] The first layer of the boundary layer grid of the fuselage and wing has a grid point of 1.0E-06, a grid spacing ratio of 1.2, and a boundary layer number of no less than 33 layers. The grid lines of the boundary layer are orthogonal to the wing surface.

[0088] The grid spacing at the head and tail of the fuselage is 2% of the reference chord length, the grid spacing is no more than 1.4, and a uniform transition is maintained. For planes that appear at the tail of the fuselage, an embedded O-shaped grid topology is used to extend to the far field to improve the distribution quality of local grid points.

[0089] The grid point distribution of the wing is the same as the grid generation principle of a single wing. The angle between the grid line at the wing-body junction and the fuselage and wing is kept at about 45 degrees as much as possible.

[0090] 5. Wing-body assembly grid generation suggestions (lift-enhancing configuration)

[0091] 1) Mesh topology

[0092] Select the appropriate grid topology to meet the CFD program's requirements for grid tilt, aspect ratio, and grid spacing ratio;

[0093] The grid topology of the high-lift device is recommended to be "OO" type, with the fuselage, main wing, leading edge slats and trailing edge flaps wrapped with "O"-shaped grids, and local "O" grids are used at the main wing, slats and flap wingtips to improve the grid quality.

[0094] 2) Grid distribution

[0095] The grid spacing along the chordwise distribution on the leading and trailing edges of the wings, slats and flaps is 0.1% of the local chord length;

[0096] The mesh of the wing root and wing tip is 0.1% of the half span;

[0097] The span-wise grid spacing at the wing root is 1% of the half span, the span-wise grid spacing at the wing tip is 0.1% of the half span, and the wing trailing edge has no fewer than 9 grid cells;

[0098] The grid spacing at the nose and tail of the fuselage is 2% of the reference chord length;

[0099] Avoid using tilted elements. The angle between hexahedral grid lines should be optimized to be close to 90 degrees. It is best not to exceed 140 degrees or less than 40 degrees.

[0100] The aspect ratio of each unit does not exceed 150, and the grid spacing growth ratio does not exceed 1.4.

[0101] 3) Boundary layer grid

[0102] The grid spacing of the first and second layers of the boundary layer is about 1.0E-6 to ensure that the Yplus value is close to 1. The grid spacing ratio after that is 1.2, and the number of layers is not less than 33;

[0103] An orthogonal grid is used near the solid wall, and the angle between the grid lines and the solid wall boundary or the computational domain boundary is close to 90 degrees.

[0104] 4) Grid distribution of seam and wake area

[0105] In critical areas where large gradients or large flow changes occur, such as shock waves and large shear regions, a denser and more standardized grid is used;

[0106] In civil aircraft calculations, the meshes between the main wing and slats, and between the main wing and flaps are refined, and a uniform transition is maintained with the meshes of the boundary layer.

[0107] The grids in the slat wake area, the main wing wake area and the flap wake area are denser and transition evenly.

[0108] 5) Grid size

[0109] The grid size of the lift-boosting device generated according to this principle is about 8 to 10 million grid cells.

[0110] 6) Calculation domain selection

[0111] The computational domain range needs to be able to capture the relevant flow characteristics. If necessary, the influence of the computational domain selection on the sensitivity of the results can be checked.

[0112] The calculation domain takes 100 times the average aerodynamic chord length in the flow direction and 50 times the average aerodynamic chord length in the span direction.

[0113] 7) Mesh quality control

[0114] The grid has no negative volume and the grid quality determinant index is not less than 0.3.

[0115] 6. Suggestions for generating meshes for complex configurations of the entire aircraft

[0116] 1) Structural grid

[0117] It is very necessary to carry out the overall design of the π-shaped blade, edge strip, horizontal / vertical tail and overall configuration, and ensure reasonable grid distribution, grid density, grid stretch rate and boundary layer grid distribution.

[0118] For wingtip missiles, an "OO" type grid topology is used to ensure the orthogonality of the grid near the missile. For missiles with a pointed leading edge, a new grid topology is required to avoid generating degenerate grids that affect convergence.

[0119] The mesh is refined at the leading and trailing edges of the aircraft wings and horizontal vertical tail, wingtips and other locations with intense flow to capture the flow characteristics;

[0120] The entire grid is smoothed to ensure that the quality of most grid units is above 0.3.

[0121] 2) Hybrid Grid

[0122] The π-shaped wing blades, the scissor angles formed by the side strips and the horizontal tail, the wing tip springs, etc. must be precisely ensured;

[0123] For configurations with complex external structures, many components, and complex flows, the quality of the spatial grid must be controlled to simulate the complex flow state well, and grid control is difficult;

[0124] The hybrid grid adopts the strategy of first generating a pure tetrahedral grid and then generating a prismatic negative layer grid. The grid density is high near the object surface, and the boundary layer height is limited. The low boundary layer height cannot simulate the viscous flow well, and repeated iterations are required to generate a grid that meets the requirements.

[0125] 3) General requirements

[0126] The far field size is about 100 times the average aerodynamic chord length;

[0127] The scale of the entire organization's grid is about 6-8 million.

[0128] As shown in Table 4, the types of data required for management primarily include structured data, text files, binary data files, graphs, charts, and images. To effectively manage case data, database data and document standards were established to standardize and ensure the quality of submitted data.

[0129]

[0130]

[0131] Table 4

[0132] This application proposes a standardized method for storing CFD verification and validation case data. This method establishes a standard for storing case data from the perspectives of data accuracy, completeness, and standardization. This method effectively supports the reliability analysis and evaluation of domestic numerical wind tunnel software and facilitates the overall integration of case data.

[0133] The above are only specific embodiments of the present disclosure, but the scope of protection of the present disclosure is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this disclosure should be included in the scope of protection of the present disclosure. Therefore, the scope of protection of the present disclosure should be based on the scope of protection of the claims.

Claims

1. A method for standardizing the storage of CFD verification and validation case data, suitable for the storage of aviation experiment or test data, characterized by: S101: Acquire historical aviation test data; S102: Determine a calculation example data organization standard, wherein the calculation example data organization standard is based on the type or classification of aviation historical test data. Determining the calculation example data organization standard at least includes determining a calculation example data naming specification, wherein the calculation example data naming specification at least includes calculation example directory naming and geometric configuration naming, computational grid naming, computational result naming, and test data naming. The calculation example directory naming includes an identification mark of the calculation example type, calculation example name, geometric / application domain characteristics, and a serial number corresponding to a aviation historical test. S103: Organizing the case data. The case data organization includes classifying the case data according to standard classification and caching the historical aviation test data according to preset rules. The case data is managed using a flat tree-like hierarchical structure model. The bottom layer of the flat tree-like hierarchical structure model is the verification and confirmation case library. The first layer is case information or project information. The second layer is geometric shapes and calculation results and test results. The data are cached in a tree-like storage manner. S104: Determine the standard for storing case data, delete the cached data and store the duplicate data, wherein the standard for storing case data is based on the data generated by the case data organization standard, adopts a hierarchical tree-like organizational structure, and enters the case database from the perspectives of new cases, basic attributes, case descriptions, comparable data, extraction tools, and related documents. Use a comparison function to filter out duplicate and identical data, and store the data after filtering; S105: Get the parameter data of the current test, and match it with the stored data, if it matches, the data corresponding to the test or experimental data, if it does not match, feedback information; S106: After the parameter data of the current test is tested or experimentally determined, repeat steps S102 to S104 to update the database.

2. The method according to claim 1, characterized in that Determining the case data compilation standards also includes determining the case description file compilation specifications, which include case identification, case description, test description, calculation description, comparable data and references.

3. The method according to claim 2, characterized in that Determining the case data collation standards also includes determining the calculation grid data collation standards, calculation result data collation standards, and test result data collation standards, among which: The computational grid data sorting standards include grid-related geometric models, grid types, grid names, grid descriptions, grid files, grid quality, and boundary conditions; The calculation result data sorting standards include: flow state, calculation parameters, force coefficient data, curve data and image data; The test result data collation standards include: basic information, test status, force measurement data and pressure measurement data.

Images