[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netCDF #KKS-961190]: make check test FAILs in ncgen/ncdump section
- Subject: [netCDF #KKS-961190]: make check test FAILs in ncgen/ncdump section
- Date: Fri, 24 Feb 2012 06:20:42 -0700
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