The basic model of MPI is "two-sided communication": you have a sender who knows where to send, and a receiver who knows from where to expect something. In your description that is not the case: the sender sends to a randomly generated receiver. You could do this with one-sided communication in MPI which will be a bit of a learning curve. There the sender (more correctly: "origin") can pick any process as receiver ("target") and put data there. So you'd use MPI_Put instead of MPI_Send.

Other possibility: the processes do a wildcard receive. This has the problem that they don't know how many times they have to issue such. But you can use a non-blocking barrier to solve that. If you can pull that off you can pat yourself on the back for being totally state-of-the-art.

Or you could use a totally different paradigm, that makes your distributed memory look like shared. Unfortunately those are generally far from efficient.

The basic model of MPI is "two-sided communication": you have a sender who knows where to send, and a receiver who knows from where to expect something. In your description that is not the case: the sender sends to a randomly generated receiver. You could do this with one-sided communication in MPI which will be a bit of a learning curve. There the sender (more correctly: "origin") can pick any process as receiver ("target") and put data there. So you'd use MPI_Put instead of MPI_Send.

Other possibility: the processes do a wildcard receive. This has the problem that they don't know how many times they have to issue such. But you can use a non-blocking barrier to solve that. If you can pull that off you can pat yourself on the back for being totally state-of-the-art.

Or you could use a totally different paradigm, that makes your distributed memory look like shared. Unfortunately those are generally far from efficient.

EDIT another answer suggests Isend/Irecv. I'm not sure that that is going to work: the recipient is dependent on that random number. If only one point sends you're in big trouble because everyone has to listen for that message but only one actually gets it. If everyone sends you can be a little more clever by accumulating the sends and receives. This can work in principle if your application has "supersteps"; it doesn't work if the sends are also random in time. But statistically it's still possible that one process gets zero data, so it will have an outstanding Irecv that is never satisfied. (Another problem is that you don't know how much buffer space to create.) So a better solution is to use a Reduce_scatter to find out how much data you're going to get and then receiving that.

The basic model of MPI is "two-sided communication": you have a sender who knows where to send, and a receiver who know from where to expect. In your description that is not the case: the sender sends to a randomly generated receiver. You could do this with one-sided communication in MPI which will be a bit of a learning curve. There the sender (more correctly: "origin") can pick any process as receiver ("target") and put data there. So you'd use MPI_Put instead of MPI_Send.

Or you could use a totally different paradigm, that makes your distributed memory look like shared. Unfortunately those are generally far from efficient.

The basic model of MPI is "two-sided communication": you have a sender who knows where to send, and a receiver who knows from where to expect something. In your description that is not the case: the sender sends to a randomly generated receiver. You could do this with one-sided communication in MPI which will be a bit of a learning curve. There the sender (more correctly: "origin") can pick any process as receiver ("target") and put data there. So you'd use MPI_Put instead of MPI_Send.

Other possibility: the processes do a wildcard receive. This has the problem that they don't know how many times they have to issue such. But you can use a non-blocking barrier to solve that. If you can pull that off you can pat yourself on the back for being totally state-of-the-art.

Or you could use a totally different paradigm, that makes your distributed memory look like shared. Unfortunately those are generally far from efficient.