PGF Compiler problems with size statement

[frae]

The pgf compiler exists with a:

0: SIZE: invalid dim

statement when reading a netCDF file with ropp2ropp (also with ropp2bufr). This seems to be caused by statements in

ropp_io/ncdf/ncdf_getvar.f90

that access an undefined dimension in a variable with size (size(rvalues, i) statement below).

  do i = 1, ndims
     status = nf90_inquire_dimension(ncid_local, dimids(i), len = cnts(i))
     if (status /= nf90_noerr) call ncdf_error_handler(status)
     cnts(i) = min(cnts(i), size(rvalues, i))
  enddo

i is e.g. 2 even though the variable itself is just a vector, since the second dimension is the record (unlimited) one. The answer of size(rvalues, i) depends on the compiler for i>1, some give undefined numbers, some just the found size of the first dimension and the pgf95 does not like it at all.

[frae]

Temporary solution implemented into ropp_io revision 662. The problem was caused by calls to:

status = nf90_inquire_variable(ncid_local, varid, &
                               ndims = ndims, dimids = dimids)

which returns 2 for a vector string variable. I assume this refers to the unlimited rec dimension, although I do not understand why this is happening. The docu seems to indicate it should return 1 instead. The above code has been modified:

  do i = 1, ndims
     status = nf90_inquire_dimension(ncid_local, dimids(i), len = cnts(i))
     if (status /= nf90_noerr) call ncdf_error_handler(status)
!    immediate exit if rec dimension is done
     if (i > size(shape(rvalues))) exit
     cnts(i) = min(cnts(i), size(rvalues, i))
  enddo

and similar for all statements in ropp_io/ncdf/ncdf_getvar.f90 and ncdf_putvar.f90. Not sure if this is necessary for all of these statements or just the string ones. This is likely a temporary fix and I leave this ticket open. pgf now working with this solution.

[frae]

Redid this since it was overwritten by EightByteInt inclusion in ncdf files. So these changes should become permanent in the m4 files, not the f90 files!

Also, when looking at the difference between my modified and the m4 generated files, I would expect only additions to the f90 files that take care of EightByteInt variables. This does not seem to be the case when looking at the diff in TRAC. Might be a problem with diff getting confused with the new additions but I want to make sure that the m4 files are the ones generating the f90 files, f90 files are not modified afterwards. Is this so?

Change this to Severity major!

[marq]

Ok,

I'm not quite sure what the problem is - I probably have to check out the source code for that.

There are several things: First, it is indeed correct that the number of elements for a string variable is 2 if has an unlimited dimension. The reason is that netcdf doesn't know the concept of strings; each 'string' actually is an array of characters, with an associated dimension. If it also has an unlimited dimension, the total number of dimensions is two, as you observed. If the code in the string version of the ncdf_[put|get]var routine is inded buggy, we should fix it properly.

Secondly, it is indeed true that most (but not all) of the .f90 files are autogenerated from the corresponding .m4 files. Otherwise, it wouldn't be possible to maintain all the different interfaces! Therefore, all changes should be made in the corresponding .m4 files; if not, they will be overwritten at the next occasion when the .f90's are regenerated.

Thirdly, I would very much prefer if could keep the ROPP version of the netCDF interface in line with the ncdf90 library, i.e. make fixes there and then propagate them to the version in the ROPP. Ncdf90 is a stand-alone library which I simply dropped into the ROPP, and I don't want to maintain two different versions. There will be a web site for it soon, promised...

I do not understand your EightByteInt stuff, but maybe that's because I haven't looked everything yet;-) For the time being, could you try to give me an example file where the problem occurs with the pgf, but not with the other ones?

Chris.

[frae]

The at the bottom attached fortran file runs fine with ifc, output:

 Element:            1  Size Output:          10
 Element:            2  Size Output:          10
 Element:            3  Size Output:          10
 Element:            4  Size Output:          10
 Element:            5  Size Output:          10
 Element:            6  Size Output:          10
 Element:            7  Size Output:          10
 Element:            8  Size Output:          10
 Element:            9  Size Output:          10
 Element:           10  Size Output:          10

it also runs with ifort, output:

 Element:            1  Size Output:          10
 Element:            2  Size Output:           0
 Element:            3  Size Output:           9
 Element:            4  Size Output:   134780584
 Element:            5  Size Output:           5
 Element:            6  Size Output:           0
 Element:            7  Size Output:          13
 Element:            8  Size Output:   134780612
 Element:            9  Size Output:   134780612
 Element:           10  Size Output:           0

but not with pgf95, output:

 Element:             1  Size Output:           10
0: SIZE: invalid dim

And pgf is right in complaining since I only access an array, not a matrix. I also found some other compilers complaining about this (e.g. SGI).

For the eightbyte extension, I guess that is a problem in TRAC when too many differences are present. Since m4 is generating the f90 files, this should be okay now. I leave any ncdf90 changes up to you...

Fortran File:

---

PROGRAM TEST_SIZE

! test size statement of compilers

  real, dimension(10) :: TESTARR1

  DO I=1,10
  print*, 'Element: ',i, ' Size Output:',size(TESTARR1,i)
  enddo

END PROGRAM

[marq]

Changeset [694]includes an updated version of the ncdf90 library, which should fix this problem. The solution is based on Axel's solution, but has a few additional tweaks to give error messages if the the values of start and count arrays are inconsistent with the array dimensionality. However, parts of this haven't been tested yet; please reopen the ticket if a similar problem occurs again.

[(none)]

Milestone 0.8 deleted