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: Holger Wenzel <address@hidden> >Subject: netcdf 3.3.1 fortran interface: HP-UX probs >Organization: . >Keywords: 199709231518.JAA15329 > > Hi, > > I'm using a program that uses your netcdf-package to perform > input/output. > > On a SGI-workstation and on a Cray J-90 everything works o.k., but > when I try to use it on a HP-workstation using either HPUX 9.07 or > HPUX 10.20 I have some problems reading netcdf files in, that were > written on another system. > > I've boild the problem down to the following program that > calculates the value of pi and writes it out to a netcdf file called > nc.test. > > test_nc.f: > > program test_nc > > implicit none > > include 'netcdf.inc' > > real x > > integer rcode, cdfid > > x=4*atan(1.) > > cdfid = NCCRE("nc.test", NCCLOB, rcode) > > call NCAPT(cdfid, NCGLOBAL, 'x', NCDOUBLE, 1, x, rcode) > > call NCCLOS(cdfid, rcode) > > stop 'test_nc end' > > end > > > > If I compile it e.g. on HPUX 10.20 with the command line, using the > -R8 switch to get double precison as default: > > fort77 -R8 -o test_nc -I$HOME/executables/H8000/include > -L$HOME/executables/H8000/lib test_nc.f -lnetcdf > a call to this program and a subsequent call to ncdump gives: > > loredana:ugg[68]$ ./test_nc;ncdump -h nc.test > STOP test_nc end > netcdf nc { > > // global attributes: > :x = 50.1238708496094 ; > } > > where the value of x should be pi. > > > > > > Doing the same procedure on a sgi gives: > > f77 -r8 -o test_nc -I/disk2/people/hw/include -L/disk2/people/hw/lib test_nc.f -lnetcdf > > ctr-sgi1:ugg[262]$ ./test_nc; ncdump -h nc.test > STOP test_nc end statement executed > netcdf nc { > > // global attributes: > :x = 3.14159265358979 ; > } > > > > On the Cray J90 everything is o.k. as well. > > > > I've compiled the netcdf-library on the HP with no problems and the > tests ran through smoothly. > > > > Changing the statement where I declare the variable x into > > real*8 x > > solves the problem with this testprogram, but I don't really want to > do that in the program I do my calculations with. > > > > I can produce a netcdf file on a HP and read it back in with no problems, > the problem I'm facing is, that I can't use the netcdf file from the > Cray or a SGI to use it on a HP or vice versa. > > If I miss something obvious here, I'd apreciate a RTFM with a pointer, > otherwise I'd be glad to provide you with more information if needed. > > Thanks for your effort. > > Holger > - -- > Holger Wenzel Institut fuer Technische Mechanik > RWTH Aachen > phone: +49/(0)241/80-4624 Templergraben 64 > email: address@hidden D-52064 Aachen Holger: Your problem is inconsistant use of the -R8 flag to fort77. The configuration script used to build the netcdf library figures out what C type matches a FORTRAN REAL, and sticks that into an include file used to build the FORTRAN interface. I'll wager the netcdf library was configured without using '-R8', so the C type matching FORTRAN REAL in the library is 'float'. If you are going to use -R8 to your FORTRAN compiles, you have to reconfigure and rebuild the netcdf library with that assumption. Set the environment variable FFLAGS to include -R8 before running configure. As a matter of style, if your program depends on 8 byte REALs or you want to compare results between machines 8 byte and 4 byte REALs, you should probably just say in your program that you want REAL*8. That way it will be more consistant across machines an you won't have to worry about keeping track of multiple versions of the netcdf library. -glenn