Thanks Martin. This is my recollection of the discussion, too. I was just
surprised to see this behavior in both MPICH and Open MPI. We did come across
this sentence in the text:
An implementation must support info objects as caches for arbitrary
(key,value) pairs, regardless of whether it recognizes the key.
But I think we can reasonably understand that to mean an info object that the
user creates. I.e. *not* the info object associated with an MPI {comm,win,file}
handle. MPICH will fix the MPI_FILE_GET_INFO behavior to do what is stated
below.
Thanks,
Ken
On 10/18/21, 3:26 PM, "Martin Schulz" <schu...@in.tum.de> wrote:
Hi Ken,
To my understanding, this is actually a bug in the MPI library or an
incorrect implementation according to the standard. We had a very lengthy
discussion about this during MPI 4.0 - here is a link to the issue:
https://github.com/mpi-forum/mpi-issues/issues/63
We had in there at some point the following principles that guided the new
text:
Principles:
a) the key/value pairs returned by MPI_GET_INFO must always have been
supplied by the user and not ignored by the MPI library
b) the semantics of supplying an INFO during object creation and during
MPI_SET_INFO should be identically defined
c) the MPI is permitted, but not required, to 'ignore' any INFO key/value
pair supplied by the user
d) if an INFO key/value pair is ignored by MPI, then it will not appear in
subsequent MPI_GET_INFO calls
e) if an INFO key/value pair was not ignored by MPI, then it must appear in
subsequent MPI_GET_INFO calls
(the same was then applied to all get infos)
d) seems to be the key aspect here. From what I remember, this was a
deliberate choice, as the assumption back then was that the user wanted to know
what the library actually did with the info (and a library was allowed to not
store other values that are not used). Also, we allowed the return of a
different value - if a library knows and uses the key "foo", but only uses the
first character, the value returned would be "b" - again with the idea that the
user wants to know what is used.
We had actually discussed a second version of MPI_Get_info that would
return the actual user supplied values, but we never pursued that - perhaps it
is worth reconsidering this again.
Martin
--
Prof. Dr. Martin Schulz, Chair of Computer Architecture and Parallel Systems
Department of Informatics, TU-Munich, Boltzmannstraße 3, D-85748 Garching
Member of the Board of Directors at the Leibniz Supercomputing Centre (LRZ)
Email: schu...@in.tum.de
On 18.10.21, 18:12, "mpi-forum on behalf of Raffenetti, Ken via mpi-forum"
<mpi-forum-boun...@lists.mpi-forum.org on behalf of
mpi-forum@lists.mpi-forum.org> wrote:
Here's an example program that illustrates the current file info
behavior with MPICH and Open MPI. Neither library will abort the application in
my tests. MPICH does not recognize the "foo" key, and I would guess the same
for Open MPI.
So is this correct behavior according to the standard? Or a bug? There
are users who prefer the current behavior, I suspect in part because there is
no attribute caching interface for MPI file objects.
#include <mpi.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(void) {
MPI_Init(NULL, NULL);
MPI_Info info;
MPI_Info_create(&info);
MPI_Info_set(info, "foo", "bar");
MPI_File fh;
MPI_File_open(MPI_COMM_SELF, "testfile", MPI_MODE_RDWR |
MPI_MODE_CREATE, info, &fh);
MPI_Info info_used;
MPI_File_get_info(fh, &info_used);
char value[4] = "";
int flag;
MPI_Info_get(info_used, "foo", 3, value, &flag);
if (!flag) {
printf("key not found\n");
MPI_Abort(MPI_COMM_WORLD, 1);
}
if (strcmp(value, "bar")) {
printf("value does not match\n");
MPI_Abort(MPI_COMM_WORLD, 1);
}
MPI_File_close(&fh);
MPI_Info_free(&info);
MPI_Info_free(&info_used);
MPI_Finalize();
return 0;
}
On 10/15/21, 2:47 PM, "mpi-forum on behalf of Raffenetti, Ken via
mpi-forum" <mpi-forum-boun...@lists.mpi-forum.org on behalf of
mpi-forum@lists.mpi-forum.org> wrote:
We brought this to the forum because during our internal discussion
is was shown that ROMIO will return any "ignored" key/value pairs set by the
user in MPI_FILE_GET_INFO. Essentially, ROMIO duplicates the users info object,
and only adjusts settings for keys it recognizes. Perhaps this is wrong
behavior according to MPI-4.0?
This behavior was introduced into ROMIO somewhat recently in May
2020. There was a user request for it based on how OMPI-IO behaved.
https://github.com/pmodels/mpich/pull/3954
Ken
On 10/13/21, 3:46 PM, "mpi-forum on behalf of Jim Dinan via
mpi-forum" <mpi-forum-boun...@lists.mpi-forum.org on behalf of
mpi-forum@lists.mpi-forum.org> wrote:
Hi Rob,
This seems reasonable to me. I think you can draw an analogy to
an application setting "mpi_assert_no_any_tag = true" and checking the value
returned by MPI_Comm_get_info to decide whether to use MPI_ANY_TAG on the
communicator. I would suggest info values like "true" and "false" so that ROMIO
can return back the same value passed by the user if the info key is accepted.
As of MPI 4.0, MPI_File_get_info must return "all hints that
are supported by the implementation and have default values specified; any
user-supplied hints that were not ignored by the implementation; and any
additional hints that were set by the implementation." So, true/false would
also allow ROMIO to return a default value for the info key if the user hasn't
set it.
One thing you can't do with info today is fail the operation
because of a key/value pair in the info argument. If there is an issue with a
particular key/value pair, it is supposed to be ignored.
~Jim.
On Mon, Oct 11, 2021 at 2:13 PM Latham, Robert J. via mpi-forum
<mpi-forum@lists.mpi-forum.org> wrote:
I'd like a way to tell users programmatically about features
ROMIO supports.
One way I imagined doing so was through the info object, though
we're having some internal discussion about how kosher that is. Any thoughts
from the broader MPI community about an approach like this:
```
MPI_Info_create(&info);
MPI_Info_set(info, "romio_feature_xyz", "requested");
MPI_File_open(...)
MPI_File_get_info(fh, &info_used)
MPI_File_get_info(info_used, "romio_feature_xyz",
MPI_MAX_INFO_VAL-1,
value, &flag);
```
Possible points of contention:
- we have examples of using hints for clients to pass
information to implementations (striping_factor, cb_buffer_size) and examples
of implementations passing information to users (cb_nodes on Blue Gene), but we
don't have too many examples of two-way hints.
- will MPI_File_get_info return all info keys or just the ones
the implementation understands? The standard dictates what is required to be
returned. ROMIO (so de facto standard) will return the union of its internal
keys and any keys (known or unknown) passed in by the user.
- The use of "requested" as a hint value that the
implementation can then either set to "enabled" or "disabled" guards the
situation where a user code is passing these infos to an older MPI IO
implementation. If the hint comes back exactly as given, then the
implementation ignored this feature request and it is not supported. If the
hint comes back "enabled" then the caller knows something about the
implementation.
Thanks
==rob
_______________________________________________
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
_______________________________________________
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
_______________________________________________
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
_______________________________________________
mpi-forum mailing list
mpi-forum@lists.mpi-forum.org
https://lists.mpi-forum.org/mailman/listinfo/mpi-forum
