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.
Eric, >Date: Fri, 30 Jul 2004 14:48:37 -0700 >From: Eric Salathe <address@hidden> >Organization: University of Washington >To: Steve Emmerson <address@hidden> >Subject: Re: 20040730: update: building netcdf 3.5.1 with NAG f95 v5.0 on OS X > Keywords: 200407302101.i6UL1haW016337 netCDF NAG F95 The above message contained the following: > Oops, you are right. I had made other hacks, which allowed it to work, > and forgot to remove them before blindly trying the cpp flag. That make more sense. > It is very odd, and I am sure and issue w/ NAG f95 v5.0. If I change > f90/netcdf_test.f90 calls to nf90_dev_var like this (add (/.../) around > latDimID): > > < call check(nf90_def_var(ncFileID, "lat", nf90_float, dimids = > latDimID, varID = latVarID) ) > --- > > call check(nf90_def_var(ncFileID, "lat", nf90_float, dimids = > (/latDimID/), varID = latVarID) ) > > the f90 test completes w/o error. So the NAGware issue has something to > do with how the rank of dimids is detected and the correct nf_* (f77) > routine is selected, but I get over my head after that. > > So, let me retract that NAG f95 v5.0 works. Version 4.2 successfully > builds netcdf 3.5.1, however. Interesting. The problem could lie with the compiler (we've seen another compiler have a problem). > -Eric > -- > Eric Salathe > Climate Impacts Group <address@hidden> > University of Washington > <http://www.atmos.washington.edu/~salathe> Regards, Steve Emmerson