- Mpi-22 - mailman3.cels.anl.gov

MPI close and re-establish connection
by sayan mandal 14 Aug '19

14 Aug '19

Hi All, I am working on a project, where I want to close the connection(read socket) setup by MPI and re-establish the connection between the processes. I noticed that if I call MPI_Finalize, The connection gets terminated, but I cannot call any MPI_ functions after that. Could you guys tell me if there is any way to do this? Regards, Sayan Mandal *Ph : +91-8902552884* Final Year Undergraduate Student, Computer Science and engineering, Indian Institute Of Technology Kharagpur, *E : *sayan007roni(a)gmail.com

1 0

Datatype questions
by unknown＠example.com 10 Nov '11

10 Nov '11

I read the mpi document (http://www.mpi-forum.org/docs/mpi-2.2/mpi22-report.pdf) where it states that a filetype is either a single etype or a derived MPI datatype constructed from multiple instances of the same etype. This looks like the definition only allow one datatype as elementary type. However, when looking some examples such as struct (http://www.osc.edu/supercomputing/training/mpi/Feb_05_2008/mpi_0802_mod_dat…) it allows several datatypes passed in to construct a new datatype. In this example (struct), how can a user determine which datatype is the elementary type? Or in fact a filetype can contains multiple elementary types. In addition, is derived datatype can only constructed by routines (mpi_type_contiguous, mpi_type_vector, etc.)? Can a programmer compose derived datatype from predefined mpi datatype (such as mpi_int + mpi_float)? Thanks.

1 0

Re: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations
by unknown＠example.com 03 Nov '10

03 Nov '10

Here's my suggestion: The draft is intended to alert people to very likely additions and even changes to the MPI standard. The draft should be in as good a shape as possible, so fixes like this to the text are reasonable. However, these are significant enough that for the Standard (not the draft), we'll clearly need another vote. We should postpone that vote until we're closer to issuing an official standard, since other things may change (for example, C++ or Fortran 200x bindings). Bill On Nov 2, 2010, at 12:31 PM, Torsten Hoefler wrote: > Bronis, >> It really seems to me that these changes exceed >> the guidelines that Rich and Bill have given >> for the release draft. While I understand the >> reasoon behind them, it is unclear that we will >> have reviewed them properly. For example, I think >> the wording below could use work. > This is a clear error and can cause significant confusion on the > user's > and implementer's side. Most of the text is copied from the > point-to-point section and is thus consistent with the remainder of > the > document (even though I don't like the wording there ("should") at > all!). > >> I am in transit to ANL right now so I cannot go >> over it properly until at least tonight... > Please take your time and check. We are not intending to rush. > >> Even then, this feels rushed. > I don't think there is rush. We can release the document without this > fix (with a known bug). That's why I commit each item separately. > However, I'm against a release with bugs but that's not my decision. > > Thanks, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Performance Modeling and Simulation Lead > Blue Waters Directorate | University of Illinois (UIUC) > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

1 0

Re: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations
by unknown＠example.com 03 Nov '10

03 Nov '10

