mirror of
https://github.com/Unidata/netcdf-c.git
synced 2024-11-27 07:30:33 +08:00
374 lines
15 KiB
Groff
374 lines
15 KiB
Groff
|
.\" $Header: /upc/share/CVS/netcdf-3/ncgen3/ncgen3.1,v 1.1 2009/09/24 18:19:10 dmh Exp $
|
||
|
.TH NCGEN3 1 "$Date: 2009/09/24 18:19:10 $" "Printed: \n(yr-\n(mo-\n(dy" "UNIDATA UTILITIES"
|
||
|
.SH NAME
|
||
|
ncgen3 \- From a CDL file generate a netCDF classic or 64 bit classicfile,
|
||
|
a C program, or a Fortran program
|
||
|
.SH SYNOPSIS
|
||
|
.HP
|
||
|
ncgen3
|
||
|
.nh
|
||
|
\%[-b]
|
||
|
\%[-c]
|
||
|
\%[-f]
|
||
|
\%[-k \fIkind_of_file\fP]
|
||
|
\%[-x]
|
||
|
\%[-n]
|
||
|
\%[-o \fInetcdf_filename\fP]
|
||
|
\%\fIinput_file\fP
|
||
|
.hy
|
||
|
.ft
|
||
|
.SH DESCRIPTION
|
||
|
\fBncgen3\fP generates either a netCDF file, or C or Fortran source code to
|
||
|
create a netCDF file. The input to \fBncgen3\fP is a description of a netCDF
|
||
|
file in a small language known as CDL (network Common Data form Language),
|
||
|
described below.
|
||
|
If no options are specified in invoking \fBncgen3\fP, it merely checks the
|
||
|
syntax of the input CDL file, producing error messages for
|
||
|
any violations of CDL syntax. Other options can be used to create the
|
||
|
corresponding netCDF file, to generate a C program that uses the netCDF C
|
||
|
interface to create the netCDF file, or to generate a Fortran program that
|
||
|
uses the netCDF Fortran interface to create the same netCDF file.
|
||
|
.LP
|
||
|
\fBncgen3\fP may be used with the companion program \fBncdump\fP to perform
|
||
|
some simple operations on netCDF files. For example, to rename a dimension
|
||
|
in a netCDF file, use \fBncdump\fP to get a CDL version of the netCDF file,
|
||
|
edit the CDL file to change the name of the dimensions, and use \fBncgen3\fP
|
||
|
to generate the corresponding netCDF file from the edited CDL file.
|
||
|
.SH OPTIONS
|
||
|
.IP "\fB-b\fP"
|
||
|
Create a (binary) netCDF file. If the \fB-o\fP option is absent, a default
|
||
|
file name will be constructed from the netCDF name (specified after the
|
||
|
\fBnetcdf\fP keyword in the input) by appending the `.nc' extension. If a
|
||
|
file already exists with the specified name, it will be overwritten.
|
||
|
.IP "\fB-c\fP"
|
||
|
Generate
|
||
|
.B C
|
||
|
source code that will create a netCDF file
|
||
|
matching the netCDF specification. The C source code is written to
|
||
|
standard output.
|
||
|
.IP "\fB-f\fP"
|
||
|
Generate
|
||
|
.B Fortran
|
||
|
source code that will create a netCDF file
|
||
|
matching the netCDF specification. The Fortran source code is written
|
||
|
to standard output.
|
||
|
.IP "\fB-o\fP \fRnetcdf_file\fP"
|
||
|
Name for the binary netCDF file created. If this option is specified, it implies
|
||
|
the "\fB-b\fP" option. (This option is necessary because netCDF files
|
||
|
cannot be written directly to standard output, since standard output is not
|
||
|
seekable.)
|
||
|
.IP "\fB-k \fRkind_of_file\fP"
|
||
|
Using -k2 or -k "64-bit offset" specifies that
|
||
|
generated file (or program) should use version 2 of format that
|
||
|
employs 64-bit file offsets. The default is to use version 1
|
||
|
("classic") format with 32-bit file offsets, although this limits the
|
||
|
size of the netCDF file, variables, and records to the sizes supported
|
||
|
by the classic format. (NetCDF-4 will support additional kinds of
|
||
|
netCDF files, "netCDF-4" and "netCDF-4 classic model".)
|
||
|
Note: -v is also accepted to mean the same thing as
|
||
|
-k for backward compatibility, but -k is preferred, to match
|
||
|
the corresponding ncdump option.
|
||
|
.IP "\fB-x\fP"
|
||
|
Don't initialize data with fill values. This can speed up creation of
|
||
|
large netCDF files greatly, but later attempts to read unwritten data
|
||
|
from the generated file will not be easily detectable.
|
||
|
.SH EXAMPLES
|
||
|
.LP
|
||
|
Check the syntax of the CDL file `\fBfoo.cdl\fP':
|
||
|
.RS
|
||
|
.HP
|
||
|
ncgen3 foo.cdl
|
||
|
.RE
|
||
|
.LP
|
||
|
From the CDL file `\fBfoo.cdl\fP', generate an equivalent binary netCDF file
|
||
|
named `\fBx.nc\fP':
|
||
|
.RS
|
||
|
.HP
|
||
|
ncgen3 -o x.nc foo.cdl
|
||
|
.RE
|
||
|
.LP
|
||
|
From the CDL file `\fBfoo.cdl\fP', generate a C program containing the
|
||
|
netCDF function invocations necessary to create an equivalent binary netCDF
|
||
|
file named `\fBx.nc\fP':
|
||
|
.RS
|
||
|
.HP
|
||
|
ncgen3 -c -o x.nc foo.cdl
|
||
|
.RE
|
||
|
.LP
|
||
|
.SH USAGE
|
||
|
.SS "CDL Syntax Summary"
|
||
|
.LP
|
||
|
Below is an example of CDL syntax, describing a netCDF file with several
|
||
|
named dimensions (lat, lon, and time), variables (Z, t, p, rh, lat, lon,
|
||
|
time), variable attributes (units, long_name, valid_range, _FillValue), and
|
||
|
some data. CDL keywords are in boldface. (This example is intended to
|
||
|
illustrate the syntax; a real CDL file would have a more complete set of
|
||
|
attributes so that the data would be more completely self-describing.)
|
||
|
|
||
|
.RS
|
||
|
.nf
|
||
|
\fBnetcdf\fP foo { // an example netCDF specification in CDL
|
||
|
|
||
|
\fBdimensions\fP:
|
||
|
lat = 10, lon = 5, time = \fBunlimited\fP ;
|
||
|
|
||
|
\fBvariables\fP:
|
||
|
\fBlong\fP lat(lat), lon(lon), time(time);
|
||
|
\fBfloat\fP Z(time,lat,lon), t(time,lat,lon);
|
||
|
\fBdouble\fP p(time,lat,lon);
|
||
|
\fBlong\fP rh(time,lat,lon);
|
||
|
|
||
|
// variable attributes
|
||
|
lat:long_name = "latitude";
|
||
|
lat:units = "degrees_north";
|
||
|
lon:long_name = "longitude";
|
||
|
lon:units = "degrees_east";
|
||
|
time:units = "seconds since 1992-1-1 00:00:00";
|
||
|
Z:units = "geopotential meters";
|
||
|
Z:valid_range = 0., 5000.;
|
||
|
p:_FillValue = -9999.;
|
||
|
rh:_FillValue = -1;
|
||
|
|
||
|
\fBdata\fP:
|
||
|
lat = 0, 10, 20, 30, 40, 50, 60, 70, 80, 90;
|
||
|
lon = -140, -118, -96, -84, -52;
|
||
|
}
|
||
|
.fi
|
||
|
.RE
|
||
|
.LP
|
||
|
All CDL statements are terminated by a semicolon. Spaces, tabs,
|
||
|
and newlines can be used freely for readability.
|
||
|
Comments may follow the characters `//' on any line.
|
||
|
.LP
|
||
|
A CDL description consists of three optional parts: \fIdimensions\fP,
|
||
|
\fIvariables\fP, and \fIdata\fP, beginning with the keyword
|
||
|
.BR dimensions: ,
|
||
|
.BR variables: ,
|
||
|
and
|
||
|
.BR data ,
|
||
|
respectively.
|
||
|
The variable part may contain \fIvariable
|
||
|
declarations\fP and \fIattribute assignments\fP.
|
||
|
.LP
|
||
|
A netCDF \fIdimension\fP is used to define the shape of one or more of the
|
||
|
multidimensional variables contained in the netCDF file. A netCDF
|
||
|
dimension has a name and a size. At most one dimension in a netCDF file
|
||
|
can have the \fBunlimited\fP size, which means a variable using this
|
||
|
dimension can grow to any length (like a record number in a file).
|
||
|
.LP
|
||
|
A \fIvariable\fP represents a multidimensional array of values of the
|
||
|
same type. A variable has a name, a data type, and a shape described
|
||
|
by its list of dimensions. Each variable may also have associated
|
||
|
\fIattributes\fP (see below) as well as data values. The name, data
|
||
|
type, and shape of a variable are specified by its declaration in the
|
||
|
\fIvariable\fP section of a CDL description. A variable may have the same
|
||
|
name as a dimension; by convention such a variable is one-dimensional
|
||
|
and contains coordinates of the dimension it names. Dimensions need
|
||
|
not have corresponding variables.
|
||
|
.LP
|
||
|
A netCDF \fIattribute\fP contains information about a netCDF variable or
|
||
|
about the whole netCDF dataset. Attributes are used
|
||
|
to specify such properties as units, special values, maximum and
|
||
|
minimum valid values, scaling factors, offsets, and parameters. Attribute
|
||
|
information is represented by single values or arrays of values. For
|
||
|
example, "units" is an attribute represented by a character array such
|
||
|
as "celsius". An attribute has an associated variable, a name,
|
||
|
a data type, a length, and a value. In contrast to variables that are
|
||
|
intended for data, attributes are intended for metadata (data about
|
||
|
data).
|
||
|
.LP
|
||
|
In CDL, an attribute is designated by a variable and attribute name,
|
||
|
separated by `:'. It is possible to assign \fIglobal\fP attributes
|
||
|
not associated with any variable to the netCDF as a whole by using
|
||
|
`:' before the attribute name. The data type of an attribute in CDL
|
||
|
is derived from the type of the value assigned to it. The length of
|
||
|
an attribute is the number of data values assigned to it, or the
|
||
|
number of characters in the character string assigned to it. Multiple
|
||
|
values are assigned to non-character attributes by separating the
|
||
|
values with commas. All values assigned to an attribute must be of
|
||
|
the same type.
|
||
|
.LP
|
||
|
The names for CDL dimensions, variables, and attributes must begin with an
|
||
|
alphabetic character or `_', and subsequent characters may be alphanumeric
|
||
|
or `_' or `-'.
|
||
|
.LP
|
||
|
The optional \fIdata\fP section of a CDL specification is where
|
||
|
netCDF variables may be initialized. The syntax of an initialization
|
||
|
is simple: a variable name, an equals sign, and a
|
||
|
comma-delimited list of constants (possibly separated by spaces, tabs
|
||
|
and newlines) terminated with a semicolon. For multi-dimensional
|
||
|
arrays, the last dimension varies fastest. Thus row-order rather than
|
||
|
column order is used for matrices. If fewer values are supplied than
|
||
|
are needed to fill a variable, it is extended with a type-dependent
|
||
|
`fill value', which can be overridden by supplying a value for a
|
||
|
distinguished variable attribute named `_FillValue'. The
|
||
|
types of constants need not match the type declared for a variable;
|
||
|
coercions are done to convert integers to floating point, for example.
|
||
|
The constant `_' can be used to designate the fill value for a variable.
|
||
|
.SS "Primitive Data Types"
|
||
|
.LP
|
||
|
.RS
|
||
|
.nf
|
||
|
\fBchar\fP characters
|
||
|
\fBbyte\fP 8-bit data
|
||
|
\fBshort\fP 16-bit signed integers
|
||
|
\fBlong\fP 32-bit signed integers
|
||
|
\fBint\fP (synonymous with \fBlong\fP)
|
||
|
\fBfloat\fP IEEE single precision floating point (32 bits)
|
||
|
\fBreal\fP (synonymous with \fBfloat\fP)
|
||
|
\fBdouble\fP IEEE double precision floating point (64 bits)
|
||
|
.fi
|
||
|
.RE
|
||
|
.LP
|
||
|
Except for the added data-type \fBbyte\fP and the lack of
|
||
|
\fBunsigned\fP,
|
||
|
CDL supports the same primitive data types as C.
|
||
|
The names for the primitive data types are reserved words in CDL,
|
||
|
so the names of variables, dimensions, and attributes must not be
|
||
|
type names. In declarations, type names may be specified
|
||
|
in either upper or lower case.
|
||
|
.LP
|
||
|
Bytes differ from characters in that they are intended to hold a full eight
|
||
|
bits of data, and the zero byte has no special significance, as it
|
||
|
does for character data.
|
||
|
\fBncgen3\fP converts \fBbyte\fP declarations to \fBchar\fP
|
||
|
declarations in the output C code and to the nonstandard \fBBYTE\fP
|
||
|
declaration in output Fortran code.
|
||
|
.LP
|
||
|
Shorts can hold values between -32768 and 32767.
|
||
|
\fBncgen3\fP converts \fBshort\fP declarations to \fBshort\fP
|
||
|
declarations in the output C code and to the nonstandard \fBINTEGER*2\fP
|
||
|
declaration in output Fortran code.
|
||
|
.LP
|
||
|
Longs can hold values between -2147483648 and 2147483647.
|
||
|
\fBncgen3\fP converts \fBlong\fP declarations to \fBlong\fP
|
||
|
declarations in the output C code and to \fBINTEGER\fP
|
||
|
declarations in output Fortran code. \fBint\fP and \fBinteger\fP are
|
||
|
accepted as synonyms for \fBlong\fP in CDL declarations.
|
||
|
Now that there are platforms with 64-bit representations for C longs, it may
|
||
|
be better to use the \fBint\fP synonym to avoid confusion.
|
||
|
.LP
|
||
|
Floats can hold values between about -3.4+38 and 3.4+38. Their
|
||
|
external representation is as 32-bit IEEE normalized single-precision
|
||
|
floating point numbers. \fBncgen3\fP converts \fBfloat\fP
|
||
|
declarations to \fBfloat\fP declarations in the output C code and to
|
||
|
\fBREAL\fP declarations in output Fortran code. \fBreal\fP is accepted
|
||
|
as a synonym for \fBfloat\fP in CDL declarations.
|
||
|
.LP
|
||
|
Doubles can hold values between about -1.7+308 and 1.7+308. Their
|
||
|
external representation is as 64-bit IEEE standard normalized
|
||
|
double-precision floating point numbers. \fBncgen3\fP converts
|
||
|
\fBdouble\fP declarations to \fBdouble\fP declarations in the output C
|
||
|
code and to \fBDOUBLE PRECISION\fP declarations in output Fortran
|
||
|
code.
|
||
|
.LP
|
||
|
.SS "CDL Constants"
|
||
|
.LP
|
||
|
Constants assigned to attributes or variables may be of any of the
|
||
|
basic netCDF types. The syntax for constants is similar to C syntax,
|
||
|
except that type suffixes must be appended to shorts and floats to
|
||
|
distinguish them from longs and doubles.
|
||
|
.LP
|
||
|
A \fIbyte\fP constant is represented by a single character or multiple
|
||
|
character escape sequence enclosed in single quotes. For example,
|
||
|
.RS
|
||
|
.nf
|
||
|
'a' // ASCII `a'
|
||
|
'\\0' // a zero byte
|
||
|
'\\n' // ASCII newline character
|
||
|
'\\33' // ASCII escape character (33 octal)
|
||
|
'\\x2b' // ASCII plus (2b hex)
|
||
|
'\\377' // 377 octal = 255 decimal, non-ASCII
|
||
|
.fi
|
||
|
.RE
|
||
|
.LP
|
||
|
Character constants are enclosed in double quotes. A character array
|
||
|
may be represented as a string enclosed in double quotes. The usual C
|
||
|
string escape conventions are honored. For example
|
||
|
.RS
|
||
|
.nf
|
||
|
"a" // ASCII `a'
|
||
|
"Two\\nlines\\n" // a 10-character string with two embedded newlines
|
||
|
"a bell:\\007" // a string containing an ASCII bell
|
||
|
.fi
|
||
|
.RE
|
||
|
Note that the netCDF character array "a" would fit in a one-element
|
||
|
variable, since no terminating NULL character is assumed. However, a zero
|
||
|
byte in a character array is interpreted as the end of the significant
|
||
|
characters by the \fBncdump\fP program, following the C convention.
|
||
|
Therefore, a NULL byte should not be embedded in a character string unless
|
||
|
at the end: use the \fIbyte\fP data type instead for byte arrays that
|
||
|
contain the zero byte. NetCDF and CDL have no string type, but only
|
||
|
fixed-length character arrays, which may be multi-dimensional.
|
||
|
.LP
|
||
|
\fIshort\fP integer constants are intended for representing 16-bit
|
||
|
signed quantities. The form of a \fIshort\fP constant is an integer
|
||
|
constant with an `s' or `S' appended. If a \fIshort\fP constant
|
||
|
begins with `0', it is interpreted as octal, except that if it begins with
|
||
|
`0x', it is interpreted as a hexadecimal constant. For example:
|
||
|
.RS
|
||
|
.nf
|
||
|
-2s // a short -2
|
||
|
0123s // octal
|
||
|
0x7ffs //hexadecimal
|
||
|
.fi
|
||
|
.RE
|
||
|
.LP
|
||
|
\fILong\fP integer constants are intended for representing 32-bit signed
|
||
|
quantities. The form of a \fIlong\fP constant is an ordinary integer
|
||
|
constant, although it is acceptable to append an optional `l' or
|
||
|
`L'. If a \fIlong\fP constant begins with `0', it is interpreted as
|
||
|
octal, except that if it begins with `0x', it is interpreted as a hexadecimal
|
||
|
constant. Examples of valid \fIlong\fP constants include:
|
||
|
.RS
|
||
|
.nf
|
||
|
-2
|
||
|
1234567890L
|
||
|
0123 // octal
|
||
|
0x7ff // hexadecimal
|
||
|
.fi
|
||
|
.RE
|
||
|
.LP
|
||
|
Floating point constants of type \fIfloat\fP are appropriate for representing
|
||
|
floating point data with about seven significant digits of precision.
|
||
|
The form of a \fIfloat\fP constant is the same as a C floating point
|
||
|
constant with an `f' or `F' appended. For example the following
|
||
|
are all acceptable \fIfloat\fP constants:
|
||
|
.RS
|
||
|
.nf
|
||
|
-2.0f
|
||
|
3.14159265358979f // will be truncated to less precision
|
||
|
1.f
|
||
|
.1f
|
||
|
.fi
|
||
|
.RE
|
||
|
.LP
|
||
|
Floating point constants of type \fIdouble\fP are appropriate for
|
||
|
representing floating point data with about sixteen significant digits
|
||
|
of precision. The form of a \fIdouble\fP constant is the same as a C
|
||
|
floating point constant. An optional `d' or `D' may be appended.
|
||
|
For example the following are all acceptable \fIdouble\fP constants:
|
||
|
.RS
|
||
|
.nf
|
||
|
-2.0
|
||
|
3.141592653589793
|
||
|
1.0e-20
|
||
|
1.d
|
||
|
.fi
|
||
|
.RE
|
||
|
|
||
|
.SH BUGS
|
||
|
.LP
|
||
|
The programs generated by \fBncgen3\fP when using the \fB-c\fP or \fB-f\fP
|
||
|
use initialization statements to store data in variables, and will fail to
|
||
|
produce compilable programs if you try to use them for large datasets, since
|
||
|
the resulting statements may exceed the line length or number of
|
||
|
continuation statements permitted by the compiler.
|
||
|
.LP
|
||
|
The CDL syntax makes it easy to assign what looks like an array of
|
||
|
variable-length strings to a netCDF variable, but the strings will simply be
|
||
|
concatenated into a single array of characters, since netCDF cannot
|
||
|
represent an array of variable-length strings in one netCDF variable.
|
||
|
.LP
|
||
|
NetCDF and CDL do not yet support a type corresponding to a 64-bit integer.
|