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

[netCDF #MCW-760344]: Strange behaviour of nc_put_var

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [netCDF #MCW-760344]: Strange behaviour of nc_put_var
  • Date: Wed, 05 Sep 2012 15:56:37 -0600
> Full Name: Jan Aschmann
> Email Address: address@hidden
> Organization: University of Bremen, Institute of Environmental Physics
> Package Version: 4.1.3
> Operating System: AIX 6.1
> Hardware: IBM PowerPC 64-Bit
> Description of problem:
> 
> Dear Sir or Madam,
> 
> I have encountered a strange problem when trying to write an 2D integer
> array to a netcdf-file (see attached code). I use the 4.1.3 library on
> an IBM AIX 64-bit machine, compiled either completely with gcc/gfortran
> or xlC/xlf. In both cases, if I compile and run the attached program I
> get this kind of strange output (xlf version):
> 
> xlf95_r -q64 -O0 -qstrict -o test test.f90 
> -L/hb/jaschman/netcdf4_withHDF5/lib -lnetcdff -lnetcdf 
> -I/hb/jaschman/netcdf4_withHDF5/include -L/hb/jaschman/HDF5/lib -lhdf5_hl 
> -lhdf5
> ** test   === End of Compilation 1 ===
> 1501-510  Compilation successful for file test.f90.
> jaschman@odin:~> ./test
> write out to file... .nc
> 17 17 0 778986336
> 
> Apparently, the last line comes out of the nf90_put_var subroutine,
> representing a memory violation. This occurs also if I use gfortran with
> a correspondingly compiled netcdf-library.
> 
> Have I done something wrong in compiling the library in the first place? I 
> have used the following flags:
> export CC=xlc_r
> export CXX=xlC_r
> export F77=xlf_r
> export FC=xlf95_r
> export CFLAGS='-q64 -O3 -qstrict -qarch=auto -qtune=auto'
> export CXXFLAGS='-q64 -O3 -qstrict -qarch=auto -qtune=auto'
> export FFLAGS='-q64 -O3 -qstrict -qarch=auto -qtune=auto'
> export FCFLAGS='-qsuffix=f=f90 -q64 -O3 -qstrict -qarch=auto -qtune=auto'
> export CPPFLAGS='-DIBMR2Fortran'
> export ARFLAGS='-X64 -cru'
> export NMFLAGS=-X32_64
> 
> My configure:
> ./configure --prefix=/hb/jaschman/netcdf4_withHDF5 
> --with-hdf5=/hb/jaschman/hdf5 --disable-dap --disable-shared
> 
> Note that I got the same behaviour if I disabled netcdf4 features
> (i.e. compile without HDF5). The abnormal behaviour vanishes if I use
> another data type as integer for the variable int_date or if I add
> another dimension. Strange enough the resulting nc file is always
> correctly created, whether the mysterious output appears or not.
> Perhaps you can help me out in this case.

Hi Jan,

You did nothing wrong, the problem is a debugging statement that was
unfortunatelyly left in the netCDF-4.1.3 Fortran-90 code, as described here:

  http://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg10490.html

You could just remove the debugging statement and rebuild the library, or 
you could upgrade to the latest version of the netCDF C library (4.2.1.1)
and Fortran library (4.2).  They are not bundled together now, you need
to first build and install the C library, then build and install the Fortran
library, specifying where the C library was installed.  This is described here:

  http://www.unidata.ucar.edu/software/netcdf/docs/building.html

I just tried it out on your example, and it worked fine.

--Russ

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



Ticket Details
===================
Ticket ID: MCW-760344
Department: Support netCDF
Priority: Normal
Status: Closed