0

I have been working with a Fortran program for some time now and was recently tasked with having it produce some HDF5 output. I created a subroutine to write the h5 file, and it requires some parameters to be passed from the original Fortran program. The Fortran program includes mpif.h and is compiled with mpif90 while the subroutine is compiled using h5fc (it is called in a parallelized loop in the main program if that matters).

I was getting incorrect log ouput from the hdf5 subroutine and went into totalview to try to find the problem and noticed that some (but not all) of the parameters were bad addresses once in the subroutine (everything was fine the main program). Whenever I comment out all the hdf5 functions and compile the subroutine with mpif90 as well, everything looks fine. This of course will not allow me to use any of the HDF5 routines I need to create the h5 file for output.

Here is the related code:

PROGRAM main_prog_mpif90

include "mpif.h"

integer(KIND=4) :: num_vert, num_theta, num_phi, datanum, fileunit
real(KIND=8) :: dist, az, el
real(KIND=8), ALLOCATABLE :: vertices(:), Data(:,:)

.
! initializations and mpi loops and other things that work just fine...
.

CALL HDF5_sub(vertices, Data, dist, num_vert, num_theta, num_phi, &
              datanum, fileunit, az, el)

.
! MPI loop ends, things are closed and deallocated...
.

END PROGRAM main_prog_mpif90


SUBROUTINE HDF5_sub(vertices, Data, dist, num_vert, num_theta, num_phi, &
                    datanum, fileunit, az, el)

integer(KIND=4) :: fileunit, num_vert, num_theta, num_phi, datanum
real(KIND=8) :: dist, az, el
real(KIND=8) :: vertices(num_vert), Data(num_theta, num_phi)

.
! Code that doesn't matter yet since I can't even get this far
.

END SUBROUTINE HDF5_sub

I'm certain I've declared everything consistently, but Totalview will always come back with the following vaiables with bad addresses:

  • vertices
  • num_vert
  • num_theta (but not num_phi)
  • Data has the first entry only, but it is correct

One other thing that might be worth mentioning: In Totalview, the Type for the variables in the main program (mpif90) are written like:

INTEGER*4

while in the subroutine (h5fc), the types are displayed in Totalview like:

integer(kind=4)

(I'm guessing a compiler difference?)

Finally, here are the compile lines for the code in question:

h5fc -g -L/usr/lib64/ -lhdf5_fortran -lhdf5 -c HDF5_sub.F90

mpif90 -g -c main_prog_mpif90.F90

So I'm thinking there is an issue between a program and one of its subroutines having been compiled with different compilers (in this case mpif90 and h5fc). If that is the case, is there any kind of work around? To put it another way, can one compile a main program and its subroutine with different compilers and expect no issues with the data types of the parameters being passed? What precautions must one take?

Of course there is a very good chance I'm doing something else totally wrong (I am very much a novice with HDF5).

The simpler the explanation the better for me!

Thank you everyone in advance.

UPDATE1: @Vladimir F, h5fc -v gives a whole bunch of output, but I'm guessing it is gfortran (it reads Driving: gfortran -O2 ... on the first line). mpif90 -v says ifort 14.0.1. The system with this code is not connected to the internet so I can not copy and paste it here (sorry!). As for the integer*4 comment, we actually have a module for the data types, I just simplified it for the questions. The module used by the main program has the following:

integer(4), PARAMETER  :: ksp = 4
integer(4), PARAMETER  :: ksp = 8

This module is compiled with mpif90 as well, and when I try to USE it in the hdf5 subroutine, it won't compile. I also tried creating a hdf5 datatype module that was identical to the one used by the main program, except compiled that module with h5fc, but the parameters still come through as bad addresses. (What can I say, willing to try almost anything at this point).

UPDATE2: I just found this question (not sure how I missed it before) that I think answers my question about using two different compilers. The question is a couple years old, so if anyone thinks there is now a solution feel free to post it. For what it is worth, I will just have to have my main program write out some parameters to a file, and the hdf5 subroutine will become a stand alone program that will read the file and generate the h5 file from that data.

Thank you all again for taking the time to help.

Community
  • 1
  • 1
CSCFCEM
  • 116
  • 6
  • For `integer*4` vs `integer(kind=4)` and why use better alternatives see http://stackoverflow.com/questions/3170239/fortran-integer4-vs-integer4-vs-integerkind-4 – Vladimir F Героям слава Dec 16 '14 at 22:17
  • Could you run `h5fc -v` and `mpif90 -v` to see what compilers they actually are? Or do you know it directly? – Vladimir F Героям слава Dec 16 '14 at 22:19
  • Well, isn't h5fc GNU fortran90 based thing, but mpi90 is Intel Fortran compiler? UPDATE: Ok, I see you found it. What platform are you on? – Severin Pappadeux Dec 17 '14 at 00:26
  • On 64bit platform there is in general one ABI (how you call routines and where parameters/returns are going), so it might work. Look at http://www.nag.co.uk/doc/inun/fl23/mi6dcl/postrelease.html how they solved it – Severin Pappadeux Dec 17 '14 at 00:30
  • @SeverinPappadeux So you think mpif90 and h5fc (or gfortran and ifort) use the same ABI? ABIs are sort of beyond what I would expect to work with in this program. I guess if they were different ABIs that would explain what I am seeing, but you say on 64bit platforms, the ABIs should be the same? Please correct me if I am not understanding you correctly. Thank you! – CSCFCEM Dec 17 '14 at 00:55
  • @CSCFCEM on 32bit systems due to historical reasons there were several ABIs, related to exe format and data passing. Moving to 64bit world greatly simplified things, again both on Windows and Linux. There is pretty much one ABI per platform nowdays, which compiler vendors are trying to comply to. The differences are typically more subtle due to structures pasing in/out, memory layout. My belief is that it is a lot easier link different compiler libs now, but if they're not working together it is harder to find where the problem is and how to fix it. – Severin Pappadeux Dec 17 '14 at 01:03
  • "The Intel Fortran Compiler for Linux is not binary compatible with GNU g77 or GNU gfortran compiler, nor is binary compatibility a future goal of the Intel Fortran compiler. Instead, the Intel Fortran Compiler for Linux is binary compatible with C-language object files created with either Intel C++ Linux Compiler or the GNU gcc compiler." – Severin Pappadeux Dec 17 '14 at 01:17
  • That was statement from Intel compiler sheet. I would try to use small C glue routines between top Intel level and bottom GNU rountines – Severin Pappadeux Dec 17 '14 at 01:18
  • Are you saying that I should have the fortran program, call a C routine, that in turn calls the fortran subroutine? – CSCFCEM Dec 17 '14 at 13:39
  • 2
    Consider using a HDF5 library that has been compiled with the Intel compiler. – IanH Dec 17 '14 at 21:04
  • `h5fc` is simply a wrapper around a Fortran compiler. If you compile HDF5 with `ifort` (and `icc`), you will find that `h5fc` uses `ifort`. However, because you want to use MPI at the same time, you actually want to be using the parallel HDF5 Fortran wrapper - `h5pfc`. This is a wrapper to `mpif90` (in turn a wrapper around whatever compiler MPI was compiled with). If you do not have `h5pfc` available on your system, you will most likely need to compile HDF5 yourself, with `FC=mpif90 CC=mpicc ./configure --enable-fortran --enable-parallel`. – Yossarian Dec 19 '14 at 09:57

0 Answers0