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
*
