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.
Marc, [In future correspondence, would you please configure your mailer to avoid unnecessary blank lines and "="s at the end of lines. Thanks.] >Date: Mon, 06 Dec 1999 19:31:54 +0100 >From: Marc Guyon <address@hidden> >Organization: . >To: address@hidden >Subject: Netcdf on Nec SX-5 >Keywords: 199912021756.KAA15510 In the above message, you wrote: > many thanks for your reply, I followed your instructions, excepted that I= > = > prefered to avoid optimisation options and to use debug options for the C= > = > (-h0,ansi -g) and the f90 (-Cdebug) compiler : the test results are the s= > ame = > with the same message of compilation without the vectorization warning...= > I = > didn't build the c++ interface because it is safe... > > so the the different variables are : > > uqbar-ssos555 : echo $CC > cc > uqbar-ssos555 : echo $FC > f90 > uqbar-ssos555 : echo $CFLAGS > - -h0,ansi -g > uqbar-ssos555 : echo $FFLAGS > - -dw -dW -Cdebug > > the A, B, C, D, E, F and G item have been placed in the compressed (gzip)= > tarfile attached above : > > mira : ls > VERSION configure.log path.log uname.log > config.log make.log test.log > > mira : pwd > /tmp/Netcdf.Log > > mira : = > > > Here, there is the true result of the ncgen test, I suppose you are right= > and = > > the differences are due to numbers representation and machine precision..= > =2E > > *** ncgen -b test successful *** > =2E/ncgen -c -o ctest0.nc c0.cdl > ctest.c && \ > cc -o ctest -h2,float0,ansi -I../libsrc -I. -DNDEBUG ctest.c ../libsrc/= > libnet > cdf.a && \ > =2E/ctest && \ > =2E./ncdump/ncdump -n c1 ctest0.nc > ctest1.cdl > 21c21 > < i:d =3D -1.e+308, 0., 1.e+308 ; > - --- > > i:d =3D -9.99999999999999e+307, 0., 9.99999999999999e+307= > ; > 101c101 > < :Gd =3D -1.e+308, 0., 1.e+308 ; > - --- > > :Gd =3D -9.99999999999999e+307, 0., 9.99999999999999e+307= > ; > 128c128 > < dr =3D -1e+308, 1e+308 ; > - --- > > dr =3D -9.99999999999999e+307, 9.99999999999999e+307 ; > 140c140 > < d1 =3D -1e+308 ; > - --- > > d1 =3D -9.99999999999999e+307 ; > 152c152 > < d2 =3D -1e+308, 1e+308 ; > - --- > > d2 =3D -9.99999999999999e+307, 9.99999999999999e+307 ; > 164c164 > < d3 =3D -1e+308, 0, 1e+308 ; > - --- > > d3 =3D -9.99999999999999e+307, 0, 9.99999999999999e+307 ; > *** ncgen -c test failed *** > gmake: *** [c-test] Error 1 Yes. I wouldn't worry about the above "errors". They have more to do with printing capabilities than an actual problem. In your file "test.log", the following occur: *** Testing nf_get_var1_int1 ... Range error: No error Range error: No error Range error: No error Range error: No error *** Testing nf_get_var_int1 ... Range error: No error Range error: No error Range error: No error Range error: No error *** Testing nf_get_vara_int1 ... Range error: No error Range error: No error Range error: No error Range error: No error *** Testing nf_get_vars_int1 ... Range error: No error Range error: No error Range error: No error Range error: No error *** Testing nf_get_varm_int1 ... Range error: No error Range error: No error Range error: No error Range error: No error *** Testing nf_get_att_int1 ... Range error: No error Range error: No error Based on the commentary in the INSTALL file regarding the SX-4 computer, I belive that the above error may be safely ignored. The "errors" come from reading in an NF_BYTE value that shouldn't be possible, but on your system, NF_BYTE-s are 16-bit integers and have a greater range than the test assumes. To sumarize, I belive that your build of this version of the netCDF package was successful. -------- Steve Emmerson <http://www.unidata.ucar.edu>