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

Re: 19980915: netCDF: automatic type conversions

>To: address@hidden
>From: Darran Edmundson <address@hidden>
>Subject: netCDF: automatic type conversions ...
>Organization: Optical Sciences Centre, Australian National University
>Keywords: 199809151144.FAA24630

Hi Darran,

> I wonder if you can offer some advice on the following
> problem?  Consider this simple f77 test code:
> 
>       program test
> 
>       implicit none
>       real x(16)
>       integer x_id, ncid, xmesh, xdim, s, i, vardim(1)
>       include 'netcdf.inc'
> 
>       xmesh=16
>       do i=1,xmesh
>          x(i) = real(i)+0.001
>       enddo
> 
>       s = nf_create('test.nc', 0, ncid)
>       s = nf_def_dim(ncid, 'x_index', xmesh, xdim)
>       vardim(1)=xdim
>       s = nf_def_var (ncid, 'x', nf_float, 1, vardim, x_id)
>       write (*,*) s
>       s = nf_enddef (ncid)
>       s = nf_put_var_real (ncid, x_id, x )
>       write (*,*) s
>       s = nf_close(ncid)
>       end
> 
> Compiled with no flags, my netcdf file has the expected
> contents,
> 
> netcdf test {
> dimensions:
>         x_index = 16 ;
> variables:
>         float x(x_index) ;
> data:
> 
>  x = 1.001, 2.001, 3.001, 4.001, 5.001, 6.001, 7.001, 8.001, 9.001,
> 10.001, 
>     11.001, 12.001, 13.001, 14.001, 15.001, 16.001 ;
> }
> 
> 
> However, if I use our DEC compiler's -r8 option to promote to
> double precision, the data is mangled, viz.
> 
> netcdf test {
> dimensions:
>         x_index = 16 ;
> variables:
>         float x(x_index) ;
> data:
> 
>  x = -3.089003e-27, 1.875125, 1526727, 2.000125, 1526727, 2.125125, 
>     9.592327e-17, 2.250062, 9.592327e-17, 2.312562, 9.592327e-17,
> 2.375062, 
>     9.592327e-17, 2.437562, 7.528636e-28, 2.500031 ;
> }
> 
> 
> I was initially under the impression that the netCDF library handled
> type conversion transparently (i.e., the cast down to real*4).  I
> guess not - and hence the put_var_{type} class of functions.  Is
> there a nice way to handle compiling for either real or double 
> without having to change the source code?

I think the problem is in trying to link your code, compiled with the
-r8 option with a netCDF library compiled without the -r8 option.  If
you rebuild the netcdf library with the -r8 option and link against
that, things should work fine.  I believe this is not just a netCDF
problem.  I suspect you will encounter similar problems whenever you try
to link an object file compiled with the -r8 option with a library
compiled without the -r8 option, and vice versa.

Please let us know, at address@hidden, if this isn't the
correct diagnosis of the problem.

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu