[Mpi-forum] New tickets on MPI Virtual Topology Functions
balaji at mcs.anl.gov
Mon Oct 12 12:17:00 CDT 2009
> 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
More information about the mpi-forum