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.
> It is a while since we have been in contact - I have not been doing much > netCDF work. In fact the current state of my fan code is embarassing. > > Per Nyberg (NEC) has installed netCDF on our new NEC SX-4/16 with much > appreciated help of Glenn Davis. I have agreed to assist Per with netCDF. > > The main remaining task is providing for f77 IEEE-64-bit floating point mode. > The f77 compiler provides 3 options for REAL: IEEE-32-bit, IEEE-64-bit & > cray-64-bit. Per has implemented libraries for IEEE-32-bit & cray-64-bit, but > not IEEE-64-bit. I have taken on this task. > 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? - 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? > > I did a 'configure' as follows (under ksh) which seemed to work OK: > > CC='cc -Xa' \ > CFLAGS=-h2 \ > CXX='' \ > FC=f77 \ > FFLAGS='-float0 -ew' \ > ./configure > > Then I did a 'make' which produced the following message: > "ncx.c", line 1119: warning: #error detected: "ix_float implementation" > This comes from following section of code: > > #elif _SX && _FLOAT2 > ... > #else > #error "ix_float implementation" > #endif > > But it is not clear to me what preceding #if commences this cpp conditional. > In fact I suspect it may be missing! ncx.c is built from ncx.m4. The sequence of cases in ncx.m4 is as follows... #if X_SIZEOF_FLOAT == SIZEOF_FLOAT && !defined(NO_IEEE_FLOAT) ... the usual case #elif vax ... vax float #elif defined(_CRAY) ... cray architectures nested #if defined(NO_IEEE_FLOAT) ... Cray floating point #else ... IEEE Cray with only doubles #endif #elif _SX && _FLOAT2 SX computer pretending to be a cray #else #error "ix_float implementation" #endif I'm sorry this is so convuluted, it is a messy world. It could be better organized, especially since there is a cray specific file ncx_cray which works better for non IEEE crays. The reason you are getting stumped is that you are building in a mode where you are IEEE float (NO_IEEE_FLOAT is undefined) X_SIZEOF_FLOAT != SIZEOF_FLOAT (you only have 8 byte IEEE numbers and you are not a CRAY. 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 think that configuration for the FORTRAN interface will handle the case where a FORTRAN REAL is 8 bytes and the C 'float' remains 4 bytes. You should be able to get what you want without changing any code. Just be sure that float0 is the mode in force when you configure and compile the C code. Adding the -ew as you have done to the FFLAGS and the FORTRAN configuration should figure out to use the C double to hold FORTRAN REAL. 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. > 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. Hope this helps. If you are getting paid excessively, I want a cut. :-). (I have suffered greatly making netcdf work on an SX4 in Houston for some NCAR climate guys.) 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. -glenn