more fortran tests with pnetcdf

[Rene Redler]

hi,

    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.

           IF (FVALUE .NE. 0.0 )
      +    INRANGE_FLOAT = (FVALUE .GE. MIN) .AND. (FVALUE .LE. MAX)

would solve this problem.



2nd) nfmpi_put_varm_* (NEC SX)

Regarding nfmpi_put_varm_* calls and its failure on the SX: Yes, all of 
the nfmpi_put_varm_* call produce segmentation violations. The first
part with start(2)=edge(2)=imap(2)=stride(2)=0 runs through.
The second pass with start(2)=edge(2)=imap(2)=stride(2)=1 is ok as well
with start(1)=2, edge(1)=1, but it fails in the next attempt to write
with start(1)=1 and edge(1)=2.

The error occures directly at the interface and it appears as if lengths
or types of arrays/variables are not consistent.


Rene