[Mpi-forum] New tickets on MPI Virtual Topology Functions

[Pavan Balaji]

> Are the two proposals mutually exclusive? One seeks to
> improve MPI_Dims_create while the other proposes to
> deprecate it. It seems like we should go one way or the
> other but not both. I suppose we could enact both if
> we omit part one (the deprecation) of the second.

Since we are just proposing to deprecate MPI_Dims_create and not 
actually removing it, improvements to it might still be useful -- might 
not be from a user's standpoint, but from an MPI implementation's 
standpoint for applications/libraries that are already using it.

> Could we just deprecate MPI_Dims_create and replace it
> with a new function that serves the exact same purpose
> but also has a communicator argument? I seem to recall
> that the idea was that sometimes the user either needs
> to do some data movement prior to the communicator
> creation or might want to fine-tune the results that
> MPI_Cart_create would otherwise provide...

I'm not sure how the user can fine-tune the values returned by the 
Dims_create function without losing out on the "topology-awareness". If 
there is a need for it, we should certainly consider adding a new 
function. But I don't see a concrete advantage in doing so.

> I gues the other changes to MPI_Cart_create would still
> be needed but do not necessarily eliminate the need for
> the manual process.

Agreed. We don't disallow the user from manually providing the 
dimensions (similar to MPI-2.2). So, most applications using MPI-2.2 
should almost automatically work correctly with this change. But at the 
same time, it might be easier to just get rid of the manual part if an 
application wants.

Thanks,

  -- Pavan

-- 
Pavan Balaji
http://www.mcs.anl.gov/~balaji