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.
>To: address@hidden >From: Anlauf Harald <address@hidden> >Subject: Re: 20040409: netCDF-3.5.1, CYGWIN and NAG f95 >Organization: Deutscher Wetterdienst (DWD) >Keywords: 200404081303.i38D3UCT005417 Hi Harald, Thanks for your message to netcdfgroup and the patches you provided. I have a few comments. > 1) The file cfortran.h coming with netCDF is quite ancient, it should be > replaced by a more recent one or patched suitably. By googling one can > certainly find most necessary but scattered information. We made some local modifications to version 4.1 of cfortran.h and had contacted Burkhard Burow to get them incorporated into his maintained version, but for whatever reason, they didn't get in. I think it will be possible to integrate our changes into cfortran.h version 4.3, but we have problems testing the result, since we don't have access to all the compilers and platforms it is supposed to support. But we will look at the change you suggest and try to include it in next version. > If somebody knows how to correctly auto-detect the type of the Fortran 95 > compiler, > he or she might also set suitable defaults for the compiler options, such as > "-mismatch -w=unused" for the NAG compiler. One of our goals for netCDF version 3.6 is to upgrade the autoconf/automake/libtool process we use to create the configure script and Makefiles. We're hoping that the new version of these tools will work better with cygwin and other platforms, and will provide better support for newer versions of Fortran and C++ compilers. > 2) The following patch should be applied to the source distribution > > --- ./nf_test/nf_test.F.orig 1997-06-11 18:20:48.000000000 +0200 > +++ ./nf_test/nf_test.F. 2004-04-06 14:41:37.375000000 +0200 > @@ -81,6 +81,9 @@ > ! DIGITAL Visual Fortran needs DFPORT for iargc > USE DFPORT > implicit none > +#elif defined(NAGf90Fortran) > + USE F90_UNIX_ENV, only : iargc, getarg > + implicit none > #else > implicit none > integer iargc It's not clear to me whether this change is intended to be independent of your first patch to cfortran.h. Should this change be made independently of whether patch 1) is made, or only if patch 1) is also made? We could test that, but we don't currently have access to a NAG f90. > 3) In the file ncx.c there is a bug which throws an floating point exception > with NAG f95. Running the Fortran 90 tests after compiling yields a core > dump: > > [...] > 00400000:D:/cygwin/usr/local/src/packages/netcdf-3.5.1/src/nf_test/nf_test.e > xe ( > symbols previously loaded) > #0 0x00450bad in ncx_put_short_double ( > xp=0xa0484ac, ip=0x22edb8) at ncx.c:408 > 408 ix_short xx = *ip; > (gdb) l 408 > 403 } > 404 > 405 int > 406 ncx_put_short_double(void *xp, const double *ip) > 407 { > 408 ix_short xx = *ip; > 409 put_ix_short(xp, &xx); > 410 if(*ip > X_SHORT_MAX || *ip < X_SHORT_MIN) > 411 return NC_ERANGE; > 412 return ENOERR; > (gdb) print *ip > $1 = -32769 > (gdb) > > Clearly, the assignment to the short xx should be made _after_ the range > check, not before! I do not know what should happen when *ip is outside the > range for shorts, so this is something for the maintainers to look into and > to fix. We need to look at this more carefully before we decide what to do about it. Thanks for pointing out the problem. --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu/staff/russ