May 2013 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPI_COMM_Spawn leave children processes in active wait
by Yauheni Zelenko 30 May '13

30 May '13

Hi, Edscott! I think you need to call MPI_Comm_disconnect() in child processes. Eugene. ________________________________________ From: discuss-bounces(a)mpich.org [discuss-bounces(a)mpich.org] On Behalf Of Edscott Wilson [edscott.wilson.garcia(a)gmail.com] Sent: Thursday, May 30, 2013 12:48 PM To: discuss(a)mpich.org Subject: [mpich-discuss] MPI_COMM_Spawn leave children processes in active wait MPI_COMM_Spawn leave children processes in active wait until parent process is done. I've just checked latest ompi and behavior is the same as in mpich. So be it. -- ------------------------------------------------------------------------------------ Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute

1 0

MPI_COMM_Spawn leave children processes in active wait
by Edscott Wilson 30 May '13

30 May '13

MPI_COMM_Spawn leave children processes in active wait until parent process is done. I've just checked latest ompi and behavior is the same as in mpich. So be it. -- ------------------------------------------------------------------------------------ Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute

1 0

Re: [mpich-discuss] weird behavior with mpiexe (3.0.4)
by Edscott Wilson 29 May '13

29 May '13

2013/5/29 Jeff Hammond <jhammond(a)alcf.anl.gov> > > > > > > > Wouldn't a message such as "`pwd` directory does not exist on node > velascoj" > > be more illustrative? > > Yes. However, the set of improper uses of MPI that could generate > helpful error messages is uncountable. Do you not think it is a good > use of finite developer effort to implement an infinitesimal fraction > of such warnings? There has to be a minimum requirement placed upon > the user. I personally think that it should include running in a > directory that actually exists. > Certainly! But then again, some developer must have thought it a good idea, since under different circumstances, I get: /bin/bash -c mpiexec -n 1 -hosts tauro,velascoj gmandel [proxy:0:0@tauro] launch_procs (./pm/pmiserv/pmip_cb.c:648): unable to change wdir to /tmp/edscott/mnt/tauro-home/GIT/gmandel (No such file or directory) [proxy:0:0@tauro] HYD_pmcd_pmip_control_cmd_cb (./pm/pmiserv/pmip_cb.c:893): launch_procs returned error [proxy:0:0@tauro] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status [proxy:0:0@tauro] main (./pm/pmiserv/pmip.c:206): demux engine error waiting for event [mpiexec@velascoj] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert (!closed) failed [mpiexec@velascoj] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status [mpiexec@velascoj] HYD_pmci_wait_for_completion (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event [mpiexec@velascoj] main (./ui/mpich/mpiexec.c:331): process manager error waiting for completion Which is inconsistent with the previous behavior. Anyways, its no big deal. BTW, would you happen to know why a process which is started with MPI_Comm_spawn will go into what seems like an active wait after MPI_Comm_disconnect and MPI_Finalize has been called? These spawned processed will hog up CPU until the parent process exits. Curious enough, this behavior is not mirrored in openmpi. Edscott ------------------------------- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute

1 0

Re: [mpich-discuss] weird behavior with mpiexe (3.0.4)
by Jeff Hammond 29 May '13

29 May '13

