The following is perfectly legal:
MPI_Comm_dup(some_comm, &tmp_comm);
MPI_Win_create(…., tmp_comm, &window);
MPI_Comm_free(tmp_comm);
So I don’t think stashing away a communicator is the solution. Is a group
sufficient? I think any rational reading of the standard would lead to windows
need
Hi Brian,
Let me first start with explaining why we need the communicator. We need to
translate local to global rank (aka. rank in your MPI_COMM_WORLD), so that
the communication map we provide make sense. The only way today is to go
back to a communicator and then basically translate a rank betwe
The objection I have to this is that it forces an implementation where every
one-sided component is backed by a communicator. While that’s the case today,
it’s certainly not required. If you look at Portal 4, for example, there’s one
collective call outside of initialization, and that’s a barr
Devels,
We would like to change the definition of the OSC module to move the
communicator one level up from the different module structures into the
base OSC module. The reason for this, as well as a lengthy discussion on
other possible solutions can be found in
https://github.com/open-mpi/ompi/pu
