Download Software

Download software | Getting Started | ITAPS Data Model | Interface Software | Services Software | Tutorial Materials | Usage Strategies

ITAPS Interfaces: Previously Released Version 1.1

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

 

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.

 

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/iMesh-Defs.inc
2
3 FC = gfortran -fcray-pointer -m32
4 CXX = g++
5 CC = gcc
6
7 FindConnectC: FindConnectC.o
8      $(CXX) $(CXXFLAGS) -o $@ FindConnectC.o ${IMESH_LIBS}
9
10 FindConnectF: FindConnectF.o
11     $(CXX) -m32 -lgfortran -lgfortranbegin -o $@ FindConnectF.o ${IMESH_LIBS}
12
13 .c.o:
14     $(CC) -c $(CFLAGS) $(IMESH_INCLUDES) $<
15
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/iMesh-Defs.inc; 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.