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.
Hi Bill, Check out this workaround to Tru64/Alpha default of not supporting IEEE floating-point: http://www.unidata.ucar.edu/netcdf/docs/known_problems_35.html#alpha-ieee It may be you have to specify a similar Fortran compiler flag to get standard IEEE floating- point exception handling, just to get past the netCDF tests. --Russ > I thought that I had filled out the system/machine-specifics in the > ticket submission form; but, in any case, the system is an HP AlphaServer > model GS160, 16cpus, 64GB mem running Tru64unix(aka OSF1) version 5.1B-6 > (BL29)-2650 with > > Fortran-77/90/95 HP Fortran V5.6-104654 > HP Fortran Compiler V5.6-104654-48F7C > > Compaq C V6.5-011 on HP Tru64 UNIX V5.1B (Rev. 2650) > Compiler Driver V6.5-003 (sys) cc Driver > > Compaq C++ V7.1-006 for HP Tru64 UNIX V5.1B (Rev. 2650) > Compiler Driver V7.1-006 (cxx) cxx Driver > > although C++ support was not enabled during the build. > > From config.log... > uname -m = alpha > uname -r = V5.1 > uname -s = OSF1 > uname -v = 2650 > > netCDF version 3.6.3 was chosen by the project group who will be running > the WRF weather modelling application in their request for project resources. > On checking the WRF site myself, I see that in the WRF required software, > there is a specific note regarding the use of netCDF-4 and disabling of > certain functionality, such as parallel-I/O and HDF5. I will review their > request with them and determine their specific reason for not wishing to > use netCDF-4.1.3. > Also I have found that there are compiler switches/directives that can be > set to customize the IEEE and floating-point environments for the C and > Fortran languages on Tru64unix. Perhaps setting a non-default value for > one of those options may address the issue. > > On rerunning the tests with 'make -i check', all of the tests succeeded > except for the 3 "floating-point exceptions" previously seen. > > If there is anything else that I could do to try to further isolate > the cause of the floating-point exceptions in testing in the Tru64unix > environment and perhaps determine a resolution, I would be glad help. > > Thanks for your assistance, > Bill > > >Return-path: <address@hidden> > >Date: Wed, 22 Feb 2012 12:45:24 -0700 > >From: Unidata netCDF Support <address@hidden> > >Subject: [netCDF #KKS-961190]: make check test FAILs in ncgen/ncdump section > >To: address@hidden > >Cc: address@hidden > >Reply-to: address@hidden > > > >I see that the problem is the occurrence of floating > >point exceptions. Please indicate what kind of machine > >and operating system you are using as we normally don't > >see those kinds of errors (they get converted to nan/inf > >values). > > > >in any case: > >1. this is a testing error. > > use "make -i check" to force make to complete all the > > tests and see if the floating point errors are the only > > failure. If so, then I would'nt worry about this. > >2. You should consider moving to, say, netcdf version 4.1.3. > > > > > >=Dennis Heimbigner > > Unidata > > > > > >Ticket Details > >=================== > >Ticket ID: KKS-961190 > >Department: Support netCDF > >Priority: Normal > >Status: Closed > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: KKS-961190 Department: Support netCDF Priority: Normal Status: Closed