Open MPI logo

Open MPI User's Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Open MPI User's mailing list

Subject: Re: [OMPI users] Parallel I/O doesn't work for derived datatypes with Fortran 90 interface
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2012-08-07 15:01:44

A common misunderstanding with this subroutine is that offset must be an INTEGER(KIND=MPI_OFFSET_KIND). OMPI 1.6's F90 interface (and earlier versions) won't work with derived datatypes as the buffer, either. OMPI 1.7 has a wholly-reimplemented "mpi" module that allows derived datatypes as the buffer when used with non-gfortran compilers (e.g., fort). It also has the the "mpi_f08" MPI-3 module, which offers many nice things beyond the "mpi" module.

Here's pseudocode for the prototype of the MPI_FILE_READ_AT subroutine:

subroutine MPI_FILE_READ_AT(fh, offset, buf, count, datatype, &
        status, ierr)
  include 'mpif-config.h'
  integer, intent(in) :: fh
  integer(kind=MPI_OFFSET_KIND), intent(in) :: offset
  <type>, intent(out) :: buf
  integer, intent(in) :: count
  integer, intent(in) :: datatype
  integer, dimension(MPI_STATUS_SIZE), intent(out) :: status
  integer, intent(out) :: ierr
end subroutine MPI_FILE_READ_AT

If your offset parameter is a regular INTEGER, then the compiler fails with a non-helpful error. Meaning: the error message is *correct*, but not exceedingly helpful. :-) It's basically trying to tell you "I couldn't find a version of MPI_FILE_READ_AT that matches the parameters you passed."

On Aug 6, 2012, at 4:09 PM, Paul Romano wrote:

> When I try to use parallel I/O routines like MPI_File_write_at or MPI_File_read_at with the buffer argument being a derived datatype, I am unable to compile and just get an error of the nature:
> MPI_FILE_READ_AT(fh, offset, buffer, count, datatype, status, ierr)
> 1
> Error: There is no specific subroutine for the generic 'mpi_file_read_at' at (1)
> I'm using Open MPI 1.6 compiled with --with-mpi-f90-size=medium. I've also tried both gfortran and ifort, and both give the same compilation error. Has anyone else seen this behavior?
> Best regards,
> Paul
> _______________________________________________
> users mailing list
> users_at_[hidden]

Jeff Squyres
For corporate legal information go to: