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

[netCDF #KKS-961190]: make check test FAILs in ncgen/ncdump section

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