A migration method in lattice boltzmann evolution calculation and related device

Abstract

The application discloses a migration method in lattice Boltzmann evolution calculation and related devices, and relates to the technical field of fluid mechanics calculation. The method comprises the following steps: determining at least one fluid node participating in the lattice Boltzzman evolution calculation from a plurality of grid nodes of a calculation domain, and acquiring sparse indexes of each fluid node and a distribution function stored based on the sparse indexes; for each fluid node, determining global coordinates of adjacent grid nodes based on the sparse indexes and preset discrete velocity directions; judging whether the global coordinates of the adjacent grid nodes correspond to the sparse indexes of any fluid node; if yes, performing migration on the distribution function based on the corresponding sparse indexes. The application reconstructs the data storage and access mechanism, performs fine calculation on the effective fluid nodes only, effectively reduces the memory occupation of the non-fluid region, and improves the migration efficiency of the lattice Boltzmann evolution calculation.

Description

Technical Field

[0001] This application relates to the field of fluid dynamics computational technology, and in particular to a migration method and related apparatus in lattice Boltzmann evolution computation. Background Technology

[0002] With the development of advanced forming technologies such as precision casting and additive manufacturing, numerical simulation of the filling process of complex components' internal flow channels and cavities has received increasing attention. The lattice Boltzmann method, with its inherent mesoscopic physical background and parallel computing advantages, has become an important tool for simulating fluid flow behavior during casting filling. Among these methods, the transfer step in lattice Boltzmann evolution calculations—the process of the distribution function being transferred between grid nodes—directly determines the entire simulation process. Therefore, the transfer method in lattice Boltzmann evolution calculations is particularly important.

[0003] Currently, it is typically necessary to allocate storage space for all grid nodes in the computation domain and directly determine adjacent grid nodes by traversing the structural data of the complete grid nodes in order to achieve the migration of the distribution function between grid nodes.

[0004] However, the computational domain often contains a large number of mold regions, solid regions, or other non-fluid regions that do not participate in the fluid evolution calculation. Storage space needs to be allocated for the grid nodes corresponding to the non-fluid regions, and node access to the complete computational domain is required during the migration calculation. This results in a large amount of invalid storage and invalid computation overhead, leading to low migration efficiency and large storage space occupation in lattice Boltzmann evolution calculation. Summary of the Invention

[0005] In view of the above problems, this application provides a transfer method and related apparatus for lattice Boltzmann evolution computation to solve the problems of low transfer efficiency and large storage space consumption in lattice Boltzmann evolution computation. The specific solution is as follows:

[0006] The first aspect of this application provides a transfer method in lattice Boltzmann evolution computation, comprising:

[0007] At least one fluid node participating in the lattice Boltzmann evolution calculation is determined from multiple grid nodes in the computational domain, and the sparse index of each fluid node is obtained, as well as the distribution function of each fluid node in each preset discrete velocity direction stored based on the sparse index of each fluid node.

[0008] For each fluid node, based on the sparse index of the fluid node and the preset discrete velocity direction of the fluid node, the global coordinates of the adjacent grid nodes of the fluid node in the preset discrete velocity direction are determined;

[0009] Determine whether the global coordinates of the adjacent grid nodes correspond to the sparse index of any fluid node;

[0010] If the global coordinates of the adjacent grid node correspond to the sparse index of a fluid node, then the distribution function of the fluid node in the preset discrete velocity direction is migrated based on the sparse index of the corresponding fluid node.

[0011] In one possible implementation, after determining whether the global coordinates of the adjacent mesh nodes correspond to the sparse index of any fluid node, the method further includes:

[0012] If the global coordinates of the adjacent grid nodes do not correspond to the sparse index of any fluid node, then the distribution function of the fluid node in the preset discrete velocity direction is subjected to boundary processing based on the preset boundary rules.

[0013] In one possible implementation, determining the global coordinates of adjacent grid nodes of the fluid node in the preset discrete velocity direction, based on the sparse index of the fluid node and the preset discrete velocity direction of the fluid node, includes:

[0014] For each fluid node, the global coordinates of the fluid node are determined based on the sparse index of the fluid node and a pre-established first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sparse index of the fluid node and the global coordinates of the fluid node.

[0015] Based on the preset discrete velocity direction of the fluid node and the global coordinates of the fluid node, the global coordinates of the adjacent grid nodes of the fluid node in the preset discrete velocity direction are determined.

[0016] In one possible implementation, determining whether the global coordinates of the adjacent grid nodes correspond to the sparse index of any fluid node includes:

[0017] Determine whether the global coordinates of the adjacent grid nodes are consistent with the global coordinates of any fluid node;

[0018] If the global coordinates of the adjacent grid node are consistent with the global coordinates of a fluid node, then based on the pre-established second mapping relationship, the global coordinates of the adjacent grid node are determined to correspond to the sparse index of a fluid node. The second mapping relationship is used to characterize the mapping relationship between the global coordinates of the fluid node and the sparse index of the fluid node.

[0019] If the global coordinates of the adjacent grid node are not consistent with the global coordinates of any fluid node, then based on the second mapping relationship, it is determined that the global coordinates of the adjacent grid node do not correspond to the sparse index of any fluid node.

[0020] In one possible implementation, the process of establishing the first mapping relationship and the second mapping relationship includes:

[0021] Obtain the global coordinates of each fluid node, and assign incremental sparse indices to each fluid node in a preset order;

[0022] Based on the sparse index of each fluid node and the global coordinates of each fluid node, the first mapping relationship and the second mapping relationship are constructed.

[0023] In one possible implementation, the method further includes:

[0024] In response to the output command, for each of the mesh nodes, it is determined whether the mesh node is a fluid node based on the acquired global coordinates of the mesh node;

[0025] If the grid node is a fluid node, the evolution calculation result of the grid node is read based on the obtained sparse index of the grid node; if the grid node is not a fluid node, the preset background value is determined as the evolution calculation result of the grid node.

[0026] Based on the evolution calculation results of each of the grid nodes, the output results of the computational domain are generated.

[0027] A second aspect of this application provides a migration device for lattice Boltzmann evolution computation, comprising:

[0028] The acquisition unit is used to determine at least one fluid node participating in the lattice Boltzmann evolution calculation from multiple grid nodes in the computational domain, and to acquire the sparse index of each fluid node, as well as the distribution function of each fluid node in each preset discrete velocity direction stored based on the sparse index of each fluid node.

[0029] The determining unit is used to determine, for each fluid node, the global coordinates of the adjacent grid nodes in the preset discrete velocity direction of the fluid node, based on the sparse index of the fluid node and the preset discrete velocity direction of the fluid node;

[0030] The judgment unit is used to determine whether the global coordinates of the adjacent grid nodes correspond to the sparse index of any fluid node;

[0031] The migration unit is used to migrate the distribution function of the fluid node in a preset discrete velocity direction based on the sparse index of the fluid node if the global coordinates of the adjacent mesh node correspond to the sparse index of the fluid node.

[0032] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the migration method in lattice Boltzmann evolution computation as described in the first aspect or any implementation thereof.

[0033] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0034] The memory is used to store computer programs;

[0035] The processor is used to execute the computer program so that the electronic device can implement the migration method in the lattice Boltzmann evolution calculation of the first aspect or any implementation thereof.

[0036] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the migration method in lattice Boltzmann evolution computation as described in the first aspect or any implementation thereof.

[0037] Based on the above technical solution, this application provides a migration method and related apparatus for lattice Boltzmann evolution computation. The method includes determining at least one fluid node participating in the lattice Boltzmann evolution computation from multiple grid nodes in the computational domain, and obtaining the sparse index of each fluid node and the distribution function stored based on the sparse index; for each fluid node, determining the global coordinates of adjacent grid nodes based on the sparse index and a preset discrete velocity direction; determining whether the global coordinates of adjacent grid nodes correspond to the sparse index of any fluid node; if they correspond, migrating the distribution function based on the corresponding sparse index. This application, by reconstructing the data storage and access mechanism, performs refined computation only on effective fluid nodes, effectively reducing memory usage in non-fluid regions and improving the migration efficiency of lattice Boltzmann evolution computation. Attached Figure Description

[0038] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0039] Figure 1 A schematic flowchart illustrating a transfer method in lattice Boltzmann evolution computation provided in an embodiment of this application;

[0040] Figure 2 A schematic diagram of a computational domain provided for an embodiment of this application;

[0041] Figure 3 A schematic diagram of a mapping table reflecting mapping relationships provided in an embodiment of this application;

[0042] Figure 4 A schematic diagram of a discrete velocity model provided in an embodiment of this application;

[0043] Figure 5 A schematic diagram of a velocity field distribution result provided in an embodiment of this application;

[0044] Figure 6 A schematic diagram of the migration device in lattice Boltzmann evolution computation provided in this application embodiment;

[0045] Figure 7 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0046] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0047] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0048] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0049] To improve the migration efficiency and reduce the storage space occupied in lattice Boltzmann evolution computation, this application provides a migration method in lattice Boltzmann evolution computation. The migration method in lattice Boltzmann evolution computation provided in this application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0050] Please see Figure 1 , Figure 1This is a flowchart illustrating a transfer method in lattice Boltzmann evolution computation provided in an embodiment of this application. The method may include the following steps:

[0051] Step S101: Determine at least one fluid node from multiple grid nodes in the computational domain to participate in the lattice Boltzmann evolution calculation, and obtain the sparse index of each fluid node, as well as the distribution function of each fluid node in each preset discrete velocity direction stored based on the sparse index of each fluid node.

[0052] It should be noted that the computational domain can refer to the discretized spatial region used for fluid simulation, which includes both fluid and solid regions. For example... Figure 2 As shown, Figure 2 This diagram illustrates a computational domain, showing a scenario where a circular solid obstacle exists within a square computational domain. The white areas represent fluid regions containing fluid nodes, and the gray circular areas represent solid regions containing solid nodes. Identifying the fluid nodes involved in the computation involves recognizing all grid points in the computational domain that are in a fluid state, discarding redundant processing of solid nodes. A sparse index can be a unique, incrementing integer identifier assigned to each identified fluid node, used to map two-dimensional or three-dimensional global grid coordinates to a one-dimensional continuous array of subscripts. Specifically, first, fluid points and solid points within the computational domain are distinguished, for example, by using ray casting or symbolic distance field methods to determine the type of each grid point. Then, the total number of fluid nodes, FluidNum, is counted, and the computational domain is traversed in row-major order. For each fluid node encountered, a sparse index from 0 to FluidNum-1 is assigned, and a mapping table from global coordinates to sparse indices (such as the FluidIndex array) and a mapping table from sparse indices to global coordinates (such as the FluidCoord array) are established. The distribution function, in the lattice Boltzmann method, describes the probability density of a particle at a specific location and along a specific discrete velocity direction. Storing the distribution function based on a sparse index for each fluid node involves creating a sparse array of size FluidNum × Q, where Q is the number of discrete velocity directions (e.g., Q=9 in the D2Q9 model). Only the distribution function values ​​of valid fluid nodes are stored in this array, without allocating storage space for solid nodes. For example, in a 2000 × 2000 computational domain, if fluid nodes account for only 10%, the traditional method would require storing the distribution functions of 4 million nodes, while this step only requires storing the distribution functions of 400,000 fluid nodes, significantly reducing memory usage. This sparse indexing mechanism transforms the data organization from O(NX × NY) to O(FluidNum), fundamentally eliminating the memory overhead of solid regions.

[0053] Based on the embodiments disclosed in the present invention above, in another embodiment of the present invention, the specific implementation method of obtaining the sparse index of each fluid node and constructing the mapping relationship in step S101 is described in detail.

[0054] As one possible implementation, the method may further include: obtaining the global coordinates of each fluid node, and sequentially assigning incremental sparse indices to each fluid node in a preset order; and constructing a first mapping relationship and a second mapping relationship based on the sparse indices of each fluid node and the global coordinates of each fluid node.

[0055] Obtaining the global coordinates of each fluid node involves traversing and identifying all grid nodes within the computational domain using a geometric discrimination algorithm. This distinguishes nodes belonging to fluid regions from those belonging to solid regions, and extracts the global grid coordinates of all nodes identified as belonging to fluid regions. Global coordinates are typically represented as two-dimensional array indices (i,j) or three-dimensional array indices (i,j,k), used to uniquely determine the spatial location of a grid node within the computational domain. Assigning incrementally increasing sparse indices to each fluid node in a predetermined order can refer to defining a specific traversal rule (such as row priority, column priority, or a specific space-filling curve order). During the traversal, each fluid node encountered is assigned a continuously increasing integer number starting from 0; this number is the sparse index. The sparse index serves as a unique identifier for each fluid node in the compressed storage space, with its value ranging from 0 to the total number of fluid nodes minus 1. For example, in a two-dimensional computational domain with NX grids along the X direction and NY grids along the Y direction, a row-major traversal is performed: first, the Y coordinate is fixed at 0, and the X coordinate is traversed from 0 to NX-1; then the Y coordinate is incremented by 1, and the above process is repeated until the entire computational domain is traversed. During this process, if the current coordinate (i,j) is determined to be a fluid node, the counter is incremented by 1, and the current counter value is assigned to the sparse index of that node; if it is determined to be a solid node, it is skipped without an index allocation or marked as an invalid value (such as -1). This sequential allocation method ensures that the sparse indexes of fluid nodes in adjacent rows or columns are also continuous or nearly continuous in memory, thereby improving the cache hit rate of subsequent data accesses. This step aims to transform the unstructured geometric fluid region into a logical sequence with linear index characteristics, laying the foundation for building an efficient sparse data structure. By allocating indexes in a pre-determined traversal order, the determinism and reproducibility of the mapping relationship construction are guaranteed, avoiding memory fragmentation problems caused by random allocation.

[0056] The first mapping relationship characterizes the mapping from the sparse index of a fluid node to its global coordinates, meaning that a known sparse index allows for quick lookup of its corresponding spatial location. The second mapping relationship characterizes the mapping from the global coordinates of a fluid node to its sparse index, meaning that a known spatial location allows for quick location of its storage index in the sparse array. The first mapping relationship is typically constructed by creating a one-dimensional array (denoted as FluidCoord), with a length equal to the total number of fluid nodes. The array's indices correspond to sparse indices, and the elements stored within the array are the corresponding global coordinate structures or tuples. The second mapping relationship is typically constructed by creating a dense array (denoted as FluidIndex) with the same dimension as the computational domain. The array's dimension is consistent with the original mesh, and the array stores the sparse index of the corresponding mesh location. For non-fluid node locations, this array stores a pre-defined invalid flag (e.g., -1). During the construction process, the generated coordinate-index pair set is used to simultaneously populate the two data structures: when processing the k-th fluid node, its global coordinates are written to the k-th position of the FluidCoord array to complete the construction of the first mapping relationship, and its sparse index k is written to the corresponding position of the global coordinates in the FluidIndex array to complete the construction of the second mapping relationship. The first and second mapping relationships are used together. The former supports the rapid calculation of the global coordinates of neighboring nodes to determine the boundary in the migration step, while the latter supports the rapid query of whether a neighbor exists in the fluid node set and its corresponding sparse index based on the calculated global coordinates of the neighbor in the judgment step. This step solidifies the geometric topology information into an index structure in memory, so that the subsequent lattice Boltzmann evolution calculation is completely independent of the real-time dependence on the original full mesh topology. This significantly improves the data retrieval efficiency, simplifying the neighborhood search process that originally required complex geometric judgments into a constant-time array lookup operation, effectively avoiding invalid access to solid nodes in each iteration, thereby greatly reducing computational overhead and memory usage.

[0057] Please see Figure 3 , Figure 3This diagram illustrates a mapping table reflecting a mapping relationship, provided in an embodiment of this application. Taking a computational domain containing a circular solid region as an example, the diagram shows the mapping result from global coordinates to a sparse index. In the diagram, 0 to 67 represent the sparse indices of fluid nodes, with a total of 68 fluid nodes. Solid nodes are marked as -1. This mapping relationship is established by traversing the computational domain in row-major order and assigning an incrementally increasing sparse index to each identified fluid node. Through this sparse index mapping table, this application maps two-dimensional global grid coordinates to one-dimensional continuous array subscripts, realizing a transformation of data organization from O(NX×NY) to O(FluidNum), fundamentally eliminating the memory overhead of solid regions, and providing an efficient table lookup foundation for subsequent migration steps based on reverse lookup of sparse indexes using global coordinates.

[0058] Step S102: For each fluid node, based on the sparse index of the fluid node and the preset discrete velocity direction of the fluid node, determine the global coordinates of the adjacent grid nodes of the fluid node in the preset discrete velocity direction.

[0059] It should be noted that the preset discrete velocity direction can refer to the set of particle motion directions defined in the lattice Boltzmann model. For example... Figure 4 As shown, Figure 4 This diagram illustrates a discrete velocity model, detailing nine commonly used discrete velocity directions in a two-dimensional context, including the stationary direction (α=0) and eight motion directions (α=1 to 8) along the coordinate axes and diagonals. Determining the global coordinates of adjacent grid nodes involves index-based coordinate lookup and vector overlay. Specifically, firstly, using the established mapping relationship between sparse indices and global coordinates (i.e., the FluidCoord array), the corresponding global grid coordinates (i,j) of the current fluid node are found based on its sparse index. Then, the preset discrete velocity direction e is combined with this coordinates. α (Such as the velocity vector in the D2Q9 model), through coordinate operations (i',j')=(i,j)+ e α The global coordinates (i', j') of adjacent grid nodes in this direction are calculated. For example, if the global coordinates of the current fluid node are (50, 50), and the current discrete velocity direction is to the right e = (1, 0), then the calculated global coordinates of the adjacent grid nodes are (51, 50). This step decouples physical location from memory layout, enabling precise location of any neighboring position in physical space even in a discontinuous sparse memory structure, providing an accurate geometric basis for subsequent migration decisions.

[0060] Based on the embodiments disclosed in the present invention above, in another embodiment of the present invention, the specific implementation method of determining the global coordinates of adjacent grid nodes in step S102 is described in detail.

[0061] As one possible implementation, this step may include: for each fluid node, determining the global coordinates of the fluid node based on the sparse index of the fluid node and a pre-established first mapping relationship, wherein the first mapping relationship is used to characterize the mapping relationship between the sparse index of the fluid node and the global coordinates of the fluid node; and determining the global coordinates of adjacent grid nodes of the fluid node in the preset discrete velocity direction based on the preset discrete velocity direction of the fluid node and the global coordinates of the fluid node.

[0062] The first mapping relationship refers to the rule for converting sparse indices at the logical level into corresponding Eulerian grid coordinates at the physical level. This first mapping relationship specifically includes a storage structure, such as a one-dimensional array `FluidCoord`, where the array index corresponds to the sparse index of the fluid node, and the array element stores the corresponding global coordinate tuple (i,j). This first mapping relationship is obtained by traversing the computational domain during the initialization phase, identifying all fluid nodes, assigning incrementally increasing sparse indices to each fluid node according to a preset order (such as row priority), and storing the global coordinates of each fluid node in the array according to this index order. The function of the first mapping relationship is to establish an anchoring connection between abstract data indices and physical spatial locations, enabling subsequent index-based data access to be restored to specific spatial location information. Specifically, when processing a fluid node with a sparse index of `index`, the precise coordinates (i,j) of that node in the global computational domain can be obtained by directly reading the element with index `index` in the first mapping relationship. For example, if the sparse index of a fluid node is 5, its global coordinates are determined to be (10, 15) by querying the first mapping relationship. This means that the node is located at the 10th cell in the X direction and the 15th cell in the Y direction of the computational domain. The input receives the sparse index of the fluid node, performs a lookup operation on the first mapping relationship, and the output obtains the corresponding global coordinates (i, j), thus realizing the fast restoration from compressed storage space to physical space coordinates. This step aims to solve the problem that logical indices in sparse data structures cannot directly reflect spatial neighborhood relationships. By introducing the first mapping relationship, it ensures that each fluid node participating in the computation can be accurately located to a specific physical grid position, providing the necessary spatial reference for subsequent neighbor node searches.

[0063] The preset discrete velocity direction can refer to the set of discrete velocity vectors defined in the lattice Boltzmann method, such as the unit vectors in the two-dimensional D2Q9 model that include the stationary direction and eight surrounding directions. The global coordinates of adjacent grid nodes are obtained through vector addition, specifically by adding the global coordinates of the current fluid node. With respect to the preset discrete velocity direction vector Add them together, the formula is as follows ,in This refers to the global coordinates of adjacent grid nodes. The purpose of this calculation method is to accurately locate the target positions where data exchange is needed in various velocity directions for the current node, based on the LBM migration mechanism. The preset discrete velocity directions can be set according to the specific simulation dimension; for two-dimensional simulations, the D2Q9 model can be used, and for three-dimensional simulations, the D3Q19 model can be used, etc. For example, for a fluid node with global coordinates (10,15), if the currently processed preset discrete velocity direction is the positive X-axis direction (i.e.,...)... If the direction is the negative Y-axis (i.e., ...), then the calculated global coordinates of the adjacent grid nodes are (11, 15); If the physical coordinates of the adjacent grid nodes are (10, 14), then this step, based on the physical coordinates determined in the previous step, uses the geometric properties of the discrete velocity model to derive the target grid position on the migration path. Thus, without relying on the index offset of the dense grid array, the positions of the neighbors of any fluid node in any discrete velocity direction can be accurately calculated solely from the coordinates and velocity direction vectors reconstructed by the sparse index. This effectively avoids the index breakage problem caused by the presence of solid regions, ensuring the topological correctness of the migration process under a sparse data structure.

[0064] Step S103: Determine whether the global coordinates of adjacent grid nodes correspond to the sparse index of any fluid node.

[0065] It should be noted that this judgment step aims to confirm whether the calculated adjacent grid nodes physically belong to a valid fluid region, thereby determining the subsequent data processing logic. In specific implementation, the mapping table from global coordinates to sparse indices (such as the FluidIndex array) constructed above is used to directly query the mapping value corresponding to the global coordinates (i', j') of the adjacent grid node. If the queried mapping value is a valid index (i.e., greater than or equal to 0), it is determined that the adjacent grid node corresponds to a sparse index of a fluid node, indicating that the neighbor is a valid fluid node; if the queried mapping value is an invalid flag (such as -1), it is determined that the adjacent grid node does not correspond to any sparse index of a fluid node, indicating that the neighbor is located in a solid region or outside the computational domain. For example, for the above-calculated adjacent coordinates (51, 50), if the value of FluidIndex

[51]

[50] is 125, it means that the point is a fluid node; if the value of FluidIndex

[51]

[50] is -1, it means that the point is a solid node. This lookup and comparison process avoids complex geometric boundary judgment algorithms, transforms neighborhood attribute recognition into efficient array index access, and greatly improves computational efficiency.

[0066] Based on the embodiments disclosed in the present invention above, in another embodiment of the present invention, the specific implementation method of determining the global coordinate correspondence in step S103 is described in detail.

[0067] As one possible implementation, this step may include: determining whether the global coordinates of an adjacent grid node are consistent with the global coordinates of any fluid node; if the global coordinates of an adjacent grid node are consistent with the global coordinates of a fluid node, then based on a pre-established second mapping relationship, determining that the global coordinates of the adjacent grid node correspond to the sparse index of a fluid node, the second mapping relationship being used to characterize the mapping relationship between the global coordinates of the fluid node and the sparse index of the fluid node; if the global coordinates of an adjacent grid node are not consistent with the global coordinates of any fluid node, then based on the second mapping relationship, determining that the global coordinates of the adjacent grid node do not correspond to the sparse index of any fluid node.

[0068] This step aims to quickly filter out adjacent grid nodes located within the fluid region by comparing spatial location information. Specifically, the executing entity uses the global coordinates (such as two-dimensional coordinates) of the adjacent grid nodes calculated in the previous step. The global coordinates of the fluid nodes are matched against a pre-stored set of global coordinates for all fluid nodes. Matching here means that the coordinate values ​​are completely equal, i.e., the two grid points occupy the same physical location in the discrete grid space. Since the global coordinates of the fluid nodes are stored in a linear structure such as a FluidCoord array, this comparison process can achieve constant-time lookup using hash lookup or an index mapping table, avoiding the high computational overhead of traditional full grid traversal. For example, if the currently calculated global coordinates of adjacent grid nodes are... Search the fluid coordinate set; if the set contains an element... If they are the same, then they are considered consistent; if only one exists in the set... or And without If the coordinates are not aligned, it is considered inconsistent. The output directly determines whether index mapping is performed or the region is classified as non-fluid. This determination mechanism based on precise coordinate matching effectively excludes solid regions and invalid meshes outside the computational domain, ensuring that subsequent data migration occurs only between valid fluid nodes.

[0069] This step involves, after confirming that adjacent nodes belong to the fluid region, further obtaining their logical indices in the sparse data structure to directly access the distribution function data stored at that index location. The second mapping relationship is a pre-constructed data structure whose core function is to map the global coordinates (Key) of fluid nodes to their corresponding sparse indices (Value). In a specific implementation, the second mapping relationship can be represented as a two-dimensional integer array (e.g., FluidIndex[NX][NY]), where the array indices correspond to the global coordinates and the array values ​​correspond to the sparse indices of the fluid nodes at those coordinates; or as a hash table, using coordinate tuples as keys and integer indices as values. When the aforementioned coordinates match, the matching global coordinates are directly used as the query key to retrieve the corresponding sparse index from the second mapping relationship. For example, assuming the global coordinates... If a node is identified as a fluid node, access FluidIndex

[15]

[20] . If the value stored at that location is... Then the sparse index corresponding to the adjacent grid node is determined as follows: This process utilizes a space-for-time tradeoff strategy, optimizing an operation that might otherwise require traversing the entire fluid list to find the index. Direct addressing. The first mapping relationship (sparse index to global coordinates) and the second mapping relationship (global coordinates to sparse index) in this step together constitute a bidirectional indexing system. The former is used to calculate the neighbor position when the index is known, and the latter is used to look up the index when the neighbor position is known. The two work together to realize efficient bidirectional conversion between sparse grid and dense physical space, ensuring the accuracy and real-time performance of data reading and writing during the migration process.

[0070] This step handles the case where adjacent grid nodes are located in a solid region or outside the computational domain boundary. When the comparison results show that the global coordinates of the adjacent grid nodes do not exist in the fluid node coordinate set, it means that there is no corresponding fluid physical quantity to be migrated at that location. In this case, based on the characteristics of the second mapping relationship, a negative conclusion is drawn: that is, the coordinates do not correspond to any valid sparse index. In specific data structure implementations, this is usually reflected in the query result being a specific invalid identifier. For example, if the second mapping relationship is initialized to... The implementation uses a two-dimensional array FluidIndex to provide global coordinates for non-fluid nodes. The value of FluidIndex[x][y] remains unchanged. Read the The value clearly indicates that the adjacent grid node does not correspond to any sparse index of the fluid node. This determination is a prerequisite for triggering subsequent boundary processing logic (such as the semi-bounce format). By explicitly utilizing the second mapping relationship to confirm the absence of a corresponding index, rather than simply ignoring it, the rigor of the algorithm logic is ensured. This allows the program to clearly distinguish between the uncalculated and confirmed solid / boundary states, thus providing a reliable basis for implementing differentiated evolution strategies for different grid types.

[0071] If the global coordinates of adjacent grid nodes correspond to the sparse index of a fluid node, then proceed to step S104.

[0072] Step S104: Based on the sparse index of the corresponding fluid node, the distribution function of the fluid node in the preset discrete velocity direction is transferred.

[0073] It should be noted that the transfer of the distribution function can refer to the transmission of the distribution function value of the current fluid node after collision to its neighboring fluid nodes. This is a core spatial transport step in the lattice Boltzmann evolution process. When the neighboring grid node is determined to be a valid fluid node, the sparse index corresponding to that neighboring node (i.e., the value read from the mapping table) is obtained, and the distribution function value of the current fluid node in a specific discrete velocity direction is written to a sparse storage array with the sparse index of that neighboring node as the index. Specifically, if the index of the current fluid node is index, the index of the neighboring fluid node is neighbor_index, and the discrete velocity direction is α, then the operation is performed. ,in This is the distribution function after the collision. For example, if the current fluid node migrates its distribution function to the right, and its right-side adjacent grid node is also a fluid node, then the collision-related distribution function of the current fluid node to the right is written to the corresponding storage location of the right-side adjacent fluid node. This direct addressing migration based on sparse indexes ensures that data is exchanged only between valid fluid nodes, completely avoiding invalid read / write operations on solid node data. This not only guarantees that the numerical accuracy of the LBM physics model is strictly equivalent to that of traditional full-mesh methods, but also significantly improves the CPU cache hit rate and further accelerates the evolutionary computation process because the operation object is a contiguously stored sparse array.

[0074] Based on the embodiments disclosed in the present invention above, in another embodiment of the present invention, the branching process after step S103 is described in detail.

[0075] As one possible implementation, the method further includes: if the global coordinates of adjacent grid nodes do not correspond to the sparse index of any fluid node, then step S105 is executed.

[0076] Step S105: Based on preset boundary rules, perform boundary processing on the distribution function of the fluid nodes in the preset discrete velocity direction.

[0077] In this context, the fact that the global coordinates of adjacent grid nodes do not correspond to the sparse index of any fluid node means that when querying the coordinates of an adjacent node using the aforementioned constructed sparse index mapping table (such as the FluidIndex array), the returned index value is an invalid flag (such as -1). This determination result directly indicates that the adjacent grid node is located outside the solid region or computational domain, i.e., a physical boundary point. Since this application uses a sparse data structure that only stores fluid nodes, the solid nodes themselves do not allocate memory space to store the discrete velocity distribution function, and therefore cannot perform conventional migration operations (i.e., data cannot be written to the solid nodes). Preset boundary rules can refer to microscopic boundary condition processing strategies adapted to the lattice Boltzmann method, used to simulate the interaction between fluid and solid walls. Common preset boundary rules include, but are not limited to, half-way bounce-back, interpolated bounce-back, or periodic boundary conditions. Taking the half-way bounce-back as an example, its core logic is to write the post-collision distribution function of the current fluid node in the discrete velocity direction α into the current fluid node in the opposite direction. The storage location on. The opposite direction here. satisfy For example, in the 2D D2Q9 model, if the neighboring node to the right (direction 1) of the current fluid node is determined to be a solid node, the data migration to the right is not performed. Instead, a semi-bounce rule is triggered, writing the post-collision distribution function of the current fluid node to the distribution function variable to the left (direction 3, i.e., the opposite direction of direction 1). Through this processing method, no state information of the solid node needs to be accessed or stored; the numerical simulation of the wall effect can be completed using only the local distribution function of the fluid node. This step aims to solve the completeness problem of boundary processing under sparse data structures. In traditional full-mesh methods, boundary processing usually involves reading or writing solid node data. However, in the sparse framework of this application, the boundary is automatically located by identifying the missing sparse index, and corresponding physical constraints are applied. This avoids invalid memory access and ensures the physical realism of the flow field at complex geometric boundaries (such as the inner cavity surface of a precision casting). This enables lattice Boltzmann evolution computation based on sparse storage to operate stably in scenarios containing a large number of irregular solid obstacles, while maintaining the same computational accuracy as traditional dense grid methods.

[0078] This application achieves deep coupling between data storage structure and physical boundary processing by combining the missing sparse index determination with preset boundary rules. Specifically, the established global coordinate-to-sparse index mapping not only accelerates data migration between fluid nodes but also acts as a boundary identifier: when the mapping result is empty, it automatically switches to the boundary processing branch instead of attempting to access non-existent solid memory addresses. This mechanism eliminates the branch judgment overhead in the evolution loop caused by maintaining an additional label array (CellType) to distinguish between fluids and solids in traditional methods, because the presence or absence of the sparse index itself implies node type information. With this co-design, this scheme significantly reduces memory usage (storing only fluid nodes) while ensuring the correctness of momentum conservation and energy dissipation under complex boundary conditions, thereby significantly improving the computational efficiency and scalability of numerical simulation of precision forming and casting processes while maintaining simulation accuracy.

[0079] Based on the embodiments disclosed in the present invention above, in another embodiment of the present invention, the specific implementation method for generating the output result of the computational domain is described in detail.

[0080] As one possible implementation, the method further includes: in response to an output command, for each grid node, determining whether the grid node is a fluid node based on the acquired global coordinates of the grid node; if the grid node is a fluid node, reading the evolution calculation result of the grid node based on the acquired sparse index of the grid node; if the grid node is not a fluid node, determining a preset background value as the evolution calculation result of the grid node; and generating the output result of the computational domain based on the evolution calculation results of each grid node.

[0081] The output command is the signal that triggers the export of calculation results. It is typically set by the user for the output time step or automatically triggered by a preset output frequency. A grid node can refer to all discrete points constituting the entire computational domain, including fluid nodes that participate in the evolution and solid nodes that do not (such as mold walls or internal obstacles). The specific implementation for determining whether a grid node is a fluid node relies on a pre-established mapping table (i.e., the FluidIndex array in the aforementioned embodiment), which stores mapping information from global grid coordinates to sparse indices. Specifically, the global coordinates (i,j) of each grid node in the computational domain are traversed, and the corresponding value in the mapping table is queried. If the query result is a valid index value (e.g., an integer greater than or equal to 0), the grid node is determined to be a fluid node; if the query result is an invalid flag value (e.g., -1), the grid node is determined not to be a fluid node, i.e., a solid node or background region. This fast discrimination method based on table lookup can efficiently distinguish different media types within the computational domain without re-performing geometric identification, laying the foundation for subsequent differentiated data reading.

[0082] The evolution calculation results refer to macroscopic physical quantities calculated during the lattice Boltzmann evolution process, mainly including fluid density and fluid velocity vectors. For meshes identified as fluid nodes, the data stored at the corresponding location in the sparse data structure (such as the SparseVelocity and SparseDensity arrays) is directly accessed using the effective sparse index obtained above. Since the sparse data structure only stores the information of fluid nodes continuously, the specific address in memory can be directly located through the sparse index, thereby quickly reading high-precision calculation results. For example, if the global coordinates of a fluid node are (100, 50), and its sparse index is found to be 42, then the velocity and density values ​​of that point are directly read from the 42nd element of the sparse array. For meshes not identified as fluid nodes (i.e., solid nodes or external background), the preset background value is determined as the evolution calculation result of that node. Preset background values ​​are constants pre-defined based on the requirements of the post-processing software or their physical meaning. For example, the velocity and density of solid regions can be uniformly set to 0, or set to a specific NaN (non-numeric) identifier for differentiation. Alternatively, they can be set as property values ​​of the mold material according to the specific application scenario. This processing method ensures the integrity of the output data, so that solid regions that were originally ignored in sparse computation have clear numerical definitions in the output file, avoiding post-processing errors caused by missing data.

[0083] The output can refer to a full-grid data file conforming to the standard format of existing Computational Fluid Dynamics (CFD) post-processing software. After data filling is completed for all grid nodes within the computational domain (fluid nodes are filled with actual calculated values, and non-fluid nodes are filled with preset background values), the evolution calculation results of each node are written to the output file according to the full grid arrangement order (e.g., row-major or column-major). The generated output is structurally equivalent to the output of the traditional full-grid LBM method, containing the physical quantity information of every grid point within the computational domain. Therefore, this step achieves a seamless conversion from an internally efficient sparse data representation to an external standard full-grid format, allowing the generated file to be directly loaded and rendered by general visualization software such as Tecplot and Paraview without modifying the existing post-processing workflow, while maintaining the low memory consumption advantage of the evolution calculation stage. Please refer to [link to relevant documentation]. Figure 5 , Figure 5This diagram illustrates a velocity field distribution result provided in an embodiment of this application. The diagram shows the velocity field distribution result obtained after performing lattice Boltzmann evolution calculations using the sparse data structure of this application. During the calculation process, this application only performs evolution calculations and stores distribution functions for effective fluid nodes, significantly reducing memory usage through a sparse indexing mechanism. In the output stage, a pre-established mapping relationship is used to map the sparse calculation results back to the full-mesh format, allowing the generated data file to be directly loaded and rendered by general-purpose post-processing software. This result demonstrates that this application maintains computational accuracy equivalent to traditional full-mesh methods while significantly reducing storage space usage, verifying the effectiveness of sparse data structures in numerical simulations of precision forming and casting processes.

[0084] This application constructs a bridge between sparse computation and standard output through the aforementioned steps. By triggering a full mesh traversal in response to output commands, and utilizing pre-stored mapping relationships, it quickly distinguishes between fluid and non-fluid nodes, achieving differentiated data filling: sparse indexes are used to accurately read high-fidelity evolution results for fluid nodes, while preset background values ​​are assigned to non-fluid nodes to complete the data domain. This mechanism not only solves the compatibility problem of sparse data structures not being directly recognized by mainstream post-processing tools, but also ensures that a lightweight mapping operation is performed only once when necessary during the output stage, avoiding the introduction of additional performance overhead during core iterations. The final generated full mesh output retains the memory-saving benefits of sparse computation while meeting the industry's demand for standardized data formats, significantly improving the practicality and scalability of the lattice Boltzmann method in complex scenarios such as precision molding and casting.

[0085] In summary, this application provides a migration method for lattice Boltzmann evolution computation. This method eliminates memory redundancy in solid regions at the source by identifying and determining only the fluid nodes involved in the computation and organizing the storage distribution function using sparse indexing technology. Furthermore, it utilizes a bidirectional mapping mechanism between sparse indexes and global coordinates to dynamically calculate the coordinates of adjacent nodes and accurately determine the migration path through table lookup comparison, successfully decoupling physical location from memory layout. This closed-loop mapping chain allows the migration process to adaptively skip solid regions, performing efficient data exchange only between fluid nodes. Ultimately, this scheme significantly reduces memory consumption and improves cache locality and computational efficiency while maintaining the original physical accuracy of the lattice Boltzmann method, effectively solving the memory bottleneck problem faced by traditional full-grid storage methods in complex scenarios such as precision molding and casting.

[0086] The above describes a transfer method in lattice Boltzmann evolution computation provided by embodiments of this application. The following will describe a system for performing the above-described transfer method in lattice Boltzmann evolution computation.

[0087] Please see Figure 6 , Figure 6 This is a schematic diagram of the migration system in lattice Boltzmann evolution computation provided as an embodiment of this application. (See attached diagram.) Figure 6 As shown, the migration system in this lattice Boltzmann evolution calculation includes:

[0088] The acquisition unit 11 is used to determine at least one fluid node participating in the lattice Boltzmann evolution calculation from multiple grid nodes in the computational domain, and to acquire the sparse index of each fluid node, as well as the distribution function of each fluid node in each preset discrete velocity direction stored based on the sparse index of each fluid node.

[0089] The determining unit 12 is used to determine the global coordinates of the fluid node's adjacent grid nodes in the preset discrete velocity direction for each fluid node, based on the sparse index of the fluid node and the preset discrete velocity direction of the fluid node.

[0090] The judgment unit 13 is used to determine whether the global coordinates of the adjacent grid nodes correspond to the sparse index of any fluid node;

[0091] The migration unit 14 is used to migrate the distribution function of the fluid node in a preset discrete velocity direction based on the sparse index of the fluid node if the global coordinates of the adjacent grid node correspond to the sparse index of the fluid node.

[0092] In one possible implementation, the device further includes:

[0093] The processing unit is configured to perform boundary processing on the distribution function of the fluid node in a preset discrete velocity direction based on a preset boundary rule if the global coordinates of the adjacent grid node do not correspond to the sparse index of any fluid node.

[0094] In one possible implementation, the determining unit 12 includes:

[0095] The first determining subunit is used to determine the global coordinates of each fluid node based on the sparse index of the fluid node and a pre-established first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sparse index of the fluid node and the global coordinates of the fluid node.

[0096] The second determining subunit is used to determine the global coordinates of adjacent grid nodes of the fluid node in the preset discrete velocity direction based on the preset discrete velocity direction of the fluid node and the global coordinates of the fluid node.

[0097] In one possible implementation, the determination unit 13 includes:

[0098] The judgment sub-unit is used to determine whether the global coordinates of the adjacent grid nodes are consistent with the global coordinates of any fluid node;

[0099] The third determining subunit is used to determine the sparse index of a fluid node corresponding to the global coordinates of the adjacent grid node based on a pre-established second mapping relationship if the global coordinates of the adjacent grid node are consistent with the global coordinates of a fluid node. The second mapping relationship is used to characterize the mapping relationship between the global coordinates of the fluid node and the sparse index of the fluid node.

[0100] The fourth determining sub-unit is used to determine, based on the second mapping relationship, that the global coordinates of the adjacent grid node do not correspond to the sparse index of any fluid node if the global coordinates of the adjacent grid node are not consistent with the global coordinates of any fluid node.

[0101] In one possible implementation, the device further includes:

[0102] The allocation unit is used to obtain the global coordinates of each fluid node and assign incremental sparse indices to each fluid node in a preset order.

[0103] The construction unit is used to construct the first mapping relationship and the second mapping relationship based on the sparse index of each fluid node and the global coordinates of each fluid node.

[0104] In one possible implementation, the device further includes:

[0105] A response unit is configured to, in response to an output command, determine whether a mesh node is a fluid node based on the acquired global coordinates of the mesh node for each mesh node.

