<div dir="ltr">Does anyone have any clue about this?<div><br></div><div>Thanks in advance.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 12 March 2014 14:40, Luiz Carlos da Costa Junior <span dir="ltr"><<a href="mailto:lcjunior@ufrj.br" target="_blank">lcjunior@ufrj.br</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Kenneth,<div class=""><div><br></div><div>Thanks for your quick reply.</div></div><div><div>I tested your suggestion and, unfortunately, this approach didn't work.</div>
<div><br></div><div>Question: when I call MPI_IPROBE it accounts also for the messages that were already received asynchronously?</div>
<div><br></div><div>Is there any way to know, for my list of mpi_requests (from my MPI_IRECV's), which ones are "opened" and which ones have messages?</div><div><br></div><div>Regards,</div></div><div><div class="h5">
<div class="gmail_extra">
<br><br><div class="gmail_quote">On 11 March 2014 17:00, Kenneth Raffenetti <span dir="ltr"><<a href="mailto:raffenet@mcs.anl.gov" target="_blank">raffenet@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
You could use MPI_Probe/MPI_Iprobe and pass in your "data" tag to test for any more pending messages.<br>
<br>
Ken<div><br>
<br>
On 03/11/2014 02:50 PM, Luiz Carlos da Costa Junior wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
Dear all,<br>
<br>
I am all set with your suggestions and my program is working quite well<br>
without any "unexpected message" since then, thanks again.<br>
<br>
However now I am facing a small problem I describe next.<br>
<br>
My receiver process receives actually 2 types of messages (2 different<br>
tags):<br>
<br></div>
* the basic tag means that the message is a "data message" ("data"<div><br>
tag) that should be processed.<br></div>
* the second one means that the worker process is done and it will<div><br>
send no more messages ("end_of_processing" tag).<br>
<br>
Once all worker processes send their end_of_processing tag, the receiver<br>
process finishes its execution.<br>
<br>
The problem I noticed is that some of the last messages sent by the<br>
worker processes were not being processed. I think the problem is<br>
related with the logic I am using with MPI_WAITANY in the receiver<br>
process. I am simply counting the number of end_of_processing messages<br>
received and if it reaches the number of worker processes, I finish the<br>
execution without checking if there are more messages to be received at<br>
the MPI_WAITANY queue.<br>
<br>
As the order that messages arrive is not relevant for MPI_WAITANY I<br>
think that my logic forgets some of the messages at the end of the<br>
queue. Is this right?<br>
<br>
Is there any way to check if there is any pending request to be processed?<br>
<br>
Best regards,<br>
Luiz<br>
<br>
<br>
On 16 January 2014 16:57, "Antonio J. Peņa" <<a href="mailto:apenya@mcs.anl.gov" target="_blank">apenya@mcs.anl.gov</a><br></div><div><div>
<mailto:<a href="mailto:apenya@mcs.anl.gov" target="_blank">apenya@mcs.anl.gov</a>>> wrote:<br>
<br>
<br>
A profiling of both of your codes would help to understand where the<br>
time is spent and the difference between them in terms of performance.<br>
<br>
Antonio<br>
<br>
<br>
<br>
On 01/16/2014 12:47 PM, Luiz Carlos da Costa Junior wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
Yes, I am comparing original x new implementation.<br>
<br>
The original implementation is as follows.<br>
<br>
c-----------------------------<u></u>------------------------------<u></u>------------<br>
subroutine my_receiver_original<br>
c ------------------------------<u></u>------------------------------<u></u>------<br>
(...)<br>
<br>
c Local<br>
c -----<br>
integer*4 m_stat(MPI_STATUS_SIZE)<br>
character card*(zbuf) ! buffer for messages received<br>
<br>
do while( keep_receiving )<br>
call MPI_RECV(card, zbuf, MPI_CHARACTER,<br>
. MPI_ANY_SOURCE, M_RECCSV, MY_COMM,<br>
. m_stat, m_ierr )<br>
<br>
c Process message: disk IO<br>
c ---------------<br>
<DO SOMETHING><br>
if( SOMETHING_ELSE ) then<br>
keep_receiving = .false.<br>
end if<br>
end do<br>
<br>
(...)<br>
<br>
return<br>
end<br>
<br>
Regards,<br>
Luiz<br>
<br>
On 16 January 2014 16:19, Balaji, Pavan <<a href="mailto:balaji@mcs.anl.gov" target="_blank">balaji@mcs.anl.gov</a><br></div></div><div>
<mailto:<a href="mailto:balaji@mcs.anl.gov" target="_blank">balaji@mcs.anl.gov</a>>> wrote:<br>
<br>
<br>
On Jan 16, 2014, at 12:16 PM, Luiz Carlos da Costa Junior<br></div><div>
<<a href="mailto:lcjunior@ufrj.br" target="_blank">lcjunior@ufrj.br</a> <mailto:<a href="mailto:lcjunior@ufrj.br" target="_blank">lcjunior@ufrj.br</a>>> wrote:<br>
> No, these failures don't occur all the time. I have a<br>
successful run (with my original implementation) which I am<br>
using as the base case for comparison.<br>
<br>
What are the two cases you are comparing? Original<br>
implementation vs. new implementation? What’s the original<br>
implementation?<br>
<br>
— Pavan<br>
<br>
______________________________<u></u>_________________<br></div>
discuss mailing list <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a> <mailto:<a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a>><div><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/<u></u>mailman/listinfo/discuss</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br></div>
discuss mailing <a href="mailto:listdiscuss@mpich.org" target="_blank">listdiscuss@mpich.org</a> <mailto:<a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a>><div><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/<u></u>mailman/listinfo/discuss</a><br>
</div></blockquote><div>
<br>
<br>
--<br>
Antonio J. Peņa<br>
Postdoctoral Appointee<br>
Mathematics and Computer Science Division<br>
Argonne National Laboratory<br>
9700 South Cass Avenue, Bldg. 240, Of. 3148<br>
Argonne, IL 60439-4847<br></div>
<a href="mailto:apenya@mcs.anl.gov" target="_blank">apenya@mcs.anl.gov</a> <mailto:<a href="mailto:apenya@mcs.anl.gov" target="_blank">apenya@mcs.anl.gov</a>><br>
<a href="http://www.mcs.anl.gov/~apenya" target="_blank">www.mcs.anl.gov/~apenya</a> <<a href="http://www.mcs.anl.gov/~apenya" target="_blank">http://www.mcs.anl.gov/~<u></u>apenya</a>><br>
<br>
<br>
______________________________<u></u>_________________<br>
discuss mailing list <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a> <mailto:<a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a>><div><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/<u></u>mailman/listinfo/discuss</a><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
discuss mailing list <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/<u></u>mailman/listinfo/discuss</a><br>
<br>
</div></blockquote><div><div>
______________________________<u></u>_________________<br>
discuss mailing list <a href="mailto:discuss@mpich.org" target="_blank">discuss@mpich.org</a><br>
To manage subscription options or unsubscribe:<br>
<a href="https://lists.mpich.org/mailman/listinfo/discuss" target="_blank">https://lists.mpich.org/<u></u>mailman/listinfo/discuss</a></div></div></blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>