Bronis, the corrections are based on the primary rule that the job of the chapter committee is to guarantee that a new functionality is included in the document in a consistent way. This was done. This was not a correction of the functionality of the nonblocking collective communications. Ticket 109 is the only one that was included and only for this ticket, such consistency checks had to be done. For all other chapters, the rule is "only typo and formatting corrections". Rolf ----- Original Message ----- > From: "Torsten Hoefler" <htor_at_[hidden]> > To: "Bronis R. de Supinski" <bronis_at_[hidden]>, "MPI 2.2" <mpi-22_at_[hidden]> > Sent: Tuesday, November 2, 2010 6:31:16 PM > Subject: Re: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations > Bronis, > > It really seems to me that these changes exceed > > the guidelines that Rich and Bill have given > > for the release draft. While I understand the > > reasoon behind them, it is unclear that we will > > have reviewed them properly. For example, I think > > the wording below could use work. > This is a clear error and can cause significant confusion on the > user's > and implementer's side. Most of the text is copied from the > point-to-point section and is thus consistent with the remainder of > the > document (even though I don't like the wording there ("should") at > all!). > > > I am in transit to ANL right now so I cannot go > > over it properly until at least tonight... > Please take your time and check. We are not intending to rush. > > > Even then, this feels rushed. > I don't think there is rush. We can release the document without this > fix (with a known bug). That's why I commit each item separately. > However, I'm against a release with bugs but that's not my decision. > > Thanks, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Performance Modeling and Simulation Lead > Blue Waters Directorate | University of Illinois (UIUC) > 1205 W Clark Street | Urbana, IL, 61801 > NCSA Building | +01 (217) 244-7736 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations
by unknown＠example.com 02 Nov '10

02 Nov '10

Bronis, > It really seems to me that these changes exceed > the guidelines that Rich and Bill have given > for the release draft. While I understand the > reasoon behind them, it is unclear that we will > have reviewed them properly. For example, I think > the wording below could use work. This is a clear error and can cause significant confusion on the user's and implementer's side. Most of the text is copied from the point-to-point section and is thus consistent with the remainder of the document (even though I don't like the wording there ("should") at all!). > I am in transit to ANL right now so I cannot go > over it properly until at least tonight... Please take your time and check. We are not intending to rush. > Even then, this feels rushed. I don't think there is rush. We can release the document without this fix (with a known bug). That's why I commit each item separately. However, I'm against a release with bugs but that's not my decision. Thanks, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Performance Modeling and Simulation Lead Blue Waters Directorate | University of Illinois (UIUC) 1205 W Clark Street | Urbana, IL, 61801 NCSA Building | +01 (217) 244-7736

1 0

Re: [Mpi-22] [MPI Forum] #109: Nonblocking Collective Operations
by unknown＠example.com 02 Nov '10

02 Nov '10

Rolf and Torsten: It really seems to me that these changes exceed the guidelines that Rich and Bill have given for the release draft. While I understand the reasoon behind them, it is unclear that we will have reviewed them properly. For example, I think the wording below could use work. I am in transit to ANL right now so I cannot go over it properly until at least tonight... Even then, this feels rushed. Bronis On Tue, 2 Nov 2010, MPI Forum wrote: > #109: Nonblocking Collective Operations > --------------------------------------------------------+------------------- > Reporter: htor | Owner: htor > Type: New routine(s) | Status: new > Priority: Waiting for PDF reviews | Milestone: 2009/02/09 San Jose > Version: MPI 3.0 | Keywords: > Implementation: Completed | Author_bill_gropp: 1 > Author_rich_graham: 0 | Author_adam_moody: 0 > Author_torsten_hoefler: 1 | Author_dick_treumann: 0 > Author_jesper_larsson_traeff: 0 | Author_george_bosilca: 0 > Author_david_solt: 0 | Author_bronis_de_supinski: 0 > Author_rajeev_thakur: 0 | Author_jeff_squyres: 0 > Author_alexander_supalov: 0 | Author_rolf_rabenseifner: 1 > --------------------------------------------------------+------------------- > > Comment(by htor): > > Replying to [comment:44 RolfRabenseifner]: > > Whether we use now the text in my last comment or, a more complete text, > > we can decide now or later, but I would prefer a more complete text, > > because then it is clear why this exception is only for 4 completion > routines: > > > > The fields in a status object returned by a call to MPI_WAIT, > MPI_TEST, or > > MPI_{TEST|WAIT}{ALL|SOME|ANY}, where the request corresponds to a > nonblocking > > collective call, are undefined, with one exceptions: The error status > field > > will contain valid information if the wait or test call returned with > MPI_ERR_IN_STATUS. > > MPI_ERR_IN_STATUS can be returned only by MPI_{TEST|WAIT}{ALL|SOME}, > because > > only these MPI completion functions take arrays of MPI_STATUS. > > Rolf and I decided to adopt this minor change (with slight modifications) > and clear fix after a phone call. It now reads: > > "The fields in a status object returned by a call to MPI_WAIT, MPI_TEST, > or any of the other derived functions (MPI_{TEST|WAIT}{ALL|SOME|ANY}), > where the request corresponds to a send call, are undefined, with one > exception: The error status field will contain valid information if the > wait or test call returned with MPI_ERR_IN_STATUS. MPI_ERR_IN_STATUS > should be returned only by MPI_{TEST|WAIT}{ALL|SOME}, because only these > MPI completion functions take arrays of MPI_STATUS." > > See revision 679. > > Thanks, > Torsten > > -- > Ticket URL: <https://BLOCKEDsvn.mpi-forum.org/trac/mpi-forum-web/ticket/109#comment:47> > MPI Forum <https://BLOCKEDsvn.mpi-forum.org/> > MPI Forum

1 0

Re: [Mpi-22] reConfigurable MPI
by unknown＠example.com 07 Jul '10

07 Jul '10

Dear Richard, Thank you very very much, I got the point. Regards, Siavash On Tue, Jul 6, 2010 at 6:09 PM, Richard Treumann <treumann_at_[hidden]>wrote: > Saivash > > Adding something this complex to the MPI Standard would require that a > handful of people [...] > > Dick > *

1 0

MPI_Scatter structure's field
by unknown＠example.com 07 Jul '10

07 Jul '10

Hello to everybody, In the script below I dont know how to Scatter the structure's field genes. I would like to scatter them in a chunk of 2. So for N old_chrome and M genes I will have: at node 0 old_chrome[0-N].genes[0-1] at node 1 old_chrome[0-N].genes[0-2] ... at node x old_chrome[0-N].genes[(M-2)to(M-1)] Any help How to Scatter? Many thanks #include <stdio.h> #include <stdlib.h> #include <mpi.h> #include <math.h> #include <time.h> #include <limits.h> #include "mylib.h" #define NUM_OF_GENERATIONS 10000 #define NUM_OF_GENES 3 #define NUM_OF_CHROMES 5 #define NUM_OF_FORCES 3 truct chromosome{ double fitness; double genes[NUM_OF_GENES]; double up_limit[NUM_OF_GENES]; double low_limit[NUM_OF_GENES]; }; struct chromosome old_chrome[NUM_OF_CHROMES], new_chrome[NUM_OF_CHROMES], temp_chrome[NUM_OF_CHROMES]; double forces[NUM_OF_FORCES]; double matrix[NUM_OF_FORCES][NUM_OF_GENES]; double matrix_local[NUM_OF_FORCES][NUM_OF_GENES]; double forces_local[NUM_OF_FORCES]; int CROSS_CHROME[NUM_OF_CHROMES]; int main(int argc, char* argv[]) { int size,rank,i,j,n; int blockCounts[4] = {1,NUM_OF_GENES,NUM_OF_GENES,NUM_OF_GENES}; MPI_Datatype types[4]; MPI_Aint displace[4]; MPI_Datatype myStructType; int base; srand48(time(NULL)); MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &rank); MPI_Comm_size(MPI_COMM_WORLD, &size); MPI_Address(old_chrome,displace); MPI_Address(old_chrome[0].genes,displace+1 ); MPI_Address(old_chrome[0].up_limit, displace+2); MPI_Address(old_chrome[0].low_limit, displace+3); types[0] = MPI_DOUBLE; types[1] = MPI_DOUBLE; types[2] = MPI_DOUBLE; types[3] = MPI_DOUBLE; base = displace[0]; for(i=0; i<4; i++) { displace[i] -= base; } MPI_Type_struct(4, blockCounts, displace, types, &myStructType); MPI_Type_commit(&myStructType); if(rank == 0) { for(i=0;i<4;i++) { for(j=0;j<2;j++) { old_chrome[i].genes[j]=drand48(); } } } for(i=0;i<NUM_OF_CHROMES;i++) { printf("%d old_chrome[%d].genes[0]= %lf\n",rank,i, old_chrome[i].genes[0]); } MPI_Barrier(MPI_COMM_WORLD); for(i=0;i<NUM_OF_CHROMES;i++) { MPI_Scatter(&old_chrome[0].genes[0],2,myStructType,&temp_chrome[0].genes[0],2,myStructType,0,MPI_COMM_WORLD); } MPI_Barrier(MPI_COMM_WORLD); for(i=0;i<NUM_OF_CHROMES;i++) { for(j=0;j<2;j++) { printf("\n%d temp_chrome[%d].genes[%d] = %lf\n",rank,i,j, temp_chrome[i].genes[j]); } } MPI_Finalize(); }

1 0

Re: [Mpi-22] reConfigurable MPI
by unknown＠example.com 06 Jul '10

06 Jul '10

Saivash Adding something this complex to the MPI Standard would require that a handful of people who think it is important, join the MPI Forum and work out a proposed addition to the standard and provide a "proof of concept" implementation. The MPI Standard is developed by people with regular jobs who consider it worthwhile to donate some of their time to the MPI Forum. Obviously, most work for organizations that are also willing to fund modest support for the MPI Forum.There is no paid staff that can be asked to work out something new. The people who want something new need to do the work. There is a Fault Tolerance subcommittee that may be doing some things that overlap what you want but my personal feeling is that the primary goals of the fault tolerance sub-committee are already so challenging that being asked to add even more to their current set of goals would not go over well. The MPI Standard, at its core, is designed around the following ideas (incomplete list obviously): 1) Applications do not need to check for errors because the library will do what the application asks if it can and issue a fatal error if success is not possible 2) Communicators do not change membership (allows collective operations to avoid overheads and unpredictability from possible membership additions/subtractions) 3) Communicator creations are always collective and deterministic. Everything that needs to be done can be done via messages among participants (no interaction with a supervisor daemon needed) 4) Tasks or processes that make up a job run independently except when an explicit application call forces them to interact. (Send/Recv forces 2 tasks to interact, Barrier on a communicator forces all tasks of that communicator to interact. Tasks that are not part of the interaction specified by the application are semantically unaffected.) These characteristic make both Fault Tolerance and the kind of extensions you envision very challenging. I do not know of any help anyone can offer you within the existing MPI Standard. Participation in the MPI Forum is generally open to any one who can find the time and can attend the meetings. (BTW - I think most MPI applications are run on managed clusters that are large enough to run several jobs at once. These clusters do not have resources come a go often. A node that needs routine repair or upgrade will be deleted from the resource pool when it finishes a job and when it is added back to the pool, some job that is waiting in the work queue will get it. The theory that it is better for a running job to claim it on the fly than for the next job waiting in the queue be assigned the node is probably rare) Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 siavash ghiasvand <siavash.ghiyasvand_at_[hidden]> wrote on 07/01/2010 03:26:39 PM: > [image removed] > > Re: [Mpi-22] reConfigurable MPI > > siavash ghiasvand > > to: > > MPI 2.2 > > 07/01/2010 03:27 PM > > Cc: > > Richard Treumann > > You seem to be interested in the situation where resources are added > to a cluster (or maybe freed up by other jobs completing) and having > a running MPI job get notified asynchronously that there are newly > available resources it can make a bid for. > > Absolutely, this is what I want to do. But first of all I tried to > know why MPI as the leader of HPC clusters world didn't include this > concept in its standard (May be it's totally against the HPC > world!). With Mr.Solt, Mr.Gropp and your guides now I know the > answer of that "Why?" > > > This idea of the cluster manager pushing resources to a job without > regard to where the job is in its execution would bring lots of new > issues. I am not aware of anybody having made a serious attempt to > even define what would be needed inside the MPI standard to let > applications catch and act on an asynchronous notification like this. > > I heard about (I'm not sure) something like this in "MPI/GAMMA Project" [1 > ], which pushes additional resources to a running MPI cluster and > when the running program reaches mpi_barrier point those new > resources are getting involved (completely asynchronous). > > > My first guess is that pushing an offer of additional resource would > not be very hard to design into a resource manager but the MPI API > side of how to react asynchronously to that offer would be very complex. > > You are right, the automatic way for handling this, is really > breathtaking. for example, if we divided a loop for 5 machines and > the cluster is running now, how we can involve a new (6th) machine > without restarting the entire cluster?! > > > Running job decides to try for more resource vs resource manager > tries to volunteer more resource to running job > > In PVM we have two functions pvm_addhosts and pvm_delhosts [2] and > they can more or less handle the first type ("Running job decides to > try for more resource") but the great issue is with the second one: > "resource manager tries to volunteer more resource to running job" > which means jobs are not aware about those new resources. > > Any help or Idea in this concept would be greatly appreciated. > > > [1]  http://www.disi.unige.it/project/gamma/mpigamma/ > [2] http://docs.cray.com/books/004-3686-001/html-004-3686-001/vemjlb.html > > > > Regards, > Siavash, *

1 0

Re: [Mpi-22] reConfigurable MPI
by unknown＠example.com 01 Jul '10

01 Jul '10

> > You seem to be interested in the situation where resources are added to a > cluster (or maybe freed up by other jobs completing) and having a running > MPI job get notified asynchronously that there are newly available resources > it can make a bid for. Absolutely, this is what I want to do. But first of all I tried to know why MPI as the leader of HPC clusters world didn't include this concept in its standard (May be it's totally against the HPC world!). With Mr.Solt, Mr.Gropp and your guides now I know the answer of that "Why?" > This idea of the cluster manager pushing resources to a job without regard > to where the job is in its execution would bring lots of new issues. I am > not aware of anybody having made a serious attempt to even define what would > be needed inside the MPI standard to let applications catch and act on an > asynchronous notification like this. > I heard about (I'm not sure) something like this in "MPI/GAMMA Project" [1<http://www.disi.unige.it/project/gamma/mpigamma/>], which pushes additional resources to a running MPI cluster and when the running program reaches mpi_barrier point those new resources are getting involved (completely asynchronous). > My first guess is that pushing an offer of additional resource would not be > very hard to design into a resource manager but the MPI API side of how to > react asynchronously to that offer would be very complex. > You are right, the automatic way for handling this, is really breathtaking. for example, if we divided a loop for 5 machines and the cluster is running now, how we can involve a new (6th) machine without restarting the entire cluster?! > Running job decides to try for more resource vs resource manager tries to > volunteer more resource to running job In PVM we have two functions pvm_addhosts and pvm_delhosts [2<http://docs.cray.com/books/004-3686-001/html-004-3686-001/vemjlb.html>] and they can more or less handle the first type ("Running job decides to try for more resource") but the great issue is with the second one: "resource manager tries to volunteer more resource to running job" which means jobs are not aware about those new resources. Any help or Idea in this concept would be greatly appreciated. [1] http://www.disi.unige.it/project/gamma/mpigamma/ [2] http://docs.cray.com/books/004-3686-001/html-004-3686-001/vemjlb.html Regards, Siavash *

1 0