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

Re: Unidata Support: 19980803: 2 Questions to netCDF 3.4

Juergen ,

>Date: Tue, 4 Aug 1998 12:20:55 +0000
>From: address@hidden
>Organization: .
>To: Steve Emmerson <address@hidden>
>Subject: Re: Unidata Support: 19980803: 2 Questions to netCDF 3.4
>Keywords: 199808030909.DAA13766

In the above message, you wrote:

> 2. output from the configure script:
> 
> loading cache ./config.cache
> checking for m4... (cached) m4
> checking for xlc... (cached) c89
> checking C compiler... works
> checking how to make dependencies... false
> checking for CC... (cached) CC
> checking C++ compiler "CC"... works
> checking how to run the C preprocessor... (cached) c89 -E
> checking for f90... (cached) f90
> checking for Fortran .F compiler...
> checking if Fortran compiler handles *.F files... no
> checking for Fortran preprocessor... c89 -E
> checking for C-equivalent to Fortran routine "SUB"... SUB
> checking for Fortran "byte"... no
> checking for Fortran "integer*1"... yes
> checking for Fortran "integer*2"... yes
> checking if Fortran "integer*1" is C "signed char"... no
> checking if Fortran "integer*1" is C "short"... yes
> checking if Fortran "integer*1" is C "int"... yes
> checking if Fortran "integer*1" is C "long"... yes
> checking if Fortran "integer*2" is C "short"... yes
> checking if Fortran "integer*2" is C "int"... yes
> checking if Fortran "integer*2" is C "long"... yes
> checking if Fortran "integer" is C "int"... yes
> checking if Fortran "real" is C "float"... yes
> checking if Fortran "doubleprecision" is C "double"... no
> checking if Fortran "doubleprecision" is C "float"... no

The last two lines above reveal the problem: on your Cray J90 there is
no C data type corresponding to the Fortran doubleprecision data type.
Because version 2 of the netCDF specification implicitly assumed that
such a type exists, this means that you will not be able to read or
write any NC_DOUBLE value using the version 2 interface.  I'm sorry.

Because version 3 of the netCDF specification doesn't make this
assumption, you should be able to use the version 3 interface to read
and write such data.  The good news is that you can mix version 2 and
version 3 calls in the same program -- so you would only need to replace
those calls that access NC_DOUBLE data.

An alternative solution would be to use the Fortran compiler's "-dp" 
option which makes a Fortran "doubleprecision" equivalent to a C
"double".  More information on this can be found in the INSTALL file.

If you want to go this route, then do the following:

    1.  Go to the top-level source directory.

    2.  Execute the command "make distclean".

    3.  Remove the file "config.cache".

    4.  Set your environment variables as per the J90 example in the
        INSTALL file.  Ensure that FFLAGS contains the "-dp" option.

    5.  Execute the "configure" script.  Redirect standard output and
        standard error to the file "configure.log".  If an error message
        occurs in the output, then stop and send me the files
        "configure.log" and "config.log".  Also check "configure.log" to
        see that the configure script found a C equivalent to a Fortran
        "doubleprecision".

    6.  Execute the command "make".  Redirect standard output and
        standard error to the file "make.log".  If an error occurs, then
        stop and send me the files "make.log" and "configure.log.

    7.  Execute the command "make test".  Redirect standard output and
        standard error to the file "test.log".  If an error occurs,
        then stop and send me the files "test.log", "make.log" and
        "configure.log.

    8.  Execute the command "make install".  Redirect standard output
        and standard error to the file "install.log".  If an error occurs,
        then stop and send me the files "install.log", "test.log",
        "make.log" and "configure.log.

Please let me know if this helps.

> checking for Fortran-equivalent to netCDF "byte"... integer*1
> checking for Fortran-equivalent to netCDF "short"... integer*2
> checking for math library
> checking for -lc... (cached) yes
> checking for ar... (cached) ar
> checking for ranlib... (cached) ranlib
> checking for stdlib.h... (cached) yes
> checking for sys/types.h... (cached) yes
> checking for strerror... (cached) yes
> checking whether cross-compiling... (cached) no
> checking for working ftruncate()... no
> checking for working alloca.h... (cached) no
> checking for alloca... (cached) no
> checking whether alloca needs Cray hooks... (cached) no
> checking stack direction for C alloca... (cached) 1
> checking for st_blksize in struct stat... (cached) yes
> checking for IEEE floating point format... no
> checking for ANSI C header files... (cached) yes
> checking for size_t... (cached) yes
> checking for off_t... (cached) yes
> checking for ssize_t... (cached) yes
> checking for ptrdiff_t... (cached) yes
> checking for uchar... (cached) yes
> checking whether char is unsigned... (cached) yes
> checking whether byte ordering is bigendian... (cached) yes
> checking size of short... (cached) 8
> checking size of int... (cached) 8
> checking size of long... (cached) 8
> checking size of float... (cached) 8
> checking size of double... (cached) 8
> checking size of off_t... (cached) 8
> checking size of size_t... (cached) 8
> checking for catman... no
> checking for makewhatis... no
> checking for manual-page index command...
> checking binary distribution directory... /home/ftp/pub/binary/dummy_system
> creating ./config.status
> creating macros.make
> udcreating fortran/nfconfig.inc
> fortran/nfconfig.inc is unchanged
> creating libsrc/ncconfig.h
> libsrc/ncconfig.h is unchanged
> 
> 3.
> #undef NF_DOUBLEPRECISION_IS_C_DOUBLE
> #undef NF_DOUBLEPRECISION_IS_C_FLOAT
> 
> 4.
> <nothing>
> 
> 5.
> FORTRAN:
>   size of doubleprecision : 8 bytes
> C:
>   size of float: 8 bytes
>   size of double: 8 bytes
>   size of long double: 16 bytes
> 
> 
> some addtitional informations:
> 
> the reported problem is, when I use the 'netcdf.inc' include file.
> 
> If I use a module which declares interfaces for the functions
> (and not an include file), like
> 
> interface
> ...
>      INTEGER FUNCTION  NF_PUT_VAR1_DOUBLE(NCID, VARID, INDEX, DVAL)
>         integer,                       intent ( in) :: NCID
>         integer,                       intent ( in) :: VARID
>         integer,         dimension(:), intent ( in) :: INDEX
>         doubleprecision,               intent ( in) :: DVAL
>       end function NF_PUT_VAR1_DOUBLE
> ...
> end interface
> 
> NOTHING works!!!
> 
> Neither the netcdf2.4 ,nor the netcdf3.4 routines give an output.
> Neither with REAL, nor with doubleprecision!
> They return an error code -40.
> 
> WHY???
> 
> How can an interface produce such an error?

Russ Rew is handling this (separate) problem.  I'll forward this to him.

> 
> 
> (On an IBM RS/6000 C20 I have no problems with any of these problems)
> 
> Thanks,
> 
> Juergen Ankenbrand

--------
Steve Emmerson   <http://www.unidata.ucar.edu>