In the I/O chapter, an implementation is allowed to ignore the hints provided by the user. MPI_File_get_info returns the current value of hints actually used in the implementation. So suppose a user passes the info key “striping_unit" with value 10, but the system on which the file is created doesn’t support user control of striping unit, the implementation can ignore the user-provided value and, in MPI_File_get_info, return the default striping unit used for the file (which could be 8, say). Rajeev

On Feb 17, 2016, at 5:57 PM, Schulz Martin <[email protected]> wrote:

...

...

...

See my reply to Jim: if we're supposed to provide the value of *the hint*, that to me sounds like the *user's input* (as opposed to what the system chose to do with that hint).

I agree, hints are given by the user to express what an application does. Those should never be changed by the MPI library (or no are no longer (user) hints).

Even if the MPI implementation should never change the value of these hints, my original question still stands, because MPI_COMM_GET_INFO's use of the phrase "actually used by the system" is still ambiguous (MPI-3.1 p250):

----- // Assume that the MPI implementation understands the "foo" info key hint, but // is unable to apply it after a communicator is created. MPI_Info_set(myinfo, "foo", "yes"); MPI_Comm_set_info(comm, myinfo); MPI_Comm_get_info(comm, myinfo_returned); ------

So I still don't have a definitive answer as to what is in myinfo_returned:

1. "foo" = "yes", because that's what the user set, and the MPI implementation understood the "foo" hint key (regardless of what it chose to do with that hint) --> This is what I think should happen

2. "foo" = "no", because the MPI implementation wasn't able to use the "foo" hint --> There's at least 2 explicit votes against this behavior (JeffSq, Martin)

3. no "foo" key is set, because the MPI implementation wasn't able to use the "foo" hint --> I'm not a big fan of this, because you can't tell the difference between "foo is not understood by the implementation" and "foo is understood by the implementation, but this hint can't be used right now".

I would say, #3 is correct - the system doesnąt use/apply the hint, I.e., the behavior is the same as if the hint wasnąt supplied. I agree, this is not ideal since knowing what an implementation supports would be good, but the standard never makes that distinction.

...

=========

Regardless of what is returned by MPI_COMM_GET_INFO, what happens in MPI_COMM_DUP?

The "actually used by the system" ambiguous phrase only applies to MPI_COMM_GET_INFO. MPI_COMM_DUP is defined in MPI-3.1 p238:

"MPI_COMM_DUP duplicates the existing communicator comm with ... info hints."

It doesn't have any scoping language about *which* hints are copied -- it pretty much implies that *all* hints are copied.

As such, I think that "foo"="yes" should be propagated to the new communicator.

Yes, I agree - even if the hint is not used and hence not returned by MPI_COMM_GET_INFO, itąs still set on the communicator. The user set it and expects it to be set and so it should be part of the duplication.

...

Which is another reason that I think that MPI_COMM_GET_INFO should also return "foo"="yes" in myinfo_returned (i.e., so that MPI_COMM_GET_INFO and MPI_COMM_DUP both behave the same way).

I agree, thatąs what it should do - GET and SET should be matching, but thatąs not how the standard is written (sadly).

The idea behavior would be three calls, IMHO:

MPI_COMM_GET_INFO - return all hints set MPI_COMM_GET_INFO_UNDERSTOOD - return all hints that could be used by an implementation MPI_COMM_GET_INFO_USED - return all hints used (thatąs the current behavior of MPI_COMM_GET_INFO)

doing this, though, throws into the usual backwards compatibility problems, though.

Martin

...

Thoughts?

-- Jeff Squyres [email protected] For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

_______________________________________________ mpi-forum mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum