From: treumann@XXXXXXXXXX
X-Lotus-FromDomain: IBMUS
To: mpi-core@XXXXXXXXXXX
Date: Fri, 18 Jun 1999 10:16:20 -0400
Subject: Re: Request for interpretation
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-mpi-core@XXXXXXXXXXX
Precedence: bulk
X-UIDL: 484407f336f8700da7fd0e1c80a445b0

Linda Stanberry has suggested that the MPI_Info object ought to behave as an
open ended repository for string pairs so any key:value the user wishes to store
there will be stored exactly as offered. For the IBM implementation we have
taken a different approach and I think we have chosen the better one.  Here is
what we are doing and why.

For MPI_INFO_SET, if a key is unknown to our implementation we will silently (rc
= MPI_SUCCESS) ignore it.  If it is known, we will do whatever validation we can
on its value and, again silently,  accept the value, accept a modified value or
reject the hint.  After the hint is set, the user can call MPI_INFO_GET to find
out what really happened.  Say we had a hint IBM_framus_size for MPI_Win and
that hint accepts values from 0-10.   With our approach, the user who
experiments with setting this to values between 100 and 1000 can see that the
effect is to set it to 10 and the user who tries "true" | "false" can see that
IBM_framus_size is not getting honored at all.  The user who misspells the key
or uses an unsupported key can see that we will make no use of the mystery hint
and can skip the effort of trying to tune with it.    For consistency,
MPI_INFO_DELETE also silently ignores unrecognized hints so a user who does a
SET and later DELETE with an unrecognized hint has not triggered an error.

The MPI-2 standard leaves each implementation free to decide which hints it will
support.  The implementation can support any subset of the defined hints plus
any additional hints.  The implementation is free to interpret a hint literally,
loosely or ignore it.  (e.g. There could be some hint which can only be accepted
if the MPI program was started with a particular command line flag set.)  Given
this level of freedom for implementors, it is important  for the user to have
some way to learn what is being done with a hint.  Only MPI-IO has a function
like MPI_FILE_GET_INFO which allows a user to find out  what a hint is doing.
For the other uses of MPI_Info, if the user cannot query hint behavior via
MPI_INFO_GET, she cannot query it at all.  Even  MPI_FILE_GET_INFO will only
tell the user if a particular hint was accepted for the particular file. It does
not indicate whether an ignored hint was inappropriate only for that file or is
a complete mystery to the implementation.

In short, I think out interpretation is a service to users.  I do not expect the
standard to be clarified to require this behavior but I do consider it correct
and worthwhile.  I urge any MPI implementation which is not open source to
consider this using interpretation so users will have some way to learn what is
being done with any effort they make to supply hints.

               Dick



Dick Treumann                IBM RS/6000 SP Development
Tele (914) 433-7846         Fax (914) 433-8363