ITAPS Interfaces: Previously Released Version 1.0

You are viewing a previous release. Go here to view the current release.


Interface Specifications

The next step to creating interoperable technologies is to define common interfaces that support the abstract data model. A key aspect of our approach is that we do not enforce any particular data structure or implementation with our interfaces, requiring only that certain questions about the geometry, mesh, or field data can be answered through calls to the interface. One of the most challenging aspects of this effort remains balancing performance of the interface with the flexibility needed to support a wide variety of data types. Performance is critical for kernel computations involving mesh and geometry access, and to address this need, we provide a number of different access patterns including individual iterator-based and agglomerated array-based requests. Further challenges arise when considering the support of many different scientific programming languages which we address using a two-pronged approach. First, we provide a C-language binding for our interfaces that is compatible with most needs in scientific computing. Additional flexibility, albeit at a somewhat higher cost, is supported through the use of the SIDL/Babel technology provided by the Common Component Architecture Forum (CCA).

There are six ITAPS interfaces, five that correspond to the core data model components, Geometry (iGeom), Mesh (iMesh/iMeshP), Fields (iField), and Data Relation Managers (iRel) and one that contains the utilities and definitions used by more than one of the core interface (iBase). These interfaces are developed primarily by the ITAPS research team, but the discussion is open (for more information, contact Lori Diachin). In the table below, each of the interfaces is briefly described and links to the interface specification and user guides are given.

Interface Specifications

Interface Description Documentation
iBase Utilities and definitions used in multiple ITAPS core interfaces such as entity type and topology defintions, creation status, tag value types, error functions. Also contains basic sets and tags functionality definitions. Incorporated into iMesh and iGeom documentation
C Specification
SIDL Specification (v0.8)
iMesh Basic services to manage a discrete mesh composed of sets of entities, such as nodes, edges, faces and volumes, modifications to these entities and tags and tag data associated sets of entities. Documentation
C Specification
SIDL Specification (v0.8)
iMeshP Functions to manage the parallel aspects of a discrete mesh that has been decomposed into a partition consisting of parts. Functions to manage the parts and partition, copies of entities on different processors, entity migration, data exchange across processor boundaries. Function descriptions include communication requirements including collective, point-to-point or none. (Note: Alpha version, subject to change) Documentation
C Specification
SIDL Specification
iGeom Continuum, geometric services such as pointwise interrogations, parametric and geometric model representations Documentation
C Specification
SIDL Specification (v0.8)
iRel Manage the relationships among two or more of the core data types, resolve cross references between entities in different groups, and provide additional functionality that depends on multiple core data types Documentation
C Specification
SIDL Specification (v0.8)
iField Under development. Documentation
C Specification
SIDL Specification


ITAPS API's are C-like and the C-specification can be called directly from C, Fortran, C++. Arguments are passed by value (in arguments) or by reference (inout, out) and Fortran users will need to use the %VAL extension. Memory allocation for lists and arrays are done either in the application or in the implementation. If inout list comes in allocated, the length must be long enough to store results of call. By definition, allocation/deallocation is done using C malloc/free and the application is required to free memory returned by implementation. Fortran users will need to use the "cray pointer" extension. Handle types are typedef'd to size_t (iBase_EntityHandle, iBase_EntitySetHandle, iBase_TagHandle, iMesh_Instance). For string arguments, we use char * with the length passed by value after all other arguments. For enumerated types, the values (iBase_SUCCESS, etc.) are available for comparison operations, but passed as integer arguments in C and C++ and as named parameters in Fortran.

Interface Implementations

The tables below list the implementations of the ITAPS interfaces that are currently available, their status, and distinguishing characteristics. For more information on a given interface implementation, please contact the ITAPS research listed in the POC column.

Implementations of the ITAPS iBase Interface

Software Name POC Status Distinguishing Characteristics
SCUtil - Scientific Computation Utility
More Information / Download
Seegyoung Seol, RPI Operational Interface-independent, general iterator and entity set sharable by all ITAPS interfaces

