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.
Frank, >Date: Tue, 19 Mar 2002 12:04:30 +0100 >From: "Schmitz, Frank" <address@hidden> >Organization: ? >To: "Steve Emmerson" <address@hidden> >Subject: WG: 20020228: netCDF Fortran-90 on UXP/V using "ftr": typeSizes >unavailable >Keywords: 200202220850.g1M8oax11501 The above message contained the following: > Waiting for an answere! > The problem is again the same, the C-test is running, the Fortran-test will > fail on VPP5000. > Best Regards, > Frank Did you receive the enclosed email from me? Regards, Steve Emmerson <http://www.unidata.ucar.edu>
--- Begin Message ---
- Subject: 20020301: netCDF Fortran-90 on UXP/V using "ftr": SIGFPE in nf_test
- Date: Fri, 01 Mar 2002 09:49:42 -0700
Frank, >Date: Fri, 1 Mar 2002 08:34:41 +0100 >From: "Schmitz, Frank" <address@hidden> >Organization: ? >To: "Steve Emmerson" <address@hidden> >Subject: AW: 20020228: netCDF Fortran-90 on UXP/V using "ftr": typeSizes >unavailable >Keywords: 200202220850.g1M8oax11501 The above message contained the following: > Thank's, > the option -Am for the modul definition file should be add. > Now, the library was created and I've run the C interface tests > successful, but I've got a floating exception after calling > ./nf_test -c. After calling 'err = nf_put_att_double(ncid, > varid(i),ATT_NAME(j,i),ATT_TYPE(j,i),ATT_LEN(j,i), att) in the > function put_atts the error occurs in the routine ncx_put_int_double. > Now I'm debugging the problem, but do you have any ideas? > Best Regards, > Frank Some of the more extreme tests of the netCDF package can cause floating-point exceptions on some systems. Your system might be one of them. I'm surprised that you're seeing a SIGFPE, however, because the program "nf_test" calls the subroutine "ignorefpe", which is defined in file "nf_test/fortlib.c", which invokes the signal(3) function to cause SIGFPE to be ignored. It could be that your signal-handling system resets to the default behavior upon receiving a signal. This would be very non-standard behavior and I would complain to the vendor if it turned out to be true. The work-around would be to modify the "ignorefpe" function so that a signal-handling function receives the SIGFPE and reregisters itself for that signal every time. More on this can be found in the netCDF support-email archive at http://www.unidata.ucar.edu/glimpsedocs/ghnetcdf.html Try entering the search string "SIGFPE;signal". Regards, Steve Emmerson <http://www.unidata.ucar.edu>
--- End Message ---