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.
Glenn, On Mon, 24 Nov 1997, Glenn P. Davis wrote: > > What we want is as follows: > > C int 32 bits > > C long 64 bits > > C float 32 bits > > C double 64 bits > > f77 INTEGER 64 bits > > f77 REAL 64 bits > > f77 DOUBLE 64 bits > > I'm not clear on what the real goal is here. > > I understand that he wants the calculations done in IEEE 64 bit registers. > > - Does he want to simply wish to avoid converting declarations > to REAL*8 or DOUBLE PRECISION? Yes it is to avoid converting declarations from REAL to DOUBLE PRECISION. This will ease migration of code from cray. > - Does he want to store the results on disk as NC_FLOAT or as NC_DOUBLE? > > - Does he require that the netcdf-2 fortran interface for NC_FLOAT take > a REAL argument, even when REAL is 64 bits? Yes. This is same as cray. i.e. NC_FLOAT corresponds to REAL NC_DOUBLE corresponds to DOUBLE PRECISION even though REAL and DOUBLE PRECISION are both 64 bits. > Given the CFLAGS and FFLAGS you present above, I think there must be > some FLMOD enviroment variable in force that is hosing you up. > The default C build on that machine (float0) should give you what you > want in the C lib without error. I think you can force the issue > by explictly saying float0 to the C compiler. I took your advice & tried specifying argument float0 to C compiler. This did solve the problem. Thanks. I do not understand why I got some other mode by default. So now 'make' seems to work ok. Then 'make test' runs two C tests ok, but then fails as follows in directory src/fortran: f77 -o ftest -float0 -ew ftest.o ../libsrc/libnetcdf.a undefined first referenced symbol in file nf_get_varm_int2_ ftest.o nf_get_varm_int1_ ftest.o nf_get_vars_int2_ ftest.o nf_get_vars_int1_ ftest.o nf_get_vara_int2_ ftest.o nf_get_vara_int1_ ftest.o nf_get_var1_int2_ ftest.o nf_get_var1_int1_ ftest.o nf_get_var_int2_ ftest.o nf_get_var_int1_ ftest.o nf_get_att_int2_ ftest.o nf_get_att_int1_ ftest.o nf_put_varm_int2_ ftest.o nf_put_varm_int1_ ftest.o nf_put_vars_int2_ ftest.o nf_put_vars_int1_ ftest.o nf_put_vara_int2_ ftest.o nf_put_vara_int1_ ftest.o nf_put_var1_int2_ ftest.o nf_put_var1_int1_ ftest.o nf_put_var_int2_ ftest.o nf_put_var_int1_ ftest.o nf_put_att_int2_ ftest.o nf_put_att_int1_ ftest.o ld fatal: symbol referencing errors. no output written to file ftest. f77 fatal : ld command error : 13 I suspect these entry points are not needed, but they cause linkinf to fail. > Optimization (vectorization) is more interesting. > If conversion between (64 bit) REAL and NC_FLOAT is desired, > ncx_putn_float_double() and ncx_getn_float_double() will be the > critical sections, and you will probably want to do a vector implementation > with the appropriate pragma or whatever. > If converting between REAL and NC_DOUBLE is desired. > ncx_putn_double_double() and ncx_getn_double_double() will be critical. Noted. > > I do not know how the netCDF version 3 Fortran interface works. What > > library > > code is involved? > > Like the new nc_ C library routines, there are NF_ FORTRAN library routines > which are type specific. These are defined in src/fortran/*.c in terms of the > C routines using an excessive amount of C preprocessor magic. > The old netcdf-2 fortran routines are also defined in > src/fortran/fort-v2compat.c. > If you are getting paid excessively, I want a cut. :-). I am not being paid anything (let alone excessively) by NEC I'm afraid! :-( > BTW, what did you think about the proposed performance tuning > interfaces? I sent some email about it in October and didn't hear > back from you. Sorry. I lost my mail inbox last month in a big reorganisation of hardware, network & software. Would you please resend the message. I remember skimming your message quickly but had not got round to considering it in detail when the mail disaster occured. Thanks again for your prompt, detailed & most helpful reply, Harvey Harvey Davies, CSIRO Mathematical and Information Sciences, Email: address@hidden Phone: +61 3 9669 8110 or +61 3 9239 4556 Fax: +61 3 9669 8112