Re: Even more IO issues

John May (johnmay@llnl.gov)
Fri, 11 Apr 1997 17:40:51 -0700

Jeff Squyres writes:
> John May cited in a previous letter that MPI IO is supposed to be
> layered on top of MPI-2.
>
> If this is so, I should point out that there is no text to support this
> position. If this is specifically a goal of the IO chapter, it needs to
> be stated somewhere. Also, was there talk that the IO section was
> "optional" to an MPI-2 implementation (I don't remember)? I ask because
> on page 2, in section 1.1, it says "MPI-2 compliance will mean
> compliance with all of MPI-2." This doesn't seem to imply that the IO
> library can be separate.

I don't know of any allowance for omitting I/O support from an
MPI-2 implementation. However as a practical matter, many of
us who are implementing MPI-IO are working independently of
MPI implementators. For example, the project I'm working on
is trying to implement an MPI-IO interface to an external
storage system that will work on multiple parallel machines,
some of which have vendor-specific versions of MPI. Assuming
MPI-2 becomes available on these machines, an I/O specification
that allows for a separable I/O library will make it possible
for us to port the I/O library to each target platform without
having to dig into the MPI code, which may well be proprietary.
All of this makes it very convenient for MPI-IO functions to
be able interact with the rest of MPI through published interfaces.

> There should also probably be a few goals listed like there are in
> MPI-1, such as users are supposed to link to the library with "-liompi"
> or something like that (this would make a uniform way to link to the IO
> library, even for MPI implementations that do provide an IO library). I
> don't have MPI-1 with me, but I seem to recall reading stuff like that
> in there.

I would be happy to see text that called for implementations to
supply separate message passing and I/O libraries to link to
an application, and perhaps also separate header files. Since
there may be no system-independent way to specify this, however,
perhaps it could be given as advice to implementors. What do
others think of this idea?

John