Common Interface Definition

The bulk of our efforts toward the goal of interoperable meshing geometry services has focused on the development of a common interface for meshes, geometry and the relationships between them, and we describe these efforts below. To ensure that our tools are as broadly available as possible, we have worked closely with the Common Component Architecture (CCA) forum to investigate the use of their SIDL/Babel language interoperability tools and to ensure that our interfaces will be compatible with the CCA component specification.

One of the primary development efforts that showcases ITAPS teamwork is our creation of common interfaces for mesh geometry and topology access. Our philosophy has been to focus primarily on the definition of accessor interfaces that provide the functionality needed by application programmers. A key aspect of this approach is that we do not enforce any particular data structure or implementation with our interfaces, only that certain questions about the mesh (such as geometry or first-order adjacency information) can be answered through calls to the interface. The challenges inherent in this type of effort include balancing performance of the interface with the flexibility needed to support a wide variety of mesh types and the desire to keep the interface minimal so that it is easy to implement and adopt.

Data Hierarchy Concepts

Meshing and discretization technologies must take into account a conceptual hierarchy of domain representations (see Figure 1). The original problem specification can be given in terms of a high-level geometric representation such as a CAD description, image data, or possibly a previous mesh, along with the physical attributes of the application (level 0). As an example, the electromagnetic simulations for accelerator design are based on a detailed and complex specification through CAD-generated geometries, while for other applications such as plasma physics, typical input geometries are relatively simple. This geometry has a global representation of some kind (such as a non-manifold solid model or pixel intensity information) that properly represents the physical domain. The geometric model can be decomposed into sub-regions (level 1), each of which could be discretized using a possibly different fundamental mesh type. Decompositions for the purpose of adaptive mesh refinement must also refer back to the original geometrical information, and hence are part of this level. The next level (2) consists of the meshes that are constructed within the components of the level 1 decomposition. Because the simulations will be run on terascale parallel computers, a further decomposition (level 3) to support the partitioning of the levels 0-2 entities across the 1000's of processors involved is defined (see the Terascale Computing Section). All the levels shown in Figure 1 can be considered different resolutions of the domain, and fit into a hierarchy of representations. Meshing and other tools (e.g. for partitioning, discretization, or solution interpolation) can access these representations through a common interface, simplifying the process of changing the resolution either inside a level or between levels. The use of this concept will be explored using the various representations available in the Common Geometry Module (CGM).

Figure 1. Domain Hierarchy

Figure 1

Analogous to the conceptual geometry hierarchy discussed in the previous paragraph, we also focus on a mesh data hierarchy (Figure 2). The highest level in this hierarchy (level A) again contains a description of the geometric domain. Access to this information is provided, for example, by generic interfaces such as CGM, direct functional interfaces to solid modeling kernels, e.g. [SheGeo92], or data file representations such as IGES and STEP. The lowest level (C) shown in the figure again represents the mesh components, while the intermediate level (B) represents the combination of the level C mesh components into an overall hybrid mesh, together with the communication mechanisms that couple their data together. In addition, level B allows the possibility of multiple mesh representations for the complete geometry to be used within a single application, or in coupled applications. At level B, code developers or users can access the entire grid hierarchy as a single object, and call functions that provide, e.g. partial differential operator discretizations, adaptive mesh refinement or multilevel data transfer over the entire mesh. This will be accomplished by providing an interface much like that currently provided in the Overture framework. Functionality at this level will enable the rapid development of new mesh-based applications. In addition to this high-level strategy, we also provide access to the hierarchy at low levels to facilitate the incorporation of our tools into existing applications. At level C, for example, we will provide access to Fortran-callable routines that return discretization or interpolation coefficients at a single mesh point or array of points on a mesh. Initially access at these lower levels is likely to provide for more efficient implementations. However, we expect that by basing the higher-level tools on highly optimized kernels, both code development and runtime efficiencies will ultimately be realized.

Figure 2. Mesh Data Hierarchy

Figure 2

Interface Definition Efforts

As of September 2002, the TSTT interface definition group has agreed to nomenclature regarding mesh entities and basic functionality for accessing geometric and topological information about the mesh. In particular, the TSTT interface supports topologically-dimensioned entities which are called VERTEX, EDGE, FACE, and REGION for 0-3D respectively. Each of these entities can live in a geometric dimension equal to or greater than its topological dimension although we assume that the geometric dimension is the same for all entities in a given mesh. In addition, various topological regions are supported; in particular, TRIANGLE, QUADRILATERAL, and POLYGON are supported in 2D and TETRAHEDRON, HEXAHEDRON, PRISM, SEPTAHEDRON, and POLYHEDRON are supported in 3D. Access to the mesh geometry and topology information is provided through a number of different mechanisms. For example, care was taken to ensure that access to coordinate and adjacency information in the mesh was provided on both an entity-by-entity basis by using iterators of opaque objects and for the entire mesh at once through arrays of doubles. All implementations are required to support both modes of access although it is recognized that only one style is typically native to the underlying implementation thus may require a copy operation if the other mode of access is requested. To improve performance of the entity-based functions, a workset iterator interface is provided that allows the user to request entities in an array of a user-specified size (for example, 100 entities at a time). These arrays can then be used in any of the entity-based function calls to retrieve large chunks of information to minimize the number of calls through the interface. Additional functionality that is currently supported for the mesh includes mesh creation, loading, destruction and services to access basic information such as its geometric dimension, the number of each type of entity, etc. Finally, the user is able to attach an arbitrary piece of data to any mesh entity or to the mesh itself through the use of tags. This allows the interface to become useful to application scientists by providing functionality for attaching boundary condition information, material properties, etc. In total, this interface contains 39 functions and provides the functionality needed to support a basic mesh-based simulation. More information on the TSTT interface specification can be found on our software web page.

Implementations of this specification are underway at LLNL (for Overture), PNNL (for NWGrid), RPI (for AOMD), SNL (for MDB/CUBIT), and ANL (for a simple triangular mesh). Additional efforts that use the interface for interoperable meshing technologies are ongoing at SUNY SB as part of the Frontier merge with various TSTT mesh generation technologies and as part of the MESQUITE mesh quality improvement toolkit.

In addition to the basic interface specification described above, a number of additional functionalities have been discussed and the interface definition efforts for them are well underway. In particular, we are considering the addition of