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.
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.
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/ >
netcdfgroup archives: