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
