Hi Pavan, Ok, I got the point about unexpected messages. I can modify the program according to your note. But things aren't clear enough for me yet. You said: You don’t need to know how many messages you will receive. You only need

to make sure that whenever a message comes in, it knows which buffer it should go into. One way to fix that is to post N receives with ANY_SOURCE and ANY_TAG:

I understand that I will have to have N buffers, one for each posted MPI_Irecv. I will also have to TEST (using MPI_PROBE or MPI_WAITANY) until a message comes. The result of this test will identify which one of the posted MPI_Irecv has actually received the message and then process the right buffer. Is this correct? Should I have to change anything at the sender's processes? At the end, my receiver process receives a message identifying that it should exit this routine. What should I do with the already posted MPI_Irecv's? Can I cancel them? Sorry for the newbie questions and thanks in advance for your attention. Regards, Luiz On 31 October 2013 16:31, Pavan Balaji <[email protected]> wrote:

On Oct 31, 2013, at 12:14 PM, Luiz Carlos da Costa Junior < [email protected]> wrote:

...

I noticed that the numbers of 261895 or 261894 unexpected messages appear every time. I am using AWS machine with 60GB of RAM memory to run my application. We could see during the execution that there was more than 30 GB available. Is this a internal limitation of MPICH implementation? Would it be possible to recompile MPICH setting a different parameter? Do you know where exactly this limitation occurs?

Unexpected messages is a bad idea in general. Even if it’s an internal parameter setting (which it isn’t), it’s not a good idea to just increase it.

Can you modify your application to not have that many unexpected messages? See my note on how you can post Irecvs to avoid this.

—- Pavan

-- Pavan Balaji http://www.mcs.anl.gov/~balaji

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss