The comm.alltoall method takes the i^th object from the sendbuf argument of task j and copies it into the j^th object of the recvbuf argument of task i.

If we run the code with a communicator group of 5 processes, then our output is as follows:

C:>mpiexec -n 5 python alltoall.py 
process 0 sending [0 1 2 3 4] receiving [0 0 0 0 0] 
process 1 sending [0 2 4 6 8] receiving [1 2 3 4 5] 
process 2 sending [ 0 3 6 9 12] receiving [ 2 4 6 8 10] 
process 3 sending [ 0 4 8 12 16] receiving [ 3 6 9 12 15] 
process 4 sending [ 0 5 10 15 20] receiving [ 4 8 12 16 20] 

We could also figure out what happened by using the following schema:

Our observations regarding the schema are as follows:

• The P0 process contains the [0 1 2 3 4]  data array, where it assigns 0 to itself, 1 to the P1 process, 2 to the P2 process, 3 to the P3 process, and 4 to the P4 process;
• The P1 process contains the [0 2 4 6 8] data array, where it assigns 0 to the P0 process, 2 to itself, 4 to the P2 process, 6 to the P3 process, and 8 to the P4 process;
• The P2 process contains the [0 3 6 9 12] data array, where it assigns 0 to the P0 process, 3 to the P1 process, 6 to itself, 9 to the P3 process, and 12 to the P4 process;
• The P3 process contains the [0 4 8 12 16] data array, where it assigns 0 to the P0 process, 4 to the P1 process, 8 to the P2 process, 12 to itself, and 16 to the P4 process;
• The P4 process contains the [0 5 10 15 20] data array, where it assigns 0 to the P0 process, 5 to the P1 process, 10 to the P2 process, 15 to the P3 process, and 20 to itself.