Respond in regards of "are people using the fortran lib". Very much indeed.
I know of several codes/persons who use it on a daily basis. So its use in
the fortran community is quite extensive, to my knowledge.
I also believe that the bindings are still heavily developed (just see the
latest 4.2 release (march 2012) which split the C and Fortran into two
separate packages). I agree that there are still some lackings in the
fortran library, I have had numerous problems with fill values (as you say)
and also problems with the LOGGING functions not being built when the C has
been built with support for debugging (however, this can easily be
circumvented to directly call the c-interface).
The current problem with the f90 interface is that it can be cumbersome to
maintain. This could be streamlined in a "at compile time interface
creation", which should make it easier to implement changes to any
interfaces, for example your int8 requirement.
However, I believe that their main focus right now is to extend it into a
F03 compliant interface. So I would not expect much feature additions in
the next release (if I am wrong, please correct me).
Also a sneak peak into the beta version (
http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-fortran-4.4-beta1.tar.gz)
shows heavy design change which addresses some of the issues I have stated
above. From a quick glance, it also appears to address the int8 issue. I
don't really have any application use for that (yet), but if you decide to
check it out, please report back to the list.
Kind regards
Nick
2013/2/15 Roy Dennington <roy@xxxxxxxxxxxx>
> 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 mailing list
> netcdfgroup@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
>
