> --===============1463524217==
> Content-Type: multipart/alternative; boundary=20cf307d03c25700b904d5c918b0
>
> --20cf307d03c25700b904d5c918b0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> 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.
We know there are lots of users, because of all the netCDF Fortran
support questions we get. For example, there seems to be quite a bit of
interest in making a Windows version of the netcdf-fortran library
available. Currently our priority is creating a netCDF C 4.3 release
candidate. We're hampered by a lack of Fortran expertise among the two
of us who are working on C-based netCDF development, support, and
maintenance.
> 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).
You're right, future work will be based on the F03 version that
Dr. Richard Weed contributed. We've made a few updates to that, but
it's not releasable yet. There is an svn repository in case you want to
try it:
http://svn.unidata.ucar.edu/repos/netcdf-fortran/trunk/
and we'll gladly accept contributed fixes to that, if anyone sees
problems they can fix.
> Also a sneak peak into the beta version (
> http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-fortran-4.4-beta1.t=
> ar.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.
The svn trunk is later than that beta version, so please try it before
reporting problems that may have already been fixed.
Thanks!
--Russ
> Kind regards
>
> Nick
>
> 2013/2/15 Roy Dennington <roy@xxxxxxxxxxxx>
>
> > Fortran developers,
> >
> >
> >
> > Are the fortran bindings still under active development? Are people usin=
> g
> > the fortran lib? I am simply asking to get a gauge on the importance of
> > the library, because I don=E2=80=99t hear much from other developers on t=
> he 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 =E2=80=9Cnf_test=E2=80=9D failures on an =
> =E2=80=9Ci8=E2=80=9D build.
> >
> >
> >
> > Thanks,
> >
> > Roy Dennington
> >
> > Semichem, Inc.
> >
> >
> >
> > Using netcdf-4.2.1.1 and netcdf-fortran-4.2, building =E2=80=9Ci8=E2=80=
> =9D where integer
> > =3D=3D 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=3Difort
> >
> > export F77=3D$FC
> >
> > export F90=3D$FC
> >
> > export FCFLAGS=3D"-O -m64 -i8 -fp-model precise"
> >
> > export FFLAGS=3D$FCFLAGS
> >
> > export CFLAGS=3D"-O -arch x86_64"
> >
> > export CXXFLAGS=3D$CFLAGS
> >
> > export CPPFLAGS=3D"-DNDEBUG -DpgiFortran -D_REENTRANT"
> >
> > export LDFLAGS=3D"-fPIC"
> >
> >
> >
> > Running =E2=80=9Cmake check=E2=80=9D reveals a number of size-related pro=
> blems.
> >
> >
> >
> > [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 =E2=80=9C*4=E2=80=9D 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 =E2=80=9Cnf_fill_int64=E2=80=9D. 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 =E2=80=9Cnf_=E2=80=9D calls, but not =
> for =E2=80=9Cnf90_=E2=80=9D
> > calls, since the corresponding =E2=80=9Cnf_=E2=80=9D 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/
> >
>
> --20cf307d03c25700b904d5c918b0
> Content-Type: text/html; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
>
> <div>Respond in regards of "are people using the fortran lib". Ve=
> ry 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.<=
> /div>
>
> <div><br></div><div>I also believe that the bindings are still heavily deve=
> loped (just see the latest 4.2 release (march 2012) which split the C and F=
> ortran into two separate packages). I agree that there are still some lacki=
> ngs 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 wh=
> en the C has been built with support for debugging (however, this can easil=
> y be circumvented to directly call the c-interface).<br>
>
> </div><div><br></div><div>The current problem with the f90 interface is tha=
> t it can be cumbersome to maintain. This could be streamlined in a "at=
> compile time interface creation", which should make it easier to impl=
> ement changes to any interfaces, for example your int8 requirement.</div>
>
> <div><br></div><div>However, I believe that their main focus right now is t=
> o extend it into a F03 compliant interface. So I would not expect much feat=
> ure additions in the next release (if I am wrong, please correct me).</div>
>
> <div><br></div><div>Also a sneak peak into the beta version (<a href=3D"htt=
> p://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-fortran-4.4-beta1.tar.=
> gz">http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-fortran-4.4-bet=
> a1.tar.gz</a>) shows heavy design change which addresses some of the issues=
> I have stated above. From a quick glance, it also appears to address the i=
> nt8 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.</div>
>
> <div><br></div><div>Kind regards</div><div><br></div><div>Nick</div><br><di=
> v class=3D"gmail_quote">2013/2/15 Roy Dennington <span dir=3D"ltr"><<a h=
> ref=3D"mailto:roy@xxxxxxxxxxxx"; target=3D"_blank">roy@xxxxxxxxxxxx</a>><=
> /span><br>
>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"><div lang=3D"EN-US" link=3D"blue" vlink=3D"p=
> urple"><div><p class=3D"MsoNormal">Fortran developers,</p><p class=3D"MsoNo=
> rmal">=C2=A0</p>
>
> <p class=3D"MsoNormal">Are the fortran bindings still under active developm=
> ent? =C2=A0Are people using the fortran lib?=C2=A0 I am simply asking to ge=
> t a gauge on the importance of the library, because I don=E2=80=99t hear mu=
> ch from other developers on the list about fortran.=C2=A0 We still depend o=
> n the library, but it is getting harder to support because our needs are ex=
> panding to include 64-bit integer data.=C2=A0 We manage to keep the functio=
> nality we need working, but we are hacking the lib to make it work.</p>
>
> <p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">Is anyone else writ=
> ing 64-bit integer data using the fortran library?=C2=A0 I would very much =
> like to hear from you.=C2=A0 Maybe I have the wrong approach.</p><p class=
> =3D"MsoNormal">=C2=A0</p>
>
> <p class=3D"MsoNormal">Below =C2=A0is a report of sorts on =E2=80=9Cnf_test=
> =E2=80=9D failures on an =E2=80=9Ci8=E2=80=9D build.</p><p class=3D"MsoNorm=
> al">=C2=A0</p><p class=3D"MsoNormal">Thanks,</p><p class=3D"MsoNormal">Roy =
> Dennington</p><p class=3D"MsoNormal">Semichem, Inc.</p>
>
> <p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">Using netcdf-4.2.1.=
> 1 and netcdf-fortran-4.2, building =E2=80=9Ci8=E2=80=9D where integer =3D=
> =3D integer*8 by default,</p><p class=3D"MsoNormal">with the following sett=
> ings:</p><p class=3D"MsoNormal">
>
> =C2=A0</p><p class=3D"MsoNormal"># Intel Fortran with gcc (64-bit libraries=
> with integer*8)</p><p class=3D"MsoNormal"># You must init the ifort-64 env=
> ironment</p><p class=3D"MsoNormal">#</p><p class=3D"MsoNormal">export FC=3D=
> ifort</p><p class=3D"MsoNormal">
>
> export F77=3D$FC</p><p class=3D"MsoNormal">export F90=3D$FC</p><p class=3D"=
> MsoNormal">export FCFLAGS=3D"-O -m64 -i8 -fp-model precise"</p><p=
> class=3D"MsoNormal">export FFLAGS=3D$FCFLAGS</p><p class=3D"MsoNormal">exp=
> ort CFLAGS=3D"-O -arch x86_64"</p>
>
> <p class=3D"MsoNormal">export CXXFLAGS=3D$CFLAGS</p><p class=3D"MsoNormal">=
> export CPPFLAGS=3D"-DNDEBUG -DpgiFortran -D_REENTRANT"</p><p clas=
> s=3D"MsoNormal">export LDFLAGS=3D"-fPIC"</p><p class=3D"MsoNormal=
> ">=C2=A0</p><p class=3D"MsoNormal">
>
> Running =E2=80=9Cmake check=E2=80=9D reveals a number of size-related probl=
> ems.</p><p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">[1] The Mak=
> efile is slightly broken because the netcdff90 lib is not in the link list.=
> </p><p class=3D"MsoNormal">
>
> =C2=A0</p><p class=3D"MsoNormal">[2] Several functions are actually size-de=
> pendent, and can only be used explicitly integer*4.=C2=A0 For example, any =
> function that is defined with INT, INTV, PINT, or PVOID.=C2=A0 My list is p=
> robably not exhaustive.=C2=A0 I only looked at functions that were failing =
> the tests.</p>
>
> <p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">fort-nc4.c:</p><p c=
> lass=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">FCALLSCFUN3(NF_INT, nc_=
> inq_typeids, NF_INQ_TYPEIDS, nf_inq_typeids,</p><p class=3D"MsoNormal">=C2=
> =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
> =C2=A0 =C2=A0=C2=A0=C2=A0 NCID, PCINT2FINT, INTV)</p>
>
> <p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">FCALLSCFUN7(NF_INT,=
> nc_inq_user_type, NF_INQ_USER_TYPE, nf_inq_user_type,</p><p class=3D"MsoNo=
> rmal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
> =A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 NCID, FINT2CINT, PSTRING, PSIZET, PCINT2=
> FINT, PSIZET, PCINT2FINT)</p>
>
> <p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">FCALLSCFUN3(NF_INT,=
> nc_set_chunk_cache_ints, NF_SET_CHUNK_CACHE, nf_set_chunk_cache,</p><p cla=
> ss=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
> =A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 INT, INT, INT)</p><p class=
> =3D"MsoNormal">FCALLSCFUN3(NF_INT, nc_get_chunk_cache_ints, NF_GET_CHUNK_CA=
> CHE, nf_get_chunk_cache,</p>
>
> <p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
> =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 PINT, PINT, PINT)</p><=
> p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">FCALLSCFUN5(NF_INT, =
> nc_set_var_chunk_cache_ints, NF_SET_VAR_CHUNK_CACHE, nf_set_var_chunk_cache=
> ,</p><p class=3D"MsoNormal">
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
> =A0=C2=A0 =C2=A0=C2=A0=C2=A0 NCID, VARID, INT, INT, INT)</p><p class=3D"Mso=
> Normal">FCALLSCFUN5(NF_INT, nc_get_var_chunk_cache_ints, NF_GET_VAR_CHUNK_C=
> ACHE, nf_get_var_chunk_cache,</p><p class=3D"MsoNormal">=C2=A0=C2=A0=C2=A0=
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=
> =C2=A0=C2=A0 NCID, VARID, PINT, PINT, PINT)</p>
>
> <p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">FCALLSCFUN5(NF_INT,=
> nc_inq_enum_member, NF_INQ_ENUM_MEMBER, nf_inq_enum_member,</p><p class=3D=
> "MsoNormal">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
> =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 NCID, FINT2CINT, FNDX2CNDX, PSTRIN=
> G, PVOID)</p><p class=3D"MsoNormal">
>
> =C2=A0</p><p class=3D"MsoNormal">[3] By explicitly added integer*4, some of=
> the tests will pass correctly.=C2=A0 In nf_test, I added the =E2=80=9C*4=
> =E2=80=9D to fix a few of the cases.</p><p class=3D"MsoNormal">grep 'in=
> teger\*4' *.F</p><p class=3D"MsoNormal">
>
> ftst_vars.F:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 integer*4 CACHE_SIZE, CACHE_NELE=
> MS, CACHE_PREEMPTION</p><p class=3D"MsoNormal">ftst_vars.F:=C2=A0=C2=A0=C2=
> =A0=C2=A0=C2=A0 integer*4 cache_size_in, cache_nelems_in, cache_preemption_=
> in</p><p class=3D"MsoNormal">ftst_vars2.F:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in=
> teger*4 CACHE_SIZE, CACHE_NELEMS, CACHE_PREEMPTION</p>
>
> <p class=3D"MsoNormal">ftst_vars2.F:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 integer*=
> 4 cache_size_in, cache_nelems_in, cache_preemption_in</p><p class=3D"MsoNor=
> mal">ftst_vars3.F:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 integer*4 member_value, ty=
> peids(max_types)</p><p class=3D"MsoNormal">ftst_vars4.F:=C2=A0=C2=A0=C2=A0=
> =C2=A0=C2=A0 integer*4 data1(vlen_len), data1_in(vlen_len)</p>
>
> <p class=3D"MsoNormal">ftst_vars4.F:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 integer*=
> 4 vlen_in(10)</p><p class=3D"MsoNormal">ftst_vars5.F:=C2=A0=C2=A0=C2=A0=C2=
> =A0=C2=A0 integer*4 data1(compound_len), data1_in(compound_len)</p><p class=
> =3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">[4]=C2=A0 There is no corre=
> sponding =E2=80=9Cnf_fill_int64=E2=80=9D.=C2=A0 At least one test fails try=
> ing to check fill values.</p>
>
> <p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">[5] In ncfortran.h,=
> it would be extremely helpful if size_t and ptrdiff_t actually mapped to i=
> nteger*8 all the time.=C2=A0 As I discussed in a previous message, the fort=
> ran bindings do not match the netcdf C library.</p>
>
> <p class=3D"MsoNormal">=C2=A0</p><p class=3D"MsoNormal">[6] The problems ca=
> n be avoided for =E2=80=9Cnf_=E2=80=9D calls, but not for =E2=80=9Cnf90_=E2=
> =80=9D calls, since the corresponding =E2=80=9Cnf_=E2=80=9D calls need repa=
> ir in each of the nf90 wrappers.</p><p class=3D"MsoNormal">
>
> =C2=A0</p></div></div><br>_______________________________________________<b=
> r>
> netcdfgroup mailing list<br>
> <a href=3D"mailto:netcdfgroup@xxxxxxxxxxxxxxxx";>netcdfgroup@xxxxxxxxxxxxxxx=
> u</a><br>
> For list information or to unsubscribe, =C2=A0visit: <a href=3D"http://www.=
> unidata.ucar.edu/mailing_lists/" target=3D"_blank">http://www.unidata.ucar.=
> edu/mailing_lists/</a> <br></blockquote></div><br>
>
> --20cf307d03c25700b904d5c918b0--
>
>
> --===============1463524217==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> netcdfgroup mailing list
> netcdfgroup@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/m
> ailing_lists/
> --===============1463524217==--
