This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
>To: address@hidden >From: "Bryan C. Weare" <address@hidden> >Subject: Re: 980217: Incompatibility of netcdf 2.3.2 run on OSF3.2 41 and >netcdf 3.3.1 on OSF4.0 464 >Organization: U.C. Davis >Keywords: 199802171929.MAA13356 Bryan, > I don't think my problem is with getting the correct library. I have > copied > libnetcdf.a to a local directory and compiled the following program using > f77 test.f libnetcdf.a > It fails because the ncopn returns ncid as 3 not 0 as expected. Aha! It sounds like the library is working OK and the problem is the assumption that "ncopn" would return some particular value. All the documentation says for either netcdf 2 or netcdf 3 is that the return value from ncopn is a small integer, but your program should not in any way depend on which small integer. If you open files in a different order, you will get different ncid values returned. In netcdf 3, ncopn doesn't return 0 as the ncid of the first opened file, it returns 3, because ncid is now the file descriptor of the open netcdf file, and file descriptors 0, 1, and 2, are already in use for stdin, stdout, and stderr. We could have tried to hide this difference, but did not think this would be an incompatibility, because we never documented what values of ncid meant; they were to be treated as opaque file "handles" for use in other netcdf function calls. > I notice that the libnetcdf.a for version 3 is much larger than for > version 2. > Exactly how large should it be? I also notice that netcdf.inc is much larger > in the newer > version. Is there ANYTHING else that is needed for FORTRAN compilations that > might have > changed? The library for version 3 is larger because: - it doesn't depend on the vendor's XDR library, but provides a new extended XDR implementation, improving portability and performance; - it provides a new C interface with 134 functions, as well as providing backward compatibility for the old netcdf-2 C interface of 34 functions; - it provides a new Fortran interface with 110 functions, as well as providing backward compatibility with the old Fortran interface of 41 functions; and - it provides new automatic type conversion facilities, letting you ask for values as DOUBLE, for example, even if they are stored as integers or reals. Similarly, netcdf.inc is larger because it must declare the netcdf-2 Fortran interfaces and parameters as well as all the new netcdf-3 interfaces and parameters. It's too bad that we didn't achieve complete backward compatibility so that you could just use old programs without even recompiling them, by linking against the new library. Instead, it's necessary to recompile as well as relink to get the benefits of the better performance and added functionality. Your executables will also be larger than with netcdf-2, which is another part of the trade-off. Sorry you ran into an incompatibility with an undocumented property. I'm also sorry this reply sounds like a lecture; I don't mean it that way, and have made the same mistake myself (inadvertently depending on undocumented properties of an implementation) numerous times. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu