March 2014 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] MPI_Address()
by Jeff Squyres (jsquyres) 12 Mar '14

12 Mar '14

Got any opinions on names for the configure option and run-time param option? I'm guessing we *might* be able to use the same configure option, but I'll bet our run-time option will have a different name. But I figured I'd ask... (Nathan just reminded me that this also applies to all the C++ MPI:: methods, too) How about: 1. ./configure --enable|disable-mpi3-deleted-interfaces 2. MPI_T name: mpi3_deleted_interfaces_check, which can take one of four values: none, warn_once, warn, or error On Mar 12, 2014, at 2:06 PM, "Balaji, Pavan" <balaji(a)anl.gov> wrote: > > Thanks, Jeff. The four levels sounds good to me. > > — Pavan > > On Mar 12, 2014, at 11:57 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > >> FWIW, we had a similar discussion in OMPI this morning. We (loosely) came up with the the following: >> >> 1. Have a configure argument to enable/disable having the deleted functions in mpi.h and the mpi module (remember that these deleted functions have no interfaces in the mpi_f08 module -- whew! ...but we'll have to see if anything gets deleted in MPI-4). At least for a while, default to having the interfaces available/compiled in. Eventually, change the default to not having them available/compiled out. >> >> 2. When the interfaces are available/compiled in, have a run-time parameter (e.g., via MPI_T) that provides 4 levels: >> >> 0: do nothing >> 1: warn the first time a deleted function is used in a process >> 2: warn every time a deleted function is used in a process >> 3: error the first time a deleted function is used in a process >> >> (the only difference between #1 and #2 is the annoyance factor) >> >> The tricky part will be how to handle future function deletions -- we should pick configure / run-time parameter names that reflects removing the functions that were deleted in MPI-3 so that we leave the door open for MPI-4 deletions handled (and retired) separately. >> >> I bring this up because it might be useful if OMPI/MPICH do similar things with regards to handling these deleted functions... We don't have to do it exactly the same, but if we're at least sorta similar, that'll be good enough. >> >> >> On Mar 12, 2014, at 12:48 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: >> >>> Added it to the ticket. >>> https://trac.mpich.org/projects/mpich/ticket/2056 >>> >>> On Mar 12, 2014, at 11:38 AM, Michael Blocksome <blocksom(a)us.ibm.com> wrote: >>> >>>> Would it be possible to make the inclusion of deprecated/deleted functions in the mpi.h header configurable? >>>> >>>> If so, then a "strict" mpich library could be configured, compiled, and used to aid those who wish to port legacy applications to the new standard. By default, this "strict" mode would be disabled in order to preserve the current design decision. >>>> >>>> >>>> Michael Blocksome >>>> Parallel Environment MPI Middleware Team Lead, TCEM >>>> POWER, x86, and Blue Gene HPC Messaging >>>> blocksom(a)us.ibm.com >>>> >>>> >>>> >>>> >>>> From: Rajeev Thakur <thakur(a)mcs.anl.gov> >>>> To: <discuss(a)mpich.org>, >>>> Date: 03/11/2014 09:51 PM >>>> Subject: Re: [mpich-discuss] MPI_Address() >>>> Sent by: discuss-bounces(a)mpich.org >>>> >>>> >>>> >>>> There are a whole bunch of such functions that were deprecated in MPI 2.0 (in 1997) and removed in MPI 3.0 (in 2012). We discussed whether to keep or remove them in MPICH, and decided to keep them so as not to gratuitously break user codes that still use the old functions. >>>> >>>> Rajeev >>>> >>>> On Mar 11, 2014, at 9:28 PM, Orion Poplawski <orion(a)cora.nwra.com> >>>> wrote: >>>> >>>>> MPI_Address() was removed from the MPI API in the MPI-3 specification so >>>>> it should be removed from mpich's mpi.h as well. Still present in 3.1 >>>>> and current repository. >>>>> >>>>> - Orion >>>>> >>>>> -- >>>>> Orion Poplawski >>>>> Technical Manager 303-415-9701 x222 >>>>> NWRA/CoRA Division FAX: 303-415-9702 >>>>> 3380 Mitchell Lane orion(a)cora.nwra.com >>>>> Boulder, CO 80301 http://www.cora.nwra.com >>>>> _______________________________________________ >>>>> discuss mailing list discuss(a)mpich.org >>>>> To manage subscription options or unsubscribe: >>>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- 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] MPI_Address()
by Balaji, Pavan 12 Mar '14

12 Mar '14

Thanks, Jeff. The four levels sounds good to me. — Pavan On Mar 12, 2014, at 11:57 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > FWIW, we had a similar discussion in OMPI this morning. We (loosely) came up with the the following: > > 1. Have a configure argument to enable/disable having the deleted functions in mpi.h and the mpi module (remember that these deleted functions have no interfaces in the mpi_f08 module -- whew! ...but we'll have to see if anything gets deleted in MPI-4). At least for a while, default to having the interfaces available/compiled in. Eventually, change the default to not having them available/compiled out. > > 2. When the interfaces are available/compiled in, have a run-time parameter (e.g., via MPI_T) that provides 4 levels: > > 0: do nothing > 1: warn the first time a deleted function is used in a process > 2: warn every time a deleted function is used in a process > 3: error the first time a deleted function is used in a process > > (the only difference between #1 and #2 is the annoyance factor) > > The tricky part will be how to handle future function deletions -- we should pick configure / run-time parameter names that reflects removing the functions that were deleted in MPI-3 so that we leave the door open for MPI-4 deletions handled (and retired) separately. > > I bring this up because it might be useful if OMPI/MPICH do similar things with regards to handling these deleted functions... We don't have to do it exactly the same, but if we're at least sorta similar, that'll be good enough. > > > On Mar 12, 2014, at 12:48 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > >> Added it to the ticket. >> https://trac.mpich.org/projects/mpich/ticket/2056 >> >> On Mar 12, 2014, at 11:38 AM, Michael Blocksome <blocksom(a)us.ibm.com> wrote: >> >>> Would it be possible to make the inclusion of deprecated/deleted functions in the mpi.h header configurable? >>> >>> If so, then a "strict" mpich library could be configured, compiled, and used to aid those who wish to port legacy applications to the new standard. By default, this "strict" mode would be disabled in order to preserve the current design decision. >>> >>> >>> Michael Blocksome >>> Parallel Environment MPI Middleware Team Lead, TCEM >>> POWER, x86, and Blue Gene HPC Messaging >>> blocksom(a)us.ibm.com >>> >>> >>> >>> >>> From: Rajeev Thakur <thakur(a)mcs.anl.gov> >>> To: <discuss(a)mpich.org>, >>> Date: 03/11/2014 09:51 PM >>> Subject: Re: [mpich-discuss] MPI_Address() >>> Sent by: discuss-bounces(a)mpich.org >>> >>> >>> >>> There are a whole bunch of such functions that were deprecated in MPI 2.0 (in 1997) and removed in MPI 3.0 (in 2012). We discussed whether to keep or remove them in MPICH, and decided to keep them so as not to gratuitously break user codes that still use the old functions. >>> >>> Rajeev >>> >>> On Mar 11, 2014, at 9:28 PM, Orion Poplawski <orion(a)cora.nwra.com> >>> wrote: >>> >>>> MPI_Address() was removed from the MPI API in the MPI-3 specification so >>>> it should be removed from mpich's mpi.h as well. Still present in 3.1 >>>> and current repository. >>>> >>>> - Orion >>>> >>>> -- >>>> Orion Poplawski >>>> Technical Manager 303-415-9701 x222 >>>> NWRA/CoRA Division FAX: 303-415-9702 >>>> 3380 Mitchell Lane orion(a)cora.nwra.com >>>> Boulder, CO 80301 http://www.cora.nwra.com >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Failed to allocate memory for an unexpected message
by Luiz Carlos da Costa Junior 12 Mar '14

12 Mar '14

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

1 0

Re: [mpich-discuss] MPI_Address()
by Jeff Squyres (jsquyres) 12 Mar '14

12 Mar '14

FWIW, we had a similar discussion in OMPI this morning. We (loosely) came up with the the following: 1. Have a configure argument to enable/disable having the deleted functions in mpi.h and the mpi module (remember that these deleted functions have no interfaces in the mpi_f08 module -- whew! ...but we'll have to see if anything gets deleted in MPI-4). At least for a while, default to having the interfaces available/compiled in. Eventually, change the default to not having them available/compiled out. 2. When the interfaces are available/compiled in, have a run-time parameter (e.g., via MPI_T) that provides 4 levels: 0: do nothing 1: warn the first time a deleted function is used in a process 2: warn every time a deleted function is used in a process 3: error the first time a deleted function is used in a process (the only difference between #1 and #2 is the annoyance factor) The tricky part will be how to handle future function deletions -- we should pick configure / run-time parameter names that reflects removing the functions that were deleted in MPI-3 so that we leave the door open for MPI-4 deletions handled (and retired) separately. I bring this up because it might be useful if OMPI/MPICH do similar things with regards to handling these deleted functions... We don't have to do it exactly the same, but if we're at least sorta similar, that'll be good enough. On Mar 12, 2014, at 12:48 PM, Rajeev Thakur <thakur(a)mcs.anl.gov> wrote: > Added it to the ticket. > https://trac.mpich.org/projects/mpich/ticket/2056 > > On Mar 12, 2014, at 11:38 AM, Michael Blocksome <blocksom(a)us.ibm.com> wrote: > >> Would it be possible to make the inclusion of deprecated/deleted functions in the mpi.h header configurable? >> >> If so, then a "strict" mpich library could be configured, compiled, and used to aid those who wish to port legacy applications to the new standard. By default, this "strict" mode would be disabled in order to preserve the current design decision. >> >> >> Michael Blocksome >> Parallel Environment MPI Middleware Team Lead, TCEM >> POWER, x86, and Blue Gene HPC Messaging >> blocksom(a)us.ibm.com >> >> >> >> >> From: Rajeev Thakur <thakur(a)mcs.anl.gov> >> To: <discuss(a)mpich.org>, >> Date: 03/11/2014 09:51 PM >> Subject: Re: [mpich-discuss] MPI_Address() >> Sent by: discuss-bounces(a)mpich.org >> >> >> >> There are a whole bunch of such functions that were deprecated in MPI 2.0 (in 1997) and removed in MPI 3.0 (in 2012). We discussed whether to keep or remove them in MPICH, and decided to keep them so as not to gratuitously break user codes that still use the old functions. >> >> Rajeev >> >> On Mar 11, 2014, at 9:28 PM, Orion Poplawski <orion(a)cora.nwra.com> >> wrote: >> >>> MPI_Address() was removed from the MPI API in the MPI-3 specification so >>> it should be removed from mpich's mpi.h as well. Still present in 3.1 >>> and current repository. >>> >>> - Orion >>> >>> -- >>> Orion Poplawski >>> Technical Manager 303-415-9701 x222 >>> NWRA/CoRA Division FAX: 303-415-9702 >>> 3380 Mitchell Lane orion(a)cora.nwra.com >>> Boulder, CO 80301 http://www.cora.nwra.com >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- 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] MPI_Address()
by Rajeev Thakur 12 Mar '14

12 Mar '14

Added it to the ticket. https://trac.mpich.org/projects/mpich/ticket/2056 On Mar 12, 2014, at 11:38 AM, Michael Blocksome <blocksom(a)us.ibm.com> wrote: > Would it be possible to make the inclusion of deprecated/deleted functions in the mpi.h header configurable? > > If so, then a "strict" mpich library could be configured, compiled, and used to aid those who wish to port legacy applications to the new standard. By default, this "strict" mode would be disabled in order to preserve the current design decision. > > > Michael Blocksome > Parallel Environment MPI Middleware Team Lead, TCEM > POWER, x86, and Blue Gene HPC Messaging > blocksom(a)us.ibm.com > > > > > From: Rajeev Thakur <thakur(a)mcs.anl.gov> > To: <discuss(a)mpich.org>, > Date: 03/11/2014 09:51 PM > Subject: Re: [mpich-discuss] MPI_Address() > Sent by: discuss-bounces(a)mpich.org > > > > There are a whole bunch of such functions that were deprecated in MPI 2.0 (in 1997) and removed in MPI 3.0 (in 2012). We discussed whether to keep or remove them in MPICH, and decided to keep them so as not to gratuitously break user codes that still use the old functions. > > Rajeev > > On Mar 11, 2014, at 9:28 PM, Orion Poplawski <orion(a)cora.nwra.com> > wrote: > > > MPI_Address() was removed from the MPI API in the MPI-3 specification so > > it should be removed from mpich's mpi.h as well. Still present in 3.1 > > and current repository. > > > > - Orion > > > > -- > > Orion Poplawski > > Technical Manager 303-415-9701 x222 > > NWRA/CoRA Division FAX: 303-415-9702 > > 3380 Mitchell Lane orion(a)cora.nwra.com > > Boulder, CO 80301 http://www.cora.nwra.com > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_Address()
by Balaji, Pavan 12 Mar '14

12 Mar '14

It should be doable. Can you comment on the trac ticket for this, so we don’t lose track of it? Thanks, — Pavan On Mar 12, 2014, at 11:38 AM, Michael Blocksome <blocksom(a)us.ibm.com> wrote: > Would it be possible to make the inclusion of deprecated/deleted functions in the mpi.h header configurable? > > If so, then a "strict" mpich library could be configured, compiled, and used to aid those who wish to port legacy applications to the new standard. By default, this "strict" mode would be disabled in order to preserve the current design decision. > > > Michael Blocksome > Parallel Environment MPI Middleware Team Lead, TCEM > POWER, x86, and Blue Gene HPC Messaging > blocksom(a)us.ibm.com > > > > > From: Rajeev Thakur <thakur(a)mcs.anl.gov> > To: <discuss(a)mpich.org>, > Date: 03/11/2014 09:51 PM > Subject: Re: [mpich-discuss] MPI_Address() > Sent by: discuss-bounces(a)mpich.org > > > > There are a whole bunch of such functions that were deprecated in MPI 2.0 (in 1997) and removed in MPI 3.0 (in 2012). We discussed whether to keep or remove them in MPICH, and decided to keep them so as not to gratuitously break user codes that still use the old functions. > > Rajeev > > On Mar 11, 2014, at 9:28 PM, Orion Poplawski <orion(a)cora.nwra.com> > wrote: > > > MPI_Address() was removed from the MPI API in the MPI-3 specification so > > it should be removed from mpich's mpi.h as well. Still present in 3.1 > > and current repository. > > > > - Orion > > > > -- > > Orion Poplawski > > Technical Manager 303-415-9701 x222 > > NWRA/CoRA Division FAX: 303-415-9702 > > 3380 Mitchell Lane orion(a)cora.nwra.com > > Boulder, CO 80301 http://www.cora.nwra.com > > _______________________________________________ > > discuss mailing list discuss(a)mpich.org > > To manage subscription options or unsubscribe: > > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] MPI_Address()
by Michael Blocksome 12 Mar '14

12 Mar '14

Would it be possible to make the inclusion of deprecated/deleted functions in the mpi.h header configurable? If so, then a "strict" mpich library could be configured, compiled, and used to aid those who wish to port legacy applications to the new standard. By default, this "strict" mode would be disabled in order to preserve the current design decision. Michael Blocksome Parallel Environment MPI Middleware Team Lead, TCEM POWER, x86, and Blue Gene HPC Messaging blocksom(a)us.ibm.com From: Rajeev Thakur <thakur(a)mcs.anl.gov> To: <discuss(a)mpich.org>, Date: 03/11/2014 09:51 PM Subject: Re: [mpich-discuss] MPI_Address() Sent by: discuss-bounces(a)mpich.org There are a whole bunch of such functions that were deprecated in MPI 2.0 (in 1997) and removed in MPI 3.0 (in 2012). We discussed whether to keep or remove them in MPICH, and decided to keep them so as not to gratuitously break user codes that still use the old functions. Rajeev On Mar 11, 2014, at 9:28 PM, Orion Poplawski <orion(a)cora.nwra.com> wrote: > MPI_Address() was removed from the MPI API in the MPI-3 specification so > it should be removed from mpich's mpi.h as well. Still present in 3.1 > and current repository. > > - Orion > > -- > Orion Poplawski > Technical Manager 303-415-9701 x222 > NWRA/CoRA Division FAX: 303-415-9702 > 3380 Mitchell Lane orion(a)cora.nwra.com > Boulder, CO 80301 http://www.cora.nwra.com > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Increasing MPI ranks
by Jeffrey Larson 12 Mar '14

12 Mar '14

I am trying to have a single master, with a group of workers who are themselves calculating function values. The evaluation of the function may itself involve spawning MPI tasks. On Wed, Mar 12, 2014 at 11:09 AM, Jed Brown <jed(a)jedbrown.org> wrote: > Jeffrey Larson <jmlarson(a)anl.gov> writes: > > > I was unaware of this issue with mpi4py, but I can reproduce it as well. > I > > will contact the mpi4py developers. > > Are you using lots of masters or lots of workers? I can run the example > in demo/spawning. It has an analogous example in C. > > I had misinterpreted the environment in which you were trying to get the > parent, so ignore my first mail. >

1 0

Re: [mpich-discuss] Increasing MPI ranks
by Jed Brown 12 Mar '14

12 Mar '14

Jeffrey Larson <jmlarson(a)anl.gov> writes: > I was unaware of this issue with mpi4py, but I can reproduce it as well. I > will contact the mpi4py developers. Are you using lots of masters or lots of workers? I can run the example in demo/spawning. It has an analogous example in C. I had misinterpreted the environment in which you were trying to get the parent, so ignore my first mail.

1 0

Re: [mpich-discuss] Increasing MPI ranks
by Jeffrey Larson 12 Mar '14

12 Mar '14

I was unaware of this issue with mpi4py, but I can reproduce it as well. I will contact the mpi4py developers. Thank you again for your help! On Wed, Mar 12, 2014 at 10:09 AM, Lu, Huiwei <huiweilu(a)mcs.anl.gov> wrote: > Hi, Jeffrey, > > The example in mpi4py manual can not run correctly with more than 16 > processes. So I have a reason to believe mpi4py library is not calling MPI > correctly. > It would be more appropriate to ask mpi4py developers to support their > manual example to run more than 16 processes first. > > -- > Huiwei > > On Mar 11, 2014, at 8:40 PM, Jeffrey Larson <jmlarson(a)anl.gov> wrote: > > > I was using the example from the mpi4py manual: > > http://mpi4py.scipy.org/docs/mpi4py.pdf > > (See the lines directly below "Worker (or child, or server) side:" in > Section 4.3: Dynamic Process Management) > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss >

1 0