I think the statement explains it - during the MPI 2 discussions, there was a lot of effort spent on defining a portable, standard, resource control specification. The forum was unable to reach a consensus, and rather than make a poor specification, they left it undefined. This permits MPI implementations to explore interfaces with their resource management systems (and permits an MPI-based cluster to be reconfigurable), just not in a MPI-standard defined way. Note that the info argument to the spawn routines, for example, provides a way to communicate with a resource manager; it was an explicit goal of the design of info to provide this way to communication information that is outside of the specification. Bill On Jun 30, 2010, at 2:56 PM, siavash ghiasvand wrote:

Hi,

In MPI22 Standard document [1] on page 305 lines 27-30 we can see this paragraph:

The MPI Forum decided not to address resource control because it was not able to design a portable interface that would be appropriate for the broad spectrum of existing and potential resource and process controllers. Resource control can encompass a wide range of abilities, including adding and deleting nodes from a virtual parallel machine, ...

Which means, an MPI-based cluster is not reconfigurable at run time! but in EuroPVM/MPI 2006 a reconfigurable version of MPI for HPC clusters was described by University of New Mexico Scalable Systems Lab [2] and they show that their implementation will enhance performance (the main goal of MPI). So, why in MPI22 standard "The MPI forum decided not to address resource control" which can improve both flexibility and performance of an MPI-based cluster?

Ref: MPI/CTP: A Reconfigurable MPI for HPC Applications

Regards, Siavash <ATT00001..txt>

William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign *