A method and device for constructing underlying model data structure
By using a combination pattern in finite element simulation software to design the basic hierarchical data structure and designing data structures separately for the interaction model and analysis model, the problem of high coupling between interactive modeling data and analysis data is solved, and the efficient organization of data is achieved. Management improves the development and maintenance efficiency of simulation software.
Patent Information
- Application Number
- CN202410802873.8
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-06-20
- Publication Date
- 2025-02-25
- Estimated Expiration
- 2044-06-20
AI Technical Summary
In existing finite element simulation software, the high coupling between interactive modeling data and analytical data results in low efficiency in organization, storage, retrieval and operation of data, and is not conducive to software development and maintenance.
The basic hierarchical data structure is designed using a combination pattern, the data structure is designed for the interaction model and the analysis model, and a data conversion mechanism between the two is constructed to realize the customized design and management of interactive modeling data and analytical data.
Reduces the coupling between interactive modeling data and analytical data, creates a clear and streamlined data framework, reduces development complexity and maintenance overhead, enhances the intuitiveness of data interaction in the user interface, and improves modeling and simulation efficiency. With user experience.
Smart Images

Figure CN118607318B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of finite element simulation, and in particular to a method and device for constructing an underlying model data structure. Background Art
[0002] In the current rapidly developing field of science and engineering, the position of finite element simulation software as a core design and analysis tool has become increasingly prominent. The finite element method (FEM) successfully overcomes the obstacles of multiple engineering disciplines by converting complex solid structures into discrete units for efficient numerical simulation, including but not limited to stress analysis, heat conduction, fluid dynamics and sound propagation, and has become the cornerstone of design verification and performance improvement in key fields from mechanical manufacturing to aerospace, automotive industry, civil construction, energy development and even biomedicine.
[0003] Within the scope of this technology, the interactive finite element modeling and simulation process includes two core steps: model construction and simulation analysis. The model construction phase requires users to interactively establish a geometric representation of the problem, configure material properties, boundary conditions, and perform meshing. The subsequent simulation calculation phase is based on the model details constructed in the early stage to form and solve the overall stiffness matrix equation to obtain an engineering solution.
[0004] In this process, modeling emphasizes user interactivity, while simulation focuses on algorithm processing. Both stages require a solid data foundation, which is usually implemented as interrelated data entity classes through object-oriented design, which not only stores necessary information but also provides data operation interfaces. However, with the expansion of software functions and the growth of code bases, the management of data classes tends to be complex. If there is a lack of efficient data structure design, it will directly restrict the scalability and maintainability of the software and increase the development and maintenance costs. This is also one of the key factors that limit the progress of domestic finite element software in interactive modeling and simulation related functions.
[0005] Therefore, there is an urgent need for a method and device for constructing the underlying model data structure, which aims to design the basic data structure at the abstract level to ensure that it can meet basic needs and flexibly adapt to the specific requirements of each functional module, providing solid data support for the entire simulation process. This is intended to create a clear and streamlined data framework for developers, reduce development complexity and long-term maintenance costs, and enhance the intuitiveness of data interaction in the user interface, thereby improving the efficiency and user experience of modeling and simulation. Summary of the invention
[0006] In view of this, it is necessary to provide a method and device for constructing an underlying model data structure to solve the technical problems existing in the prior art, such as low efficiency in data organization, storage, retrieval and operation, and inconvenience in development and maintenance of finite element simulation software due to the high coupling between interactive modeling data and analysis data.
[0007] On the one hand, in order to solve the above technical problems, the present invention provides a method for constructing an underlying model data structure, which is applied to finite element simulation software, and the method comprises:
[0008] Design basic hierarchical data structures based on composite patterns;
[0009] Designing an interaction model data structure based on the hierarchical data structure;
[0010] Designing an analysis model data structure based on the hierarchical data structure;
[0011] Design a model data conversion mechanism between the interaction model data structure and the analysis model data structure.
[0012] In a possible implementation, the designing of the basic hierarchical data structure based on the combination pattern includes:
[0013] At the abstract level, it is designed as a tree-like hierarchical structure composed of nodes, wherein the nodes include branch nodes and leaf nodes, and the branch nodes include container branch nodes and model branch nodes;
[0014] In combination with the finite element modeling and simulation requirements, an abstract model node class BaseObject and an abstract container class BaseContainerObject are designed for the model branch node and the container branch node respectively; the abstract model node class BaseObject and the abstract container class BaseContainerObject constitute the basic hierarchical data structure.
[0015] In a possible implementation, the abstract model node class BaseObject is used to:
[0016] Based on the multi-level features of branch nodes and leaf nodes in the tree hierarchy, model node management methods such as add_child() and remove_child() are provided.
[0017] In a possible implementation, after designing the basic hierarchical data structure based on the combination pattern, the method further includes:
[0018] Based on the support of Qt model-view components, data() and row() data access methods are provided for the basic hierarchical data structure;
[0019] Based on the visualization requirements of finite element modeling simulation data, generate_name() and set_parent() methods are provided for the basic hierarchical data structure.
[0020] In a possible implementation, based on the support for Qt model-view components, providing data() and row() data access methods for the basic hierarchical data structure includes:
[0021] Develop Qt data model class QmyDataModel to implement Qt abstract item model class QAbstractItemModel;
[0022] Develop data() and row() data access methods in the abstract model node class BaseObject, construct the basic hierarchical data structure and associate it with the Qt data model class QmyDataModel;
[0023] Based on the Qt model-view interaction component, interactive functions are designed for the basic layer data.
[0024] In a possible implementation, the abstract container class BaseContainerObject inherits from the abstract model node class BaseObject, and the abstract container class BaseContainerObject has all the properties and methods of the abstract model node class BaseObject.
[0025] In a possible implementation, the designing of the interaction model data structure based on the hierarchical data structure includes:
[0026] Based on the basic hierarchical data structure, according to the different requirements of each functional module involved in the modeling process, the abstract level expansion and the specific level implementation are performed to generate an interactive model data structure;
[0027] Wherein, the functional modules include:
[0028] The sketch module has key functions including sketching and geometric constraint functions. For the sketching function, the relevant data involved in the sketching process is decomposed into the sketch and its basic geometric elements, and a reasonable sketch module data structure is designed based on the basic hierarchical data structure.
[0029] The component module has key functions including component creation and component Boolean operation. For the component creation function, the relevant data involved in the component creation process is decomposed into various component features, and reasonable data structures are designed for different features based on the basic hierarchical data structure.
[0030] Boundary module, whose key functions include boundary / load condition creation and visualization. For boundary / load condition creation and visualization, consider how to establish the relationship between boundary / load conditions, application area and component topology, and design a reasonable boundary module data structure based on the basic hierarchical data structure.
[0031] The key functions of the grid module include grid division and visualization. For the grid division and visualization functions, the data association between the geometric model, grid model and grid visualization model is clarified, and a reasonable grid module data structure is designed based on the basic hierarchical data structure.
[0032] In a possible implementation, the designing and analyzing the model data structure based on the hierarchical data structure includes:
[0033] Following the standardized calculation process requirements of the finite element, based on the basic hierarchical data structure, a specific hierarchical data structure for finite element calculation and analysis is designed, and the specific hierarchical data structure includes a finite element unit abstract class ElementBase;
[0034] On the basis of the finite element unit abstract class ElementBase, Element1D, Element2D and Element3D are designed according to the dimensional characteristics of the unit, which are used to represent one-dimensional unit, two-dimensional unit and three-dimensional unit respectively.
[0035] In a possible implementation, the model data conversion mechanism includes a Gmsh mesh data extraction and conversion mechanism and a boundary / load condition data conversion mechanism;
[0036] The Gmsh mesh data extraction and conversion mechanism is used to design mesh data extraction and conversion functions based on the Gmsh mesh data format and the finite element unit node data structure of the system, and convert the Gmsh mesh data into finite element mesh data that can be recognized by the system;
[0037] The boundary / load condition data conversion mechanism is used to design the boundary / load condition data conversion function based on the interactive model data structure and the analytical model data structure, and correctly convert the relevant attributes of the boundary / load condition objects in the interactive model into the constraint conditions in the analytical model to correct the overall stiffness equation.
[0038] On the other hand, the present invention further provides a device for constructing an underlying model data structure, which is used to execute the method for constructing an underlying model data structure in any one of the above possible implementations, and the device includes:
[0039] A basic level data structure building unit, used to design a basic level data structure based on a combination pattern;
[0040] An interaction model data structure building unit, used for designing an interaction model data structure based on a hierarchical data structure;
[0041] An analysis model data structure construction unit, used to generate an analysis model data structure based on the hierarchical data structure;
[0042] The model data conversion construction unit is used to construct a model data conversion mechanism between the interaction model data structure and the analysis model data structure.
[0043] The beneficial effects of the present invention are as follows: the construction method of the underlying model data structure provided by the present invention designs a basic hierarchical data structure based on the combination mode at the abstract level, which can not only meet basic needs, but also flexibly adapt to the specific requirements of each functional module, and provide solid data support for the entire simulation process. At the same time, on this basis, by constructing an interactive model data structure for interactive modeling data and an analytical model data structure for analytical data, that is, customized design and management of interactive modeling data and analytical data are achieved, reducing the coupling degree of interactive modeling data and analytical data, thereby creating a clear and streamlined data framework for developers, reducing development complexity and long-term maintenance costs, and enhancing the intuitiveness of data interaction in the user interface, improving the efficiency of modeling and simulation and user experience. In addition, the present invention realizes efficient docking between interactive model data and analytical data by constructing a data conversion mechanism between the interactive model and the analytical model, thereby improving the overall flexibility and maintainability of the software. BRIEF DESCRIPTION OF THE DRAWINGS
[0044] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative work.
[0045] Figure 1 A schematic diagram of a flow chart of an embodiment of a method for constructing an underlying model data structure provided by the present invention;
[0046] Figure 2 For the present invention Figure 1 A schematic flow chart of an embodiment of S101;
[0047] Figure 3 A schematic flow chart of an embodiment of a data structure designed to support Qt model-view component interaction functions provided by the present invention;
[0048] Figure 4 For the present invention Figure 1 A schematic diagram of a hierarchical data structure designed for a sketch drawing function in a sketch module in step S102;
[0049] Figure 5 For the present invention Figure 1 A schematic diagram of a hierarchical data structure designed for component creation functions in a component module in step S102;
[0050] Figure 6 For the present invention Figure 4 The sketch module data structure and Figure 5 Schematic diagram of the association relationship between component module data structures;
[0051] Figure 7 For the present invention Figure 1 A schematic diagram of a hierarchical data structure designed for the geometric model and its topological structure association relationship in the component module in step S102;
[0052] Figure 8 For the present invention Figure 1 A schematic diagram of a hierarchical data structure for boundary / load condition creation and visualization function design for a boundary module in step S102;
[0053] Fig. 9 For the present invention Figure 1 A schematic diagram of a hierarchical data structure for the grid division and visualization function design of the grid module in step S102;
[0054] Fig.10 For the present invention Figure 1 A schematic flow chart of an embodiment of a boundary / load condition data conversion mechanism in step S104;
[0055] Fig.11 For the present invention Fig.10 A flowchart of an embodiment of the get_node_local_info() method called in step S1001 to obtain node information corresponding to boundary / load conditions;
[0056] Fig.12 A schematic structural diagram of an embodiment of a device for constructing an underlying model data structure provided by the present invention. DETAILED DESCRIPTION
[0057] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.
[0058] It should be understood that the schematic drawings are not drawn to scale. The flowchart used in the present invention shows the operations implemented according to some embodiments of the present invention. It should be understood that the operations of the flowchart can be implemented out of order, and the steps without logical context can be reversed in order or implemented simultaneously. In addition, those skilled in the art, under the guidance of the content of the present invention, can add one or more other operations to the flowchart, and can also remove one or more operations from the flowchart. Some of the block diagrams shown in the accompanying drawings are functional entities, which do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor systems and / or microcontroller systems.
[0059] Reference to an "embodiment" herein means that a particular feature, structure, or characteristic described in conjunction with the embodiment may be included in at least one embodiment of the present invention. The appearance of the phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein may be combined with other embodiments.
[0060] The present invention provides a method and device for constructing an underlying model data structure, which are applied to finite element simulation software and are described below.
[0061] Figure 1 A schematic diagram of an embodiment of a method for constructing a bottom-level model data structure provided by the present invention is shown in FIG. Figure 1 As shown, the method for constructing the underlying model data structure includes:
[0062] S101. Design basic hierarchical data structures based on composite patterns;
[0063] S102. Designing an interactive model data structure based on a hierarchical data structure;
[0064] S103, designing an analysis model data structure based on a hierarchical data structure;
[0065] S104. Design a model data conversion mechanism between the interaction model data structure and the analysis model data structure.
[0066] The method for constructing the underlying model data structure provided by the embodiment of the present invention designs a basic hierarchical data structure based on the combination mode at the abstract level, which can not only meet basic needs, but also flexibly adapt to the specific requirements of each functional module, and provide solid data support for the entire simulation process. At the same time, on this basis, by constructing an interactive model data structure for interactive modeling data and an analytical model data structure for analytical data, that is, customized design and management of interactive modeling data and analytical data are achieved, reducing the coupling degree of interactive modeling data and analytical data, thereby creating a clear and streamlined data framework for developers, reducing development complexity and long-term maintenance costs, and enhancing the intuitiveness of data interaction in the user interface, improving the efficiency of modeling and simulation and user experience. In addition, the present invention realizes efficient docking between interactive model data and analytical data by constructing a data conversion mechanism between the interactive model and the analytical model, thereby improving the overall flexibility and maintainability of the software.
[0067] Among them, step S101 needs to determine the appropriate basic data structure at the abstract level according to the finite element modeling simulation characteristics, and apply it to the design of the specific data structure of the subsequent interaction model and analysis model. After analysis, the hierarchical data structure is designed as the basis at the abstract level based on the combination mode in the embodiment of the present invention for the following reasons:
[0068] The ultimate goal of the modeling process is to build an interactive model. Here, the data entity class of the model is defined as Model. The interactive model consists of various data entity objects to describe the characteristics of various aspects of the interactive model. For example, the geometric model data obtained by geometric modeling is managed by the data entity class Part in units of parts, and the various parameter settings related to material properties are managed by the data entity class Material.
[0069] The ultimate goal of the simulation calculation process is to construct the overall stiffness matrix equation for solution. Its data basis is the analysis model. Here, the data entity class of the model is defined as FEMModel. The analysis model is composed of various data entity objects to describe various objects that may be involved in the finite element calculation process. For example, the unit data class ElementData records unit information and related unit operations, and the node data class NodeData records finite element node information and related finite element node operations. FEMModel needs to use these data entity classes to perform various matrix operations (stiffness matrix, load matrix, etc.), and finally construct the matrix relationship representing the system control equation and perform matrix operations to solve it, so as to obtain the system's displacement field, strain field and other mechanical field functions.
[0070] It should be noted that, whether it is the interactive model Model or the analysis model FEMModel, the data entity objects that make up them do not exist in a flat manner without any connection, but form a multi-level structure based on the characteristics of each data entity class. For example, the data entity class Part that manages the geometric model and the data entity class Material that manages the material properties describe the characteristics of different aspects of the interactive model Model respectively. Users need to build or set both in different modules, so they should belong to the same level of concept and be directly managed by Model; while the data entity class Sketch that manages the sketch properties of the geometric model does not have a direct connection with the interactive model Model, but is more closely related to Part and is a subordinate object required to build Part, so Sketch should be at the next level of Part and not at the same level as Material.
[0071] Using a hierarchical structure to access and manage multiple data entity classes is more reasonable than a flat approach with no structure design. There are two main reasons for this:
[0072] First, there are many data entity classes. Once the mutual calls between classes are taken into account, the dependencies and associations will become redundant and complicated. By adopting an intuitive and reasonable hierarchical structure design, more related data entity classes can be grouped together and placed in the corresponding levels. Through such a design, the number of classes at each level can be effectively reduced, thereby streamlining the dependencies and associations between classes;
[0073] Second, based on the hierarchical structure design, the development work can be simplified. Specifically, in the process of developing module functions, developers can first locate the data entity class related to the function in the first level, and then enter the lower level step by step until they find the specific data entity class and carry out the development of related functions.
[0074] If the design is performed according to the above hierarchical structure, a new problem will be discovered: an analysis process may involve multiple interactive models Model, and an interactive model Model may have multiple sub-nodes such as geometric components Part, material properties Material, etc. In order to reasonably manage these data entity objects, it is necessary to select appropriate design patterns to design hierarchical data structures. As a structural design pattern in software engineering, the core purpose of the composite pattern is to handle the hierarchical structure of objects and organize a group of objects into a tree structure to represent the "part-whole" hierarchical relationship. This pattern enables users to operate single objects and object combinations in a unified manner without distinguishing whether they are separate objects or combined objects, thereby improving the flexibility and reusability of the code. To this end, the present invention introduces a composite pattern to construct a hierarchical structure.
[0075] Based on the above analysis, in step S101, the embodiment of the present invention designs a hierarchical data structure as a basic data structure at an abstract level based on the combination pattern. The hierarchical structure is a tree-like hierarchical structure composed of nodes, in which there are mainly two types of nodes: branch nodes and leaf nodes. Branch nodes can contain child nodes, while leaf nodes do not contain child nodes. In the embodiment of the present invention, branch nodes can be further subdivided into two categories according to data characteristics: container branch nodes and model branch nodes. Figure 2 As shown in the figure, the three types of nodes have the following characteristics:
[0076] The container branch node mainly undertakes the management function of the model branch node. The node form managed is relatively simple and is only used to manage the model branch node. For example, the container branch node Models is used to manage the interactive model data entity object Model, and the container branch node Parts is used to manage the geometric component data entity object Part.
[0077] Model branch nodes are key branch nodes used to describe various features of the interaction model and analysis model, such as the data entity class Model representing the interaction model and the data entity class Part representing the geometric component. The nodes managed by this branch node can be diverse, such as container branch nodes, model branch nodes, or leaf nodes. For example, the model branch node Model manages the container branch node Parts, Parts manages the model branch node Part, Part manages the container branch node PartFeatures, PartFeatures manages the model branch node GeometryFeature, GeometryFeature manages the model branch node Sketch, and Sketch manages the leaf node SketchComponent.
[0078] Leaf nodes are managed by model branch nodes and are used to store basic data in interaction models and analysis models, and provide basic methods for operating data. For example, the data entity class SketchComponent represents the basic geometric elements in the sketch, which stores the basic geometric element data required by the sketch and provides methods for operating the data.
[0079] The difference between model branch nodes and leaf nodes is that leaf nodes, as the smallest elements that make up the data model, generally do not have a clear physical meaning, but exist as functional detail elements that participate in the system interaction process, providing basic functions and data support in the system, such as the sketch basic geometric element class SketchComponent and the section assignment class SectionAssignment. In comparison, model branch nodes have clearer physical meanings, such as geometric components Part and material properties Material. The differences in the features described by each model branch node can be more intuitively identified and correspond to the finite element modeling and simulation process.
[0080] Based on the above analysis and design, from the abstract level, the data entity objects in the system data structure can be divided into two categories: abstract model node class BaseObject and abstract container class BaseContainerObject, that is, the abstract model node class BaseObject and the abstract container class BaseContainerObject constitute the basic hierarchical data structure, where:
[0081] The abstract model node class is the most basic abstract base class in the current data structure design. In terms of attributes, it has data features such as uid and node_type. The abstract model node class BaseObject is used for:
[0082] Based on the multi-level features of branch nodes and leaf nodes in the tree hierarchy, model node management methods such as add_child() and remove_child() are provided.
[0083] The abstract container class BaseContainerObject inherits from the abstract model node class BaseObject, so it has all the properties and methods of the abstract model. In addition, considering that the container class maintains the number of its child node objects, and when the number of child node objects changes, the container class needs to update its name attribute, so that it can be updated and presented in Qt model-view components such as QTreeView, it is also necessary to provide the container class with additional methods for managing child node objects.
[0084] As the bottom layer, the basic hierarchical data structure mainly provides necessary data support for the finite element simulation system functions. For example, in order to provide the creation and editing functions of geometric models, the system needs to have data entity classes such as the component class Part and the geometric feature class GeometryFeature to form a suitable data structure to meet the data access, reading and writing and other functional requirements required for the creation and editing functions. However, this type of data-related operation process, as a back-end function, is an internal behavior of the system and is not user-oriented. Taking into account the user's interaction needs, if the system can provide a certain degree of data visualization function and provide users with the possibility of data interaction operations, it can present the data structure to the user more intuitively, which is conducive to improving the user's interaction experience. To this end, in some embodiments of the present invention, after step S101, the abstract model node class BaseObject is also used to:
[0085] Based on the support for Qt model-view components such as QTreeView, data access methods such as data() and row() are provided for basic hierarchical data structures;
[0086] Based on the visualization requirements of finite element modeling simulation data, methods such as generate_name() and set_parent() are provided for the basic hierarchical data structure.
[0087] By providing data access methods such as data() and row() and methods such as generate_name() and set_parent() for the basic level data structure, the basic level data can be made interactive and visualized, providing users with the possibility of data interaction operations, and presenting the data structure to users more intuitively, which is conducive to improving the user's interactive experience.
[0088] Figure 3 The present invention provides a flow chart of an embodiment of a data structure designed to support the Qt model-view component interaction function. The implementation process includes the following three steps:
[0089] S301. Develop the Qt data model class QmyDataModel to implement the Qt abstract item model class QAbstractItemModel;
[0090] S302, developing data() and row() data access methods in the abstract model node class BaseObject, constructing a basic hierarchical data structure and associating it with the Qt data model class QmyDataModel;
[0091] S303. Design interactive functions for the Qt model-view interaction component as the basic hierarchical data.
[0092] Wherein, in step S301, the model-view interaction components based on the Qt View / Model framework, such as QTreeView and QTableView, are used in the interactive interface. To support the function of this component, it is necessary to implement Qt's abstract item model class QAbstractItemModel, and use it as the data model basis of the visualization component. For this purpose, the present invention develops a Qt data model class QmyDataModel, which is used to implement the abstract interfaces in QAbstractItemModel, such as index(), rowCount(), data(), and setData().
[0093] In step S302, based on the realization of the Qt data model QmyDataModel, it is also necessary to establish the connection between the model and the basic hierarchical data structure. To this end, two aspects of design work need to be carried out:
[0094] It is necessary to develop data access methods data() and row() in the abstract model node class BaseObject;
[0095] It is necessary to introduce the Qt data change notification mechanism into the abstract model node class BaseObject, that is, to call methods such as beginRemoveRows() and endRemoveRows() in Qt before and after the code involving data modification to realize the update binding of the system data structure and the Qt data model.
[0096] In step S303, after the above design, the visual presentation of system data in model-view components such as QTreeView and QTableView can be realized. For example, in the tree view component QTreeView, the model data is presented in a tree hierarchy, where the nodes are subclasses of the abstract container class or abstract model node class designed in this patent, such as Models, Model, Parts and Part, etc. However, in order to realize the interaction between users and system data, it is also necessary to design interactive functions for the model-view interactive components on this basis, such as designing a right-click pop-up operation function for the tree view component QTreeView that displays the system model node data.
[0097] The right-click pop-up window operation functions are as follows: users can right-click the data structure model node in the tree view QTreeView, and the system will identify the node type of the clicked object and pop up the corresponding function menu. For example, if you click the container branch node Models, a shortcut menu with functions such as "Create a new model node Model" will pop up; if you click the model branch node Part, a shortcut menu with functions such as "Rename" and "Switch to Part" will pop up. To this end, two aspects of design are required: the design of the model-view component interaction logic and the design of the functional architecture of the shortcut menu.
[0098] For the design of the interaction logic of the model-view component, it is necessary to design the data tree view class DataTreeView to associate with the Qt tree view component QTreeView. Bind the customContextMenuRequested signal of QTreeView with the show_menu() method of DataTreeView to achieve: when the user clicks on a node object in QTreeView (such as Models, Part, etc.), the system will call the shortcut menu display method show_menu() of DataTreeView to pop up the shortcut function menu.
[0099] In the show_menu() method, the node object selected by the user in the QTreeView is passed in as a parameter, and the system needs to judge the node type of the object, so as to pop up the corresponding shortcut function menu. To implement this method, the functional architecture design of the shortcut menu is required.
[0100] The following three aspects need to be designed for the functional architecture of the shortcut menu:
[0101] First, design the menu management class MenuManager, which is used to register and manage various shortcut menus, and provide an access method get_menu() for obtaining specific menus. In this method, the node object selected by QTreeView is used as a parameter to determine its node type, so as to select from the registered menu list and provide feedback to the system. For example, if the user right-clicks the Models node in QTreeView, after a series of message transmissions, the get_menu() method of MenuManager is finally called. This method determines that the user selected the node as Models, and then searches for the corresponding shortcut menu in the menu list attribute menus of MenuManager. If there is a corresponding registered shortcut menu, the menu is returned; otherwise, the system default general shortcut menu is returned.
[0102] Second, design an abstract menu BaseMenu, which has common properties and interfaces for menus. For example, the menu action list attribute acts is used to manage the Qt action class QAction, and the registration action interface method register_acts() is used to register executable actions for this menu.
[0103] Third, on this basis, design specific menu subclasses that inherit from BaseMenu, including but not limited to ModelsMenu, ModelMenu, PartsMenu and PartMenu. For each specific menu subclass, implement the interface provided by BaseMenu in different ways, and design and develop different functions. For example, in PartMenu, design the do_act_rename_part() method to implement the "Part node rename" action in the shortcut menu. This action needs to be registered into the menu action list attribute acts of PartMenu through the register_acts() method. When the menu management class MenuManager creates and registers the shortcut menu PartMenu, it calls the action registration method register_acts() of the shortcut menu. At this time, the action defined in PartMenu will be registered in its menu action list acts.
[0104] exist Figure 3 In the complete interactive function design of the model-view interaction component shown in the figure, the visual presentation and real-time binding update of the data-user level are realized through the design of the Qt data model, system data structure and model-view interaction function, and the quick operation of the user-data level is realized. The data structure can be presented to the user more intuitively, which is conducive to improving the user's interactive experience and modeling efficiency, and reducing the user's error rate.
[0105] Compared with the prior art, the hierarchical structure designed based on the combination pattern in step S101 helps developers to focus on a small number of related model node data more efficiently when developing each module. Because of the hierarchical structure design, many data entity classes are assigned to model nodes of appropriate levels. Compared with the flat data structure, the number of data entity classes in the first level of the hierarchical structure has been greatly reduced. In the hierarchical structure, there must be a close relationship between the underlying data and the upper data. Therefore, when developers develop specific functions in different modules, they only need to first find the model branch nodes that may be associated with the intended development function in the first level (i.e., the first-level child nodes of the model branch node Model), and then in the development process, further go deep into the lower-level child nodes of the model branch node according to the needs. For example, in the component module, only the model branch node Part and its child nodes need to be considered to complete the corresponding function development, while in the material module, the model branch node Part and the model branch node Material need to be considered at the same time to complete the corresponding function development.
[0106] Based on the basic hierarchical data structure designed at the abstract level in step S101, the interactive model data structure of the interactive model can be designed in step S102. There are many functional modules related to the interactive model, including but not limited to the sketch module, component module, material module, mesh module, boundary module, etc. It is necessary to expand the above hierarchical data structure design based on the combination mode at the abstract level and implement it at the specific level according to the requirements of different modules. The following introduces the data structure design related to the important functions of several typical modules in the system, namely the sketch drawing function of the sketch module, the component creation function of the component module, the boundary / load condition creation and visualization function of the boundary module, and the meshing and visualization function of the mesh module.
[0107] Figure 4 For the present invention Figure 1 Schematic diagram of the hierarchical data structure designed for the sketch drawing function in the sketch module in step S102.
[0108] First, the interactive logic of the sketch drawing function of the sketch module is analyzed. It can be seen from the state diagram that to draw a basic geometric shape, whether it is a rectangle, circle or line segment, the process required is similar: enter the coordinates of the key geometric points defined by the graphic in turn. During the process, you can use the mouse to move and click in the window to complete the drawing operation of the key geometric points, or directly enter the coordinate value in the correct format through the text box; then check whether there is any duplication in the input coordinates, and generate the geometric model of the corresponding basic geometric shape after the detection passes.
[0109] A series of common methods can be abstracted from the above execution steps, such as the method set_pnt1() for setting the first key geometric point, the method set_pnt2() for setting the second key geometric point, the method check_overlap() for detecting whether there is overlap in key points, and the method generate_component() for generating basic geometric shape geometric models. In addition, considering that there can be multiple basic geometric elements in a sketch, and Boolean operations can be performed or constraints can be established between the geometric elements, the following methods are designed in the sketch module: Figure 4 The hierarchical structure shown. The design content is as follows:
[0110] Design the data entity class Sketch representing the sketch as the model branch node, and manage the basic sketch geometry component class SketchComponent as the leaf node, so that the two form an aggregation relationship;
[0111] Design an abstract class SketchComponent that represents the basic sketch geometry component. On the one hand, it has properties such as the key geometry point list pnts and the geometry model object ais_shapes of the basic geometry elements. On the other hand, it provides interfaces such as set_pnt1(), set_pnt2(), and check_overlap(), as well as common methods such as display_component() and reset().
[0112] Taking the abstract class SketchComponent as the base class, we design data entity subclasses such as LineSketch, CircleSketch and RectangleSketch. By implementing the abstract interface in SketchComponent, the above data entity subclasses realize the construction function of different basic geometric elements. For example, calling set_pnt1() of RectangleSketch can complete the drawing of the vertex of the upper left corner of the rectangle, and then moving the mouse can preview the rectangular wireframe to be drawn in the window. Calling set_pnt2() can complete the drawing of the vertex of the lower right corner of the rectangle. Then the system automatically calls the check_overlap() method to determine whether the coordinates of the two corner points coincide. If they pass, it continues to call generate_component() to generate the geometric model object of the rectangular sketch element. Calling the CircleSketch method in the same way will get different results. For example, set_pnt1() will draw the center point of the circle, and dragging the mouse will realize the preview of the circular wireframe. Set_pnt2() will draw the points on the circumference. Finally, after repeated detection of the coordinates through check_overlap(), the geometric model object of the circular sketch element is generated using generate_component().
[0113] The advantages of the corresponding data structure design of the sketch drawing function of the above sketch module are: the one-to-many aggregation relationship between Sketch and SketchComponent provides the function of drawing multiple geometric elements in one sketch; SketchComponent, as an abstract class, has common properties and methods, and provides key interfaces for subclasses to implement, which effectively reduces the amount of code to be developed, reduces the difficulty of development, and improves the scalability of the sketch module data structure.
[0114] Figure 5 For the present invention Figure 1 Schematic diagram of the hierarchical data structure designed for component creation function in the component module in step S102.
[0115] By analyzing the component creation function of the component module, it can be seen that the geometric model of the component creation is relatively complex. On the one hand, the geometric model may have different geometric dimensional characteristics, such as 3D, 2D and 1D, and the required modeling parameters are obviously different; on the other hand, the geometric model can be created in different ways, such as stretching, sweeping, rotating and plane drawing, and the required processes and required sketch elements are different. If development is carried out for all possible combinations of the above two, there will be too many function-related classes and data entity classes to be developed. Therefore, it is necessary to design a data structure that allows the development of the two to be relatively independent while maintaining mutual association to jointly describe the characteristics of the geometric model.
[0116] By analyzing the interactive logic of the component module's geometric model building function, the following interactive process can be formulated: first, the user determines whether the dimensional characteristics of the constructed geometric model are 3D, 2D, or 1D; based on the selection of this parameter, the system will provide different geometric model creation methods, such as 3D can be created through stretching, sweeping, and rotation, and 2D can be created through stretching, sweeping, rotation, and plane methods; after the user selects the creation method, enter the sketch drawing module, draw sketches according to the processes of different creation methods, and provide sketch element parameters for geometric model creation; finally, complete the modeling process and create a geometric model with the selected dimensional characteristics according to the selected method.
[0117] Based on the above process, the data entity class related to the component module and the component creation function is designed as follows Figure 5 The structure shown. The design content is as follows:
[0118] Design the data entity class Part that represents the part as the model branch node, and manage the data entity class PartFeatures as the container branch node. PartFeatures manages various features in the part Part, and the two form a combination relationship. Part and PartFeatures inherit from the abstract model node class BaseObject and the abstract container class BaseContainerObject respectively;
[0119] The design inherits the abstract class PartFeature of the component feature from the abstract model node class BaseObject. It is a child node managed by the component feature container branch node PartFeatures, and the two form an aggregation relationship. With PartFeature as the base class, the specific feature class of the component can be realized, such as the component geometry feature class GeometryFeature;
[0120] The component geometry feature class GeometryFeature is designed as the model branch node, under which the PartTopo abstract class representing the component dimension feature and the PartGeneration abstract class representing the component creation method are designed as model branch nodes;
[0121] PartTopo has attributes such as topo_type, which represents the dimensional feature type, and provides various interfaces such as the check_cross_section() method for checking the validity of the cross-section sketch and the generate_cross_section() method for cross-section generation. Data entity subclasses representing different dimensional features (such as WireShape, ShellShape, and SolidShape) inherit the PartTopo abstract class and implement the interface methods in different ways, showing their differences in executing the above methods. For example, ShellShape generates a wireframe as a cross section based on a sketch, while SolidShape generates a plane as a cross section based on a sketch;
[0122] PartGeneration has properties such as generate_type, which represents the type of part creation, parameters, and sketch object list sketches. It also provides the generate_part() interface method for generating part geometry models. Data entity subclasses representing different creation methods (such as Sweep, Extrude, and Revolve) inherit the PartGeneration abstract class and implement the interface methods in different ways, showing their differences in the process of creating parts. For example, Sweep needs to draw the sweep path and sweep section in two steps, while Extrude only needs to provide the extrusion depth after drawing the sweep section.
[0123] Considering that the geometric model of the component needs to be based on the sketch element as the basic data, there must be an association between the data structure of the sketch module and the component module. PartTopo and PartGeneration are both child nodes of GeometryFeature, and are associated with the sketch data entity class Sketch during the component creation process. Figure 6 shown.
[0124] Figure 6 For the present invention Figure 4 The sketch module data structure and Figure 5 Schematic diagram of the association relationship between component module data structures. Specifically:
[0125] The sketches property of PartGeneration directly manages the sketch data entity class Sketch used to construct the geometric part. Since different part creation methods require different numbers of sketches to complete different creation processes, PartGeneration and Sketch form a one-to-many aggregation relationship. For example, the data entity class Sweep corresponding to the sweep creation method has its sketches property associated with two sketch data entity classes Sketch, one representing the sweep path and the other representing the sweep section.
[0126] During the component creation process, PartTopo will determine whether the sketch element SketchComponent corresponding to the sketch data meets the requirements for component creation based on its dimensional feature type, such as whether there are breakpoints or self-intersection problems. Therefore, PartTopo forms a dependency relationship with the sketch data entity class Sketch.
[0127] In order to save the geometric objects constructed during the component creation process, a special data entity class ShapeInfo is designed. This class is not only used to save geometric objects, but also has the interaction responsibility related to geometric objects, providing data support for the geometric interaction functions of each module, so it is an important part of the data structure design of this patent. When only discussing the geometric modeling functions in the sketch module and the component module, there are three related attributes:
[0128] Represents the shape of a geometric object. The geometric object corresponding to shape is an independent geometric object in the geometric model generated during the component creation process;
[0129] Parent pointer parent_feature. Through parent_feature, you can access the parent node GeometryFeature that manages the ShapeInfo instance, which facilitates the indexing between objects during the interaction process;
[0130] Manage the list entities of various topological structures in geometric objects. Any geometric object is composed of basic elements such as points, lines, and surfaces. These basic elements are the topological structure of the geometric object. Since various conditions and parameters (including boundary conditions, constraints, and mesh seeds, etc.) need to be applied to different topological structures of geometric objects through user-system interaction during finite element modeling, the ability to independently interact with these topological structures is crucial for the interactive modeling experience of finite elements. Although Open CASCADE provides basic picking and highlighting functions for the topological structure of geometric objects, this is not sufficient to complete the interactive setting and effective management of related data. Therefore, corresponding mechanisms and data structures are designed in the present invention to optimize the storage and access of the above-mentioned topological structures of geometric objects, such as Figure 7 shown.
[0131] Figure 7 For the present invention Figure 1 The hierarchical data structure diagram of step S102 in FIG. 1 is designed for the geometric model and its topological structure association relationship in the component module, specifically:
[0132] After the independent geometric object is created, the system will first generate a ShapeInfo object and assign the geometric object as a parameter to the shape attribute of ShapeInfo. Then the _init_entities() method of ShapeInfo will be executed to traverse the topological structure of the geometric object, and the _init_vertices(), _init_edges() and _init_faces methods will be executed on the point, line and surface objects respectively to generate a list of point, line and surface topological structure objects of the geometric object, and finally stored in the entities attribute of ShapeInfo in the form of key-value pairs.
[0133] The above point, line, and surface topological structure object lists contain data entity classes VertexInfo, EdgeInfo, and FaceInfo, which are all inherited from the abstract class EntityInfo. EntityInfo has an attribute shape that represents the geometric object, a parent pointer parent_info pointing to the ShapeInfo object, and an attribute entity_type that represents its topological structure type. VertexInfo, EdgeInfo, and FaceInfo represent point, line, and surface topological structure objects, respectively. They inherit from EntityInfo and implement their own methods and properties. For example, VertexInfo has a coordinate attribute pos, and EdgeInfo has a seed information object attribute seed_info for the seeding operation in the mesh module.
[0134] Through the one-to-many aggregation relationship formed by ShapeInfo and VertexInfo, EdgeInfo, and FaceInfo, this patent effectively realizes the management of geometric objects and their topological structures, and provides an important data foundation for the geometric model interaction functions in each functional module.
[0135] Considering that there may be multiple geometric objects in the geometric model of a component Part, the attribute shape_infos is designed in the child node GeometryFeature of Part to manage the data entity class ShapeInfo corresponding to the geometric objects in the geometric model of the component in a list manner, thereby forming a one-to-many aggregation relationship between GeometryFeature and ShapeInfo.
[0136] Figure 8 For the present invention Figure 1 Schematic diagram of the hierarchical data structure for boundary / load condition creation and visualization function design for the boundary module in step S102.
[0137] In the boundary module, users need to interactively select areas on the geometric model and apply boundary conditions and load conditions to them. Boundary condition types include but are not limited to fixed constraint boundary conditions, given displacement boundary conditions, etc. Load condition types include but are not limited to concentrated force conditions, shell edge load conditions, uniform pressure conditions, etc.
[0138] Although boundary conditions and load conditions are significantly different from a physical perspective, they have many commonalities in terms of interactive operation settings, properties, and functions. For example, both require users to interactively select topological structures as application areas on the geometric model of the component and set corresponding conditional parameters to define the direction, value, and other contents of the boundary / load conditions. Therefore, the commonalities need to be considered when designing the data structure.
[0139] However, there are also differences between the two, such as the type of application area: displacement boundary conditions can be applied to any topology of the geometric model, while concentrated force load conditions can only be applied to the point topology of the geometric model, and shell edge load conditions can only be applied to the line topology of the 2D shell geometric model. Therefore, the differences need to be considered when designing the data structure.
[0140] As mentioned above, there is a key data in the application of boundary / load conditions, namely, the application area, which corresponds to the topological structure in the component geometric model. Therefore, when designing the data structure, it is necessary to consider how to establish the relationship between the boundary / load conditions, the application area, and the component topological structure. In summary, the present invention designs the following Figure 8 The data structure shown. The design content is as follows:
[0141] Design the boundary condition basic abstract class BCBaseClass, which contains the common content of boundary conditions and load conditions, such as the attribute basic_info that describes the common basic information of boundary conditions, the method location() to access the applied area information, etc. Among them, the attribute basic_info corresponds to the basic basic information class BaseBasicInfo, so the boundary condition basic abstract class BCBaseClass and the basic basic information class BaseBasicInfo form an aggregation relationship;
[0142] The design basic information class BaseBasicInfo manages the common basic information of the boundary / load conditions, such as the loading step attribute step and the applied region attribute location involved in the conditions. The applied region attribute location is a list of the applied region class SelectionRegion, corresponding to the boundary / load condition that can be applied to multiple topological structures of multiple geometric component objects, so the basic information class BaseBasicInfo and the applied region class SelectionRegion form a one-to-many aggregation relationship;
[0143] Design the applied region class SelectionRegion, which contains the attribute entities corresponding to the topology information abstract class EntityInfo. As mentioned above, EntityInfo has an aggregation relationship with the geometric object information class, and EntityInfo can be implemented as specific point, line, and surface topology structure objects VertexInfo, EdgeInfo, and FaceInfo. Therefore, the relationship between the three is understood here as the boundary / load conditions can be applied to the topology structure in the geometric object model. The applied region class SelectionRegion forms an aggregation relationship with the topology information abstract class EntityInfo;
[0144] The design is based on the boundary condition base abstract class BCBaseClass and its subclasses - the boundary condition abstract class BoundaryCondition and the load abstract class Load. Then, according to the needs, specific boundary / load condition classes can be designed based on the above abstract subclasses. For example, based on BoundaryCondition, a fixed constraint boundary condition class FixedBC can be designed, and based on Load, a concentrated force load condition class ConcentratedForceLoad can be designed. It is worth noting that interfaces (such as display_arrows() and generate_node_local_value()) are designed in the abstract class BCBaseClass. These abstract methods need to be implemented in specific boundary / load condition classes (such as FixedBC and ConcentratedForceLoad) to present the differences in behavior and functions of different specific boundary / load conditions.
[0145] It should be noted that in the data structure used to store the visualization information of the boundary / load condition display object, the corresponding data structure is designed to store the visualization information of the display object instead of storing the geometric model of the display object. The reason is that the main function of the boundary / load condition display object is to explicitly display the characteristics of the applied boundary / load conditions to the user with a set of arrows with clear directions and certain distribution characteristics when the user executes the interactive boundary / load condition setting function, thereby helping the user to confirm the correctness of the applied boundary / load conditions. The display object does not affect the modeling function and simulation calculation of the system, and only needs to be displayed in the boundary condition setting module. Therefore, there is no need to actually store the object to increase the storage burden of additional geometric model elements. However, in order to correctly display the object in the boundary condition setting module, it is still necessary to design a data structure to reproduce the display object when needed. Therefore, the following design was made:
[0146] In the properties of the basic abstract object BCBaseClass of boundary conditions, there is a basic basic information object BaseBasicInfo, which manages the application area object SelectionRegion of boundary / load conditions. When it is necessary to draw a visual model of boundary / load conditions, the system calls the get_sizes_and_locs_for_arrow_visual() method of BCBaseClass, and determines the topological structure applied by the boundary / load condition by traversing the topological structure information object EntityInfo in SelectionRegion. Then the system calculates the distribution mode of these topological structures to obtain the spatial coordinate values of the distribution points of the arrows in the visual model of boundary / load conditions. Subsequently, the specific subclasses of the boundary condition BoundaryCondition and the load condition Load inherited from the basic abstract object BCBaseClass of boundary conditions calculate the direction of the arrows in the visual model of boundary / load conditions according to the parameters set by the user. Finally, the geometric model of the arrows in the visual model of boundary / load conditions is constructed by combining the spatial coordinates of the arrow distribution points and the arrow direction using the Open CASCADE related geometric modeling method, and provided to the system for visual presentation of boundary / load conditions.
[0147] Fig. 9 For the present invention Figure 1 Schematic diagram of the hierarchical data structure for the grid division and visualization function design of the grid module in step S102.
[0148] Finite element simulation analysis cannot be performed directly after completing operations such as geometric modeling, material property setting, and boundary condition creation. This is because the finite element theory requires discretization of complex geometric domains to construct the overall stiffness matrix equation required for solution, so the geometric model needs to be meshed.
[0149] In this system, there are three models related to the grid module:
[0150] The geometric model based on Open CASCADE is created by the user through interactive modeling settings in the component module. It is the most important basic geometric model in the modeling process. All design operations in subsequent modules are basically based on this model.
[0151] Based on the Gmsh mesh model, in the mesh module, by calling the Gmsh meshing function, the first geometric model based on Open CASCADE can be meshed to obtain the Gmsh-based mesh model data. The main function of this model is to provide mesh information, including cell data, node data, etc. This model does not have a visualization function. In order to visualize the mesh data, it is necessary to build the following third model;
[0152] The mesh visualization model based on Open CASCADE is based on the second mesh model data based on Gmsh. By calling the Open CASCADE geometric modeling method, a point and line geometric model representing the mesh is generated and covered on the first geometric model based on Open CASCADE to achieve visualization effect.
[0153] This system has developed a mesh module based on the mesh generation tool library Gmsh, thereby realizing the meshing operation of the geometric model based on Open CASCADE. By calling the relevant methods of the meshing function of Gmsh, the complex geometric model can be discretized into a spatial mesh composed of spatial nodes and their connections. In this patent, the spatial nodes are called finite element nodes, and the basic geometric shapes composed of finite element nodes and connections are called finite element units. The data information generated by the methods in the Gmsh tool library has a specific format. In the mesh module, in addition to taking into account the storage and access requirements of the mesh data, the data structure also needs to meet the meshing related functions in the module (such as the interactive seeding function) and form associations with other module data. Therefore, it is necessary to design a specific data structure for the mesh data.
[0154] Meshing can be divided into the following three stages: (1) Meshing preparation, including mesh parameter setting, local seeding and encryption, etc.; (2) Meshing; (3) Meshing visualization. In response to the different requirements of the three stages, the mesh data structure design is completed as follows:
[0155] Meshing preparation stage. In the mesh module, the local density of the mesh can be controlled by interactive seeding operations on the edge topology of the geometric model. This function involves the edge topology characteristics of the geometric model, as well as data such as seed distribution form and related parameters. To meet the requirements of this function, this patent designs the following data structure:
[0156] The model branch node Part manages the geometry object information class ShapeInfo through the model branch node GeometryFeature, which is associated with the line topology structure information class EdgeInfo through the aggregation relationship. This class manages the line topology structure of independent geometry objects in the part. EdgeInfo contains the seed information object attribute seed_info of the seeding operation in the mesh module, corresponding to the seed information class SeedInfo;
[0157] SeedInfo manages properties related to seeding operations, including seed distribution strategy, seed spatial coordinate list, etc. It also provides a method seeds_pos() to access the seed spatial list and a method seeds_vertices() to obtain the OpenCASCADE geometric object corresponding to the seed. This method can be called when it is necessary to display seeds on the line topology structure.
[0158] Through the above design, the seed information is directly bound to the line topology structure, so that programmers can more intuitively and conveniently access the seed information used for local mesh encryption when developing related mesh division functions.
[0159] Meshing stage. After completing various meshing settings (such as size parameters and seeding operations), you can execute the meshing function of Gmsh to obtain mesh data in a specific format. In order to achieve effective storage and access of mesh data, this patent designs the following Fig. 9 The data structure shown. Specifically:
[0160] The design data entity class GmshInfo is used to store the mesh data in a specific format obtained by Gmsh mesh division;
[0161] By reading the node and unit information in the Gmsh mesh data, the mesh data in a custom format is generated and saved in the mesh data class MeshData. MeshData contains the nodes and elems attributes, which are object lists of the finite element node data class NodeData and the finite element unit data class ElementData respectively. In NodeData, not only the spatial coordinate information pos of the finite element node is provided, but also the properties and parameters related to the construction of the finite element analysis model can be provided, such as the finite element node degree of freedom mark nfs, etc. In ElementData, there is not only the node information list nodes that make up the unit, but also the properties and parameters related to the construction of the finite element analysis model, and can even be used to calculate and save the corresponding unit stiffness matrix;
[0162] The mesh information class MeshInfo is designed to form an aggregation relationship with GmshInfo and MeshData to achieve effective management of the two. Considering that the significance of mesh information is to bind with geometric objects so that the system can build an analysis model, the association relationship between MeshInfo and ShapeInfo is designed. ShapeInfo records the MeshInfo corresponding to the geometric object through the mesh information attribute mesh_info.
[0163] Grid visualization stage. After completing the grid division work, the corresponding grid data is obtained. In order to realize the interactive operation between the system and the user, it is also necessary to realize the visualization of the grid, that is, to convert the Gmsh grid data into grid visualization model data based on OpenCASCADE. In order to realize the grid visualization function, the present invention designs the following data structure:
[0164] During the meshing process, the system will generate mesh data in a Gmsh-specific format based on the meshing results, and after conversion, form a mesh data object MeshData;
[0165] By extracting the node and unit information of the mesh in the object, a geometric model for mesh visualization can be constructed based on the basic geometric modeling method provided by Open CASCADE. The model consists of mesh nodes and wireframes, covering the surface of the original geometric object. The visual geometric model is assigned to the visual_mesh attribute of the geometric object information ShapeInfo during the meshing process.
[0166] Based on the basic hierarchical data structure designed at the abstract level in step S101, the analysis model data structure of the analysis model can be designed in step S103. Following the standardized calculation process requirements of the finite element, in the interactive model construction process, the discretization of the geometric object model has been completed, the mesh data GmshInfo has been obtained, and it has been converted into a data structure MeshInfo that can be recognized by the system. The finite element unit abstract class ElementBase is designed in the analysis model, which has unit common properties (such as the unit degree of freedom dof_num) and provides unit common interfaces (such as the method generate_ke() for generating unit stiffness matrix).
[0167] The finite element unit abstract class ElementBase depends on the mesh data object MeshData in MeshInfo, and obtains the finite element calculation elements such as the unit stiffness matrix by calling the list of the finite element node data object NodeData and the finite element unit data object ElementData. In addition, the finite element unit abstract class ElementBase also depends on the child nodes under the model branch node object Model corresponding to the interactive model. For example, Material can provide material property parameters for the unit, and this data will be used to calculate the finite element calculation elements such as the elastic matrix of the unit.
[0168] Based on the finite element unit abstract class ElementBase, it can be designed as Element1D, Element2D and Element3D according to the dimensional characteristics of the unit, which are used to represent one-dimensional units, two-dimensional units and three-dimensional units respectively. Then, according to the unit characteristics and calculation requirements under different dimensional characteristics, more detailed unit classification and design can be carried out. For example, a three-node triangular unit Element2DT3 inherited from the two-dimensional unit class Element2D can be designed to solve two-dimensional problems. This type of specific unit subclass needs to implement the interface methods preset by the finite element unit abstract class ElementBase, such as the method generate_shape_function() for creating shape functions and the method generate_ke() for creating unit stiffness matrices.
[0169] Based on step S102 and step S103, the interactive model data structure and the analysis model data structure are designed. Because the data structures of the two are different, it is necessary to design a data conversion mechanism between the models in step S104. The data conversion mechanism includes but is not limited to the Gmsh mesh data extraction and conversion mechanism, boundary / load condition data conversion mechanism, etc.:
[0170] The Gmsh mesh data extraction and conversion mechanism is used to design mesh data extraction and conversion functions based on the Gmsh mesh data format and the system's finite element unit node data structure, and convert Gmsh mesh data with a specific format into finite element mesh data that can be recognized by the system.
[0171] The boundary / load condition data conversion mechanism is used to design the boundary / load condition data conversion function based on the interactive model data structure and the analysis model data structure, and correctly convert the relevant properties of the boundary / load condition objects in the interactive model into the constraint conditions in the analysis model to correct the overall stiffness equation.
[0172] The Gmsh mesh data extraction and conversion mechanism is specifically used to convert Gmsh mesh data into finite element mesh data that can be recognized by the system. The Gmsh mesh data itself has a specific format, in which each row of data includes mesh node number, node space coordinates, node connection order, mesh unit number, mesh unit type, etc. The mesh data extraction and conversion work can be performed on the premise of establishing the correspondence between the Gmsh mesh type and the finite element mesh type. The process is roughly as follows:
[0173] First, traverse the Gmsh grid data, process the data row by row, and create a corresponding finite element unit data object ElementData for each row of unit data;
[0174] Then, according to the Gmsh element type number in the row of data, the corresponding finite element type is obtained and assigned to ElementData;
[0175] Subsequently, according to the number of nodes and the node numbering sequence corresponding to the finite element unit type, the finite element node data object NodeData is created, and the node information (such as node number, node space coordinates, etc.) in the row of Gmsh data is extracted and assigned to these NodeData objects;
[0176] Finally, based on the above grid data information, a mapping relationship class LToGMap between the local number and the global number in the component is established for NodeData and ElementData respectively. For the case of multiple components, a local-global conversion method of numbers needs to be designed. Based on the number mapping relationship class LToGMap, the local numbers of units and nodes are converted into global numbers in a unified order to avoid duplicate numbering problems.
[0177] The boundary / load condition data conversion mechanism is specifically used to consider the boundary conditions and load conditions after the overall stiffness equation is constructed, and introduce them into the overall stiffness matrix equation in an appropriate way before the solution calculation can be performed, otherwise the overall stiffness matrix singularity will not be calculated normally. This involves correctly converting the relevant properties of the boundary condition objects and the load condition objects in the interactive model into the constraints in the analysis model to correct the overall stiffness equation. From a data perspective, it is necessary to convert the geometric model topology information corresponding to the boundary condition object BoundaryCondition in the interactive model and the applied region object SelectionRegion in the load condition object Load attribute into the node number in the mesh model used for solution calculation. To this end, the following is designed. Fig.10 The conversion process shown in the figure is designed as follows:
[0178] S1001. Convert boundary / load condition objects in the interactive model into finite element node information;
[0179] S1002, executing the local-global number mapping operation in FEMModel to adjust the finite element node number;
[0180] S1003. Based on the global node number and parameter information of the boundary / load conditions, the overall stiffness equation is modified.
[0181] In step S1001, the system calls the convert_to_nodes_info() method of its container child nodes Loads and BoundaryConditions through the model branch node Model, obtains all load condition objects Load and boundary condition objects BoundaryCondition from the interactive model, and converts these objects into finite element node information. Specifically, the method:
[0182] The first step is to traverse the child nodes of the boundary / load condition container class (Loads / BoundaryConditions), that is, the list of load condition objects Load and boundary condition objects BoundaryCondition, and process all objects one by one;
[0183] Step 2: For each boundary / load condition object, execute the method get_node_local_info() to obtain the node information corresponding to the boundary / load condition application area;
[0184] The third step is to obtain the grid node number information corresponding to all boundary / load condition objects and organize them into a list as output to complete the operation of the method and convert the boundary / load condition objects into grid node information.
[0185] In the second step, the execution flow of the get_node_local_info() method of the boundary / load condition object is as follows Fig.11 As shown, the content is as follows:
[0186] S1101, obtaining the application region object SelectionRegion of the condition through the basic information attribute BaseBasicInfo of the boundary / load condition object;
[0187] S1102, confirming the applied geometric model topology structure object EntityInfo, and using its parent pointer to obtain the geometric information object ShapeInfo, and accessing its associated mesh information GmshInfo;
[0188] S1103. Find the corresponding topological structure of the Gmsh mesh model in the corresponding GmshInfo according to the geometric model topological structure number of EntityInfo, and obtain the Gmsh mesh node number on the mesh model topological structure, and finally obtain the mesh node number corresponding to the boundary / load condition application area.
[0189] In step S1002, the local-global number mapping operation in FEMModel is performed to map the mesh node numbers in each component into the global system, and to clarify the global mesh node numbers to which the boundary / load conditions act.
[0190] In step S1003, according to the global node number obtained in step S1002 and the specific parameter information of the boundary / load conditions, the overall stiffness matrix and the overall load matrix in the overall stiffness equation are processed by the multiplication method to obtain the overall stiffness equation for solving. At this point, the process of converting the boundary / load conditions from the interactive model to the analytical model is completed.
[0191] In order to better implement the method for constructing the underlying model data structure in the embodiment of the present invention, based on the method for constructing the underlying model data structure, the embodiment of the present invention also provides a device for constructing the underlying model data structure, such as Fig.12 As shown, the construction device 1200 of the underlying model data structure includes:
[0192] A basic level data structure construction unit 1201 is used to design a basic level data structure based on a combination pattern;
[0193] An interaction model data structure construction unit 1202, used to design an interaction model data structure based on a hierarchical data structure;
[0194] An analysis model data structure construction unit 1203, used to generate an analysis model data structure based on the hierarchical data structure;
[0195] The model data conversion construction unit 1204 is used to construct a model data conversion mechanism between the interaction model data structure and the analysis model data structure.
[0196] The underlying model data structure construction device 1200 provided in the above embodiment can implement the technical solution described in the above embodiment of the underlying model data structure construction method. The specific implementation principles of the above modules or units can refer to the corresponding contents in the above embodiment of the underlying model data structure construction method, which will not be repeated here.
[0197] Those skilled in the art will appreciate that all or part of the processes of the above-mentioned embodiments can be implemented by instructing related hardware (such as a processor, a controller, etc.) through a computer program, and the computer program can be stored in a computer-readable storage medium, wherein the computer-readable storage medium is a disk, an optical disk, a read-only storage memory, or a random access memory, etc.
[0198] The above is a detailed introduction to a method and device for constructing an underlying model data structure provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for technical personnel in this field, according to the idea of the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.
Claims
1. A method for constructing an underlying model data structure, characterized in that: Applied to finite element modeling simulation software, the method comprises: Design basic hierarchical data structures based on composite patterns; Designing an interaction model data structure based on the hierarchical data structure; Designing an analysis model data structure based on the hierarchical data structure; Design a model data conversion mechanism between the interaction model data structure and the analysis model data structure; The designing of the interactive model data structure based on the hierarchical data structure includes: based on the basic hierarchical data structure, performing abstract level expansion and specific level implementation according to different requirements of each functional module involved in the modeling process, to generate the interactive model data structure; The design of the analysis model data structure based on the hierarchical data structure includes: following the standardized calculation process requirements of the finite element, based on the basic hierarchical data structure, designing a specific hierarchical data structure for finite element calculation and analysis, the specific hierarchical data structure including the finite element unit abstract class ElementBase; The model data conversion mechanism includes a Gmsh mesh data extraction and conversion mechanism and a boundary / load condition data conversion mechanism.
2. The method for constructing the underlying model data structure according to claim 1, characterized in that: The basic hierarchical data structure is designed based on the combination pattern, including: At the abstract level, it is designed as a tree-like hierarchical structure composed of nodes, wherein the nodes include branch nodes and leaf nodes, and the branch nodes include container branch nodes and model branch nodes; In combination with the finite element modeling and simulation requirements, an abstract model node class BaseObject and an abstract container class BaseContainerObject are designed for the model branch node and the container branch node respectively; the abstract model node class BaseObject and the abstract container class BaseContainerObject constitute the basic hierarchical data structure.
3. The method for constructing the underlying model data structure according to claim 2, characterized in that: The abstract model node class BaseObject is used for: Based on the multi-level features of branch nodes and leaf nodes in the tree hierarchy, model node management methods such as add_child() and remove_child() are provided.
4. The method for constructing the underlying model data structure according to claim 3, characterized in that: After designing the basic hierarchical data structure based on the combination pattern, it also includes: Based on the support of Qt model-view components, data() and row() data access methods are provided for the basic hierarchical data structure; Based on the visualization requirements of finite element modeling simulation data, generate_name() and set_parent() methods are provided for the basic hierarchical data structure.
5. The method for constructing the underlying model data structure according to claim 4, characterized in that: Based on the support of Qt model-view components, data() and row() data access methods are provided for the basic hierarchical data structure, including: Develop Qt data model class QmyDataModel to implement Qt abstract item model class QAbstractItemModel; Develop data() and row() data access methods in the abstract model node class BaseObject, construct the basic hierarchical data structure and associate it with the Qt data model class QmyDataModel; Based on the Qt model-view interaction component, interactive functions are designed for the basic layer data.
6. The method for constructing the underlying model data structure according to claim 2, characterized in that: The abstract container class BaseContainerObject inherits from the abstract model node class BaseObject, and the abstract container class BaseContainerObject has all the properties and methods of the abstract model node class BaseObject.
7. The method for constructing the underlying model data structure according to claim 1, characterized in that: The functional modules include: Sketch module, whose key functions include sketch drawing and geometric constraint functions. For the sketch drawing function, the relevant data involved in the sketch drawing process is decomposed into sketches and their basic geometric elements, and a reasonable sketch module data structure is designed based on the basic hierarchical data structure. The component module has key functions including component creation and component Boolean operation. For the component creation function, the relevant data involved in the component creation process is decomposed into various component features, and reasonable data structures are designed for different features based on the basic hierarchical data structure. Boundary module, whose key functions include boundary / load condition creation and visualization. For boundary / load condition creation and visualization, consider how to establish the relationship between boundary / load conditions, application area and component topology, and design a reasonable boundary module data structure based on the basic hierarchical data structure. The key functions of the grid module include grid division and visualization. For the grid division and visualization functions, the data association between the geometric model, grid model and grid visualization model is clarified, and a reasonable grid module data structure is designed based on the basic hierarchical data structure.
8. The method for constructing the underlying model data structure according to claim 1, characterized in that: The method further comprises: On the basis of the finite element unit abstract class ElementBase, Element1D, Element2D and Element3D are designed according to the dimensional characteristics of the unit, which are used to represent one-dimensional unit, two-dimensional unit and three-dimensional unit respectively.
9. The method for constructing the underlying model data structure according to claim 1, characterized in that: The Gmsh mesh data extraction and conversion mechanism is used to design mesh data extraction and conversion functions based on the Gmsh mesh data format and the finite element unit node data structure of the system, and convert the Gmsh mesh data into finite element mesh data that can be recognized by the system; The boundary / load condition data conversion mechanism is used to design the boundary / load condition data conversion function based on the interactive model data structure and the analytical model data structure, and correctly convert the relevant attributes of the boundary / load condition objects in the interactive model into the constraint conditions in the analytical model to correct the overall stiffness equation.
10. A device for constructing a bottom-level model data structure, characterized in that: The device is used to execute the method for constructing the underlying model data structure according to any one of claims 1 to 9, comprising: A basic level data structure building unit, used to design a basic level data structure based on a combination pattern; An interaction model data structure building unit, used for designing an interaction model data structure based on a hierarchical data structure; An analysis model data structure construction unit, used to generate an analysis model data structure based on the hierarchical data structure; A model data conversion construction unit, used to construct a model data conversion mechanism between the interaction model data structure and the analysis model data structure; The designing of the interactive model data structure based on the hierarchical data structure includes: based on the basic hierarchical data structure, performing abstract level expansion and specific level implementation according to different requirements of each functional module involved in the modeling process, to generate the interactive model data structure; The design of the analysis model data structure based on the hierarchical data structure includes: following the standardized calculation process requirements of the finite element, based on the basic hierarchical data structure, designing a specific hierarchical data structure for finite element calculation and analysis, the specific hierarchical data structure including the finite element unit abstract class ElementBase; The model data conversion mechanism includes a Gmsh mesh data extraction and conversion mechanism and a boundary / load condition data conversion mechanism.
Citation Information
Patent Citations
Data exchange method and system based on STEP and GEO formats
CN111368467A
Large-scale parallel grid generation method and system suitable for numerical reactor
CN112464540A