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

NEC SX-4 64 bit IEEE Netcdf

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