Object Libraries, Executables, and Supported Machines/OS's

Please read the copyright, licensing, and acknowledgements page: The I/O API library is available under the Lesser Gnu Public License, version 2.1; the "tool" and example programs are available under the Gnu Public License, version 2.

The current release version of the I/O API library is Version 3.2. Version 4.0 is in beta. Versions 3.0 and 3.1 in maintenance only release mode, and versions 2.2 and 2.1 are available for historic interest. To download source for these, please go to the I/O API Download Page.

Release Version 3.0, 3.1, 3.2 of the I/O API and the I/O -related tool and sample programs, as well as obsolete prior versions 2.1 and 2.2, are available here on the CMAS Center web site:

ioapi-3.2.tar.gz
ioapi-3.1.tar.gz
ioapi-3.0.tar.gz
ioapi-2.2.tar.gz
ioapi-2.1.tar.gz
in source code form. Versions 3.2 and 4.0 also available from GitHub, using the following command: 
    git clone https://github.com/cjcoats/ioapi-3.2
or 
    git clone https://github.com/cjcoats/ioapi-3.2 -b ioapi-4.0 ioapi-4.0
New features of 2.2 and later releases are documented here in the I/O API Change Log; build instructions are in the I/O API Availability/Downlsoad/Build Document.

For each supported architecture, there are several relevant archive libraries of compiled object files:

libioapi.a
contains object files for the I/O API (both public and private routines), the coordinate and grid manipulation routines , the date and time manipulation routines , and the utility routines.
libnetcdf.a (and libnetcdff.a for netCDF-4.1 or later)
contains object files for the underlying netCDF library; it is compiled with optimization on (typically at optimization level -O2).
Note that netCDF-4 requires additional (installation dependent) libraries
libpnetcdf.a
if you are building with PnetCDF/MPI distributed I/O enabled (e.g., for CMAQ).
libpvm3.a
contains object files for the underlying PVM library: if you build with I/O API Coupling Mode enabled.

Note that optimized and debug versions of the libraries are normally built into distinct build-directories each with its own $BIN (e.g., Linux2_x86_64ifort vs Linux2_x86_64ifortdbg); you should segregate profiling-enabled, global;-climate, and distributed-I/O (etc.) libraries similarly. If you call I/O API routines, you will need both libioapi.a and libnetcdf.a (and, for netCDF-4, libnetcdff.a; these are normally copied into the relevant build-directory); if you build with PnetCDF/MPI distributed I/O enabled, you will need libpnetcdf.a; if you build with coupling mode enabled, you will also need libpvm3.a. If you call only coordinate and grid or date and time manipulation routines or utility routines, you will just need libioapi.a.

I/O API Version 3.x libraries have build support for C and Fortran-90 compilers only (but not Fortran-77), on the following hardware/operating-system/compiler-set/compiler-option platforms referred to by environment variable $BIN. Note that supporting additional platforms generally is quite easy, following the pattern of these existing builds, as found in the ioapi/Makeinclude.$BIN configuration files:

Linux2_x86_64* NOTE: Most "64-bit" Linux compilers default to the so-called "64-bit-small" memory model, which limits individual arrays, COMMON blocks, and initialized data to less than 2 GB, unless you override this by compile-flags.
Exceptions are the Sun compilers and g95, which default to medium memory model, which supports huge arrays and huge COMMON blocks (but not huge machine-code surbroutines). Note that for various other compilers, there are explicitly medium-memory-model configurations, which should be kept separate from the "normal" small-memory-model versions. See this note for more info

The libraries have in the past been compiled for a number of platforms (some of which are noted above), but the machines used for building these no longer are available to compile and build the latest versions of the libraries. It should be a simple task to build versions of the libioapi.a and libnetcdf.a archive libraries on most UNIX/Linux workstations--at least, those with Feldman-descended Fortran compilers.

For C programmers: Further note that since most of the .c library routines use/are C wrappers around Fortran code, you need to use cc -c to build ".o" files for your program, and then use the relevant Fortran compiler, as appropriate, to invoke the linker (since f90 knows how to link in the Fortran run-time libraries but cc doesn't), as in the following example which builds SunOS5 program "qux" from "qux.c": 


    setenv LIB /env/apps/SunOS5/lib             #  library directory
    cc -c qux.c                                 #  produces qux.o

    f90 -o qux qux.o -L${LIB} -lioapi -lnetcdf  #  linking step

Previous: Data Types

Next: Public INCLUDE Files

To: Models-3/EDSS I/O API: The Help Pages