Hello Pierre, What do you mean by fortran90 programs require fortran 2003 features?
Regards, 2017-11-08 16:43 GMT-05:00 <[email protected]>: > Send Hdf-forum mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_ > lists.hdfgroup.org > > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Hdf-forum digest..." > > > Today's Topics: > > 1. Re: no specific subroutine for the generic ?h5dread_f? > (Pierre de Buyl) > 2. Re: Collective IO and filters (Dana Robinson) > 3. Re: Collective IO and filters (Michael K. Edwards) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 8 Nov 2017 22:39:32 +0100 > From: Pierre de Buyl <[email protected]> > To: [email protected] > Subject: Re: [Hdf-forum] no specific subroutine for the generic > ?h5dread_f? > Message-ID: <20171108213932.GJ2236@pi-x230> > Content-Type: text/plain; charset=utf-8 > > Also, some ".f90" programs require the "fortran2003" feature as well. This > is a > possible cause ofr "no specific subroutine for the generic" problem. > > Pierre > > On Mon, Nov 06, 2017 at 02:49:44PM +0000, Scot Breitenfeld wrote: > > Can you include how you declared your arguments in h5dread_f? I would > suspect that one of your arguments is wrong and the compiler is not finding > the correct interface. > > > > Scot > > > > > On Nov 4, 2017, at 12:03 AM, Guido granda mu?oz <[email protected]> > wrote: > > > > > > Hello, > > > > > > I am having trouble with a code that uses hdf5. The code is written in > fortran90 it consists of a main program(proccor.f90) and a > module(module_correlation_functions.f90). > > > > > > After using the makefile to compile the code, I get the following > error: > > > > > > gfortran -O3 -c module_correlation_functions.f90 > -I/usr/local/hdf5/include -L/usr/local/hdf5/lib > /usr/local/hdf5/lib/libhdf5hl_fortran.a /usr/local/hdf5/lib/libhdf5_hl.a > /usr/local/hdf5/lib/libhdf5_fortran.a /usr/local/hdf5/lib/libhdf5.a -lz > -ldl -lm -Wl,-rpath -Wl,/usr/local/hdf5/lib > > > module_correlation_functions.f90:1583:68: > > > > > > call h5dread_f(dset_id,H5T_IEEE_F32BE,x,npart,error) > > > 1 > > > Error: There is no specific subroutine for the generic ?h5dread_f? at > (1) > > > module_correlation_functions.f90:1588:68: > > > > > > call h5dread_f(dset_id,H5T_IEEE_F32BE,y,npart,error) > > > 1 > > > Error: There is no specific subroutine for the generic ?h5dread_f? at > (1) > > > module_correlation_functions.f90:1593:68: > > > > > > call h5dread_f(dset_id,H5T_IEEE_F32BE,z,npart,error) > > > 1 > > > Error: There is no specific subroutine for the generic ?h5dread_f? at > (1) > > > makefile:38: recipe for target 'module_correlation_functions.o' failed > > > make: *** [module_correlation_functions.o] Error 1 > > > > > > > > > The makelife I used to compile the code includes the location of the > hdf5 library : > > > > > > > > > LIBSHDF=-I/usr/local/hdf5/include -L/usr/local/hdf5/lib > /usr/local/hdf5/lib/libhdf5hl_fortran.a /usr/local/hdf5/lib/libhdf5_hl.a > /usr/local/hdf5/lib/libhdf5_fortran.a /usr/local/hdf5/lib/libhdf5.a -lz > -ldl -lm -Wl,-rpath -Wl,/usr/local/hdf5/lib > > > FCFLAGS = -O3 > > > # List of executables to be built within the package > > > PROGRAMS = procorr > > > > > > # "make" builds all > > > all: $(PROGRAMS) > > > > > > procorr.o: module_correlation_functions.o > > > procorr: module_correlation_functions.o > > > > > > # ============================================================ > ========== > > > # And now the general rules, these should not require modification > > > # ============================================================ > ========== > > > > > > # General rule for building prog from prog.o; $^ (GNU extension) is > > > # used in order to list additional object files on which the > > > # executable depends > > > %: %.o > > > $(FC) $(FCFLAGS) -o $@ $^ $(LIBSHDF) > > > > > > # General rules for building prog.o from prog.f90 or prog.F90; $< is > > > # used in order to list only the first prerequisite (the source file) > > > # and not the additional prerequisites such as module or include files > > > %.o: %.f90 > > > $(FC) $(FCFLAGS) -c $^ $(LIBSHDF) > > > > > > # Utility targets > > > .PHONY: clean veryclean > > > > > > clean: > > > rm -f *.o *.mod *.MOD > > > rm -f .last_fourier_transform > > > rm -f cdm_redshift0_* > > > rm -f *~ $(PROGRAMS) > > > > > > The call hdf5 statement is located on the module file > (module_correlation_functions.f90) > > > > > > I am probably doing something wrong on the makefile because I used the > same hdf5 library location to compile another fortran90+hdf5 code without > any trouble. Could please help me ? > > > > > > The gfortran version used is: GNU Fortran (Ubuntu > 5.4.0-6ubuntu1~16.04.4) 5.4.0 > > > and the hdf5 version is: hdf5-1.8.19 compiled with the enable fortran > option. > > > > > > > > > > ------------------------------ > > Message: 2 > Date: Wed, 8 Nov 2017 21:41:42 +0000 > From: Dana Robinson <[email protected]> > To: "[email protected]" <[email protected]> > Cc: HDF Users Discussion List <[email protected]> > Subject: Re: [Hdf-forum] Collective IO and filters > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Yes. We already do this in our test harness. See test/dynlib3.c in the > source distribution. It's a very short source file and should be easy to > understand. > > Dana > > On 11/8/17, 13:28, "Michael K. Edwards" <[email protected]> wrote: > > Thank you, Dana! Do you think it would be appropriate (not just as of > the current implementation, but in terms of the interface contract) to > use H5free_memory() on the buffer passed into an H5Z plugin, replacing > it with a new (post-compression) buffer allocated via H5allocate()? > > On Wed, Nov 8, 2017 at 1:23 PM, Dana Robinson <[email protected]> > wrote: > > The public H5allocate/resize/free_memory() API calls use the > library's > > memory allocator to manage memory, if that is what you are looking > for. > > > > > > > > https://support.hdfgroup.org/HDF5/doc/RM/RM_H5.html > > > > > > > > Dana Robinson > > > > Software Developer > > > > The HDF Group > > > > > > > > From: Hdf-forum <[email protected]> on behalf of > Jordan > > Henderson <[email protected]> > > Reply-To: HDF List <[email protected]> > > Date: Wednesday, November 8, 2017 at 12:59 > > To: "[email protected]" <[email protected]> > > Cc: HDF List <[email protected]> > > Subject: Re: [Hdf-forum] Collective IO and filters > > > > > > > > Ah yes, I can see what you mean by the difference between the use of > these > > causing issues between in-tree and out-of-tree plugins. This is > particularly > > interesting in that it makes sense to allocate the chunk data > buffers using > > the H5MM_ routines to be compliant with the standards of HDF5 library > > development, but causes issues with those plugins which use the raw > memory > > routines. Conversely, if the chunk buffers were to be allocated > using the > > raw routines, it would break compatibility with the in-tree filters. > Thank > > you for bringing this to my attention; I believe I will need to > think on > > this one, as there are a few different ways of approaching the > problem, with > > some being more "correct" than others. > > > > ------------------------------ > > Message: 3 > Date: Wed, 8 Nov 2017 13:43:15 -0800 > From: "Michael K. Edwards" <[email protected]> > To: Dana Robinson <[email protected]> > Cc: HDF Users Discussion List <[email protected]> > Subject: Re: [Hdf-forum] Collective IO and filters > Message-ID: > <CAJ0nH1gaxnfyGcOiaaJ1rd-jdpWdsw8f4iXRewHFW7y7gCWuFQ@ > mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Great. What's the best way to communicate this to plugin developers, > so that their code gets updated appropriately in advance of the 1.12 > release? > > On Wed, Nov 8, 2017 at 1:41 PM, Dana Robinson <[email protected]> > wrote: > > Yes. We already do this in our test harness. See test/dynlib3.c in the > source distribution. It's a very short source file and should be easy to > understand. > > > > Dana > > > > On 11/8/17, 13:28, "Michael K. Edwards" <[email protected]> wrote: > > > > Thank you, Dana! Do you think it would be appropriate (not just as > of > > the current implementation, but in terms of the interface contract) > to > > use H5free_memory() on the buffer passed into an H5Z plugin, > replacing > > it with a new (post-compression) buffer allocated via H5allocate()? > > > > On Wed, Nov 8, 2017 at 1:23 PM, Dana Robinson <[email protected]> > wrote: > > > The public H5allocate/resize/free_memory() API calls use the > library's > > > memory allocator to manage memory, if that is what you are looking > for. > > > > > > > > > > > > https://support.hdfgroup.org/HDF5/doc/RM/RM_H5.html > > > > > > > > > > > > Dana Robinson > > > > > > Software Developer > > > > > > The HDF Group > > > > > > > > > > > > From: Hdf-forum <[email protected]> on behalf > of Jordan > > > Henderson <[email protected]> > > > Reply-To: HDF List <[email protected]> > > > Date: Wednesday, November 8, 2017 at 12:59 > > > To: "[email protected]" <[email protected]> > > > Cc: HDF List <[email protected]> > > > Subject: Re: [Hdf-forum] Collective IO and filters > > > > > > > > > > > > Ah yes, I can see what you mean by the difference between the use > of these > > > causing issues between in-tree and out-of-tree plugins. This is > particularly > > > interesting in that it makes sense to allocate the chunk data > buffers using > > > the H5MM_ routines to be compliant with the standards of HDF5 > library > > > development, but causes issues with those plugins which use the > raw memory > > > routines. Conversely, if the chunk buffers were to be allocated > using the > > > raw routines, it would break compatibility with the in-tree > filters. Thank > > > you for bringing this to my attention; I believe I will need to > think on > > > this one, as there are a few different ways of approaching the > problem, with > > > some being more "correct" than others. > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Hdf-forum is for HDF software users discussion. > [email protected] > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > > > ------------------------------ > > End of Hdf-forum Digest, Vol 101, Issue 14 > ****************************************** > -- Guido
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
