Toward interoperable mesh, geometry and field components for PDE simulation development

Abstract

Mesh-based PDE simulation codes are becoming increasingly sophisticated and rely on advanced meshing and discretization tools. Unfortunately, it is still difficult to interchange or interoperate tools developed by different communities to experiment with various technologies or to develop new capabilities. To address these difficulties, we have developed component interfaces designed to support the information flow of mesh-based PDE simulations. We describe this information flow and discuss typical roles and services provided by the geometry, mesh, and field components of the simulation. Based on this delineation for the roles of each component, we give a high-level description of the abstract data model and set of interfaces developed by the Department of Energy’s Interoperable Tools for Advanced Petascale Simulation (ITAPS) center. These common interfaces are critical to our interoperability goal, and we give examples of several services based upon these interfaces including mesh adaptation and mesh improvement.

A Elementary examples of ITAPS mesh interface usage

This appendix presents very simple examples illustrating usage of the ITAPS mesh interface. These examples are meant to be illustrative rather than exhaustive; much of the functionality of the mesh interface is not showcased here. The examples are written as stand-alone programs that can be compiled and run with any ITAPS-compliant mesh database.

We note that the interface examples described here were developed during the first round of SciDAC funding under the predecessor of the ITAPS center, the Terascale Simulation Tools and Technologies (TSTT) center. With the advent of the SciDAC-2 program, the center was renamed to ITAPS, but the team, philosophy and interface definition efforts remain largely the same. In the examples given here, each interface is in the ITAPS namespace to avoid potential function definition collisions. The “base” functionality described in Sect. 3.1, which includes tags, sets, and error handling is in the iBase interface; the mesh functionality described in Sect. 3.2 is in the iMesh interface.

Full SIDL descriptions of the interfaces are available at http://www.itaps-scidac.org/ under the Software link. For those interested in providing feedback on the interface definitions or participating in the interface definition activity, please contact the ITAPS management team at itaps-mgmt@lists.llnl.gov.

1.1 A.1 Language Interoperability

The ITAPS interface is designed to be not only data-structure neutral, but also programming language neutral. That is, a mesh server can be written in one language and client code in another. The ITAPS interface is specified using an interface description language (SIDL), and translated into language-specific interfaces through a tool called Babel [36, 59]. Babel also generates glue code that mediates all inter-language issues, including function name mangling and passage of string and array arguments. As an example of how this works in practice, consider the case of a request for mesh adjacency information. An application code using the ITAPS interface makes an adjacency request by calling a stub function (auto-generated by Babel) in the language of the application. This function re-packages function arguments and calls an internal object representation function (auto-generated by Babel, in C), which again repackages arguments and calls a skeleton function (auto-generated by Babel) in the language of the server. This function, finally, calls the server implementation of the original SIDL function. This approach eliminates all language-specific issues, including name mangling schemes and the treatment of strings and arrays, including dynamic array handling. In exchange, four versions of each SIDL function exist (three of which are auto-generated), and a call from client code must pass through all these layers. Not surprisingly, this complexity in call sequences can have a significant impact on application efficiency.

As an example of the function signatures that Babel creates in various languages, let us examine the mesh interface function for retrieving the entities adjacent to a single entity. The SIDL declaration for this function is

Clients call this function in different ways depending on the language in which the client is written. The C++ binding most nearly duplicates the SIDL function declaration;

In the C binding, the function name has been decorated to prevent naming clashes between SIDL interfaces, and two arguments have been added. One of these ( self ) is a handle for the iMesh data and the other ( _ex ) is used to return exceptions.

In Fortran77, all arguments are passed by address, and SIDL uses 64-bit integers when passing handles. Like the C binding, arguments have been added for the iMesh data and exception return.

Finally, the Fortran90 API is organized into modules and takes advantage of user-defined types, in a manner quite similar to the C API.

1.2 A.2 Mesh adjacency example

This example shows two ways in which entity adjacencies can be retrieved using the ITAPS iMesh interface. This example is written in C++; because the ITAPS team uses Babel for interlanguage calls, the underlying implementation could be in any Babel-supported language.

In line 9, a new mesh instance is created, using a factory. This factory is implementation-specific, but its interface is not, freeing an application from any compile-time dependence on a single implementation. The ITAPS implementation is supplied at link time or, with dynamically-loaded libraries, at run time. In lines 10–12, mesh data is read from a file into the root set of the mesh.

Lines 14–28 iterate through all the three-dimensional entities (regions) of the mesh, counting their total number of vertices. The iteration is controlled by an entity-by-entity iterator, initialized in line 17. Note that this iterator is not defined as part of the iMesh::Mesh base interface but in a more specialized interface, iMesh::Entity; line 15 casts the Mesh object to Entity. ¹ In line 19, the iterator provides both a boolean value indicating whether more data is available and the handle of the next available entity if there is one. This syntax is admittedly somewhat awkward, but if a mesh is modified, it is impossible in general to be certain whether there will be another entity until one tries to retrieve the next one. Line 24 is the heart of the adjacency retrieval loop, returning an array of all vertices adjacent to the current region in the iteration.

Lines 30–41 illustrate block retrieval of entity adjacency information. Line 32 first retrieves all regions in the mesh. Then, in line 39, all vertices adjacent to the entities whose handles are in ents (i.e., all regions) are returned; the contents of offsets identifies, for each ent , where its list of vertices begins in allverts .

Finally, lines 42–44 report whether the total numbers of adjacent vertices retrieved by these alternate approaches are consistent.

1.3 A.3 Set and tag example

This example shows simple retrieval of entity sets and identification of tags attached to those sets. Again, the underlying ITAPS implementation could be in any Babel-supported language.

After reading a mesh as in the previous example, all the entity sets defined for the mesh are retrieved (line 20).

Lines 22–31 retrieve tag information for the sets. Specifically, line 27 retrieves all tags attached to a particular entity set, and the loop from lines 28–30 populates a standard template library set of tag handles.

Finally, the loop from lines 33–39 output information about each tag found, in order of increasing tag handle. For each tag handle, the name of the tag (retrieved in line 35) and its size in bytes (retrieved in line 36) are output.