Implementations of the ITAPS iMesh Interface

Software Name POC Status Distinguishing Characteristics
MOAB - Mesh-Oriented Data Base
More Information / Download
Tim Tautges, ANL Complete All mesh region topologies except Septahedron, all upward and downward adjacencies (varying cost), 2D/3D, full implementation
GRUMMP - Generation and Refinment of Unstructured, Mixed-Element Meshes in Parallel
More Information / Download
Carl Ollivier-Gooch, UBC Complete Supports all mesh topologies except septahedra, polygons, and polyhedra (no edges in 3D), all upward and downward adjacencies (again, no edges in 3D), 2D/3D, full implementation
FMDB - Flexible distributed Mesh DataBase
More Information / Download
Seegyoung Seol, RPI Complete Supports all 2D/3D mesh topologies except septahedra, polygons, and polyhedra, all upward and downward adjacency, full implementation
More Information / Download
Xiaolin Li, SUNY SB Partial Supports triangles, quadrilaterals, tetrahedron, hexahedron, all downward adjacenies plus vertex to face upward adjacency, 2D/3D, partial implementation (set functionality incomplete)

Implementations of the ITAPS iGeom Interface

Software Name POC Status Distinguishing Characteristics
CGM Common Geometry Module
More Information / Download
Tim Tautges, ANL Complete  

Implementations of the ITAPS iRel Interface

Software Name POC Status Distinguishing Characteristics
More Information / Download
Tim Tautges, ANL Complete Supports relations for all Mesh/Geom Impls


Useful links:

  • The version control system Subversion
  • Babel is the foundation for a multilanguage scientific compoenent framework. The SIDL interfaces are compliant with version 1.4.0 of Babel available here. The Babel home page contains useful information on buidling and using the Babel tool
  • Autoconf is used to automatically configure software source code packages and is used to build all of our available implementations. We use Autopack v1.3.2

Building iMesh Executables

Building an iMesh executable requires that the compiler be able to find the ITAPS header files (e.g., iMesh.h and iBase.h, or their Fortran counterparts) and that the linker be able to find a library containing the iMesh implementation. By convention, iMesh implementations contain a makefile snippet that defines a standard set of variables; an application's makefile then includes this snippet, greatly simplifying the build process. An example makefile code snippet for building an ITAPS executable is shown below.

1 include /path/to/iMesh/
3 FC = gfortran -fcray-pointer -m32
4 CXX = g++
5 CC = gcc
7 FindConnectC: FindConnectC.o
8 $(CXX) $(CXXFLAGS) -o $@ FindConnectC.o ${IMESH_LIBS}
10 FindConnectF: FindConnectF.o
11 $(CXX) -m32 -lgfortran -lgfortranbegin -o $@ FindConnectF.o ${IMESH_LIBS}
13 .c.o:
14 $(CC) -c $(CFLAGS) $(IMESH_INCLUDES) $<
16 .F.o:
17 ${FC} -c ${FFLAGS} ${IMESH_INCLUDES} $<

Note that both executables are linked using the C++ linker to accommodate implementation libraries written in C++. The make variables IMESH_INCLUDES (used in lines 14 and 17) and IMESH_LIBS (using in lines 8 and 11) are defined in /path/to/iMesh/; these variables are of course implementation-dependent. An additional useful variable defined by convention in this file is IMESH_LIB_FILES, which identifies iMesh implementation library files, so that these can be used as dependencies in makefile targets.

Compliance Testing

To ensure that your implementations are working as expected we provide a compliance testing software tool suite. As you develop your interface wrappers, please check for code correctness to ensure you are interface compliant before attempting to link with an ITAPS service. If you have confirmed you are compliant with these tests, but still have a problem with the use of an ITAPS implementation or service, please contact the ITAPS POC.

The iMesh and iMeshP compliance test suite is available here.

Simple Examples

Simple examples and tutorial presentation materials for using the interface can be found here.