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

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

Bill,

> I have been able to determine that the use of the -ieee flag to the C
> compiler and the use of either the -fpe1 or the -fpe3 flag to the Fortran
> compiler address the "floating-pont exceptions" issues encountered in
> testing netCDF 3.6.3.
> The difference in the -fpe1 and -fpe3 flags is the action taken with
> respect to action taken on denormalized numbers used in underflow calculatons:
> -fpe1 sets them to zero, -fpe3 retains their current value; otherwise with
> respect to divide-by-zero, overflow and invalid-data both -fpe1 and -fpe3
> generate the appropriate NaN or infinity.
> Does the netCDF software have a preference for either of the -fpe1 or -fpe3
> behaviours on denormalized numbers?

I don't think the tests done with "make check" distinguish between -fpe1 or 
-fpe3
on Tru64/Alpha platforms, but since we don't have such a platform on which to 
test 
things, I can't say for sure.  Try configuring with FFLAGS="-fpe3" first, and if
that passes all the tests, I'd recommend using it.  And if you actually want to
get run-time detection of underflow or overflow, which is not the default 
behavior 
for IEEE-conforming floating-point arithmetic, you could even just ignore the 
"make
check" problems and use the resulting library as is.  It will access and write 
data
just fine, unless the data is outside the range of normal arithmetic.

--Russ
> >Return-path: <address@hidden>
> >Date: Fri, 24 Feb 2012 06:20:42 -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
> >
> >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
> 
> 

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