Also, lots of people seem to like the idea of getting rid of MPI_ANY_SOURCE in a subset. I am one of these people. MPI_ANY_SOURCE is a problem. The difficulty is that the master in a master worker algorithm is likely to find MPI_ANY_SOURCE and MPI_PROBE useful.
This issue captures a (the?) key decision that this group must make imo. Is the goal of the sub-setting to provide a performance boost, or to address the "mpi is too big" concern? In some sense the concerns overlap, but here is a big example of where they often don't. Many of the applications I've worked with use it in setting up communication (esp. in amr codes). And many of these people asked for an mpi-subset. Interesting to note that for many of these codes, actual performance of the send/recv is _not_ an issue - the work associated with preparing and managing messages for those sorts of codes, as well as the work imbalances, overwhelm the performance issues. (But note these code teams may _say_ mpi performance is an issue, but a complete view of their communication requirements does not support that claim.) However, they also require MPI_ALL_REDUCE, and at the peta-scale, so performance there is critical. MPI_ANY_SOURCE is found in many libraries I use, but library developers seem to make significant use of mpi functionality, without complaint. All this said, admittedly counter-claims and examples may be produced. However, as Dick stated for the Master/worker model, a large segment of users "require" MPI_ANY_SOURCE" somewhere in their code. I'm not saying a decision needs to be reached quickly, but I do believe we should keep this issue clearly in view in order to keep the discussions on-track. Richard -- Richard Barrett Future Technologies Group, Computer Science and Mathematics Division, and Scientific Computing Group, National Center for Computational Science Oak Ridge National Laboratory http://ft.ornl.gov/~rbarrett