[0106] The result determination unit is used to read the evolution calculation result of the grid node based on the obtained sparse index of the grid node if the grid node is the fluid node; and to determine the preset background value as the evolution calculation result of the grid node if the grid node is not the fluid node.

[0107] The generation unit is used to generate the output result of the computational domain based on the evolution calculation results of each of the grid nodes.

[0108] This application also provides an electronic device in its embodiments. (See reference...) Figure 7 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 7The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0109] like Figure 7 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 701, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 702 or a program loaded from a storage device 708 into a random access memory (RAM) 703. When the electronic device is powered on, the RAM 703 also stores various programs and data required for the operation of the electronic device. The processing unit 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output (I / O) interface 705 is also connected to the bus 704.

[0110] Typically, the following devices can be connected to I / O interface 705: input devices 706 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 707 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 708 including, for example, memory cards, hard drives, etc.; and communication devices 709. Communication device 709 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 7 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.

[0111] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the lattice Boltzmann evolution computation methods provided in this application.

[0112] This application also provides a computer-readable storage medium carrying one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the migration methods in lattice Boltzmann evolution computation provided in this application.

[0113] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0114] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0115] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0116] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method of migration in lattice-Boltzmann evolution computation, characterized by, include: At least one fluid node participating in the lattice Boltzmann evolution calculation is determined from multiple grid nodes in the computational domain, and the sparse index of each fluid node is obtained, as well as the distribution function of each fluid node in each preset discrete velocity direction stored based on the sparse index of each fluid node. For each fluid node, based on the sparse index of the fluid node and the preset discrete velocity direction of the fluid node, the global coordinates of the adjacent grid nodes of the fluid node in the preset discrete velocity direction are determined; Determine whether the global coordinates of the adjacent grid nodes correspond to the sparse index of any fluid node; If the global coordinates of the adjacent grid node correspond to the sparse index of a fluid node, then the distribution function of the fluid node in the preset discrete velocity direction is migrated based on the sparse index of the corresponding fluid node.

2. The method of claim 1, wherein, After determining whether the global coordinates of the adjacent grid nodes correspond to the sparse index of any fluid node, the method further includes: If the global coordinates of the adjacent grid nodes do not correspond to the sparse index of any fluid node, then the distribution function of the fluid node in the preset discrete velocity direction is subjected to boundary processing based on the preset boundary rules.

3. The transfer method in lattice Boltzmann evolution calculation according to claim 1, characterized in that, For each fluid node, determining the global coordinates of adjacent grid nodes in the preset discrete velocity direction based on the sparse index of the fluid node and the preset discrete velocity direction of the fluid node includes: For each fluid node, the global coordinates of the fluid node are determined based on the sparse index of the fluid node and a pre-established first mapping relationship. The first mapping relationship is used to characterize the mapping relationship between the sparse index of the fluid node and the global coordinates of the fluid node. Based on the preset discrete velocity direction of the fluid node and the global coordinates of the fluid node, the global coordinates of the adjacent grid nodes of the fluid node in the preset discrete velocity direction are determined.

4. The transfer method in lattice Boltzmann evolution calculation according to claim 3, characterized in that, The step of determining whether the global coordinates of the adjacent grid nodes correspond to the sparse index of any fluid node includes: Determine whether the global coordinates of the adjacent grid nodes are consistent with the global coordinates of any fluid node; If the global coordinates of the adjacent grid node are consistent with the global coordinates of a fluid node, then based on the pre-established second mapping relationship, the global coordinates of the adjacent grid node are determined to correspond to the sparse index of a fluid node. The second mapping relationship is used to characterize the mapping relationship between the global coordinates of the fluid node and the sparse index of the fluid node. If the global coordinates of the adjacent grid node are not consistent with the global coordinates of any fluid node, then based on the second mapping relationship, it is determined that the global coordinates of the adjacent grid node do not correspond to the sparse index of any fluid node.

5. The transfer method in lattice Boltzmann evolution calculation according to claim 4, characterized in that, The process of establishing the first mapping relationship and the second mapping relationship includes: Obtain the global coordinates of each fluid node, and assign incremental sparse indices to each fluid node in a preset order; Based on the sparse index of each fluid node and the global coordinates of each fluid node, the first mapping relationship and the second mapping relationship are constructed.

6. The transfer method in lattice Boltzmann evolution calculation according to claim 1, characterized in that, The method further includes: In response to the output command, for each of the mesh nodes, it is determined whether the mesh node is a fluid node based on the acquired global coordinates of the mesh node; If the grid node is a fluid node, the evolution calculation result of the grid node is read based on the obtained sparse index of the grid node; if the grid node is not a fluid node, the preset background value is determined as the evolution calculation result of the grid node. Based on the evolution calculation results of each of the grid nodes, the output results of the computational domain are generated.

7. A migration device in lattice Boltzmann evolution computation, characterized in that, include: The acquisition unit is used to determine at least one fluid node participating in the lattice Boltzmann evolution calculation from multiple grid nodes in the computational domain, and to acquire the sparse index of each fluid node, as well as the distribution function of each fluid node in each preset discrete velocity direction stored based on the sparse index of each fluid node. The determining unit is used to determine, for each fluid node, the global coordinates of the adjacent grid nodes in the preset discrete velocity direction of the fluid node, based on the sparse index of the fluid node and the preset discrete velocity direction of the fluid node; The judgment unit is used to determine whether the global coordinates of the adjacent grid nodes correspond to the sparse index of any fluid node; The migration unit is used to migrate the distribution function of the fluid node in a preset discrete velocity direction based on the sparse index of the fluid node if the global coordinates of the adjacent mesh node correspond to the sparse index of the fluid node.

8. A computer program product, characterized in that, Includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the migration method in lattice Boltzmann evolution computation as described in any one of claims 1 to 6.

9. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the migration method in lattice Boltzmann evolution computation as described in any one of claims 1 to 6.

10. A computer storage medium, characterized in that, The storage medium carries one or more computer programs that, when executed by an electronic device, enable the electronic device to implement the migration method in lattice Boltzmann evolution computation as described in any one of claims 1 to 6.

Images