Node-based adjacent grid searching method and system

Abstract

The invention relates to an adjacent grid searching method and system based on nodes. The method comprises the following steps of S1, importing grid data; s2, constructing a hash table; s3, maintaining a hash table; and S4, querying the adjacent grids of the target grid. The method solves the query efficiency problem under the condition of frequent grid updating, has the advantages of efficiently supporting dynamic grid data updating, remarkably reducing the calculation overhead and improving the adjacent grid query efficiency, avoids high calculation overhead for reconstructing the whole data structure, and has the advantages of being high in efficiency and high in efficiency especially when the grids are locally segmented and merged. According to the method, the relation between adjacent grids can be quickly updated, the query efficiency is remarkably improved, the dynamic expansion capacity is achieved, the real-time storage and query requirements of large-scale grid data can be effectively met, and the method is suitable for the scene of efficiently processing million-level grid data.

Description

Technical Field

[0001] This invention relates to the fields of computer graphics and computer-aided engineering technology, specifically to a node-based method and system for finding adjacent grids. Background Technology

[0002] In the field of Computer-Aided Engineering (CAE), mesh generation is a crucial step in solving complex physical problems (such as structural mechanics and fluid mechanics). As the scale of engineering simulation problems continues to expand, the amount of mesh data grows exponentially. Especially in the processing of large-scale mesh data, efficiently finding adjacency relationships between meshes has become a pressing technical challenge. Traditional mesh adjacency query methods typically require high computational overhead, especially when there are frequent local mesh splits and merges. Traditional algorithms often need to reconstruct the entire mesh data structure, leading to low query efficiency.

[0003] In existing technologies, queries for grid adjacency relationships typically employ full traversal or spatial index-based methods. These methods have significant limitations when handling dynamically changing grid data. When a grid undergoes local partitioning or merging, existing technologies often require recalculating the entire grid's topology. This full update approach is not only computationally intensive but also significantly reduces query response time. Furthermore, when processing millions of grid data points, the lack of an efficient indexing mechanism leads to a sharp decline in query performance, making it difficult to meet real-time requirements.

[0004] While some optimization methods have improved query efficiency to some extent, these methods still suffer from computational bottlenecks when the grid data volume reaches millions and is frequently dynamically updated, making it difficult to meet the requirements of efficient querying. Especially when performing local grid segmentation and merging operations, how to efficiently and in real-time update the adjacency relationships of grids without rebuilding the entire data structure becomes crucial for improving query efficiency. Current technologies have not yet effectively solved this technical challenge, and there is an urgent need for a grid adjacency relationship lookup scheme that supports dynamic updates and offers high query efficiency.

[0005] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0006] In view of the above-mentioned deficiencies of the prior art, the first aspect of the present invention provides a node-based neighbor grid search method, comprising the following steps: Step S1: Import grid data; wherein the grid data includes multiple grid IDs and their corresponding set of node IDs; Step S2: Construct a hash table; wherein the hash table is used to construct and store the mapping relationship between node IDs and their associated set of grid IDs; Step S3: Maintain the hash table; wherein, when a local split or merge occurs in the grid, the hash table is incrementally updated, updating only the affected node and grid data; Step S4: Query the neighboring grids of the target grid; wherein, in response to the input of the target grid ID, the set of neighboring grid IDs of the target grid is obtained by querying the hash table.

[0007] In the node-based neighbor grid lookup method described above, optionally, the construction of the hash table in step S2 further includes the following steps: The MurmurHash algorithm is used to calculate the hash value of each node ID to determine its storage location in the hash table; Each storage location stores the corresponding node ID, a set of grid IDs sharing that node, and a linked list pointer used to resolve hash collisions.

[0008] In the node-based adjacent grid search method described above, optionally, each bucket of the hash table stores a linked list, and multiple elements with the same hash value are stored in the same linked list; When the number of stored elements exceeds the threshold set by the load factor, the hash table automatically expands, doubling the number of buckets and recalculating the storage location for existing elements.

[0009] In the node-based neighbor grid search method described above, step S3 may optionally include the following steps: Remove grid IDs that became invalid due to splitting or merging operations from the hash table; Insert the newly added grid ID and its corresponding node ID association into the hash table.

[0010] In the node-based neighboring grid search method described above, optionally, when a grid is partially split or merged, the grid ID change rule is configured as follows: the original grid ID is deleted, and the new grid ID is incremented based on the original maximum grid ID, wherein the new grid ID is the grid ID newly generated during the partial split or the grid ID merged during the partial merge; the existing node ID remains unchanged, and the new node ID is incremented based on the original maximum node ID.

[0011] In the node-based neighbor grid search method described above, optionally, in step S3, The local segmentation process also includes the following steps: Incremental update of the hash table maintenance: first traverse the node IDs of the divided grid, find the corresponding storage location in the hash table, and delete the divided grid ID; Starting from the end of the imported split grid data, traverse the new grid data, adding the new grid data to the hash table in turn, until an existing grid ID is encountered, that is, stop traversing when the grid ID exists in the original hash table; The process of local merging also includes the following steps: Incremental updates maintain the hash table. First, traverse the node IDs of the merged grids, find the corresponding storage location in the hash table, and delete the merged grid IDs. Starting from the end of the imported merged grid data, traverse the grid data, adding new grid data to the hash table in turn, until an existing grid ID is encountered, that is, stop traversing when the grid ID exists in the original hash table.

[0012] In the node-based neighboring grid search method described above, optionally, when querying the neighboring grid ID of the target grid in step S4, the following steps are also included: Traverse the set of node IDs of the target mesh; Retrieve the set of grid IDs associated with each node ID from the hash table; The query results are deduplicated, and the IDs of the adjacent grids of the target grid are finally returned.

[0013] To achieve the above objectives, a second aspect of the present invention provides a node-based neighbor grid search system, wherein the node-based neighbor grid search method as described in any of the embodiments of the first aspect includes: The data import module is used to import grid data; wherein, the grid data includes multiple grid IDs and their respective sets of node IDs; The hash table building module is used to build and store hash tables that map the relationship between node IDs and their associated set of grid IDs. The dynamic maintenance module is used to incrementally update the hash table when the grid is partially split or merged, updating only the affected node and grid data; The adjacent query module is used to obtain the set of adjacent grid IDs of the target grid by querying the hash table in response to the input of the target grid ID.

[0014] To achieve the above objectives, a third aspect of the present invention provides a terminal device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when running the program, implements the node-based neighbor grid search method as described in any one of the preceding first aspects.

[0015] To achieve the above objectives, a fourth aspect of the present invention provides a computer-readable storage medium storing computer-executable instructions or a computer program that, when executed by a processor, implements the node-based adjacent grid search method as described in any one of the first aspects above.

[0016] This invention provides a node-based adjacent grid search method and system. By constructing a hash table to establish a mapping relationship between nodes and grids, and incrementally updating only the affected parts when the grid changes dynamically, it solves the query efficiency problem under frequent grid updates. It has the advantages of efficiently supporting dynamic grid data updates, significantly reducing computational overhead, and improving the efficiency of adjacent grid queries, while avoiding the high computational cost of rebuilding the entire data structure. Especially during local grid segmentation and merging, it can quickly update the relationship between adjacent grids, significantly improving query efficiency. It also has dynamic scalability, effectively addressing the real-time storage and query needs of large-scale grid data, and is suitable for scenarios involving the efficient processing of millions of grid data points.

[0017] The following will further explain the concept, specific structure, and technical effects of the present invention in conjunction with the accompanying drawings, so as to fully understand the purpose, features, and effects of the present invention. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating an embodiment of a node-based adjacent grid search method provided by the present invention; Figure 2 yes Figure 1 A flowchart illustrating an embodiment of step S2; Figure 3 yes Figure 1 A schematic diagram of the structure of one embodiment of step S3; Figure 4 yes Figure 1 A flowchart illustrating an embodiment of step S4. Detailed Implementation

[0019] To make the technical means, inventive features, objectives, and effects of the invention readily understandable, the invention is further illustrated below with reference to specific figures. However, the invention is not limited to the embodiments described below.

[0020] It should be noted that the structures, proportions, sizes, etc., illustrated in the accompanying drawings of this specification are only used to complement the content disclosed in the specification for those skilled in the art to understand and read, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0021] Terms such as “comprising” and “including” indicate that, in addition to the components that are directly and explicitly stated in the specification and claims, the technical solution of the present invention does not exclude the presence of other components that are not directly or explicitly stated.

[0022] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0023] In traditional computer-aided engineering grid data processing, the efficiency of adjacency lookup is limited by the frequent reconstruction of the global data structure. When a grid is partially split or merged, the system needs to re-traverse all node-grid relationships and rebuild the complete topology index structure. This global reconstruction mechanism leads to a non-linear increase in computational resource consumption and grid size, especially in simulation scenarios with high dynamic update frequencies, resulting in a significant increase in system response time.

[0024] For example, in transient fluid dynamics simulations, the mesh needs to be locally refined and merged in real time based on changes in flow field characteristics. Each local adjustment triggers a global index reconstruction, causing computational nodes to traverse all boundary nodes of millions of mesh cells and recalculate adjacency relationships. This process consumes more than 80% of the simulation computation cycle, causing the flow field solver to wait for topology data updates, severely restricting the real-time performance of multiphysics coupled computations.

[0025] If the above problems are not addressed, frequent global reconstruction operations will lead to a continuous deterioration in computing resource utilization, making the system unable to meet the real-time interactive requirements of engineering simulations. In long-running operational condition prediction scenarios, accumulated computational latency may cause simulation progress to lag behind the actual physical process, severely impacting the timeliness of engineering decisions. Simultaneously, the memory peaks during large-scale mesh processing may exceed the hardware's capacity, leading to the risk of computational interruption or result loss.

[0026] To address this, the present invention proposes a node-based neighbor grid search method, such as... Figure 1 As shown, it may include the following steps: Step S1: Import grid data.

[0027] In step S1, grid data refers to structured data that includes multiple grid IDs and their corresponding set of node IDs. This data can be obtained by file reading or database querying and is used to provide the initial association between grids and nodes. This step provides the data foundation for establishing the mapping relationship later.

[0028] In this embodiment, the imported grid data is sorted in ascending order by grid ID. The format is as follows: [{cellid1:[nodeid1,nodeid2,nodeid3,...]},{cellid2:[nodeid4,nodeid5,nodeid6,...]},..,].

[0029] Step S2: Construct a hash table.

[0030] In step S2, a hash table is used to construct and store the mapping between node IDs and their associated set of grid IDs. The use of a hash table enables fast indexing from nodes to grids.

[0031] In an optional embodiment, the construction of the hash table in step S2 may further include the following steps: The MurmurHash algorithm is used to calculate the hash value of each node ID to determine its storage location in the hash table; Each storage location stores the corresponding node ID, a set of grid IDs sharing that node, and a linked list pointer used to resolve hash collisions.

[0032] Specifically, the MurmurHash algorithm was chosen for hash value calculation. Its core lies in achieving rapid mixing through bitwise operations and non-linear transformations. For example, in 32-bit hash calculations, rotation and XOR operations are used, allowing even small changes in the input data to cause significant differences in the hash value. The data structure for each storage location is designed to include a node ID field, a grid ID set field, and a linked list pointer field. The grid ID set is stored in an array with an initial capacity of 8. The linked list pointer links conflicting elements within the same hash bucket, using a singly linked list structure. Each linked list node contains the element data with the same hash value and a pointer to the next node. The hash table's load factor can be set to 0.75. When the number of elements exceeds the product of the number of buckets and the load factor, automatic resizing is triggered, for example, doubling the number of buckets and redistributing the elements.

[0033] Specifically, in the hash table construction process, the node ID is first converted into a hash value using the MurmurHash algorithm. For example, the input node ID is segmented and multiple rounds of mixed operations are performed to generate a 32-bit hash code, which is then moduloed to determine the storage bucket location. Each storage bucket stores the node ID and its associated set of grid IDs. For example, when node A is shared by grid 1 and grid 2, its corresponding storage location records the ID of node A and the set containing grid 1 and grid 2. When different node IDs are mapped to the same storage bucket after hash calculation, conflicting elements are linked together using a linked list pointer. For example, if node B and node C have the same hash value, a pointer is set in the storage location of node B to point to the linked list node of node C. During the query process, the target storage bucket is directly located through hash calculation, and the associated grid set can be quickly obtained by traversing the linked list and comparing the node IDs. This scheme reduces the probability of collisions through hash algorithm optimization and achieves dynamic expansion by combining a linked storage structure. This ensures that the time complexity of the query operation remains between O(1) and O(n) in the scenario of processing millions of grid data, where n is the length of the linked list in a single bucket. In actual tests, the average linked list length does not exceed 3. Meanwhile, the dynamic storage design of the grid ID set supports fast insertion and deletion operations, providing a data foundation for subsequent incremental updates.

[0034] In such Figure 2 In the illustrated embodiment, the underlying data structure of the hash table uses an array. When creating the hash table, an array is created first, with a default size of 16, but users can customize the capacity according to their needs. Then, the node IDs and grid IDs from the imported grid data are parsed out. The MurmurHash algorithm is used to calculate the hash value of the node IDs, determining the location of each node's data within a bucket. Each bucket stores the node ID, shares the same grid set for that node, and a pointer to the linked list.

[0035] This invention uses a linked list method to resolve hash collisions. When there is no hash collision, the data is stored in a bucket. When there is a hash collision, the data is stored in the linked list connected to the corresponding bucket. Multiple elements with the same hash value are stored in the same linked list.

[0036] As the number of grid cells increases, the hash table supports dynamic expansion. This application expands the hash table by setting a load factor. In an optional embodiment, the load factor is set to 0.75. In other optional embodiments, the user can also set the value of the load factor according to actual needs.

[0037] Furthermore, this application proposes that each bucket of the hash table stores a linked list, and multiple elements with the same hash value are stored in the same linked list; when the number of stored elements exceeds the threshold set by the load factor, the hash table is automatically expanded, doubling the number of buckets and recalculating the storage location of existing elements.

[0038] The linked list structure within each bucket allows elements with the same hash value to be stored in a chained manner. For example, each linked list node can contain key-value pairs and a pointer to the next node. When a hash collision occurs, the new element is appended to the tail of the linked list in the corresponding bucket, avoiding the linear probing overhead of open addressing. The load factor threshold can be set between 0.6 and 0.9. For example, when set to 0.75, a resizing operation is triggered when the number of stored elements reaches 75% of the total number of buckets. During resizing, the number of buckets doubles, for example, from an initial 16 buckets to 32. Then, the hash values ​​of existing elements are recalculated and allocated to new bucket positions. The recalculation of hash values ​​uses the same MurmurHash algorithm as the initial hash calculation, ensuring uniform element distribution.

[0039] Specifically, when inserting a new element into the hash table, its hash value is first calculated using the MurmurHash algorithm to locate the corresponding bucket. If the linked list of that bucket already contains an element, the new element is added to the end of the linked list without traversing the entire linked list. When the number of elements exceeds the load factor threshold, a resizing mechanism is triggered, creating twice the number of new buckets. All elements in the original hash table are traversed, and their positions in the new buckets are recalculated. For example, if the original hash table contains 8 buckets and has a load factor of 0.75, when the 7th element is inserted, resizing is triggered, the number of new buckets becomes 16, and the original elements are redistributed according to the new number of buckets. Through this doubling of resizing, the hash table's capacity growth maintains a logarithmic relationship with the data volume, significantly reducing the probability of collisions in subsequent insertion operations. After resizing, query operations only need to locate the new bucket and traverse the corresponding linked list, avoiding the problem of excessively long linked lists due to insufficient buckets, thus maintaining stable query efficiency.

[0040] Therefore, the solution in this embodiment not only achieves efficient node-to-grid mapping, but also provides a flexible mechanism for handling hash collisions, ensuring the performance and reliability of the hash table in large-scale data processing.

[0041] Through the above technical solutions, this application effectively solves the performance problems caused by hash collisions, storage efficiency, and insufficient capacity in the process of constructing a hash table. The MurmurHash algorithm is used to calculate the hash value of the node ID, ensuring a uniform distribution of node IDs in the hash table, reducing element accumulation within hash buckets, and improving subsequent query speed. Storing the node ID and its associated set of grid IDs in each storage location directly establishes a mapping relationship from nodes to multiple grids, providing a data foundation for dynamic updates and adjacent queries. Linked list pointers are introduced to resolve hash collisions, avoiding data overwriting or loss due to hash collisions, while maintaining the dynamic expansion capability of the hash table. The linked list structure allows for flexible storage of elements with the same hash value, avoiding the decrease in query efficiency caused by collisions in open addressing. By doubling the number of buckets, the probability of collisions during subsequent insertion operations is reduced. The redistribution of existing elements during the expansion process ensures that the hash table maintains high query performance after expansion, avoiding frequent collisions and performance degradation caused by insufficient buckets. The synergistic effect of these technical features ensures efficient construction and maintenance of hash tables, and provides stable data structure support for subsequent incremental updates and fast queries, thereby improving the overall system performance and reliability.

[0042] Step S3: Maintain the hash table.

[0043] In step S3, when a local split or merge occurs in the mesh, the hash table is incrementally updated, updating only the affected nodes and mesh data, thus avoiding the computational overhead of global data reconstruction. In this way, the system can efficiently maintain changes in the mesh topology.

[0044] In optional embodiments, such as Figure 3 As shown, step S3 may also include the following steps: Remove grid IDs that have become invalid due to splitting or merging operations from the hash table. For example, when a grid is split into multiple sub-grids, the original grid ID is deleted; when multiple grids are merged into a new grid, the original grid IDs of the merged grids are also deleted. This step is achieved by traversing the affected node IDs, finding the corresponding storage location in the hash table, and removing the relevant grid IDs.

[0045] Insert the newly added grid ID and its corresponding node ID association into the hash table.

[0046] The deletion of invalid grid IDs is configured to be achieved by traversing the set of node IDs of the split or merged grids. Specifically, when a grid is split, the original grid ID is marked as invalid, and after its corresponding node ID is located in the hash table, the grid ID is removed from the associated grid ID set. For example, in a grid splitting scenario, if the original grid ID G1 is split into G2 and G3, G1 is identified as an invalid ID and removed from all associated nodes. The insertion of new grid IDs is configured to traverse from the end of the split or merged grid data until an existing grid ID is detected. For example, new grid IDs after a splitting operation are generated according to an incrementing rule, and insertion stops when G2 is detected in the hash table, thus avoiding duplicate updates.

[0047] Specifically, during the dynamic update of the grid, the maintenance of the hash table is performed in two phases. First, by traversing the set of node IDs of the grid being operated on, the corresponding storage location in the hash table is located, and invalid grid IDs are removed from the association set. For example, in a merge operation, after the set of merged grid IDs {G4, G5} is traversed, the associations of their corresponding node IDs in the hash table are cleared. Subsequently, newly added grid IDs and their node associations are inserted into the hash table, where the generation rule for new IDs is configured to increment based on the original maximum ID. For example, if the new grid ID after the merge is G6, its corresponding set of node IDs is inserted into the hash table one by one, and the storage location of each node ID is determined by a hash algorithm. By processing invalid and new data in phases, the hash table only needs to update the locally affected areas, avoiding the computational overhead of full reconstruction, while ensuring the integrity of the associations when querying adjacent grids.

[0048] Through the above technical solution, this application achieves efficient dynamic maintenance of hash tables. By precisely deleting invalid grid IDs and inserting newly added grid ID-node ID associations, the problem of residual invalid data or missing newly added data in the hash table is avoided. This method only performs local updates on the changed parts, without needing to rebuild the entire hash table, greatly reducing computational overhead. At the same time, by maintaining the accuracy and integrity of the data, the accuracy of adjacent grid query results is ensured. This incremental update mechanism is particularly suitable for scenarios with frequent local changes in large-scale grid data, and can significantly improve the efficiency and reliability of grid adjacency relationship queries.

[0049] In an optional embodiment, when a mesh is partially split or merged, the mesh ID change rule is configured as follows: the original mesh ID is deleted, and the new mesh ID is incremented based on the original maximum mesh ID. The new mesh ID is either a newly generated mesh ID during partial splitting or a merged mesh ID during partial merging. The existing node ID remains unchanged, and the new node ID is incremented based on the original maximum node ID.

[0050] The deletion of an original grid ID involves iterating through all node entries associated with that ID in the hash table and removing the corresponding grid ID record. The generation of a new grid ID is based on the largest existing grid ID in the hash table, with a fixed increment size (e.g., 1) to ensure uniqueness and continuity of the new ID. Existing node IDs are retained by skipping update operations on existing node entries, only assigning IDs to newly added nodes. The generation of new node IDs is based on the current largest node ID value in the hash table and uses an incremental allocation method; for example, the largest ID value is incremented by 1 each time a new node is added.

[0051] Specifically, in the grid partitioning scenario, when the original grid is divided into multiple sub-grids, the original grid ID is marked as invalid and deleted from the hash table. Newly added sub-grid IDs are sequentially incremented starting from the current maximum grid ID. For example, if the original maximum grid ID is 100, the IDs of the three newly added sub-grids are 101, 102, and 103, respectively. Existing node IDs remain unchanged; only nodes at the new partition boundaries are assigned the incremented IDs. In the grid merging scenario, the original grid IDs of the merged grids are deleted, and the new merged grid ID is generated by incrementing the current maximum grid ID. The node ID processing rules are consistent with the partitioning scenario: existing nodes retain their original IDs, and new nodes are incremented based on the maximum node ID. Through this rule, grid ID update operations in the hash table can accurately locate the affected storage location, avoiding the performance overhead of global traversal. Simultaneously, the incrementing ID allocation mechanism ensures that the hash table does not experience duplicate identifiers or incorrect associations during dynamic updates, maintaining data consistency.

[0052] Furthermore, in practical implementation, a global counter can be used to track the maximum grid ID and node ID. Each time a grid operation is performed, the current value of this counter is first queried, then an ID is assigned to the newly generated grid or node based on this value, and the counter value is updated after the assignment is complete.

[0053] Therefore, during incremental updates to the hash table, the original grid IDs that need to be deleted can be precisely located, and the newly added grid IDs and their associated node information can be accurately inserted, thus ensuring the consistency and query efficiency of the hash table. Through the above technical solution, this application solves the identifier conflict problem during dynamic updates, ensuring the uniqueness of newly added identifiers and preventing hash table query conflicts caused by random allocation. Simultaneously, by retaining existing node IDs, the stability of the original node relationships is maintained, while the newly added node IDs are generated based on the maximum node ID, avoiding duplication with existing node IDs. This synergistic effect of the dual incrementing rules enables incremental updates to the hash table to accurately locate the affected data range in dynamic partitioning or merging scenarios, while maintaining the orderliness of the global identifier system, thereby improving the efficiency of grid operations and data consistency.

[0054] In this embodiment, the specific local segmentation process may include the following steps: Incremental update of the hash table maintenance: first traverse the node IDs of the divided grid, find the corresponding storage location in the hash table, and delete the divided grid ID; Starting from the end of the imported split grid data, traverse the new grid data, adding the new grid data to the hash table in turn, until an existing grid ID is encountered, that is, stop traversing when the grid ID exists in the original hash table.

[0055] Similarly, the specific process of local merging may include the following steps: Incremental updates maintain the hash table. First, traverse the node IDs of the merged grids, find the corresponding storage location in the hash table, and delete the merged grid IDs. Starting from the end of the imported merged grid data, traverse the grid data, adding new grid data to the hash table in turn, until an existing grid ID is encountered, that is, stop traversing when the grid ID exists in the original hash table.

[0056] In short, the process begins by importing the partially segmented and merged grid data. It then iterates through the node IDs of the partially segmented and merged grid data, calculates the hash value of the node ID using the MurmurHash algorithm, finds the bucket in the hash table containing the partially segmented / merged grid data, deletes the corresponding grid ID from the bucket, and then iterates through the partially segmented and merged grid data from the end, checking if the grid ID exists in the hash table. If the grid ID does not exist in the hash table, the iterated data is inserted into the hash table; if the grid ID exists, the iteration ends, completing the partial data update.

[0057] The hash table deletion operation is implemented by locating the linked list of nodes corresponding to the split or merged grids, and the set of grid IDs stored in each node is dynamically modified. When new data is inserted, the grid ID increment rule is used to quickly locate the new part by traversing backward from the end of the data. The traversal automatically terminates when an existing grid ID is detected. This mechanism works in conjunction with the hash table's automatic expansion capability to maintain query efficiency by doubling the number of buckets when the data volume surges. For example, when the number of stored grids exceeds 75% of the hash table capacity, the number of buckets automatically expands to twice its original size, and the original nodes are redistributed.

[0058] Specifically, in the grid partitioning scenario, the set of node IDs for each grid to be partitioned is queried one by one, and the corresponding linked list nodes in the hash table are updated to remove the old grid IDs. The new grid data generated by the partitioning is arranged in ascending order of IDs. When scanning backward from the end of the data, the newly added ID sequence forms a continuous interval with the original data. The insertion operation stops when an existing ID value is encountered. During the merging operation, the IDs of the grids to be merged are removed from all associated nodes, and the IDs of the merged new grids are generated in an ascending manner. Traversing the end of the data ensures that only the newly added part is processed.

[0059] From a time complexity perspective, when performing local grid partitioning or merging, the incremental update method only updates the data of the affected grids. Assuming each partition or merge involves only p grids, the time complexity of the incremental update operation is O(p * k), where p is the number of affected grids and k is the number of nodes in each grid. Compared to the traditional global reconstruction method (which requires rebuilding the entire grid data structure), the time complexity of incremental updates is significantly reduced. From a space complexity perspective, incremental updates only update the affected grids and nodes, so the space overhead is relatively small, involving only local adjustments to the hash table. The increase in space complexity mainly comes from hash table resizing: as the amount of data increases, the hash table will dynamically resize (when the number of elements exceeds the load factor). During resizing, the number of buckets in the hash table doubles, and all elements are rehashed and allocated to new buckets. The time complexity of this operation is O(N), where N is the number of elements currently stored in the hash table. Although the resizing overhead is high, the resizing frequency is low, so it will not become a major performance bottleneck.

[0060] This process makes the time complexity of hash table update operations proportional to the scope of local changes, avoiding the performance loss caused by global data reconstruction.

[0061] Step S4: Query the neighboring grids of the target grid.

[0062] In step S4, in response to the input of the target grid ID, the set of neighboring grid IDs of the target grid is obtained by querying the hash table.

[0063] In optional embodiments, such as Figure 4 As shown, querying the neighboring grid IDs of a target grid can include the following steps: Input the target grid data to be queried, and iterate through the set of node IDs of the target grid.

[0064] The MurmurHash algorithm is used to calculate the hash value of the node ID. The hash value is used to find the bucket that stores the data of the node, and the set of grid IDs that share the node in the bucket is obtained. In this way, the set of grid IDs associated with each node ID can be found in the hash table.

[0065] The query results (set of grid IDs) are deduplicated to obtain the neighboring grid IDs of the target grid.

[0066] Specifically, in applications where grid data is dynamically updated, the process first iterates through all node IDs of the target grid. For example, a grid with four boundary nodes will trigger four hash table lookups. Each lookup uses the MurmurHash algorithm to quickly locate the hash bucket and traverses the linked list within the bucket to obtain all grid IDs associated with that node. When a boundary node is shared by three different grids, the set of grid IDs corresponding to that node will return three distinct IDs. The hash set is then used to deduplicate all query results, reducing an initial lookup containing 50 IDs to 35 unique IDs. The final output set of neighboring grid IDs can be directly used for neighborhood calculations in finite element analysis, avoiding the additional computational overhead caused by duplicate data.

[0067] In this embodiment, from a time complexity perspective, when querying the neighboring grids of a target grid, the algorithm first traverses the set of node IDs of the target grid, and then searches for the set of associated grid IDs for each node ID in the hash table. The time complexity of this process is O(k), where k is the number of nodes in the target grid. Since the average time complexity of a hash table query operation is O(1), the overall query time complexity is basically O(k), which is linearly related to the number of nodes in the target grid. From a space complexity perspective, the hash table needs to store each node ID and its associated set of grid IDs. Assuming there are a total of N grids, each grid corresponds to a set of nodes, and each node has at most M grid IDs. The space complexity of the hash table is O(N * M), which is proportional to the number of grids and the number of grids corresponding to each node.

[0068] Through the above technical solution, this application effectively solves the problem of result redundancy in adjacent grid queries. Specifically, by traversing all node IDs of the target grid, the integrity of the query range is ensured, avoiding the omission of adjacent grids. Utilizing the fast query characteristics of hash tables significantly improves query efficiency. Finally, by performing deduplication on the query results, duplicate grid IDs caused by node sharing are eliminated, ensuring the accuracy and uniqueness of the returned results. This method not only maintains high query speed but also improves the accuracy of the results, thereby optimizing the efficiency of subsequent processing flows.

[0069] To achieve the above objectives, the present invention also proposes a node-based adjacent grid search system, including a data import module, a hash table construction module, a dynamic maintenance module, and an adjacent query module.

[0070] The data import module is used to import grid data, which can include multiple grid IDs and their corresponding set of node IDs. This module can be configured to batch load grid data through a structured data interface, which supports data input in CSV or binary stream formats, and can efficiently read terabyte-level grid data using memory mapping technology, for example.

[0071] The hash table building module is implemented as an independent data storage unit. The hash table building module is used to build and store hash tables that map the relationship between node IDs and their associated set of grid IDs.

[0072] The dynamic maintenance module is implemented as an event responder to incrementally update the hash table when a local mesh split or merge occurs, updating only the affected nodes and mesh data. This module can trigger incremental update operations by subscribing to mesh topology change events; for example, in a mesh split operation, it only needs to process local areas involving no more than 5% of the total number of nodes.

[0073] The neighbor query module responds to the input of a target grid ID by retrieving the set of neighbor grid IDs of the target grid through a hash table. This module can receive query requests via a message queue and employs a multi-threaded parallel processing mechanism. For example, each query request is broken down into subtasks equal to the number of nodes in the target grid for parallel hash table access.

[0074] The specific implementation method has been described in detail above and will not be repeated here.

