Rob,

Thanks for the clarification.  I am using a old school solution to the
problem, namely with a little 12 line subroutine that simply reverses
the order of the bytes in each floating point word.  Before fortran
compilers supported 'byteswapping', this was the way we did it, and it
still does the job.

T. Rosmond


On Thu, 2011-01-06 at 14:52 -0600, Rob Latham wrote:
> On Tue, Dec 21, 2010 at 06:38:59PM -0800, Tom Rosmond wrote:
> > I use the function MPI_FILE_SET_VIEW with the 'native'
> > data representation and correctly write a file with MPI_FILE_WRITE_ALL.
> > However, if I change to the 'external32' representation, the file is
> > truncated, with a length that suggest that either only one process did a
> > write, or each process wrote to the same location.  
> 
> Hi T. Rosmond.  'external32', while part of the standard, has not been
> widely implemented in MPI-IO libraries.  Neither OpenMPI nor MPICH2
> support that data representation.  I suspect the MPI-IO routines are
> returning an error in ierr (at least I hope they are). 
> 
> If you check the error code against MPI_SUCCESS and process it with
> MPI_ERROR_STRING, then you'll quickly see it's not supported.
> 
> I added a subroutine "check_err" to your test program and your test
> program prints out the following:
> 
> "Unsupported datarep passed to MPI_File_set_view , error stack:
> MPI_FILE_SET_VIEW(117): Only native data representation currently
> supported"
> 
> I'm not a fortran person so it took me a while to get the call right.
> For posterity (and to maybe help out some other not-fortran guy down
> the road), here's what check_err does:
> 
>       subroutine check_err(iret)
>       include 'mpif.h'
>       integer iret
>       integer ierr
>       integer outlen
>       CHARACTER(LEN = MPI_MAX_ERROR_STRING) string
>       if (iret .ne. MPI_SUCCESS) then
>           call MPI_ERROR_STRING(iret, string, outlen, ierr)
>           print *, string(1:outlen)
>       endif
>       end subroutine check_err
> 
> 
> external32 is a good idea but nowadays portable files are better
> served with something like HDF5, NetCDF-4 or Parallel-NetCDF, all of
> which generate files that are not only portable but are also
> self-describing.
> 
> ==rob
> 

Reply via email to