Scalable Interfaces for Geometry and Mesh based Applications

MOAB — The Mesh-Oriented datABase

The Mesh-Oriented datABase (MOAB) is a component for representing and evaluating mesh data. MOAB can store and represent structured and unstructured meshes consisting of elements in the finite element “zoo”, including 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 being versatile enough to support individual entity access. The MOAB library can naturally represent finite elements 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 in that data model.

Since MOAB is implemented in C++, and in order to enable language-agnostic meshing and coupler workflows, iMOAB, a decomposition, and a topology-aware interface have been exposed. We expose several standard operations such as scalable reading and writing of mesh files in various formats, creation, and manipulation of parallel unstructured meshes in-memory, efficient migration of meshes from one set of processes to another, optimal communication strategies for data fields stored as tags, computation of mesh intersections between two topological distributions and conservative remapping weight generation for solution field projections in multiphysics applications. Because the data models used by iMOAB are a thin layer on top of the underlying MOAB library, the conventions described here apply almost unmodified to iMOAB as well as to the MOAB library.

The meshes represented in MOAB originate in a variety of forms, including mesh read from files of various formats (e.g. HDF5 “.h5m” file, NetCDF “.nc”, 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) that MOAB can read. One can also generate meshes with GMsh and convert it to a more compact format. The native MOAB I/O format is h5m, which is based on the HDF5 parallel library. This format provides native parallel load of meshes in a scalable fashion. Note that the MeshKit library can generate meshes using CGM and MOAB, and uses the similar conventions. 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.

Related Links

Copyright © 2014--2023 SIGMA. All Rights Reserved.