What is a Geometric Model
SMTK aims to integrate models from a variety of sources by exposing a common interface for accessing model entities across different modeling kernels. Supported modeling kernels include the following:
- parametric kernels, where volumes, faces, and edges have well-defined parametric coordinates that can sufficiently represent curved models; and
- discrete kernels, where volumes, faces, and edges are each discretized into a piecewise collection of primitive cells, which may have internal parameterizations but do not guarantee a parameterization at the model-entity level.
Each modeling kernel, whether discrete or parametric, provides model representations with varying levels of fidelity, from simple unstructured point clouds to triangles complete with non-manifold boundary representations. The fidelity involved depends on which modeling kernel an SMTK session uses, as well as on the choices made by the modeling kernel when constructing a model.
Models are composed of geometric entities and relationships between entities, depending on levels of fidelity. Supported geometric entities are as follows:
- vertices, representing topological domains of dimension 0;
- edges, representing topological domains of dimension 1;
- faces, representing topological domains of dimension 2;
- volumes, representing topological domains of dimension 3;
- groups (or collections), consisting of model entities; and
- models (or parts), representing assemblies.
Relationships, such as those regarding “use” and “sidedness,” are utilized to properly model contact between geometric entities. When one side of a model face is part of the boundary of a model volume, for example, we say that the volume “uses” the face. In cases of non-manifold topologies, each geometric entity (vertices, edges, and faces) has multiple “uses.” A face can be “used” by at most two volumes, since it has only two sides. By tracking face “uses” explicitly, SMTK allows multi-physics codes to assign boundary conditions for different physical phenomena to different sides of faces.
Examples
For an illustration of the range of models supported by STMK, consider the following concrete examples.
Open CASCADE CAD Models
Open CASCADE CAD models are accessible—based on the Computer Graphics Metafile’s (CGM’s) parametric interface—to read Standard for the Exchange of Product Data (STEP), Initial Graphics Exchange Specification (IGES), and other CAD files. Open CASCADE CAD models include both geometric entities and non-manifold topological relationships between entities.
Discrete Models
Discrete models such as two-dimensional geographic shapefiles, three-dimensional (3D) STereoLithography (STL) or object (OBJ) files, and many other file formats are modeled using a VTK-based kernel packaged with SMTK. Discrete models may include full non-manifold topology.
Exodus Meshes
Models based on Exodus meshes are created via a custom model session packaged with SMTK. (Model sessions are described in the next section.) This session presents each Exodus block and side set as an SMTK group entity. SMTK assumes that the blocks and side sets in the Exodus mesh represent a meaningful partitioning (or conceptualization) of the discrete information. SMTK also assumes that the partitioning is sufficient to assign the necessary material properties, boundary conditions, and other information required by a simulation.
You may use Exodus meshes for complex models whose “formal” non-manifold representations would contain hundreds of thousands of model faces and volumes. For example, the mesh depicted in the model at the top of the page is a 750 MB Exodus file. Rendering this file generates 21 million triangles. The model is courtesy of Argonne National Laboratory and was generated using Reactor Geometry Generator (RGG), Scalable Interfaces for Geometry and Mesh Based Applications (SIGMA) tools from the Department of Energy, and CUBIT Geometry and Mesh Generation Toolkit.
SMTK’s Model Manager and Model Session
SMTK stores all of the geometric entities and their relationships in a model manager. A manager can hold entities from multiple modeling kernels, providing uniform access to the entities. A manager can also serialize and deserialize entities.
Each manager’s entities are kept up-to-date by one or more model sessions. A session associates a manager’s entities to the entities’ counterparts in a single modeling kernel. The below image shows a conceptual diagram of an application accessing three models within a single model manager. Each of the model entities comes from a unique session. The sessions use different modeling kernel application programming interfaces (APIs) to load and traverse models, to create entries in the model manager, and to perform operations on the models. The APIs utilized in the image are CGM, SMTK’s built-in discrete modeler, and Capstone.
Since each session potentially uses a unique modeling kernel, you have access to different operations for various sessions. For example, you may have access to operations for creating vertices, edges, and faces; for sweeping parametric faces to form volumes; and for changing the assignment of discrete-modeling primitives from one edge or face to another. You may also have access to Boolean point-set operations like unions, intersections, and subtractions. In SMTK, you can ask model sessions for a list of operators that can act on model entities in a particular session. You can also programmatically query operators for the inputs they require. In addition, you can query operators for textual descriptions of their effects. For each operation, SMTK generates a user interface, which is discussed in more detail below.
Sessions and Processes
Some modeling kernel APIs link to conflicting versions of libraries, or they have cumbersome licensing or stability issues, making it undesirable for a single model manager to handle a given set of kernels. SMTK works around this by providing a forwarding session, which serializes and deserializes the data in a remote process’ model manager in response to operations that are forwarded to the session. You can use the same concept of forwarding to make client-server applications. The below image shows how a ParaView-based application in CMB implements a forwarding session.
As forwarding sessions are used across processes, SMTK is intended to grant read-only access to the contents of the model manager. To change the model, always use an SMTK operator, as opposed to changing records in the model manager. Doing the latter will not update the model in the underlying modeling kernel. Keeping the information in the model manager to a minimum and developing clients that do not request large amounts of data to be serialized reduces the amount of work that needs to be redone after performing modeling operations. For example, the renderings in the below image were completed on the server, while the model trees to the right of the renderings were drawn on the client. Since the client does not use any tessellation information itself, the model trees do not need to be serialized.
Geometric Modeling Operators
As mentioned earlier, each modeling session provides a different set of operators that you can use to alter the geometric domain intended for discretization into a mesh for a simulation. The only way to modify a model and to guarantee that changes are propagated from SMTK’s model manager to the modeling kernel is to employ operators. Each operator accepts parameters and associations that fully specify a task for the modeling kernel. Associations bind one or more model entities to the operator as the primary geometry that the operation will affect. For instance, the Boolean union operator uses any associated geometry as the workpiece (i.e., the part that remains after subtraction) and has a parameter named “tool,” which accepts geometry to add to the workpiece. The below image shows user interfaces that are automatically generated for each operation. Buttons located next to an association or parameter entry indicate that a list of geometric entities is expected for that entry. The buttons allow you to reset the list of entities or to populate an entry with the current selection.
Interfacing with VTK and Qt
You can use SMTK to develop applications to customize presentation of and interaction with geometric models. For example, you can customize VTK-based 3D renderings and Qt-based tree views.
VTK Rendering of SMTK Models
In SMTK, each model entity—whether it is an edge, a face, or even a group—can have an associated tessellation that is used to display the model. There is a VTK source filter that, given an SMTK model manager and a model of interest, generates a multi-block dataset containing one vktPolyData object for each model entity owned by the specified model. You can color each block independently through vtkCompositePolyDataMapper. Since VTK provides a method for identifying which block is picked, identifying the selected model entity is simple. Arbitrary pipelines can then process the model geometry. Be aware, however, that the tessellations produced by SMTK are not guaranteed to be conformal, unless the underlying model is discrete (not parametric). Many CAD packages provide non-watertight tessellations for rendering, as doing so is much faster than generating a conforming surface mesh.
Qt Model-View-Controller Presentation
SMTK contains several classes to help you present various model perspectives. There are circumstances where you may want to only show entities of a given dimension or to show parent-child relationships other than boundaries. For instance, since SMTK allows you to attach an integer, a floating-point, and/or string properties to each model entity, you can show entities at the top of the tree and their properties as children. Use cases include the following:
- a tree view that shows model entities, allowing you to select entities when they are obscured in a 3D rendering by other geometry (e.g., a face inside a cavity);
- a tree view that shows model entities, allowing you to select entities when they are not being illustrated (e.g., shell-oriented uses that are not explicitly rendered and are associated with boundary conditions, rather than faces, in some multi-physics simulations);
- a list view that displays group membership and supports drag-and-drop modifications;
- a tree view that illustrates relationships between entities, sizing functions, and/or feature definitions used to constrain meshers; and
- a list view that shows entities ordered by their intersection points along a ray fired through a rendered view.
(The latter is for selection of entities as input to operations or for association with simulation attributes.) Instead of writing a separate model or widget for each use case, SMTK has a framework that can express any of these cases. The framework consists of two base classes, DescriptivePhrase and SubphraseGenerator, plus some subclasses of each. The base classes are not tied to any particular user interface library. As a result, you can use them in both desktop and Web applications. If Qt support is enabled, SMTK also provides a subclass of QAbstractItemModel that uses DescriptivePhrase and SubphraseGenerator.