[0075] To achieve the above objectives, the present invention also provides a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor runs the program, it can implement the steps of the node-based adjacent grid search method as described in any of the foregoing embodiments.

[0076] Processors and memory can be configured separately or integrated together, for example, integrated on a system-on-chip (SOC) in a terminal device.

[0077] To achieve the above objectives, the present invention also provides a computer-readable storage medium storing computer-executable instructions or a computer program, which, when processed and executed, implement the node-based adjacent grid search method as described above.

[0078] The computer-readable storage medium is, for example, memory. Memory can be volatile or non-volatile, or it can include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DRRAM).

[0079] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0080] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A node-based adjacent grid search method, characterized in that, Includes the following steps: Step S1: Import grid data; wherein the grid data includes multiple grid IDs and their corresponding set of node IDs; Step S2: Construct a hash table; wherein the hash table is used to construct and store the mapping relationship between node IDs and their associated set of grid IDs; Step S3: Maintain the hash table; wherein, when a local split or merge occurs in the grid, the hash table is incrementally updated, updating only the affected node and grid data; Step S4: Query the neighboring grids of the target grid; wherein, in response to the input of the target grid ID, the set of neighboring grid IDs of the target grid is obtained by querying the hash table.

2. The node-based adjacent grid search method according to claim 1, characterized in that, The construction of the hash table in step S2 also includes the following steps: The MurmurHash algorithm is used to calculate the hash value of each node ID to determine its storage location in the hash table; Each storage location stores the corresponding node ID, a set of grid IDs sharing that node, and a linked list pointer used to resolve hash collisions.

3. The node-based adjacent grid search method according to claim 2, characterized in that, Each bucket of the hash table stores a linked list, and multiple elements with the same hash value are stored in the same linked list. When the number of stored elements exceeds the threshold set by the load factor, the hash table automatically expands, doubling the number of buckets and recalculating the storage location for existing elements.

4. The node-based adjacent grid search method according to claim 1, characterized in that, Step S3 further includes the following steps: Remove grid IDs that became invalid due to splitting or merging operations from the hash table; Insert the newly added grid ID and its corresponding node ID association into the hash table.

5. The node-based adjacent grid search method according to claim 4, characterized in that, When a mesh is partially split or merged, the mesh ID change rules are configured as follows: the original mesh ID is deleted, and the new mesh ID is incremented based on the original maximum mesh ID. The new mesh ID is either the mesh ID newly generated during the partial split or the mesh ID merged during the partial merge. The existing node ID remains unchanged, and the new node ID is incremented based on the original maximum node ID.

6. The node-based adjacent grid search method according to claim 5, characterized in that, In step S3, The local segmentation process also includes the following steps: Incremental update of the hash table maintenance: first traverse the node IDs of the divided grid, find the corresponding storage location in the hash table, and delete the divided grid ID; Starting from the end of the imported split grid data, traverse the new grid data, adding the new grid data to the hash table in turn, until an existing grid ID is encountered, that is, stop traversing when the grid ID exists in the original hash table; The process of local merging also includes the following steps: Incremental updates maintain the hash table. First, traverse the node IDs of the merged grids, find the corresponding storage location in the hash table, and delete the merged grid IDs. Starting from the end of the imported merged grid data, traverse the grid data, adding new grid data to the hash table in turn, until an existing grid ID is encountered, that is, stop traversing when the grid ID exists in the original hash table.

7. The node-based adjacent grid search method according to claim 1, characterized in that, In step S4, when querying the neighboring grid IDs of the target grid, the following steps are also included: Traverse the set of node IDs of the target mesh; Retrieve the set of grid IDs associated with each node ID from the hash table; The query results are deduplicated, and the IDs of the adjacent grids of the target grid are finally returned.

8. A node-based adjacent grid search system, characterized in that, The node-based neighbor grid lookup method as described in any one of claims 1 to 7 includes: The data import module is used to import grid data; wherein, the grid data includes multiple grid IDs and their respective sets of node IDs; The hash table building module is used to build and store hash tables that map the relationship between node IDs and their associated set of grid IDs. The dynamic maintenance module is used to incrementally update the hash table when the grid is partially split or merged, updating only the affected node and grid data; The adjacent query module is used to obtain the set of adjacent grid IDs of the target grid by querying the hash table in response to the input of the target grid ID.

9. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor runs the program, it implements the node-based neighbor grid search method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions or computer programs, which, when processed and executed by a processor, implement the node-based adjacent grid search method as described in any one of claims 1 to 7.

Images