Re: Hdf-forum Digest, Vol 101, Issue 14

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: Hdf-forum Digest, Vol 101, Issue 14

guido
Hello Pierre,

What do you mean by fortran90 programs require fortran 2003 features?

Regards,

2017-11-08 16:43 GMT-05:00 <[hidden email]>:
Send Hdf-forum mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 <[hidden email]>
To: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
To: "[hidden email]" <[hidden email]>
Cc: HDF Users Discussion List <[hidden email]>
Subject: Re: [Hdf-forum] Collective IO and filters
Message-ID: <[hidden email]>
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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> on behalf of Jordan
    > Henderson <[hidden email]>
    > Reply-To: HDF List <[hidden email]>
    > Date: Wednesday, November 8, 2017 at 12:59
    > To: "[hidden email]" <[hidden email]>
    > Cc: HDF List <[hidden email]>
    > 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" <[hidden email]>
To: Dana Robinson <[hidden email]>
Cc: HDF Users Discussion List <[hidden email]>
Subject: Re: [Hdf-forum] Collective IO and filters
Message-ID:
        <[hidden email]>
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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> on behalf of Jordan
>     > Henderson <[hidden email]>
>     > Reply-To: HDF List <[hidden email]>
>     > Date: Wednesday, November 8, 2017 at 12:59
>     > To: "[hidden email]" <[hidden email]>
>     > Cc: HDF List <[hidden email]>
>     > 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.
[hidden email]
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.
[hidden email]
http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org
Twitter: https://twitter.com/hdf5