NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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.
netcdfgroup
archives: