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
iMesh.

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:

None

