Re: more fortran tests with pnetcdf

Hi Rene,

>     some more examination of problems reported earlier
> revealed the following:
> 
> 1st) test_nf_*_put_real  (Linux)
> 
>    I was misleading to investigate test.nc, since these
> test routines write their own scratch files. Her I see
> only negative number for integers "ir". Moreover, I get
> the same on different systems. The fact that a positive
> real 2147483647.0 is converted to a negative
> -2147483648 can perhaps be demonstrated by the simple
> program below. 2147483647 is the largest number that
> can be represented with a 4 byte integer.
> 
>        program int_conv
>        real    r4
>        integer i4
>        r4 = 2147483647.0
>        i4 = r4
>        write (*,'(i12)') i4
>        end
> 
> This is not a particular problem of the parallel NetCDF
> test case but I also got similar results when re-investigating
> the nf_test shipped with NetCDF-3.5.1.
> 
> The fact that reading and comparing these values does not lead
> to errors during the nf_test on some systems can be traced down
> to FUNCTION INRANGE_FLOAT (util.F) which checks, whether the
> expected value (always a double and determined internally) lies
> in a given range for a particular datatype, here NF_INT for "ir" .
> 
> The critical piece of the code is the else branch in
> 
>        IF (.NOT.((VALUE .GE. MIN) .AND. (VALUE .LE. MAX))) THEN
>            INRANGE_FLOAT = .FALSE.
>        ELSE
>            FVALUE = VALUE
>            INRANGE_FLOAT = (FVALUE .GE. MIN) .AND. (FVALUE .LE. MAX)
>        END IF
> 
> where some compilers (Intel and Absoft) assign a zero to FVALUE, other 
> assign something else (NEC SX, g77).
> 
> This problem is not particular to parallel NetCDF but also
> shows up in NetCDF-3.5.1.
> 
> I don't know whether the assignment of double to float (FVALUE = VALUE)
> is well defined in the Fortran standard. Maybe this issue can be 
> forwarded to the original developers of nf_test.

I've forwarded your description of the problem to Steve Emmerson.  He
may be asking for more details.

Thanks for your efforts in tracking down and reporting this problem.

--Russ

_____________________________________________________________________

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