Fortran developers,
Are the fortran bindings still under active development? Are people using
the fortran lib? I am simply asking to get a gauge on the importance of the
library, because I don't hear much from other developers on the list about
fortran. We still depend on the library, but it is getting harder to
support because our needs are expanding to include 64-bit integer data. We
manage to keep the functionality we need working, but we are hacking the lib
to make it work.
Is anyone else writing 64-bit integer data using the fortran library? I
would very much like to hear from you. Maybe I have the wrong approach.
Below is a report of sorts on "nf_test" failures on an "i8" build.
Thanks,
Roy Dennington
Semichem, Inc.
Using netcdf-4.2.1.1 and netcdf-fortran-4.2, building "i8" where integer ==
integer*8 by default,
with the following settings:
# Intel Fortran with gcc (64-bit libraries with integer*8)
# You must init the ifort-64 environment
#
export FC=ifort
export F77=$FC
export F90=$FC
export FCFLAGS="-O -m64 -i8 -fp-model precise"
export FFLAGS=$FCFLAGS
export CFLAGS="-O -arch x86_64"
export CXXFLAGS=$CFLAGS
export CPPFLAGS="-DNDEBUG -DpgiFortran -D_REENTRANT"
export LDFLAGS="-fPIC"
Running "make check" reveals a number of size-related problems.
[1] The Makefile is slightly broken because the netcdff90 lib is not in the
link list.
[2] Several functions are actually size-dependent, and can only be used
explicitly integer*4. For example, any function that is defined with INT,
INTV, PINT, or PVOID. My list is probably not exhaustive. I only looked at
functions that were failing the tests.
fort-nc4.c:
FCALLSCFUN3(NF_INT, nc_inq_typeids, NF_INQ_TYPEIDS, nf_inq_typeids,
NCID, PCINT2FINT, INTV)
FCALLSCFUN7(NF_INT, nc_inq_user_type, NF_INQ_USER_TYPE, nf_inq_user_type,
NCID, FINT2CINT, PSTRING, PSIZET, PCINT2FINT, PSIZET,
PCINT2FINT)
FCALLSCFUN3(NF_INT, nc_set_chunk_cache_ints, NF_SET_CHUNK_CACHE,
nf_set_chunk_cache,
INT, INT, INT)
FCALLSCFUN3(NF_INT, nc_get_chunk_cache_ints, NF_GET_CHUNK_CACHE,
nf_get_chunk_cache,
PINT, PINT, PINT)
FCALLSCFUN5(NF_INT, nc_set_var_chunk_cache_ints, NF_SET_VAR_CHUNK_CACHE,
nf_set_var_chunk_cache,
NCID, VARID, INT, INT, INT)
FCALLSCFUN5(NF_INT, nc_get_var_chunk_cache_ints, NF_GET_VAR_CHUNK_CACHE,
nf_get_var_chunk_cache,
NCID, VARID, PINT, PINT, PINT)
FCALLSCFUN5(NF_INT, nc_inq_enum_member, NF_INQ_ENUM_MEMBER,
nf_inq_enum_member,
NCID, FINT2CINT, FNDX2CNDX, PSTRING, PVOID)
[3] By explicitly added integer*4, some of the tests will pass correctly.
In nf_test, I added the "*4" to fix a few of the cases.
grep 'integer\*4' *.F
ftst_vars.F: integer*4 CACHE_SIZE, CACHE_NELEMS, CACHE_PREEMPTION
ftst_vars.F: integer*4 cache_size_in, cache_nelems_in,
cache_preemption_in
ftst_vars2.F: integer*4 CACHE_SIZE, CACHE_NELEMS, CACHE_PREEMPTION
ftst_vars2.F: integer*4 cache_size_in, cache_nelems_in,
cache_preemption_in
ftst_vars3.F: integer*4 member_value, typeids(max_types)
ftst_vars4.F: integer*4 data1(vlen_len), data1_in(vlen_len)
ftst_vars4.F: integer*4 vlen_in(10)
ftst_vars5.F: integer*4 data1(compound_len), data1_in(compound_len)
[4] There is no corresponding "nf_fill_int64". At least one test fails
trying to check fill values.
[5] In ncfortran.h, it would be extremely helpful if size_t and ptrdiff_t
actually mapped to integer*8 all the time. As I discussed in a previous
message, the fortran bindings do not match the netcdf C library.
[6] The problems can be avoided for "nf_" calls, but not for "nf90_" calls,
since the corresponding "nf_" calls need repair in each of the nf90
wrappers.
