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
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.