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