Commit eb48021c authored by Ben Boeckel's avatar Ben Boeckel Committed by Robert Maynard

moab: bring in MOAB upstream

parent 0cc6827b
# Only use the local sparsehash when the system version is not requested.
MOAB, a Mesh-Oriented datABase, is a software component for creating,
storing and accessing finite element mesh data. MOAB is being
designed in close collaboration with the SciDAC Terascale Simulation
Tools and Technologies (TSTT) Center and with the CUBIT project at
Sandia National Laboratories.
A few highlights of the capabilities in MOAB include:
* Representation of 0-3d elements in the finite element "zoo"
(including support for quadratic elements), as well as support for
polygon and polyhedron entities
* Highly efficient storage and query of structured and unstructured
mesh (e.g. a brick-shaped hex mesh requires approximately 25 and 55 MB
per million hex elements in the structured and unstructured
representations, respectively)
* Powerful data model allowing representation of various metadata in
the form of "sets" (arbitrary groupings of mesh entities and sets) and
"tags" (annotation of entities, sets, and entire mesh)
* Open source (LGPL) mesh readers/writers for Sandia ExodusII,
CUBIT .cub save/restore, VTK, and other mesh formats
* Implementation of the DOE Scidac TSTT center's mesh interface (see for more details of this interface)
MOAB is available under an LGPL license from Sandia National
Laboratories. More information, including instructions for
downloading MOAB, are located at
This diff is collapsed.
This is a list of the known issues with MOAB v4. For more details please see
the online ticket system at the MOAB website:
# Severity Summary/Details
=== ======== ===================================================================
#161 enhancement Need better MBCN test
#170 enhancement get_connectivity should optionally return an offset list
#29 enhancement Specifying sets not to write
#32 enhancement support writing compressed (szip) HDF5 files
#138 enhancement Error handlers
#141 enhancement reader/writer file set
#172 enhancement environmental variables
#174 enhancement Mechanism for leaving readers instantiated
#26 enhancement pipelining utilities
MOAB, a Mesh-Oriented datABase, is a software component for creating,
storing and accessing finite element mesh data.
Copyright 2004 Sandia Corporation. Under the terms of Contract
DE-AC04-94AL85000 with Sandia Coroporation, the U.S. Government
retains certain rights in this software.
This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
Lesser General Public License for more details. A copy of the full
GNU Lesser General Public License can be found at
For more information, contact the authors of this software at
# Config file for MOAB; use the CMake find_package() function to pull this into
# your own CMakeLists.txt file.
# This file defines the following variables:
# MOAB_FOUND - boolean indicating that MOAB is found
# MOAB_INCLUDE_DIRS - include directories from which to pick up MOAB includes
# MOAB_LIBRARIES - libraries need to link to MOAB; use this in target_link_libraries for MOAB-dependent targets
# MOAB_CXX, MOAB_CC, MOAB_F77, MOAB_FC - compilers used to compile MOAB
# MOAB_CXXFLAGS, MOAB_CCFLAGS, MOAB_FFLAGS, MOAB_FCFLAGS - compiler flags used to compile MOAB; possibly need to use these in add_definitions or CMAKE_<LANG>_FLAGS_<MODE>
set(MOAB_CC @CC@)
set(MOAB_FC @FC@)
set(MOAB_F77 @F77@)
set(MPI_DIR "@MPI_DIR@")
set(HDF5_DIR "@HDF5_DIR@")
set(NetCDF_DIR "@NetCDF_DIR@")
set(PNetCDF_DIR "@PNetCDF_DIR@")
set(Zoltan_DIR "@Zoltan_DIR@")
# Compiler flags used by MOAB
# Library and include defs
get_filename_component(MOAB_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
# Target information
if(EXISTS "@HDF5_DIR@/share/cmake/hdf5/hdf5-config.cmake")
# MOAB: 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". 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.
MOAB can be used in several ways: as the underlying mesh data representation for applications (MOAB is used in this way in the VERDE mesh verification code, as a mesh input mechanism (using mesh readers included with MOAB), or as a translator between mesh formats (using readers and writers included with MOAB).
MOAB was developed as part of the CUBIT project at Sandia National Laboratories, and was partially funded by the DOE SciDAC program as part of the Terascale Tools and Technologies (TSTT) center.
# Dependencies
MOAB depends on the NetCDF libraries (C and C++) to compile the ExodusII reader/writer. Support for C++ was added to netcdf in version 3.5.1, and took a bit of time to get compiling ironed out, so make sure you have version 3.6 or later. To get netcdf, search the web or try [NetCDF].
The only MOAB file format that can represent the entire MOAB data model is MOAB's native HDF5-based file format. Support for this file format requires version 5 of the HDF library. It may be obtained at [HDF5].
- Unpack the source code in some directory.
- Run the 'configure' script in the top source directory with the '--help' option to see a list of available configure options. '--prefix', '--with-netcdf', and '--with-hdf5' are common options specified.
- From either the source directory or some other, empty directory, run the 'configure' script in the top source directory with any desired configuration options.
- In whichever directory the configure script was run in, issue the command 'make' to compile MOAB and any configured MOAB-based tools.
- In whichever directory MOAB was build in, issue the command 'make check' to verify that MOAB compiled and is working correctly.
- Issue the command 'make install' to install the MOAB library and headers in the configured install directory. (This step is optional if you're only building tools distributed with MOAB.)
# Bugs, Correspondence, Contributing
MOAB is LGPL code, and we encourage users to submit bug reports (and, if desired, fixes) to Users are encouraged to check [SIGMA-MOAB] documentation pages often for news and updates. Please submit pull requests (PR) with a Bitbucket fork or send us patches that you would like merged upstream.
\ No newline at end of file
Where's the configure script?
After installing the GNU autotools suite, execute the following
command to generate the configure script (and other necessary
generated files):
autoreconf -fi
If for some reason, the autoreconf command is not available,
the following sequence of commands should have the same result:
aclocal -I m4
libtoolize -f
automake -a
Why aren't the configure script and other generated files in the
CVS repository?
Because they are generated files. Why save a version history for
them? Further, some of the above commands get re-run automatically
when's or other files are changed. This could lead to
compatibility problems if some of the generated files in the CVS
repository are from a different version of the GNU autotools.
Aren't we requiring users to have GNU autotools installed in order
to configure MOAB?
No. Developers (or anyone else using source directly from the CVS
repository) must have the autotools installed. When creating a
tarball for distribution of MOAB, the commands below should be run.
The resulting tarball will contain all necessary generated files,
including the configure script.
What needs to be done to prepare MOAB for distribution as a tarball?
Check out a clean copy of MOAB.
Execute the following commands in the top-most directory:
autoreconf -fi
make dist
To create a distributable tarball from a working source directory, do
make dist
To create a distributable tarball from a clean check-out of the MOAB
source, do:
automake -a
./configure --without-netcdf --without-hdf5
make dist
MOAB iMesh Interface Implementation, iMesh v1.2
1. Non-compliant iMesh functionality:
1.1 Iterators for list-type entity sets:
The iMesh 1.2 specification requires that iterators over list-type entity sets be updated
in response to membership changes in the set. Specifically, if entities are added to or
removed from the set, the spec requires that added entities be iterated without needing to
reset the iterator, and that removed entities not be iterated. MOAB will not support this
capability in the iMesh 1.2 release. Future support will depend on whether this can be
implemented efficiently, without degrading performance for static mesh applications.
1.2 No support for septahedron entities:
MOAB does not support septahedron entities at this time (though such entities could be
represented as general polyhedra).
2. MOAB capabilities not accessible through iMesh:
2.1 Dense tags: MOAB supports two kinds of tag storage: dense tags, where tag values are
stored in sequence for sequences of contiguous entity handles; and sparse tags, which are
stored in (entity handle, tag value) tuples. iMesh does not support creation of a tag
with a default value, nor does it have a mechanism for passing general options to the tag
creation function. Therefore, MOAB's iMesh implementation creates sparse tags by
default. Alternatives for specifying the tag creation type will be explored for future
iMesh releases.
2.2 Variable-length tags: MOAB supports a variable-length tag, where a tag value can have
a different length for each entity to which it is assigned. This functionality is not
supported in iMesh.
2.3 Direct access to tag data (tag_iterate functionality): MOAB 4.0.1 introduced the
ability for applications to get direct access to tag storage for dense-type tags (see the
tag_iterate function in src/moab/Interface.hpp). This functionality is not supported in
2.4 Corner vs. all vertices in connectivity list: MOAB represents so-called "higher-order
entities", e.g. quadratic tetrahedra, by allowing the connectivity list to be an
application-specified size. The connectivity array returned by MOAB's iMesh
implementation will always be the total number of vertices, including any high-order
vertices. MOAB's interface allows applications to specify whether all or just corner
vertices are requested.
2.5 Retrieval of entity, set handles in order from list-type sets: MOAB uses the same
handle type for both entities and entity sets. The order of addition of entities and
entity sets to list-type sets is therefore preserved, since these handles are stored in
the same list. Since iMesh uses a different handle type for entities than for sets, and
returns those handles in different API functions (iMesh_getEntities versus
iMesh_getEntSets), the original order of addition in the case where entities and entity
sets are interspersed cannot be recovered.
2.6 No support for knife-type elements: MOAB supports a seven-sided element referred to as
a "Knife" element; this element results from collapsing a quadrilateral bounding a
hexahedron by merging opposite nodes. This element type is not supported in iMesh.
Other errata:
This document describes file formats supported by MOAB and options
controlling file input and output.
Supported File Formats
Some of the file formats listed below may not be supported by a particular
build of MOAB depending on the availability of external libraries. An
up-to-date list of file formats supported in a particular build of MOAB
can be obtained programatically using the MBReaderWriterSet API or as
a simple list using the '-l' option of the mbconvert utility.
Format Name Read Write File name suffixes
------------------ ------ ------------ ------ --------------------
MOAB native MOAB yes yes h5m mhdf
Exodus II EXODUS yes yes exo exoII exo2 g gen
Kitware VTK VTK up to v3.0 v3.0 vtk
Cubit CUBIT yes no cub
SLAC SLAC no yes slac
GMV GMV no yes gmv
Ansys ANSYS no yes ans
Gmsh GMSH v1.0, v2.0 v2.0 msh gmsh
Stereo Lithography STL yes yes stl
Any of the values from the 'Name' column may be passed as an option
to the file IO methods to request a particular file. If no file
format is specified, the default is to choose the write format using
the file extension and to try all file readers until one succeeds.
File IO Options
An options list as passed to MOAB file IO routines is a single C-style
string containing the concatenation of a list of string options, were
individual options are separated by a designated separator character.
The default separator character is a semicolon (;). To specify an alternate
separator character, begin the options string with a semicolon followed
by the desired separator. Options are not case sensitive.
Common Options
Specify the precision to use when writing float and double values
(such as node coordinates) to text-based file formats.
Do not overwrite existing file.
Max. distance deviation between facet and geometry, default:0.001.
Max. normal angle deviation (degrees) between facet and geometry, default:5.
Max. facet edge length, default:0.
Actuation of all CGM attributes, default:no.
Set threashold for debug messages from low-level (format-specific)
reader/writer. Default is 0 (none).
Parallel IO Options
MOAB must be built with parallel support enabled before these options
can be used.
Parallel Read Options:
Set parallel read mode. Options are:
- NONE - force serial read/write on each processor (default)
- BCAST - read on one processor and broadcast a copy to all others
- BCAST_DELETE - read file on one processor, broadcasting partitioned
data to other processors.
- READ_DELETE - read file on all processors and partition by deleting
mesh from non-local partitions.
- READ_PART - read only relevant subset of file on each processor,
utilizing format-specific parallel I/O if available
(this option is not supported for all file formats.)
- WRITE_PART - write only relevant subset of file on each processor,
creating a single file utilizing format-specific parallel
I/O if available (this option is not supported for all
file formats.)
- FORMAT - depricated (use WRITE_PART)
Resolve which entities are shared between which processes, such
that propogation of data across processes can be done. This should
probably be the defautl behavior, as you almost certainly want this
unless, perhaps, PARALLEL=BCAST.
Specify that mesh should be partitioned using partition IDs stored
in a tag. If the tag name is not specified, the default ("PARTITION")
is used.
If a tag name is specified to the 'PARTITION' option, then treat as