[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 970923: netcdf 3.3.1 fortran interface: HP-UX probs address@hidden

>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