[This is a branch-off from thread "Pt2pt messaging with MPI_PROC_NULL (and MPI_TAG_NULL,MPI_ADDRESS_NULL)" ] It turns out that MPI_COMM_NULL opens some questions that I am sure can be resolved by people on the list. It is enlightening that you see my suggested MPI_COMM_NULL as a set and not an item. I did not think about that, but it is of course the more natural approach and MPI_COMM_NULL can then be seen as problematic. I do indeed have the view that the MPI_xxxx_NULL items are to be compared to NaN in that they are items in themselves. In particular they are items that are not members of any set of similar items. Thus, MPI_COMM_NULL is a process communicator that is not a member of any set of (valid) process communicators and it is not MPI_COMM_EMPTY. I am not sure that there is a need for an explicit MPI_COMM_EMPTY, but if there was it is allowed and can be created as a sub-communicator to any communicator by MPI_Comm_create, eg for MPI_COMM_WORLD: MPI_Comm_create(MPI_COMM_WORLD,MPI_GROUP_EMPTY,&mpi_comm_empty) but its usefulness I find debatable. The set operations in MPI are, I believe, restricted to the MPI_GROUP_xxx set of items and do not directly involve communicators, but I am on thin ice here. This is for the intra-communicator people, MPMD and multi-physics scientists to have opinions on. In my view, the group members of MPI_COMM_NULL should be MPI_GROUP_NONE (not MPI_GROUP_EMPTY) if it should return any members at all. My suggestion would rather be that MPI_COMM_NULL is an illegal communicator argument in any call to MPI_Group_*() or MPI_Comm_*() that takes a communicator as an argument, eg MPI_Comm_dup(), MPI_Comm_free(), MPI_Comm_group(). So, I think that you and I are arguing for the same definition of MPI_COMM_NULL . /Nils On Thu, Oct 21, 2021 at 7:14 PM Dan Holmes <[email protected]> wrote:
Hi Nils,
In general, I like the idea of having default/invalid values for these MPI-related user variables. [...] IMHO, there would need to be a statement that, “when the comm argument is MPI_COMM_NULL, the only acceptable value for the source/dest argument is MPI_PROC_NULL” because asking for the 3rd item from an empty set (for example) is clearly an error. Your proposal tries to treat MPI_COMM_NULL as if it is a valid MPI intra-communicator that has size zero, or a valid inter-communicator that has a remote group of size zero. I think I would prefer to create MPI_COMM_EMPTY for that purpose, and continue to use MPI_COMM_NULL for situations that call for an invalid communicator, i.e. something that can never be used as a communicator without causing an error condition.
The phrase used elsewhere in the MPI Standard is “XYZ parameter is significant only <when condition>”