> This is weird. If I chdir to /home/edscott/tmp and execute the following > command I get: > > edscott@tauro ~/tmp $ mpiexec -n 2 -hosts tauro,velascoj /bin/hostname > tauro > velascoj > > But if I chdir to /home/edscott/temp and do the same I get: > > edscott@tauro ~/temp $ mpiexec -n 2 -hosts tauro,velascoj /bin/hostname > tauro > [mpiexec@tauro] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert (!closed) > failed > [mpiexec@tauro] HYDT_dmxu_poll_wait_for_event > (./tools/demux/demux_poll.c:77): callback returned error status > [mpiexec@tauro] HYD_pmci_wait_for_completion > (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event > [mpiexec@tauro] main (./ui/mpich/mpiexec.c:331): process manager error > waiting for completion > > > Wouldn't a message such as "`pwd` directory does not exist on node velascoj" > be more illustrative? Yes. However, the set of improper uses of MPI that could generate helpful error messages is uncountable. Do you not think it is a good use of finite developer effort to implement an infinitesimal fraction of such warnings? There has to be a minimum requirement placed upon the user. I personally think that it should include running in a directory that actually exists. Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond ALCF docs: http://www.alcf.anl.gov/user-guides

1 0

weird behavior with mpiexe (3.0.4)
by Edscott Wilson 29 May '13

29 May '13

This is weird. If I chdir to /home/edscott/tmp and execute the following command I get: edscott@tauro ~/tmp $ mpiexec -n 2 -hosts tauro,velascoj /bin/hostname tauro velascoj But if I chdir to /home/edscott/temp and do the same I get: edscott@tauro ~/temp $ mpiexec -n 2 -hosts tauro,velascoj /bin/hostname tauro [mpiexec@tauro] control_cb (./pm/pmiserv/pmiserv_cb.c:202): assert (!closed) failed [mpiexec@tauro] HYDT_dmxu_poll_wait_for_event (./tools/demux/demux_poll.c:77): callback returned error status [mpiexec@tauro] HYD_pmci_wait_for_completion (./pm/pmiserv/pmiserv_pmci.c:197): error waiting for event [mpiexec@tauro] main (./ui/mpich/mpiexec.c:331): process manager error waiting for completion Wouldn't a message such as "`pwd` directory does not exist on node velascoj" be more illustrative? ------------------------------- Dr. Edscott Wilson Garcia Applied Mathematics and Computing Mexican Petroleum Institute

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Pavan Balaji 21 May '13

21 May '13

On 05/21/2013 08:58 AM US Central Time, Jeff Squyres (jsquyres) wrote: > You're talking in addition to the 2 hour hybrid time on Wednesday, > right? (i.e., assuming that that will be taken up with init/finalize > discussions) Correct. -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Jeff Squyres (jsquyres) 21 May '13

21 May '13

You're talking in addition to the 2 hour hybrid time on Wednesday, right? (i.e., assuming that that will be taken up with init/finalize discussions) On May 21, 2013, at 9:49 AM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > On 05/21/2013 08:46 AM US Central Time, Jeff Squyres (jsquyres) wrote: >> Ah. Well. There you go. :-) >> >> I'd say that all these keyval things are worthy of discussion in >> SJC... (fortran included!) > > I'll see if Martin can give us some time for it. > > -- Pavan > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Pavan Balaji 21 May '13

21 May '13

On 05/21/2013 08:46 AM US Central Time, Jeff Squyres (jsquyres) wrote: > Ah. Well. There you go. :-) > > I'd say that all these keyval things are worthy of discussion in > SJC... (fortran included!) I'll see if Martin can give us some time for it. -- Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Jeff Squyres (jsquyres) 21 May '13

21 May '13

Ah. Well. There you go. :-) I'd say that all these keyval things are worthy of discussion in SJC... (fortran included!) On May 21, 2013, at 9:44 AM, Pavan Balaji <balaji(a)mcs.anl.gov> wrote: > > It comes under "Groups, Contexts, Communicators, and Caching". I'm > handling that as well. > > -- Pavan > > On 05/21/2013 08:41 AM US Central Time, Jeff Squyres (jsquyres) wrote: >> FWIW: I don't know if attributes/callbacks are the purview of hybrid, but then again, I don't know exactly who's purview they fall under... >> >> >> On May 20, 2013, at 6:54 PM, Fab Tillier <ftillier(a)microsoft.com> >> wrote: >> >>> Pavan Balaji wrote on Mon, 20 May 2013 at 15:45:35 >>> >>>> >>>> On 05/20/2013 11:16 AM US Central Time, Fab Tillier wrote: >>>>> In MPI-3, section 8.7.1 (page 363) states that delete callbacks are >>>>> invoked on MPI_COMM_SELF before anything else happens, and that >>>>> MPI_FINALIZED will return false from any of these delete callbacks. >>>>> There's no mention about attribute callbacks on other built-in >>>>> communicators, and no mention of behavior for built-in types. Likely >>>>> they should be invoked too for consistency's sake. >>>> >>>> I'd think not. For built-in communicators, it makes sense since they >>>> cannot be freed by the user. For other communicators, it's the user's >>>> responsibility to free them. So the callbacks should be triggered at >>>> that time. >>> >>> I meant for all built-in objects (communicators and types), not just MPI_COMM_SELF. I agree that any user-allocated objects are the users's responsibility (just say no to automatic garbage collection). >>> >>>>> What's interesting is that this section states that there is an >>>>> ordering enforced (reverse from the order in which they are set), >>>>> while MPI_COMM_FREE (page 248) states that the callbacks are invoked >>>>> in arbitrary order. >>>>> >>>>> We should probably make that consistent, and to preserve backward >>>>> compatibility, the "arbitrary order" may have to become stricter for >>>>> implementations to match the finalize behavior. >>>> >>>> Gross. Yes, I agree it should be consistent. >>> >>> I added some comments about the above to the ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/374) as well as raised an issue about the keyval parameter value to the callbacks when the keyval has been freed by the user. >>> >>> Anyway, I think we're all converging on our opinions, which is always a good thing. >>> >>> Cheers, >>> -Fab >> >> > > -- > Pavan Balaji > http://www.mcs.anl.gov/~balaji -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Re: [mpich-discuss] [PATCH v2] test: add attrdeleteget, MPI_Attr_get called from delete_fn
by Pavan Balaji 21 May '13

21 May '13

It comes under "Groups, Contexts, Communicators, and Caching". I'm handling that as well. -- Pavan On 05/21/2013 08:41 AM US Central Time, Jeff Squyres (jsquyres) wrote: > FWIW: I don't know if attributes/callbacks are the purview of hybrid, but then again, I don't know exactly who's purview they fall under... > > > On May 20, 2013, at 6:54 PM, Fab Tillier <ftillier(a)microsoft.com> > wrote: > >> Pavan Balaji wrote on Mon, 20 May 2013 at 15:45:35 >> >>> >>> On 05/20/2013 11:16 AM US Central Time, Fab Tillier wrote: >>>> In MPI-3, section 8.7.1 (page 363) states that delete callbacks are >>>> invoked on MPI_COMM_SELF before anything else happens, and that >>>> MPI_FINALIZED will return false from any of these delete callbacks. >>>> There's no mention about attribute callbacks on other built-in >>>> communicators, and no mention of behavior for built-in types. Likely >>>> they should be invoked too for consistency's sake. >>> >>> I'd think not. For built-in communicators, it makes sense since they >>> cannot be freed by the user. For other communicators, it's the user's >>> responsibility to free them. So the callbacks should be triggered at >>> that time. >> >> I meant for all built-in objects (communicators and types), not just MPI_COMM_SELF. I agree that any user-allocated objects are the users's responsibility (just say no to automatic garbage collection). >> >>>> What's interesting is that this section states that there is an >>>> ordering enforced (reverse from the order in which they are set), >>>> while MPI_COMM_FREE (page 248) states that the callbacks are invoked >>>> in arbitrary order. >>>> >>>> We should probably make that consistent, and to preserve backward >>>> compatibility, the "arbitrary order" may have to become stricter for >>>> implementations to match the finalize behavior. >>> >>> Gross. Yes, I agree it should be consistent. >> >> I added some comments about the above to the ticket (https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/374) as well as raised an issue about the keyval parameter value to the callbacks when the keyval has been freed by the user. >> >> Anyway, I think we're all converging on our opinions, which is always a good thing. >> >> Cheers, >> -Fab > > -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0