Re: 20011130: NetCDF having failures on NERSC's IBM-SP!?

>To: <address@hidden>
>From: Dave Pierce <address@hidden>
>Subject: NetCDF having failures on NERSC's IBM-SP!?
>Organization: UCAR/Unidata
>Keywords: 200111301809.fAUI9bN23525

Hi Dave,

> I was startled to find that netCDF does not seem to work on NERSC's
> IBM-SP, the new one (seaborg).  I *think* it used to work on the old one
> (gseaborg);  not 100% sure on that, but I use netCDF a lot and think I
> would have noticed if it didn't work.  The following test program
> illustrates the problem.  It simply tries to make a netCDF file with
> dimensions 'Lat' and 'Lon':
> 
>         program driver
> 
>         include 'netcdf.inc'
> 
>         real  deltat
>         character*1000                  title
>         integer                         nx, ny, nt, ncid, xdimid, ydimid
> 
>         deltat = .5
>         nx = 10
>         ny = 20
>         nt = 30
> 
>         print *, 'creating file...'
>         ncid   = nccre( 'mldepth.nc', NCCLOB, err )
> 
>         print *, 'defining dim Lon...'
>         xdimid = ncddef( ncid, 'Lon', nx, err )
> 
>         print *, 'defining dim Lat...'
>         ydimid = ncddef( ncid, 'Lat', ny, err )
> 
>         print *, 'end def mode...'
>         err = nf_enddef( ncid )
> 
>         end
> 
> I compile it like this:
> (seaborg)173% !ma
> make test2
>         xlf -O -c test2.f -I/usr/local/include
> -I/usr/common/homes/d/dpierce/include
> -I/usr/common/homes/d/dpierce/src/f90_modules
> -I/usr/common/usg/netcdf/3.4/include
> ** driver   === End of Compilation 1 ===
> 1501-510  Compilation successful for file test2.f.
>         xlf -O -o test2 test2.o          -L/usr/local/lib
> -L/usr/common/homes/d/dpierce/lib -L/usr/common/usg/netcdf/3.4/lib
> -lcrdnetcdf -lnetcdf
> 
> And get the following output:
> 
> (seaborg)174% ./test2
>  creating file...
>  defining dim Lon...
>  defining dim Lat...
> ncdimdef: ncid 3: String match to name in use
> 
> !?!  Obviously, the name (Lat) should NOT be in use already, as only one
> other dim has been defined, and that was called 'Lon'.
> 
> I've tried various permutations of this, including using xlf90 instead of
> xlf, and using netCDF versions 3.4, 3.5, and 3.5b3, all of which are
> installed on seaborg and all of which generate the same error.  I
> originally noticed the error on another program that was working fine on
> another machine but died with this "string match to name in use" error
> when I compiled it on seaborg; I tried some other test programs that have
> always worked for me and they died on the same error as well.
> 
> I'm not entirely clear on what seaborg is; it's some kind of
> recently-installed IBM SP2 running AIX.  There may be more info at NERSC's
> web site if that is critical.

I just tried your program out on NCAR's IBM SP supercomputer
"blackforest", which is the only SP I have access to.  This has netCDF
3.5.1beta software installed, and it worked fine:

  $ uname -a
  AIX bf0909en 3 4 000129854C00
  $ xlf -O -c p.f -I/usr/local/include -o p -L/usr/local/lib32/r4i4 -lnetcdf
  ** driver   === End of Compilation 1 ===
  1501-510  Compilation successful for file p.f.
  $ ./p
  /bin/sh: ./p: 0403-006 Execute permission denied.
  $ xlf -O p.f -I/usr/local/include -o p -L/usr/local/lib32/r4i4 -lnetcdf
  ** driver   === End of Compilation 1 ===
  1501-510  Compilation successful for file p.f.
  $ ./p
   creating file...
   defining dim Lon...
   defining dim Lat...
   end def mode...

It appears as if the version you are accessing was built or installed
incorrectly.  It's also possible there is a mismatch between the way
the netCDF library was compiled and the way you are compiling the test
program, for example perhaps the library was compiled with 8-byte
reals or 8-byte integers.

I wouldn't think this has much to do with the version of the netCDF
library (3.4 vs. 3.5.1beta), since it's so basic.  All I can suggest
is that you try running the self test programs using "make test" in a
directory where you have write permission to see if the installed
library passes its self-tests.  Or contact the person who built and
installed the library and find out what compiler flags they used to
get it to pass its self-test and make sure you use the same flags ...

--Russ