- mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Sept meeting
by Richard Graham 22 Jul '08

22 Jul '08

You should use the EuroPVM registration page. This has worked for others. Rich On 7/22/08 12:28 PM, "Nathan DeBardeleben" <ndebard(a)lanl.gov> wrote: > Rich, for the Dublin meeting, I see that the $200 registration is open > but what about the hotel? Should we use the EuroPVM registration page > (even if we're not attending the conference afterwards?) or just > register with the hotel directly? > > Richard Graham wrote: >> The first cut at an agenda for the Sept meeting has been posted, along with >> other information about this meeting. I have scheduled MPI 2.1, 2.2, and >> the three MPI 3.0 working groups we have agreed to focus on. I have not has >> any requests for meeting space from the other working groups, so if I don't >> get any more requests, I will fill in the remaining time slots with MPI 2.2, >> and FT working group times (I can also expand the RMA wg and Collectives wg >> time slot, if there is a request for this). >> >> Also, I have posted the latest set of dates for 2009. This is getting >> firmer, so now is a good time to raise any problems with this time. I >> understand that there are people that don't want the Nov meeting to happen >> right before SC, but seems like the majority are in favor of this, so we >> will keep the date as is, unless enough people express another opinion. >> >> >> Rich >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum >>

1 0

Re: [Mpi-forum] Sept meeting
by Nathan DeBardeleben 22 Jul '08

22 Jul '08

Rich, for the Dublin meeting, I see that the $200 registration is open but what about the hotel? Should we use the EuroPVM registration page (even if we're not attending the conference afterwards?) or just register with the hotel directly? Richard Graham wrote: > The first cut at an agenda for the Sept meeting has been posted, along with > other information about this meeting. I have scheduled MPI 2.1, 2.2, and > the three MPI 3.0 working groups we have agreed to focus on. I have not has > any requests for meeting space from the other working groups, so if I don't > get any more requests, I will fill in the remaining time slots with MPI 2.2, > and FT working group times (I can also expand the RMA wg and Collectives wg > time slot, if there is a request for this). > > Also, I have posted the latest set of dates for 2009. This is getting > firmer, so now is a good time to raise any problems with this time. I > understand that there are people that don't want the Nov meeting to happen > right before SC, but seems like the majority are in favor of this, so we > will keep the date as is, unless enough people express another opinion. > > > Rich > > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-forum > -- -- Nathan --------------------------------------------------------------------- Nathan DeBardeleben, Ph.D. Los Alamos National Laboratory High Performance Computing Systems Integration (HPC-5) phone: 505-667-3428 email: ndebard(a)lanl.gov ---------------------------------------------------------------------

1 0

Sept meeting
by Richard Graham 22 Jul '08

22 Jul '08

The first cut at an agenda for the Sept meeting has been posted, along with other information about this meeting. I have scheduled MPI 2.1, 2.2, and the three MPI 3.0 working groups we have agreed to focus on. I have not has any requests for meeting space from the other working groups, so if I don't get any more requests, I will fill in the remaining time slots with MPI 2.2, and FT working group times (I can also expand the RMA wg and Collectives wg time slot, if there is a request for this). Also, I have posted the latest set of dates for 2009. This is getting firmer, so now is a good time to raise any problems with this time. I understand that there are people that don't want the Nov meeting to happen right before SC, but seems like the majority are in favor of this, so we will keep the date as is, unless enough people express another opinion. Rich

1 0

Dec meeting
by Richard Graham 17 Jul '08

17 Jul '08

I have had several inquiries about the Dec. meeting of the MPI Forum. We are firm on the meeting location being in the bay area. The exact location is still being determined. Sun will host this meeting again - thanks !!! - if their facilities are available, otherwise we will meet at a hotel. I will let people know as soon as I have exact details ironed out. Also, the Feb meeting will also be in the bay area, for those wanting to know this. I hope this week to update the meeting locations and dates for 2009, based on the discussion in the last meeting. Rich

1 0

Dublin meeting
by Richard Graham 16 Jul '08

16 Jul '08

Registration for the Next MPI Forum meeting, Sept 3-5 in Dublin Ireland is up and running. The URL is: https://www.ornl.gov/ccsd_registrations/nccs_mpi_forums/ I will have an agenda posted as soon as I hear back from the various working groups. Rich

1 0

Oct meeting hotel rooms, and more
by Richard Graham 15 Jul '08

15 Jul '08

We need a head count for hotel rooms at the Airport Marriott in Chicago for the October meeting, so that we can book rooms at the hotel. Attendance was low when head-count for this was taken in Menlo Park. The hotel rate will be the government rate (I think it is $149 at that time of year). Please let me know by the end of this week when you will need a room. Also, registration for the Dublin meeting should be up soon. It will be $200/person. Thanks, Rich

1 0

MPI 2.2 proposal: resolving MPI_Request_free issues
by Erez Haba 14 Jul '08

14 Jul '08

The set of issues related to MPI_Request_free have come up in the last MPI forum meeting. I've added an MPI 2.2 proposal for resolving those issues. See: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/mpi22/MPI_Request_free Please comment. Thanks, .Erez MPI_Request_free issues Author: Erez Haba Description: The MPI_Request_free mechanism was provided for reasons of performance and convenience on the sending side. However there are number of issues with its definitions and the advice to use text that conflicts with many implementations. Issue #1: Advice to user quote: "Once a request is freed by a call to MPI_REQUEST_FREE, it is not possible to check for the successful completion of the associated communication with calls to MPI_WAIT or MPI_TEST. Also, if an error occurs subsequently during the communication, an error code cannot be returned to the user - such an error must be treated as fatal." This is the only place in the MPI standard that mandates an error to be FATAL, regardless of the user settings. This is truly unrecoverable because the user can not associate the error with the failed send and cannot recover after MPI_Request_free was called. This poses a problem for a fault-tolerance implementation as it must handle this failure without the ability to notify the user for the specific error for the lack of context. Issue #2: Advice to user quote: "Questions arise as to how one knows when the operations have completed when using MPI_REQUEST_FREE. Depending on the program logic, there may be other ways in which the program knows that certain operations have completed and this makes usage of MPI_REQUEST_FREE practical. For example, an active send request could be freed when the logic of the program is such that the receiver sends a reply to the message sent - the arrival of the reply informs the sender that the send has completed and the send buffer can be reused." The suggestion to reuse (free) the buffer once a reply arrived seems straight forward, however it is a naïve one which might lead to access violation at best or worse data corruption. When zero copy is being use the local interconnect resource manager might still be using the send buffer even though a reply message was received. One alternative to enable that programming paradigm is always to copy the buffer (or the tail of the buffer) when using MPI_Isend. This will prevent any misuse of the user buffer. Consider the following examples: Example 1: TCP interconnect Rank 0 on node A sends message x to rank 1 on node B using the following sequence, MPI_Isend(buffer) MPI_Request_free Upon receive message x, rank 1 sends message y back to rank 0; when rank 0 receive message y it frees the buffer with the following sequence MPI_Recv free(buffer) This would result in access violation (seg fault) as the TCP stack still tries to touch buffer after it was freed. This would happen because although node B sends back message y, it did not piggyback the TCP acknowledgment seq numbers back with message x. As a result message y was consumed by the application and buffer was freed. Hence if the TCP stack on node A tries to resend buffer tail resulting in access violation. (note that node A sent message x using zcopy) Example 2: TCP interconnect (2 connections) To make it easier to understand think about the above same problem, but now there are two TCP connections each to only deliver messages in one direction and TCP acknowledgment in the other. This setting decouples the reply message from the TCP acknowledgment and makes the previous example easier to competence. Example 3: RMA interconnect (using RMA write) In this case rank 0 on node A issue its MPI_Isend using RDMA Write. The receiver is polling on memory detecting that the write complete and sends a reply back. The reply message bypasses the hardware acknowledgment that the write was successfully complete. Rank 0 processes it and the app frees the memory which disrupts the DMA on node A and causes the send to fail. Proposed Solution 3 proposals from the least restrictive to the most restrictive: Solution #1: Remove the advice to user to reuse the buffer once a reply has arrived. There is no safe way to reuse the buffer (free), overwrite is somewhat safer. Solution #2: Remove the advice to user altogether, disallow the usage pattern of freeing active requests. Only inactive requests are allowed to be freed. (i.e., not started). Solution #3: Deprecate MPI_Request_free. Users can always use MPI_Wait to complete the request. Recommendation: Use solution #2, as users still need to free requests if they are not used; e.g., the app called MPI_Send_init but never got the start that request; hence the request still need to be freed. History Calling MPI_Request_free was added for convenience (the user does not have to remember to free the request later) and performance (freeing the request is not on the critical path when the reply message arrives and require processing). Impact on Implementations (assuming solution 2) High quality implementations would detect a call to free an active request and return an error. Impact on Applications / Users Applications must refrain freeing the request before it's complete. Therefore, requiring the application to track the request handle to completion. (this potentially breaks existing applicaitons) Alternative Solutions Entry for the Change Log Using MPI_Request_free to free an active request has been disallowed.

1 0

October MPI Forum meeting
by Richard Graham 11 Jul '08

11 Jul '08

Just to let people know that this meeting will be back at the airport location, if we can get a meeting rooms. The MS facility that we all liked so much is not available this time. Rich

1 0

MPI Forum wiki
by Jeff Squyres 08 Jul '08

08 Jul '08

Policy change: all anonymous edits on the MPI Forum wiki have been disabled (the server got spam-bombed). You must register for an account and then login to be able to edit wiki pages, tickets, etc. For uninteresting reasons, the wiki we're using is not capable of registering users, so you have to use a secondary system to register for an account: https://svn.mpi-forum.org/wiki/start Once you get a username/password on that system, you can use that username/password to logon to the real MPI Forum wiki: https://svn.mpi-forum.org/trac/mpi-forum-web/wiki (this information is on the front page of the wiki as well) ***NOTE 1: It is *STRONGLY* encouraged that you visit the "Preferences" link in the top-right of the MPI Forum Wiki to set your e-mail address. ***NOTE 2: We copied all existing MPI Forum Subversion usernames/ passwords to the wiki system. Hence, if you were involved in the MPI-2.1 editing effort and have a Subversion account, you do not need to re-register; you can simply use your existing Subversion username and password to login to the wiki. Finally, note that Subversion and the wiki are two separate systems; changing your password on one of them will not be reflected on the other. Many thanks to Indiana University for donating system administrator time and server resources to get all this stuff setup. -- Jeff Squyres Cisco Systems

1 0

An error in mpi program
by wg zhang 07 Jul '08

07 Jul '08

Hi,guys, I am not sure am I supposed to ask for help here or not. But I do need your guys' help to give me some hint solving this problem. I have a parallel fortran code which is written by us. It seems like working well but actually the output from 1 node to 5 nodes are the same(the results I think are correct).When I am using more than 6 nodes, the output is different,which I think is wrong. For example,the following lines are the output from 1(or 2) node calculation and 6 nodes calculation. Look at the data. The atomic positions are the same. But the order of atoms are different. Why dose this happen? Why the results are different with 5 nodes and 6 nodes? atom type atomic position 1 Al 0.0000 0.0000 -1.8869 2 O -1.6539 0.1249 -1.0842 3 O 0.7188 -1.4947 -1.0842 4 O 0.9351 1.3699 -1.0842 5 Al 2.3727 -1.3699 -0.2816 6 Al -2.3727 1.3699 0.2816 7 O 1.6539 -0.1249 1.0842 8 O -0.7188 1.4947 1.0842 9 O -0.9351 -1.3699 1.0842 10 Al 0.0000 0.0000 1.8869 1 Al 0.0000 0.0000 -1.8869 2 O -1.6539 0.1249 -1.0842 3 O 0.7188 -1.4947 -1.0842 4 Al 0.9351 1.3699 -1.0842 5 O 2.3727 -1.3699 -0.2816 6 O -2.3727 1.3699 0.2816 7 O 1.6539 -0.1249 1.0842 8 Al -0.7188 1.4947 1.0842 9 Al -0.9351 -1.3699 1.0842 10 Al 0.0000 0.0000 1.8869 Your help is really appreciated, Wayne

1 0