1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
|
<!-- Generated by Harlequin WebMaker 2.2.3 (24-Apr-1996)
LispWorks 3.2.2 -->
<HTML> <HEAD>
<TITLE>Appendix D NetCDF 2 FORTRAN Transition Guide</TITLE>
</HEAD>
<BODY bgcolor="#ffffff">
<A NAME=HEADING20></A>
<A HREF="guidef-21.html">[Next] </A><A HREF="guidef-19.html">[Previous] </A><A HREF="guidef-1.html">[Top] </A><A HREF="guidef-3.html">[Contents] </A><A HREF="guidef-21.html">[Index] </A><A HREF="http://www.unidata.ucar.edu/packages/netcdf/">[netCDF Home Page]</A><A HREF="http://www.unidata.ucar.edu/">[Unidata Home Page]</A><P>
NetCDF User's Guide for Fortran<P>
<A NAME=HEADING20-0></A>
<H1>Appendix D <A NAME=MARKER-2-3355></A>NetCDF 2 <A NAME=MARKER-10-3356></A>FORTRAN Transition Guide</H1>
<HR>
<A NAME=HEADING20-1></A>
<H4> <A NAME=MARKER-2-3357></A>Overview of <A NAME=MARKER-10-3358></A>FORTRAN interface changes</H4>
NetCDF version 3 includes a complete rewrite of the netCDF library. It is about twice as fast as the previous version. The netCDF file format is unchanged, so files written with version 3 can be read with version 2 code and vice versa. <P>
The core library is now written in <A NAME=MARKER-2-3359></A><A NAME=MARKER-2-3360></A>ANSI C. <A NAME=MARKER-10-3361></A>You must have an ANSI C compiler to compile this version. <A NAME=MARKER-2-3362></A><A NAME=MARKER-2-3363></A><A NAME=MARKER-2-3364></A>The FORTRAN interface is layered on top of the C interface using a different technique than was used in netCDF-2.<P>
Rewriting the library offered an opportunity to implement improved C and FORTRAN interfaces that provide some significant benefits: <P>
<UL>
<LI><A NAME=MARKER-2-3365></A><A NAME=MARKER-2-3366></A>type safety, by eliminating the need to use <A NAME=MARKER-10-3367></A><A NAME=MARKER-2-3370></A>type punning in arguments;<P>
<LI>automatic type conversions, by eliminating the undesirable <A NAME=MARKER-2-3371></A>coupling between the language-independent external netCDF types (<A NAME=MARKER-10-3372></A>NF_BYTE, ..., <A NAME=MARKER-10-3373></A>NF_DOUBLE) and language-dependent internal data types (<A NAME=MARKER-10-3374></A>INT*1, ..., <A NAME=MARKER-10-3375></A>DOUBLE PRECISION);<P>
<LI>support for <A NAME=MARKER-2-3376></A><A NAME=MARKER-2-3377></A>future enhancements, by eliminating obstacles to the clean addition of support for packed data and multithreading;<P>
<LI>more standard error behavior, by uniformly communicating an error status back to the calling program in the return value of each function. <P>
</UL>
It is not necessary to rewrite programs that use the version 2 <A NAME=MARKER-10-3380></A>FORTRAN interface, because the netCDF-3 library includes a <A NAME=MARKER-2-3381></A><A NAME=MARKER-2-3382></A><A NAME=MARKER-2-3383></A>backward compatibility interface that supports all the old functions, globals, and behavior. We are hoping that the benefits of the new interface will be an incentive to use it in new netCDF applications. It is possible to convert old applications to the new interface incrementally, replacing netCDF-2 calls with the corresponding netCDF-3 calls one at a time.<A NAME=MARKER-10-3384></A><P>
Other changes in the implementation of netCDF result in improved portability, maintainability, and performance on most platforms. A clean separation between I/O and type layers facilitates platform-specific optimizations. The new library no longer uses a vendor-provided <A NAME=MARKER-2-3385></A><A NAME=MARKER-2-3386></A>XDR library, which simplifies linking programs that use netCDF and speeds up data access significantly in most cases.<P>
<A NAME=HEADING20-11></A>
<H4> <A NAME=MARKER-2-3387></A><A NAME=MARKER-2-3388></A><A NAME=MARKER-2-3389></A>The New <A NAME=MARKER-10-3390></A>FORTRAN Interface</H4>
First, here's an example of <A NAME=MARKER-10-3391></A>FORTRAN code that uses the netCDF-2 interface:<P>
<PRE>
<A NAME=MARKER-10-3392></A>! Use a buffer big enough for values of any type
DOUBLE PRECISION DBUF(NDATA)
REAL RBUF(NDATA)
...
EQUIVALENCE (RBUF, DBUF), ...
INT XTYPE ! to hold the actual type of the data
INT STATUS ! for error status
! Get the actual data type
CALL NCVINQ(NCID, VARID, ...,XTYPE, ...)
...
! Get the data
CALL NCVGT(NCID, VARID, START, COUNT, DBUF, STATUS)
IF(STATUS .NE. NCNOERR) THEN
PRINT *, 'Cannot get data, error code =', STATUS
! Deal with error
...
ENDIF
IF (XTYPE .EQ. NCDOUBLE) THEN
CALL DANALYZE(DBUF)
ELSEIF (XTYPE .EQ. NCFLOAT) THEN
CALL RANALYZE(RBUF)
...
ENDIF
</PRE>
Here's how you might handle this with the new netCDF-3 <A NAME=MARKER-10-3393></A>FORTRAN interface:<P>
<PRE>
<A NAME=MARKER-10-3394></A>! I want to use doubles for my analysis
DOUBLE PRECISION DBUF(NDATA)
INT STATUS
! So I use a function that gets the data as doubles.
STATUS = NF_GET_VARA_DOUBLE(NCID, VARID, START, COUNT, DBUF)
IF(STATUS .NE. NF_NOERR) THEN
PRINT *, 'Cannot get data, ', NF_STRERROR(STATUS)
! Deal with error
...
ENDIF
CALL DANALYZE(DBUF)
</PRE>
The example above illustrates changes in function names, data type conversion, and error handling, discussed in detail in the sections below. <P>
<A NAME=HEADING20-49></A>
<H4> <A NAME=MARKER-2-3395></A><A NAME=MARKER-2-3396></A><A NAME=MARKER-2-3397></A>Function Naming Conventions</H4>
The netCDF-3 C library employs a new naming convention, intended to make netCDF programs more readable. For example, the name of the function to rename a variable is now <CODE><A NAME=MARKER-10-3398></A>NF_RENAME_VAR</CODE> instead of the previous <A NAME=MARKER-10-3399></A><CODE>NCVREN</CODE>. <P>
All netCDF-3 <A NAME=MARKER-10-3400></A>FORTRAN function names begin with the <A NAME=MARKER-10-3401></A><CODE>NF_</CODE> prefix. The second part of the name is a verb, like <A NAME=MARKER-10-3402></A><CODE>GET</CODE>, <A NAME=MARKER-10-3403></A><CODE>PUT</CODE>, <A NAME=MARKER-10-3404></A><CODE>INQ</CODE> (for inquire), or <A NAME=MARKER-10-3405></A><CODE>OPEN</CODE>. The third part of the name is typically the object of the verb: for example <A NAME=MARKER-10-3406></A><CODE>DIM</CODE>, <A NAME=MARKER-10-3407></A><CODE>VAR</CODE>, or <A NAME=MARKER-10-3408></A><CODE>ATT</CODE> for functions dealing with dimensions, variables, or attributes. To distinguish the various I/O operations for variables, a single character modifier is appended to <A NAME=MARKER-10-3409></A><CODE>VAR</CODE>: <P>
<UL>
<LI><CODE><A NAME=MARKER-10-3410></A>VAR </CODE>entire variable access<P>
<LI><CODE><A NAME=MARKER-10-3411></A>VAR1 </CODE>single value access<P>
<LI><CODE><A NAME=MARKER-10-3412></A>VARA </CODE>array or array section access<P>
<LI><CODE><A NAME=MARKER-10-3413></A>VARS </CODE>strided access to a subsample of values<P>
<LI><CODE><A NAME=MARKER-10-3414></A>VARM </CODE>mapped access to values not contiguous in memory<P>
</UL>
At the end of the name for variable and attribute functions, there is a component indicating the type of the final argument: <A NAME=MARKER-10-3415></A><CODE>TEXT</CODE>, <A NAME=MARKER-10-3416></A><CODE>INT1</CODE>, <A NAME=MARKER-10-3417></A><CODE>INT2</CODE>, <A NAME=MARKER-10-3418></A><CODE>INT</CODE>, <A NAME=MARKER-10-3419></A><CODE>REAL</CODE>, or <A NAME=MARKER-10-3420></A><CODE>DOUBLE</CODE>. This part of the function name indicates the type of the data container you are using in your program: character string, <A NAME=MARKER-10-3421></A>1-byte integer, and so on.<P>
Also, all <A NAME=MARKER-10-3422></A><A NAME=MARKER-2-3423></A><A NAME=MARKER-2-3424></A><A NAME=MARKER-2-3425></A>PARAMETER names in the public <A NAME=MARKER-10-3426></A>FORTRAN interface begin with the prefix <CODE><A NAME=MARKER-10-3427></A>NF_</CODE>. For example, the <A NAME=MARKER-10-3428></A>PARAMETER which was formerly <A NAME=MARKER-10-3429></A><CODE>MAXNCNAM</CODE> is now <A NAME=MARKER-10-3430></A><CODE><A NAME=MARKER-2-3431></A>NF_MAX_NAME</CODE>, and the former <A NAME=MARKER-10-3432></A><CODE>FILFLOAT</CODE> is now <CODE><A NAME=MARKER-10-3433></A><A NAME=MARKER-2-3434></A>NF_FILL_FLOAT</CODE>. <P>
As previously mentioned, all the old names are still supported for backward compatibility.<P>
<A NAME=HEADING20-60></A>
<H4> <A NAME=MARKER-2-3435></A><A NAME=MARKER-2-3436></A>Type Conversion</H4>
With the new interface, users need not be aware of the external type of numeric variables, since automatic conversion to or from any desired numeric type is now available. You can use this feature to simplify code, by making it independent of external types. <A NAME=MARKER-2-3437></A><A NAME=MARKER-2-3438></A><A NAME=MARKER-2-3439></A>The elimination of <A NAME=MARKER-10-3440></A><A NAME=MARKER-2-3441></A><A NAME=MARKER-2-3442></A><A NAME=MARKER-2-3443></A>type punning <A NAME=MARKER-10-3444></A>prevents some kinds of type errors that could occur with the previous interface. Programs may be made more robust with the new interface, because they need not be changed to accommodate a change to the external type of a variable.<P>
If conversion to or from an external numeric type is necessary, it is handled by the library. This automatic conversion and separation of external data representation from internal data types will become even more important in netCDF version 4, when new external types will be added for packed data for which there is no natural corresponding internal type, for example, arrays of 11-bit values.<P>
<A NAME=MARKER-2-3445></A><A NAME=MARKER-2-3446></A><A NAME=MARKER-2-3447></A>Converting from one numeric type to another may result in an error if the target type is not capable of representing the converted value. (In netCDF-2, such overflows can only happen in the XDR layer.) For example, a <A NAME=MARKER-10-3448></A>REAL may not be able to hold data stored externally as an <CODE><A NAME=MARKER-10-3449></A>NF_DOUBLE</CODE> (an IEEE floating-point number). When accessing an array of values, an <CODE><A NAME=MARKER-10-3450></A>NF_ERANGE</CODE> error is returned if one or more values are out of the range of representable values, but other values are converted properly.<P>
Note that mere loss of precision in type conversion does not return an error. Thus, if you read double precision values into an <A NAME=MARKER-10-3451></A>INTEGER, for example, no error results unless the magnitude of the double precision value exceeds the representable range of <A NAME=MARKER-10-3452></A>INTEGERs on your platform. Similarly, if you read a large integer into a <A NAME=MARKER-10-3453></A>REAL incapable of representing all the bits of the integer in its mantissa, this loss of precision will not result in an error. If you want to avoid such precision loss, check the external types of the variables you access to make sure you use an internal type that has a compatible precision. <P>
<A NAME=MARKER-2-3454></A><A NAME=MARKER-2-3455></A><A NAME=MARKER-2-3456></A>The new interface distinguishes arrays of characters intended to represent text strings from arrays of 8-bit bytes intended to represent small integers. The interface supports the internal types <A NAME=MARKER-10-3457></A> CHARACTER and INT1 intended for text strings<A NAME=MARKER-10-3458></A> and one byte integers.<P>
<A NAME=HEADING20-66></A>
<H4> <A NAME=MARKER-10-3459></A><A NAME=MARKER-2-3460></A><A NAME=MARKER-2-3461></A>Error handling</H4>
The new interface handles errors differently than netCDF-2. In the old interface, the default behavior when an error was detected was to print an error message and exit. To get control of error handling, you had to <A NAME=MARKER-10-3462></A>call a function NCPOPT and to determine the cause of an error, you had to test the value of <A NAME=MARKER-10-3463></A>a returned error parameter.<P>
In the new interface, functions return an integer status that indicates not only success or failure, but also the cause of the error. <A NAME=MARKER-10-3464></A>The library will never try to print anything, nor will it call <CODE>exit</CODE> (unless you are using the netCDF version 2 compatibility functions). You will have to check the function return status and do this yourself. We eliminated these globals in the interest of supporting parallel (multiprocessor) execution cleanly, as well as reducing the number of assumptions about the environment where netCDF is used. The new behavior should provide better support for using netCDF as a hidden layer in applications that have their own GUI interface.<P>
<A NAME=HEADING20-69></A>
<H4> <A NAME=MARKER-10-3465></A><CODE><A NAME=MARKER-2-3466></A><A NAME=MARKER-2-3467></A><A NAME=MARKER-2-3468></A>NCLONG</CODE> and <A NAME=MARKER-10-3469></A><CODE>NF_INT </CODE></H4>
Where the netCDF-2 interface used <A NAME=MARKER-10-3470></A><CODE>NCLONG</CODE> to identify an external data type corresponding to 32-bit integers, the new interface uses <A NAME=MARKER-10-3471></A><CODE>NF_INT</CODE> instead. <A NAME=MARKER-10-3472></A><CODE>NCLONG</CODE> is defined to have the same value as <A NAME=MARKER-10-3473></A><CODE>NF_INT</CODE> for backward compatibility, but it should not be used in new code. With new 64-bit platforms using long for 64-bit integers, we would like to reduce the confusion caused by this name clash. Note that there is still no netCDF external data type corresponding to 64-bit integers. <P>
<A NAME=HEADING20-71></A>
<H4> What's Missing?</H4>
<A NAME=MARKER-10-3474></A>There is no function corresponding to the <A NAME=MARKER-10-3475></A><A NAME=MARKER-2-3476></A><CODE>NCTLEN</CODE> function from the version 2 interface. The separation of internal and external types and the new type-conversion interfaces make <CODE><A NAME=MARKER-10-3477></A>NCTLEN</CODE> unnecessary. Since users read into and write out of native types, <A NAME=MARKER-10-3478></A>knowledge of the space required for native types is perfectly adequate to determine how much space to allocate for a value. <P>
<A NAME=MARKER-2-3479></A><A NAME=MARKER-2-3480></A><A NAME=MARKER-2-3481></A>In the previous library, there was no checking that the characters used in the name of a netCDF object were compatible with CDL restrictions. The ncdump and ncgen utilities that use CDL permit only alphanumeric characters, "<CODE>_</CODE>" and "<CODE>-</CODE>" in names. Now this restriction is also enforced by the library for creation of new dimensions, variables, and attributes. Previously existing components with less restrictive names will still work OK. <P>
<A NAME=HEADING20-74></A>
<H4> Other Changes</H4>
There are two new functions in netCDF-3 that don't correspond to any netCDF-2 functions: <CODE><A NAME=MARKER-10-3482></A>NF_INQ_LIBVERS</CODE> and <A NAME=MARKER-10-3483></A><CODE>NF_STRERROR</CODE>. The version of the netCDF library in use is returned as a string by <A NAME=MARKER-10-3484></A><CODE>NF_INQ_LIBVERS</CODE>. An error message corresponding to the status returned by a netCDF function call is returned as a string by the <CODE><A NAME=MARKER-10-3485></A>NF_STRERROR</CODE> function. <P>
A new <A NAME=MARKER-10-3486></A><CODE><A NAME=MARKER-2-3487></A>NF_SHARE</CODE> flag is available for use in an <A NAME=MARKER-10-3488></A><CODE>NF_OPEN</CODE> or <A NAME=MARKER-10-3489></A><CODE>NF_CREATE</CODE> call, to suppress the default buffering of accesses. The use of <A NAME=MARKER-10-3490></A><CODE>NF_SHARE</CODE> for concurrent access to a netCDF dataset means you don't have to call <A NAME=MARKER-10-3491></A><CODE>NF_SYNC</CODE> after every access to make sure that disk updates are synchronous. It is important to note that changes to ancillary data, such as attribute values, are not propagated automatically by use of the <A NAME=MARKER-10-3492></A><CODE>NF_SHARE</CODE> flag. Use of the <A NAME=MARKER-10-3493></A><CODE>NF_SYNC</CODE> function is still required for this purpose.<P>
The version 2 interface had a single inquiry function, <A NAME=MARKER-10-3494></A><CODE>NCVINQ </CODE>for getting the name, type, and shape of a variable. Similarly, only a single inquiry function was available for getting information about a dimension, an attribute, or a netCDF dataset. When you only wanted a subset of this information, you had to provide <A NAME=MARKER-10-3495></A>dummy arguments as placeholders for the unneeded information. The new interface includes additional inquire functions that return each item separately, so errors are less likely from miscounting arguments. <P>
The previous implementation returned an error when <A NAME=MARKER-2-3496></A><A NAME=MARKER-2-3497></A><A NAME=MARKER-2-3498></A><A NAME=MARKER-2-3499></A><A NAME=MARKER-2-3500></A>0-valued count components were specified in <A NAME=MARKER-10-3501></A><CODE>NCVPT</CODE> and <A NAME=MARKER-10-3502></A><CODE>NCVGT</CODE> calls. This restriction has been removed, so that now functions in the <A NAME=MARKER-10-3503></A><CODE>NF_PUT_VAR</CODE> and <A NAME=MARKER-10-3504></A><CODE>NF_GET_VAR</CODE> families may be called with 0-valued count components, resulting in no data being accessed. Although this may seem useless, it simplifies some programs to not treat 0-valued counts as a special case. <P>
The previous implementation returned an error when the same dimension was used more than once in specifying the shape of a variable in ncvardef. This restriction is relaxed in the netCDF-3 implementation, because an autocorrelation matrix is a good example where using the same dimension twice makes sense. <P>
In the new interface, units for the <A NAME=MARKER-10-3505></A><CODE>IMAP</CODE> argument to the <A NAME=MARKER-10-3506></A><CODE>NF_PUT_VARM </CODE>and <CODE><A NAME=MARKER-10-3507></A>NF_GET_VARM</CODE> families of functions are now in terms of the number of data elements of the desired internal type, not in terms of bytes as in the netCDF version-2 mapped access interfaces.<P>
<A NAME=MARKER-2-3508></A><A NAME=MARKER-2-3509></A><A NAME=MARKER-2-3510></A><A NAME=MARKER-2-3511></A>Following is a table of netCDF-2 function names and names of the corresponding netCDF-3 functions. For parameter lists of netCDF-2 functions, see the netCDF-2 User's Guide.<A NAME=MARKER-10-3512></A>
<TABLE BORDER="1"><TD><CODE>NCABOR</CODE><TD><CODE>NF_ABORT</CODE><TR>
<TD><CODE>NCACPY</CODE><TD><CODE>NF_COPY_ATT</CODE><TR>
<TD><CODE>NCADEL</CODE><TD><CODE>NF_DEL_ATT</CODE><TR>
<TD><CODE>NCAGT</CODE><TD><CODE>NF_GET_ATT_DOUBLE, NF_GET_ATT_REAL, NF_GET_ATT_INT, NF_GET_ATT_INT1, NF_GET_ATT_INT2</CODE><TR>
<TD><CODE>NCAGTC</CODE><TD><CODE>NF_GET_ATT_TEXT</CODE><TR>
<TD><CODE>NCAINQ</CODE><TD><CODE>NF_INQ_ATT, NF_INQ_ATTID, NF_INQ_ATTLEN, NF_INQ_ATTTYPE</CODE><TR>
<TD><CODE>NCANAM</CODE><TD><CODE>NF_INQ_ATTNAME</CODE><TR>
<TD><CODE>NCAPT</CODE><TD><CODE>NF_PUT_ATT_DOUBLE, NF_PUT_ATT_REAL, NF_PUT_ATT_INT, NF_PUT_ATT_INT1, NF_PUT_ATT_INT2</CODE><TR>
<TD><CODE>NCAPTC</CODE><TD><CODE>NF_PUT_ATT_TEXT</CODE><TR>
<TD><CODE>NCAREN</CODE><TD><CODE>NF_RENAME_ATT</CODE><TR>
<TD><CODE>NCCLOS</CODE><TD><CODE>NF_CLOSE</CODE><TR>
<TD><CODE>NCCRE</CODE><TD><CODE>NF_CREATE</CODE><TR>
<TD><CODE>NCDDEF</CODE><TD><CODE>NF_DEF_DIM</CODE><TR>
<TD><CODE>NCDID</CODE><TD><CODE>NF_INQ_DIMID</CODE><TR>
<TD><CODE>NCDINQ</CODE><TD><CODE>NF_INQ_DIM, NF_INQ_DIMLEN, NF_INQ_DIMNAME</CODE><TR>
<TD><CODE>NCDREN</CODE><TD><CODE>NF_RENAME_DIM</CODE><TR>
<TD><CODE>NCENDF</CODE><TD><CODE>NF_ENDDEF</CODE><TR>
<TD><CODE>NCGOPT</CODE><TD><CODE>(none)</CODE><TR>
<TD><CODE>NCINQ</CODE><TD><CODE>NF_INQ, NF_INQ_NATTS, NF_INQ_NDIMS, NF_INQ_NVARS, NF_INQ_UNLIMDIM</CODE><TR>
<TD><CODE>NCOPN</CODE><TD><CODE>NF_OPEN</CODE><TR>
<TD><CODE>NCPOPT</CODE><TD><CODE>(none)</CODE><TR>
<TD><CODE>NCREDF</CODE><TD><CODE>NF_REDEF</CODE><TR>
<TD><CODE>NCSFIL</CODE><TD><CODE>NF_SET_FILL</CODE><TR>
<TD><CODE>NCSNC</CODE><TD><CODE>NF_SYNC</CODE><TR>
<TD><CODE>NCTLEN</CODE><TD><CODE>(none)</CODE><TR>
<TD><CODE>NCVDEF</CODE><TD><CODE>NF_DEF_VAR</CODE><TR>
<TD><CODE>NCVG1C</CODE><TD><CODE>NF_GET_VAR1_TEXT</CODE><TR>
<TD><CODE>NCVGGC</CODE><TD><CODE>NF_GET_VARM_TEXT, NF_GET_VARS_TEXT</CODE><TR>
<TD><CODE>NCVGT</CODE><TD><CODE>NF_GET_VARA_DOUBLE, NF_GET_VARA_REAL, NF_GET_VARA_INT, NF_GET_VARA_INT1, NF_GET_VARA_INT2</CODE><TR>
<TD><CODE>NCVGT1</CODE><TD><CODE>NF_GET_VAR1_DOUBLE, NF_GET_VAR1_REAL, NF_GET_VAR1_INT, NF_GET_VAR1_INT1, NF_GET_VAR1_INT2</CODE><TR>
<TD><CODE>NCVGTC</CODE><TD><CODE>NF_GET_VARA_TEXT</CODE><TR>
<TD><CODE>NCVGTG</CODE><TD><CODE>NF_GET_VARM_DOUBLE, NF_GET_VARM_REAL, NF_GET_VARM_INT, NF_GET_VARM_INT1, NF_GET_VARM_INT2, NF_GET_VARS_DOUBLE, NF_GET_VARS_REAL, NF_GET_VARS_INT, NF_GET_VARS_INT1, NF_GET_VARS_INT2</CODE><TR>
<TD><CODE>NCVID</CODE><TD><CODE>NF_INQ_VARID</CODE><TR>
<TD><CODE>NCVINQ</CODE><TD><CODE>NF_INQ_VAR, NF_INQ_VARDIMID, NF_INQ_VARNAME, NF_INQ_VARNATTS, NF_INQ_VARNDIMS, NF_INQ_VARTYPE</CODE><TR>
<TD><CODE>NCVP1C</CODE><TD><CODE>NF_PUT_VAR1_TEXT</CODE><TR>
<TD><CODE>NCVPGC</CODE><TD><CODE>NF_PUT_VARM_TEXT, NF_PUT_VARS_TEXT</CODE><TR>
<TD><CODE>NCVPT</CODE><TD><CODE>NF_PUT_VARA_DOUBLE, NF_PUT_VARA_REAL, NF_PUT_VARA_INT, NF_PUT_VARA_INT1, NF_PUT_VARA_INT2</CODE><TR>
<TD><CODE>NCVPT1</CODE><TD><CODE>NF_PUT_VAR1_DOUBLE, NF_PUT_VAR1_REAL, NF_PUT_VAR1_INT, NF_PUT_VAR1_INT1, NF_PUT_VAR1_INT2</CODE><TR>
<TD><CODE>NCVPTC</CODE><TD><CODE>NF_PUT_VARA_TEXT</CODE><TR>
<TD><CODE>NCVPTG</CODE><TD><CODE>NF_PUT_VARM_DOUBLE, NF_PUT_VARM_REAL, NF_PUT_VARM_INT, NF_PUT_VARM_INT1, NF_PUT_VARM_INT2, NF_PUT_VARS_DOUBLE, NF_PUT_VARS_REAL, NF_PUT_VARS_INT, NF_PUT_VARS_INT1, NF_PUT_VARS_INT2</CODE><TR>
<TD><CODE>NCVREN</CODE><TD><CODE>NF_RENAME_VAR</CODE><TR>
<TD><CODE>(none)</CODE><TD><CODE>NF_INQ_LIBVERS</CODE><TR>
<TD><CODE>(none)</CODE><TD><CODE>NF_STRERROR</CODE></TABLE>
<P>
<!-- TOC --><DL>
<DT><A HREF="guidef-20.html#HEADING20-1"><B></B>Overview of FORTRAN interface changes</A>
<DD>
<DT><A HREF="guidef-20.html#HEADING20-11"><B></B>The New FORTRAN Interface</A>
<DD>
<DT><A HREF="guidef-20.html#HEADING20-49"><B></B>Function Naming Conventions</A>
<DD>
<DT><A HREF="guidef-20.html#HEADING20-60"><B></B>Type Conversion</A>
<DD>
<DT><A HREF="guidef-20.html#HEADING20-66"><B></B>Error handling</A>
<DD>
<DT><A HREF="guidef-20.html#HEADING20-69"><B></B>NCLONG and NF_INT </A>
<DD>
<DT><A HREF="guidef-20.html#HEADING20-71"><B></B>What's Missing?</A>
<DD>
<DT><A HREF="guidef-20.html#HEADING20-74"><B></B>Other Changes</A>
<DD>
</DL>
<HR>
<ADDRESS>NetCDF User's Guide for Fortran - 5 JUN 1997</ADDRESS>
<A HREF="guidef-21.html">[Next] </A><A HREF="guidef-19.html">[Previous] </A><A HREF="guidef-1.html">[Top] </A><A HREF="guidef-3.html">[Contents] </A><A HREF="guidef-21.html">[Index] </A><A HREF="http://www.unidata.ucar.edu/packages/netcdf/">[netCDF Home Page]</A><A HREF="http://www.unidata.ucar.edu/">[Unidata Home Page]</A><P>
</BODY>
|
