Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Due to the current gap in continued funding from the U.S. National Science Foundation (NSF), the NSF Unidata Program Center has temporarily paused most operations. See NSF Unidata Pause in Most Operations for details.
Russell K. Rew and Glenn P. Davis
The purpose of the Network Common Data Form (netCDF) data access library is to support the creation, access, and sharing of scientific data in a form that is self-describing and network-transparent. "Self-describing" means that a netCDF file includes information defining the data it contains. "Network-transparent" means that the data can be accessed by computers that have different representations for integers, characters, and floating-point numbers. The netCDF interface supports a variety of scientific data types, including point values, soundings, multidimensional grids, and images.
NetCDF software provides both C and FORTRAN interfaces for data access; either language interface may be used for reading or writing data stored using the other. The format of netCDF files is hidden beneath the netCDF interface; knowledge of the way netCDF data is represented is not needed by users. The format uses a standard, external data representation for bytes, integers, floating-point numbers, and data structures that ensures that two netCDF files created by the same netCDF calls on two different types of computer are the same. Hence, netCDF files can be written on one type of computer and read on another without explicit conversion.
The netCDF software has been successfully tested in various environments on different machine architectures. The software is being made freely available to encourage the sharing of both scientific data and the software that makes the data useful.
Below, we discuss the background and evolution of the netCDF interface, describe the data abstraction it supports, compare netCDF with other interfaces for scientific data access, discuss experiences with the use of netCDF software in meteorological applications, and discuss future plans for the netCDF software.
The netCDF software was created specifically to provide an interface between system software for capturing broadcast meteorological data and application software for analyzing and displaying the captured data. The netCDF software also helps solve two general problems that hinder the development of generic application software for the manipulation, analysis, and display of scientific data: machine-dependent, low-level representations for data and the absence of a suitable abstraction for accessing scientific data.
Low-Level Data Representation
Binary data written and read in a completely standard way on one machine architecture cannot necessarily be accessed by the same standard programs on another machine architecture, because both internal and external representations of various kinds of data are machine-dependent. Various approaches for dealing with this problem include:
There are advantages and drawbacks to each of these approaches. All but the last require that the detailed data formats must be known to programs that access the data. This makes it difficult to add more information or to change the format without changing all the programs that read the data The first approach is theoretically the most efficient of machine resources but can require as many as N(N+1)/2 converters for N different machine architectures. The software maintenance problems that result when a data structure must be changed make it impractical. Approaches 2, 3, and 4, by using a standard intermediate external form, require only 2N converters for each of N machine architectures. Approach 2 can require unacceptably more time and space than binary representations. Approach 3 requires an impractical amount of software if very many kinds of data objects are to be represented. NetCDF is an example of the fourth approach, in which both data and metadata (data describing the data) are included in a data file, using a standard machine-independent binary format.
Low-Level Access to Scientific Data
For most access to scientific data, the programmer must know enough about the structure of the data and its physical representation to be able to read or write data values of the right type in the correct order. In the commercial world, database systems provide access to data in a way that is independent of its physical representation. Thus, applications are immune to changes in the physical data representation, and different applications can be given different views of the same data. Although some success has been reported with the use of relational database management systems for small scientific data sets (Riggs 1987, Steinberg 1987), conventional database systems have not been widely used for accessing scientific data.
The essential problem seems to be the lack of an abstraction or model more appropriate for scientific data than the relation abstraction used as the basis for current database systems. A better model for scientific data would support accessing data variables by name, associating descriptive information with variables, accessing cross-sections of multidimensional data, the use of coordinate systems, and the representation of implicit relations among the elements of multidimensional arrays.
Development of the netCDF Interface
The development of netCDF began because Unidata needed a common interface between ingested real-time meteorological data and Unidata applications. We wanted an interface that would support the abstractions of multidimensional, named variables with descriptive attributes and that would use an external data representation that was machine-independent and thus network-compatible. We also wanted support for random access to data, so that applications could efficiently access small portions of large data files, and an interface for both C and FORTRAN under both UNIX and VMS operating systems.
We searched for existing software to meet all these requirements and found none. However, the Common Data Format (CDF) software developed at the NASA Goddard National Space Science Data Center (NSSDC) came close (Treinish and Gough 1987). It only lacked a machine-independent external data representation, a C binding, a UNIX implementation, and a mechanism to access aggregates of data with a single call.
As the result of a Unidata workshop in August 1988, we specified a Unidata netCDF interface that incorporated ideas from the SeaSpace implementation of an extended CDF interface (Fahle 1988); from the NSSDC CDF; and from Candis (Raymond 1988), an independently developed, UNIX-based package of C software that supported self-describing multidimensional scientific data.
To achieve network-transparency, the netCDF was implemented on top of XDR, a layer of software for external data representation. XDR was developed by Sun Microsystems and is a nonproprietary standard for describing and encoding data. It supports encoding arbitrary C data structures into machine-independent sequences of bits. The encoding used for floating-point numbers is the Institute for Electrical and Electronics Engineers standard for normalized floating-point numbers. XDR has been implemented on a wide variety of computers, including SUNs, VAXs, Apple Macintoshes, IBM-PCs, IBM mainframes, and CRAYs. It assumes only that 8-bit bytes can be encoded and decoded in a consistent way.
In implementing the netCDF, we minimized storage overhead. As a typical example, a netCDF file containing NMC model outputs for pressure at maximum wind on a global grid of 73 latitudes, 73 longitudes, and eight forecast times, along with metadata identifying the reference time, forecast times, latitude and longitude coordinates, and other information contained in the GRIB products has a storage overhead of about 1.5% over the space required to store the floating-point values of the pressures.
The netCDF software implements an abstract data type, which means that all operations to access and manipulate data in a netCDF file must use only the set of functions provided by the interface. The interface comprises 28 functions in C for creating, opening, reading, writing, declaring components of, inquiring about components of, and closing netCDF files. The same capabilities are supported by 34 FORTRAN routines.
The components of a netCDF file are its dimensions, variables, and attributes. These components can be used together to capture the meaning of data and relations among data fields in a scientific data set.
Dimensions
A netCDF dimension is a named integer used to specify the shape (i.e., dimensionality) of one or more of the multidimensional variables contained in a netCDF file. A dimension may be used to represent a real physical dimension, such as time, latitude, longitude, or height It might also be used to index more abstract quantities: color-table entry or station-time pair, for example.
Every netCDF dimension has both a name and a size. A dimension name is an arbitrary sequence of alphanumeric characters beginning with a letter. A dimension size is an arbitrary positive integer, except that one dimension in a netCDF file can have an unlimited size. Such a dimension is called the unlimited dimension or the record dimension. A variable with an unlimited dimension can grow to any length along that dimension. The unlimited dimension is like a record number in conventional record-oriented files.
NetCDF dimensions are used to specify the shapes of netCDF variables, to identify and relate variables that are defined on a common grid, and to provide a natural way to define coordinate systems.
Variables
A netCDF variable represents an array of values of the same type. Variables are used to store the bulk of the data in a netCDF file. A variable has a name, a data type, and a shape described by its list of dimensions, all of which are specified when the variable is created. It is possible to define netCDF variables with no dimensions, also called scalar variables. Besides a name, type, and shape, each variable may also have data values and any number of attributes, which may be added or changed after the variable is created.
Attributes
A netCDF attribute is intended to represent information about a netCDF variable or about an entire netCDF file. This information is analogous to the metadata stored in data dictionaries and schema in conventional database systems. An attribute has an associated variable, a name, a data type, a length, and a value or values. Individual variable attributes are identified by specifying the variable and an attribute name. Conventional names for commonly used variable attributes include "units", "long_name," "valid_range," and "missing_value." Other attributes may be used to: tag the quality of data; specify a format to use when tabulating data; specify a scale and offset for low-resolution, floating-point data stored as bytes or short integers; provide information about instruments or calibrations associated with the data;or annotate the data in any other way desired.
When an attribute is created, it is associated with a single variable. Attributes for different variables may differ in data type, length, and values, even though they share the same name. For example, "valid_range" should be an integer 2-vector for an integer variable but a floating-point 2-vector for a floating-point variable.
A global attribute is one that applies to a whole netCDF file rather than a particular variable. Conventional global attributes include "title" and "history." Global attributes are defined and accessed similarly to variable attributes.
Typically, the data in variables of an open netCDF file will reside on disk, because the data may be too large to fit in memory all at once. The metadata associated with a netCDF file is typically small enough to be memory-resident.
Primitive netCDF Data Types
There are six primitive netCDF data types: byte (eight bits), character (eight bits), short integer (16 bits), long integer (32 bits), floating-point (32 bits), or double-precision floating-point (64 bits). The number of bits specified for each type is the number of bits used in its external data representation; the internal representation is appropriate to the machine on which the netCDF library is used. The type used to represent variable data depends on the range of values of the data and the precision to which values are known. Bytes and characters are almost the same: byte arrays represent data, such as images, in which a full eight bits are required for each value; character arrays represent text strings.
These types were chosen, because they are familiar to C and FORTRAN programmers, they have well-defined external representations independent of any particular computers, and they are sufficient for providing a reasonably wide range of trade-offs between data precision and number of bits required for each datum.
Additional primitive types may be added in the future in a way that is compatible with existing programs and files. For example, a hyperlong type for 64-bit integers will eventually be needed, along with a new type for multibyte characters. These can both be added without affecting existing netCDF files or applications and with only minor changes required for the generic applications that will use them.
Forms of Data Access
The netCDF interface supports direct (random) access to single data values, direct access to arbitrary cross-sections of data for a single variable, and record-oriented access to data for a single variable in an open netCDF file.
To directly access a single data value, one specifies a netCDF file, a variable, and a multidimensional index for the variable. Files are specified not by name but by a netCDF ID--a small integer obtained when the file was created or opened. Similarly, variables are specified not by name, but by variable IDs--small integers used to identify variables in a netCDF file.
Data in a netCDF file can also be accessed as aggregates of values called hyperslabs. A hyperslab is a generalized rectangular piece of a multidimensional variable that is specified by giving the indices of the starting corner point and a list of edge lengths along each of the dimensions of the variable. The block of data values returned (or written) has the rightmost dimension of the variable varying fastest in the C interface. For FORTRAN, the order is reversed, with the leftmost dimension of the variable varying fastest. These ordering conventions correspond to the customary order in which multidimensional variables are stored in C and FORTRAN. The different dimension orders for the C and FORTRAN interfaces do not reflect a different order for values stored in the netCDF file but merely different orders supported by the procedural interfaces to the two languages. As a result, netCDF files written by programs in one language may be read by programs written in the other.
Conventional record-oriented data access is possible whenever a record dimension is defined, by using the index of the record dimension as a record number. The record dimension is treated exactly like other dimensions for netCDF data access, except that it has no upper bound.
An Example
At Unidata, we capture the forecast grids from the National Meteorological Center (NMC), which are broadcast in GRIB format (Stackpole 1989), and decode them into netCDF files. Examples of the dimensions, variables, and attributes used in one such file will help to make the netCDF abstraction more concrete.
The example file stores U and V wind components from the NMC global product set. These are broadcast as four separate latitude/longitude grids that overlap at the equator and along the 0- and 180-degree longitudes, but we stitch the grids together into one global grid in the netCDF file.
The file uses six netCDF dimensions: latitude, longitude, forecast time, standard atmospheric level, a character-string index, and a reference-time index. The names and sizes of these six dimensions in the example file are:
| Dimension | Size |
|---|---|
lat | 73 |
lon | 73 |
frtime | 10 |
level | 10 |
name_len | 80 |
rtime | unlimited |
The unlimited dimension, rtime, is used as a record number, in
case we want to store data for multiple reference times in the same netCDF
file. The name_len dimension is a maximum string length for
each character-valued variable.
There are fifteen netCDF variables of various types and shapes. Four of them
are variables with the same names as the dimensions (lat,
lon, frtime, and level),and they give
the coordinate values along these dimensions. Seven of the variables use the
record dimension rtime and, hence, may vary from
record-to-record. Here are declarations of the type, name, and shape of the
netCDF variab1es:
float u_wind (rtime, frtime, level, lat, lon) float v_wind (rtime, frtime, level, lat, lon) float lat (lat) float lon (lon) int frtime (frtime) float level (level) int year (rtime) int month (rtime) int day (rtime) int hour (rtime) int minute (rtime) int grib_center int grib_model char center_name (name_len) char model_name (name_len)
NetCDF attributes specified for all variables include their units and long
names. The u_wind and v_wind variables also have a
valid range attribute. Two global attributes for the file are
title and history. Here are values for the global
attributes and a few of the variable attributes:
:history = "created by LDM2 from NPS broadcast" :title = "NMC Global Product Set: Wind Component" u_wind:long_name ="eastward wind component" u_wind:units ="m/sec~ u_wind: valid_range = -500., 500. lat:long_name ="latitude" lat :units ="degrees N" frtime:long_name ="forecast time" frtime:units ="hours" level: long_name = "level" level: units = "mb"
Data values for the four coordinate variables lon,
lat, frtime, and level, are included
in the netCDF file:
lon = -180., -175., -170., ..., 180. lat = -90., -87.5., -85., ..., 90. frtime = 0, 6, 12, ..., 60 level = 1000., 850., 700., ..., 100.
The bulk of the data is stored in the five-dimensional variables
u_wind and v_wind. With a single netCDF hyperslab
read, a contouring application can open the resulting file to access a
latitude/longitude subgrid at a specified reference time, level, and
forecast time. Other cross-sections of the data can be accessed as easily.
BUFR
BUFR (ECMWF 1988) is a compact, flexible, machine-independent format for self-defining data It has been approved by a commission of the World Meteorological Organization as a standard (FM94BUFR) for interchanging and transmitting meteorological and oceanographic data. It relies on a centralized registry of data types and tables to make data self-defining. BUFR data contains embedded references to these registered standard data structures and tables. Universal BUFR decoders have been written, implementing the conversion of BUFR data to native integer and floating-point numbers for subsequent manipulation, analysis, and display.
Although BUFR and netCDF have some superficial similarities, we have concluded that BUFR is better for data transmission and that netCDF is more suitable for data access. We plan to implement a BUFR-to-netCDF decoder to take advantage of the complementary advantages of BUFR and netCDF for transmission and access.
Forms like BUFR are not necessarily well-suited to the kinds of data access needed for analysis and display applications. For example, data compression is important in data interchange and transmission but will conflict with the convenient use of floating-point values, random access to data subsets, and self-contained data description. BUFR emphasizes the physical data format of data objects, whereas netCDF gives prominence to the program interface for reading and writing the data, even though it also specifies an underlying physical structure.
When we learned about BUFR, we considered using it either instead of netCDF or as a replacement for XDR in the physical representation of netCDF data. Both uses turned out to be impractical. For example, a netCDF-to-BUFR converter will always lose information, although expanding BUFR data to netCDF form is quite practical. BUFR does not provide a mechanism for including names or other variable-length, character-string values. BUFR depends on a centralized registry of data types out of which larger BUFR data structures are constructed, so that a netCDF variable for which the type was not already registered could not be stored.
We believe it will not be possible to anticipate and preregister all the kinds of data that will be needed for building data structures useful among distributed applications for analysis and display. NetCDF is built instead on the assumption that we can anticipate a sufficient set of data access primitives for such uses. With netCDF, one can create and use ad hoc scientific data types with whatever new units and descriptive attributes are necessary.
Candis
Dave Raymond (New Mexico Institute of Mining and Technology) independently developed a package of C software for UNIX, called Candis (Raymond 1988). Candis supports self-describing scientific data and has a modular "pipes and filters" approach to processing, analyzing, and displaying scientific data. We incorporated some ideas from Candis, such as using named dimensions and variables with differing shapes in a single data object, into the Unidata netCDF interface.
The main difference between Candis and netCDF is that Candis is based on sequential access, whereas netCDF is a random-access interface. Random access permits accessing small parts of large files without reading through all of the data, but sequential access allows use of the UNIX model of pipes and filters, in which the input of one program is connected to the output of another program without using intermediate files. Candis is only available for UNIX systems; netCDF is supported on both UNIX and VMS, as well as other operating systems. Candis variables are limited to four dimensions; netCDF variables can have 32 dimensions. Candis is only intended for floating-point data; netCDF supports byte, character, and integer data, as well. Candis provides a C program interface; netCDF provides both C and FORTRAN interfaces. Candis uses ASCII for a portable external data representation of Candis files; netCDF uses Sun's XDR, instead. There is an extensive set of data manipulation, analysis, and display utilities available for use with the Candis interface; netCDF currently has only a very limited set of utilities. Dave Raymond has written programs that convert between netCDF and Candis formats, so that it is possible to take advantage of Candis utilities on netCDF files.
CDF
The NSSDC CDF (Gough 1988) was developed as a FORTRAN library for VAX/VMS systems to support an abstraction for storing multidimensional scientific data. It has been used for many different kinds of data and supports an extensive collection of analysis and display applications. It has the virtues of simplicity (only 13 subroutines), independence from storage format, generality, and support for generic applications.
There are significant differences between the NSSDC CDF and netCDF: the CDF does not use a machine-independent, external representation for data; the data abstraction supported by CDF numbers dimensions rather than naming them; there is no aggregate access to values in CDF, such as the hyperslab access provided by netCDF; and CDF uses a multifile implementation for a CDF dataset, where a netCDF dataset is represented in a single file. At present, however, there are much more data archived in CDF format, there are more utilities and applications available for CDF format than for netCDF, and CDF supports more efficient dynamic addition of variables and attributes to an existing CDF file.
The National Center for Supercomputing Applications has developed and made freely available their Hierarchical Data Format (HDF) software. HDF is an extensible data format for self-describing files. There is a substantial set of applications and utilities available based on HDF; these support raster-image manipulation and display and browsing through multidimensional scientific data. The HDF software includes a package of routines for accessing each HDF datatype, as well as a lower-level interface for building packages to support new types. HDF supports both C and FORTRAN interfaces, and it has been successfully ported to a wide variety of machine architectures and operating systems. Although HDF files are not machine-independent, the format in which numbers are represented is included as part of numeric data descriptors, so that conversion programs are possible.
Like BUFR, HDF depends on a centralized registry of basic data tags, but the HDF tags designate fundamental data types needed in application programs, rather than the more specific meteorological and oceanographic types defined in the BUFR tables. The NCSA group that maintains and enhances HDF software has studied the Unidata netCDF documentation and decided to support the netCDF interface for scientific data access, provided they can implement it on top of the basic HDF layer. We believe this is both desirable and practical. Such an implementation will eventually permit applications software written using either the netCDF or HDF Scientific Data Set interfaces to be shared among both communities of users.
The netCDF C interface has been compiled and tested successfully on a Sun 3 and SPARCstation under SunOS, a DEC VAX under VMS, a DEC VAX and DECstation 3100 under Ultrix, an Apple Macintosh II under MacOS, a Compaq 80386 under 386-ix, a NeXT under MACH, and a Cray XMP under UNICOS. Since there is no standard for FORTRAN to C interfaces, the set of FORTRAN jackets that provide the FORTRAN interface on top of the C library varies for each machine architecture and set of compilers. Consequently, the FORTRAN interface has so far only been tested successfully on a Sun 3 and SPARCstation under SunOS, a DEC VAX under VMS, a DEC VAX under Ultrix, and 8 DECstation 3100 under Ultrix.
We have adapted Unidata's local-data-capture software and Purdue's WXP analysis-and-display software to use the netCDF interface. The NMC forecast grids that are transmitted as part of the National Weather Service Numerical Products Service broadcast are decoded on-line from GRIB data and written as netCDF files. Surface and upper-air data from the NWS Domestic Data Plus service is captured as text and later decoded into hourly netCDF files on demand or according to an hourly schedule. We have adapted the WXP display programs to read the netCDF input and have noticed an improvement in performance over the previous data access methods, both on Sun/SunOS and VAX/VMS systems. The WXP objective analysis programs use current surface or upper-air netCDF data as input and produce analyzed data on grids in the form of a netCDF file as output. A Unidata program that contours NMC forecast grids on arbitrary map projections expects a netCDF input file.
Other groups have begun using the Unidata netCDF interface since we made it available early in 1989. The Satellite Remote-Sensing Group at the University of Miami has written software to convert a customized storage format for DSP images to and from netCDF files and to objectively analyze satellite imagery and drifting-buoy data using netCDF files as input. Other groups who have begun to use the netCDF interface include two groups at NCAR, a group at Purdue University, and a development group within Apple Computer, Inc. Two groups within NASA are considering the use of netCDF software.
Several aspects of our experience at Unidata with using netCDF in application programs are worthy of note.
When efficiency was of paramount concern, we had to become aware of the order in which netCDF data was written on the disk, since the best I/O performance is achieved by reading or writing contiguous data. All variable data are ordered with the rightmost dimension for each variable varying fastest in the C interface or slowest in the FORTRAN interface. Hence, the order in which data are most commonly accessed should determine the order of the dimensions that define the shape of a variable, in order to avoid needless inefficiency. We found that netCDF access is I/O-bound rather than compute-bound, even when the conversion to or from XDR was nontrivial.
We have been able to run applications on a VAX using data captured on a Sun (or vice-versa), without any kind of explicit conversion. This makes software development, testing, and use in a distributed and heterogeneous environment almost seamless: the network becomes transparent, and knowing where data came from or what format it uses is interesting but unnecessary. We have also been able to tailor the structure of the data in a netCDF file by editing an ASCII description of its structure. Instead of changing and recompiling programs, we use netCDF utilities that convert between a netCDF file and its ASCII description. For example, when we decided to combine the periodic decoding and capture of U and V components of wind speed at various levels and forecast times into a single netCDF file, we did not have to change any source code. Since the two original netCDF files were self-describing, we just merged the descriptions into one and everything worked.
The netCDF software does have some weaknesses, which are primarily caused by trade-offs between efficiency and convenience of access. Specifically, the netCDF representation of data is not as compact as special-purpose formats for particular datasets or formats like BUFR, which are designed for data transmission and exchange. For example, the NMC grid data is typically expanded by a factor of four when it is decoded into netCDF files, because it is decoded into native floating-point instead of scaled and biased integers packed into the minimum number of bits. While compression is possible for 10w-resolution data by using, for example, eight-bit bytes instead of 32-bit floating-point numbers, the netCDF was not designed to achieve optimal compression. The advantages of a special-purpose archive formats for small archives should be compared to the benefits of machine-independence, the ability to store metadata, and the ability to directly access cross-sections of the data that the netCDF interface provides.
NetCDF is not a database system for scientific data. Although it provides a higher--and we feel more useful--level of abstraction than physical data formats, there is no way to index data by value or retrieve data by queries relating to data values. Some of these facilities can be built on top of the netCDF interface, but they do not exist now.
Translating data into and out of XDR form adds overhead to data transfers, but, for many applications, the extra CPU cycles used to convert data to and from a machine-independent representation are not significant. The amount of XDR overhead depends on many factors, including the data type, the type of computer, the granularity of data access, and how well the implementation has been tuned to the computer on which it is run. For the applications we have encountered, the overhead of the XDR layer is a reasonable price to pay for portable, network-transparent data access.
If one of the strengths of the netCDF interface is its independence from a centralized registry of data types, the lack of a comprehensive and uniform set of conventions for variab1e names, units, and attributes is also one of its weaknesses. The existence of such a set of conventions would make writing generic applications easier, and it would aid in the development of a hierarchy of types for netCDF variables that would support a corresponding hierarchy of netCDF operators.
We plan to have a collection of netCDF operators made available that provides an algebra of useful operations on generic scientific data stored in netCDF files. These include selectors that will extract subsets of variables or reduce the dimensionality of a netCDF file; constructors that will merge netCDF files, combine variables, or increase dimensionality; graphics generators that read netCDF files and produce graphical output; mathematical operators for algebraic operations, partial derivatives, statistics, smoothing, and mapping to different grids; and specialized data converters to convert units, to convert to or from standard archive forms (like GRIB and BUFR), or to convert to a canonical form for comparisons. By composing these fundamental operators, users will have a wide variety of capabilities.
We plan to extend the netCDF library in an upward-compatible way to support netCDF servers on a network Applications programs, as clients of the netCDF servers, will be able to access cross-sections of data efficiently, as if it were stored in a local file. A netCDF server will have the ability to support virtual netCDF objects that provide different views of large or remote datasets . Other servers may also be capable of transparently providing a netCDF interface to non-netCDF archives.
The current version of netCDF software is available using anonymous FTP. The
software distribution includes source for all netCDF software as well as
instructions for porting the netCDF software to a new system. Test programs
are included to test the XDR implementation, the netCDF library, the FORTRAN
jackets, and the netCDF utilities For UNIX systems, a compressed tar file
can be accessed (in binary mode) from the file netcdf.tar.Z in
the anonymous FTP directory of unidata.ucar.edu. VMS sites can
get a backup saveset of the same software from the anonymous directory of
laurel.ucar.edu. The software distribution includes a
PostScript file of the netCDF User's Guide. A printed copy of the User's
Guide may be obtained from the Unidata Program Center.
References:
European Centre for Medium-Range Weather Forecasts, 1988: Binary universal form for data representation. FM 94 BUFR Collected papers and specification. ECMWF, February.
Fahle, Joseph, 1989: TeraScan Applications Programming Interface. SeaSpace, San Diego, California.
Fulker, DavidW., 1989: Seminal software to analyze and manage geoscientific information. Preprint Volume, Fifth International Conf. for Meteor., Ocean., and Hydrology, Anaheim, CA, Amer. Meteor. Soc.
Gough, Michael L., 1988: NSSDC CDF Implementer's Guide (DEC VAX/VMS) Version 1.1. National Space Science Data Center, 88-17, NASA/Goddard Space Flight Center.
Raymond, David J., 1988: A C language-based modular system for analyzing and displaying gridded numerical data. J. Atmos.Oceanic Tech., 5, 501-511.
Riggs, Simon, 1987. Use of the R-EXEC Database Management System: Manipulation of the PULSARS Data File. RAL-87-104, SERC Rutherford Appleton Laboratory, UK, November.
Stackpole, John D., 1989: GRIB, The WMO Format for the Storage of Weather Product Information and the Exchange of Weather Product Messages in Gridded Binary Form. National Weather Service, National Meteorological Center.
Steinberg, Carol J., 1987: Data retrieval in a distributed telemetry ground data system. Data Engineering, 10, 53-59.
Treinish, L. A. and M. L. Gough, 1987: A software package for the data independent management of multidimensional data. EOS Transactions, Am. Geophys. U., 68, 633-635.
