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

Re: 20010808: netCDF on T3E

>To: address@hidden
>From: "Daniel S. Schaffer" <address@hidden>
>Subject: netCDF on T3E
>Organization: NOAA/FSL
>Keywords: 200108081441.f78Ef3125942

Dan,

This sounds like the netCDF library you're linking against was built
with a set of compiler options different from and inconsistent with
the compiler options you're using for your application.  On platforms
where you can specify to the compiler the size of basic types, it's
necessary to use the same specification for libraries and code that
will use those libraries.

Another possibility is that the Fortran compiler you are using has a
different size for variables declared "REAL" than the C compiler uses
for "float", and similarly for "INTEGER" and "int".  When the netCDF
library is built from source, the first step is to run a "configure"
script that is supposed to find the corresponding types and create
Makefiles so that the Fortran library is built properly on top of the
C library with the right data types.  

This is also supposed to be fairly extensively tested when you run
"make test" in the Fortran directory as part of building and
installing the netCDF library.  You might be able to see the right
flags to use with the Fortran compiler by running "make test" in the
netCDF source directory and see how the test code is compiled and
linked against the library.  Of course if the test fails, then that
points to a more basic problem we'll have to investigate further.

If the netCDF library was built with the wrong compiler flags on your
T3E (e.g. for a 64-bit environment and you want a 32-bit environment),
you build another version of the libraries from source with the C and
Fortran flags you want using the appropriate CFLAGS and FFLAGS
environment variables before running the configure script.  In this
case, for details see

  http://www.unidata.ucar.edu/packages/netcdf/INSTALL.html

For T3E-specific information about netCDF, see the NERSC site:

  http://hpcf.nersc.gov/software/libs/io/netcdf/

Please let us know, at address@hidden, if you need more
information or help.

--Russ


On Tue, 14 Aug 2001, Daniel S. Schaffer wrote:

> We now think we have a handle on our problem.  The netCDF on
> the T3E was expecting 64 bit reals and integers but we
> were passing 32 bit reals and integers.  Is there
> an easy way to configure netCDF to expect 32 bit?
> 
> Thanks,
> dan
> 
> On Wed, 8 Aug
> 2001, Russ Rew wrote:
> 
> > >To: address@hidden (netCDF support)
> > >From: "Daniel S. Schaffer" <address@hidden>
> > >Subject: netCDF on T3E
> > >Organization: NOAA/FSL
> > >Keywords: 200108081441.f78Ef3125942
> >
> > Hi Dan,
> >
> > > My colleague Tom Henderson and I have been in contact
> > > with Russell.  I recently have run into a problems with
> > > netCDF on a T3E.  I am executing the following code within
> > > an MPI program:
> > >
> > >       status=nf_open ('cgoa_grid_2.nc',nf_nowrite,ncid)
> > >       print *, 'got to 2'
> > >       status=nf_inq_att (ncid,nf_global,'type',attype,ltype)
> > >       print *, 'called nf_inq_att ', ncid, attype, ltype, status
> > >
> > >
> > > While I have not yet been able to isolate the problem completely,
> > > I get one of two behaviors depending on the rest of the code.
> > > Either I get:
> > > NC_SHARE not implemented for ffio
> > > in the call to nf_open
> >
> > First, is it possible you have not included the "netcdf.inc" include
> > file in this subroutine, so the parameters "nf_nowrite" and
> > "nf_global" are not initialized?  That would explain the symptoms.
> >
> > Also looking at the src for libsrc/ffio.c, it appears as if the message
> >
> >  NC_SHARE not implemented for ffio
> >
> > will only be printed if the "nf_share" mode bit has been set on open,
> > but since you are opening with "nf_nowrite" mode, that doesn't seem to
> > make sense.  The "nf_nowrite" parameter is initialized in the
> > netcdf.inc file as 0, whereas "nf_share" is initialized to be 2048.
> > Does another thread also open the file and set the "nf_share" flag
> > first?  If so, I don't think that will work; for the T3E parallel
> > netCDF used from multiple threads, you should instead be using the
> > "underbar underbar" functions like nc__open().  See the Fortran netcdf
> > man page for descriptions of these, which were explicitly added for
> > the T3E.
> >
> > > or I get status -49 in the call to nf_inq_att
> > >
> > > Any ideas what might be going on here?
> >
> > The status -49 for the Fortran interface is defined in the netcdf.inc
> > include file:
> >
> >       parameter (nf_enotvar = -49)
> >
> > which means "Variable not found" if you use the nf_strerror() to
> > convert it to an error message.  The variable id you supply,
> > "nf_global", is the ID of the global pseudo-variable and as a parameter
> > is assigned the value 0 in the netcdf.inc include file.  This should
> > always be "found".  Is it possible you have not included the
> > netcdf.inc file in this subroutine, so nf_global is uninitialized?
> >
> > --Russ
> >
> > _____________________________________________________________________
> >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                     http://www.unidata.ucar.edu
> >
> 
> -- 
> -------------------------------------------------------------------------------
> 
> Dan Schaffer, Research Associate            e-mail: address@hidden
> NOAA/ERL/Forecast Systems Lab               phone:  (303) 497-7252
> R/E/FS5  325 Broadway                       fax:    (303) 497-6301