Parallel-NetCDF 1.0.0 pre-release for NEC SX

[Jianwei Li]

 	Hi, Rene,

 	Thank you for catching so many details!
 	Below, I'll try to give some explanation and possible fix.

On Thu, 14 Apr 2005, Rene Redler wrote:

> hi all,
>
>   the appropriate loader option forced the loader
> to build a binary by ignoring unresolved symbols.
> It was already documented in README.SX by myself ;(
> sorry.
>
> Nevertheless it would not be nice to have this
> in the final release since the user would have
> to set the loader option any time when linking
> against the libpnetcdf.a

 	You are right! We should remove those deprecated stuff
 	from pnetcdf.inc to make it clearer for fortran users.
>
> When running nf_test on the SX I noticed some problem
> with the int1 and int2 interfaces. Integer*1 is
> not supported by the SX compiler.
>
> During the configure the following is detected:
>
> checking size of short... (cached) 2
> checking size of int... (cached) 4
> checking size of long... (cached) 8
> checking size of float... (cached) 4
> checking size of double... (cached) 8
> checking size of size_t... (cached) 4
> checking sizeof MPI_Offset... (cached) 8
> checking size of MPI_Offset... (cached) 8
> checking for Fortran "byte"... no
> checking for Fortran "integer*1"... no
> checking for Fortran "integer(kind(1))"... yes
> checking for Fortran "integer*2"... yes
> checking if Fortran "integer(kind(1))" is C "signed char"... no
> checking if Fortran "integer(kind(1))" is C "short"... no
> checking if Fortran "integer(kind(1))" is C "int"... yes
> checking if Fortran "integer(kind(1))" is C "long"... no
> checking if Fortran "integer*2" is C "short"... no
> checking if Fortran "integer*2" is C "int"... yes
> checking if Fortran "integer*2" is C "long"... no
> checking if Fortran "integer" is C "int"... yes
> checking if Fortran "real" is C "float"... yes
> checking if Fortran "doubleprecision" is C "double"... yes
> checking for Fortran-equivalent to netCDF "byte"... integer
> checking for Fortran-equivalent to netCDF "short"... integer*2
> checking for Fortran "integer*8"... yes
>
> Then it seems to me as if the variable declarations in the
> interface are not consistent (in my mpinetcdf.h):
>
> When I look at the definition of the 4th parameter for the nfmpi_*_att_int* 
> family I find the following
>
> nfmpi_put_att_int1  :  char
> nfmpi_get_att_int1  :  int
>
> nfmpi_put_att_int2  :  int
> nfmpi_get_att_int2  :  short
>
> nfmpi_put_att_int   :  MPI_Fint
> nfmpi_get_att_int   :  int
>
> To me only the last pair seems to be consistent
> and it might explain what could go wrong here.

 	After a careful look at the above interfaces, I found
 	that the 6th parameter of nfmpi_put_att_int* corresponded
 	to the 4th parameter of nfmpi_get_att_int*. So they appear
 	to be consistant both as char/short/int respectively for
 	_int1/_int2/_int.

 	Since you said your platform NEC SX didn't support
 	FORTRAN integer*1, you were asking about the incorrectness
 	in handling integer*2 (int2), right?
 	Unfortunately, we were building the nfmpi_*_att_int2
 	interface by calling our ncmpi_*_att_short C implementations.
 	And based on your configure log, on your platform,
 	F integer*2 != C short (instead, F integer*2 == C int).
 	So I think that may be the problem.

 	There may be the same hidden problem in all FORTRAN
 	_int1/_int2/_int interfaces, because, in our current
 	implementation, they are hard-coded to call
 	C _char/_short/_int functions with char/short/int parameter types.
 	We should have made use of the configured information to
 	build this FORTRAN->C type-related function mappings as
 	well as type mappings.

 	For now, if you want to make your stuff work, you can
 	try directly modifying src/libf/put_att_int2f.c and
 	src/libf/get_att_int2f.c (as you already have a good
 	knowledge of our source code) to make them call
 	ncmpi_*_att_int() instead of ncmpi_*_att_short().
 	Also you may need to change the 6th/4th parameter type
 	from short to int in the FORTRAN function definition
 	in the above source code.

 	Besides get/put_att_* functions, I guess you need to do
 	the same for put_var*_int2f.c and get_var*_int2f.c
 	if you run into the same trouble for get/put_var* functions.

 	I hope this can help you get through the rest of your
 	test/work. We are sorry about the inconvenience and we
 	will fix this in our 1.0 release.

 	Best Regards,
 	Jianwei

>
> Are there any other ideas or suggestions how to fix this?
>
> Best regards, Rene
>