MOAB — The Mesh-Oriented datABase
The Mesh-Oriented datABase (MOAB) is a component for representing and evaluating mesh data. MOAB can store structured and unstructured mesh, consisting of elements in the finite element “zoo” plus polygons and polyhedra. The functional interface to MOAB is simple yet powerful, allowing the representation of many types of metadata commonly found on the mesh. MOAB is optimized for efficiency in space and time, based on access to mesh in chunks rather than through individual entities, while also versatile enough to support individual entity access. The MOAB library can naturally represent finite element and other types of mesh data . Various types of meta-data are often used in conjunction with a mesh. Examples include boundary condition groupings, material types, and provenance information for the mesh. Because the data model used in MOAB is so abstract, conventions are useful for describing how meta-data is stored into that data model.
MOAB implements the ITAPS iMesh interface; iMesh is a common interface to mesh data implemented by several different packages, including MOAB. Various tools like smoothing, adaptive mesh refinement, and parallel mesh communication are implemented on top of iMesh. Because the data models used by MOAB and iMesh, the ITAPS mesh interface , are so similar, the conventions described here apply almost unmodified to iMesh as well as to MOAB.
The meshes represented in MOAB originate in a variety of forms, including mesh read from files of various formats (e.g. CUBIT “.cub” file, VTK, etc.) as well as mesh written into MOAB directly by
various software libraries (e.g. MeshKit). Although there is no standard for naming or storing meta-data with a mesh, there is a great deal of commonality in the types of meta-data typically found with mesh-data. This document describes conventions that have been established for commonly encountered meta-data. Various mesh readers implemented in MOAB attempt to read meta-data from a file and write it into the MOAB data model using these conventions. Although there is no requirement to store a given type of meta-data in the form described here, a number of services have been written to handle meta-data using these conventions, no matter the source of the meta-data being processed.
Several specific tools are often used in concert with MOAB and bear special mention here. The CUBIT toolkit generates finite element meshes, and saves them to a native save file (referred to as a “.cub” file) which MOAB is able to read. Reading CUBIT meshes into MOAB through the .cub file format is preferred over other formats, since most other mesh formats written by CUBIT do not save most meta-data. The MeshKit library also generates mesh using CGM and MOAB, and uses the same conventions for storing meshes into MOAB. Finally, MOAB includes a CGM reader which can read a geometric model into a faceted representation in MOAB. Meta-data from all these tools are stored in MOAB using the conventions described here.
The MOAB data model consists of the following basic types:
- Entity: The basic elements of topology, e.g. vertex, edge, triangle, tetrahedron, etc. MOAB represents all types in the finite element zoo, plus polygons and polyhedra.
- Entity Set: An arbitrary collection of entities and other sets. Sets can have parent/child relations with other sets, and these relations are distinct from “contains” relations.
- Interface: The interface object through which other entities are accessed, in the sense of object-oriented-programming. iMesh refers to the interface as the “root” set.
- Tag: A piece of data that can be assigned a distinct value to each entity and entity set, and to the interface itself. Tags have a prescribed name, size in bytes, and data type; allowed data types are integer, double, entity handle, and byte or opaque.
MOAB supports common parallel mesh operations like parallel import and export (to/from a single HDF5-based file), parallel ghost exchange, communication of field data, and general sending and receiving of mesh and metadata between processors. Parallel read has been demonstrated on up to 16K processors.