- mpiwg-p2p - mailman3.cels.anl.gov

MPI Forum Web/Mailing List Migration Update
by Bland, Wesley 06 Sep '16

06 Sep '16

TL;DR - The DNS records for the MPI Forum will be moving from Illinois to Google tonight<http://airmail.calendar/2016-09-06%2019:00:00%20CDT>. This should have user impact, but it’s possible that there will be a short outage depending on your local DNS caches. Other services will be migrating soon. More Details - As part of the overall migration process that I referenced in an email about a month ago, we’re moving the DNS records out of the University of Illinois and up to the cloud (in this case, Google Domains). This should have no impact on your ability to view websites or send emails to these mailing lists, but it’s possible that as the new DNS information propagates to all of the caches around the world, there will be some brief outages. For now, nothing should change. If everything goes well tonight<http://airmail.calendar/2016-09-06%2019:00:00%20CDT>, I hope to start migrating services next week (with the intention of having everything migrated before the 14th so we can make sure everything is stable for EuroMPI and the September MPI Forum meeting. Here is the rough timeline: Sometime this week - Move DNS records from UIUC to Google (hard to predict exactly when this happens) This week - Prepare mailing lists (moving from Indiana to Argonne) and website (website preview available at https://mpi-forum.github.io/) for move. Early next week - Move mailing lists and website to their new hosts September 14th<http://airmail.calendar/2016-09-14%2012:00:00%20CDT> - Migration complete (anything not migrated will be postponed until after the EuroMPI/MPI Forum meeting) If you have questions/concerns about the migration, new website, mailing lists, etc., please let me know. Thanks, Wesley

1 0

Re: [mpiwg-p2p] Updated Comm. Info Proposal
by Jim Dinan 18 May '16

18 May '16

[ re-sending to @lists.*, in case the original didn't get through ] On Wed, May 18, 2016 at 4:57 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > Hi Jeff, > > Thanks for reviewing the proposal! A few responses inline below: > > On Sat, May 7, 2016 at 12:25 PM, Jeff Squyres (jsquyres) < > jsquyres(a)cisco.com> wrote: > >> (NOTE: the "reply to" address on this list is currently incorrect; it is >> mpiwg-p2p(a)mpi-forum.org. If you reply to this address, it will bounce. >> I have emailed IU to get it corrected to mpiwg-p2p(a)***lists.*** >> mpi.forum.org) >> >> p249 33-34: >> >> "Hints may be propagated using a communicator creation routine that >> accepts an info argument." >> >> "Propagated" is not the right verb here. >> > > This sentence seems redundant now. Can we just delete it? > > >> p250 39-40: >> >> "Users should check whether info hints, for which new values were given, >> are used by the MPI implementation." >> >> I see where you are going with the phrase "for which new values were >> given" -- but there's no reference point/time in the text to define "new". >> I'd just leave that phrase out -- i.e., users should check for *all* values >> that they send in via COMM_SET_INFO. >> > > The concern that caused us to add this is a user trying to change > something like mpi_assert_no_any_tag from true to false. How about > replacing this with "Users should check whether updates to existing hints > have been recognized by the MPI implementation."? > > p365 20-23: >> >> "Some info hints allow the MPI library to change its behavior in order to >> improve performance or resource utilization. If an application provides >> such an info hint, it must be compatible with any changes in the behavior >> of the MPI library that are allowed by the info hint." >> >> What info hint -- assertion or otherwise -- exists other than to change >> an MPI implementation's behavior? I see where you're going with this text, >> but it's a bit fuzzy because *all* info hints are provided to allow an MPI >> implementation to change its behavior. And that change in behavior may not >> be for improving performance or resource utilization -- they may be for >> other reasons, but still may require the application to conform to new >> behavior. >> > > Yeah, this is horribly vague. Instead of "change its behavior", how about > "restrict its support for certain operations"? > > p415 44: >> >> MPI_COMM_GET_INFO should be MPI_WIN_GET_INFO. >> >> p500 42: >> >> MPI_COMM_GET_INFO should be MPI_FILE_GET_INFO. >> > > Nice catch -- fixed. > > Per discussion at the last MPI Forum meeting, do you have a followup >> proposal for fixing the train wreck that is MPI_COMM_SET_INFO / >> MPI_COMM_GET_INFO? These MPI assertion info keys are somewhat useless >> without it. >> > > Not yet. Haven't forgotten about this.. > > ~Jim. >

1 0

Re: [mpiwg-p2p] Updated Comm. Info Proposal
by Jim Dinan 18 May '16

18 May '16

Hi Jeff, Thanks for reviewing the proposal! A few responses inline below: On Sat, May 7, 2016 at 12:25 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com > wrote: > (NOTE: the "reply to" address on this list is currently incorrect; it is > mpiwg-p2p(a)mpi-forum.org. If you reply to this address, it will bounce. > I have emailed IU to get it corrected to mpiwg-p2p(a)***lists.*** > mpi.forum.org) > > p249 33-34: > > "Hints may be propagated using a communicator creation routine that > accepts an info argument." > > "Propagated" is not the right verb here. > This sentence seems redundant now. Can we just delete it? > p250 39-40: > > "Users should check whether info hints, for which new values were given, > are used by the MPI implementation." > > I see where you are going with the phrase "for which new values were > given" -- but there's no reference point/time in the text to define "new". > I'd just leave that phrase out -- i.e., users should check for *all* values > that they send in via COMM_SET_INFO. > The concern that caused us to add this is a user trying to change something like mpi_assert_no_any_tag from true to false. How about replacing this with "Users should check whether updates to existing hints have been recognized by the MPI implementation."? p365 20-23: > > "Some info hints allow the MPI library to change its behavior in order to > improve performance or resource utilization. If an application provides > such an info hint, it must be compatible with any changes in the behavior > of the MPI library that are allowed by the info hint." > > What info hint -- assertion or otherwise -- exists other than to change an > MPI implementation's behavior? I see where you're going with this text, > but it's a bit fuzzy because *all* info hints are provided to allow an MPI > implementation to change its behavior. And that change in behavior may not > be for improving performance or resource utilization -- they may be for > other reasons, but still may require the application to conform to new > behavior. > Yeah, this is horribly vague. Instead of "change its behavior", how about "restrict its support for certain operations"? p415 44: > > MPI_COMM_GET_INFO should be MPI_WIN_GET_INFO. > > p500 42: > > MPI_COMM_GET_INFO should be MPI_FILE_GET_INFO. > Nice catch -- fixed. Per discussion at the last MPI Forum meeting, do you have a followup > proposal for fixing the train wreck that is MPI_COMM_SET_INFO / > MPI_COMM_GET_INFO? These MPI assertion info keys are somewhat useless > without it. > Not yet. Haven't forgotten about this.. ~Jim.

1 0

Meeting Today
by Jim Dinan 09 May '16

09 May '16

Hi All, I'm not sure if there is a meeting planned for today. I don't have anything that I think requires live discussion. I would just ask everyone to please review the draft info proposal. Thanks, ~Jim.

1 0

Re: [mpiwg-p2p] Updated Comm. Info Proposal
by Jeff Squyres (jsquyres) 07 May '16

07 May '16

(NOTE: the "reply to" address on this list is currently incorrect; it is mpiwg-p2p(a)mpi-forum.org. If you reply to this address, it will bounce. I have emailed IU to get it corrected to mpiwg-p2p(a)***lists.***mpi.forum.org) p249 33-34: "Hints may be propagated using a communicator creation routine that accepts an info argument." "Propagated" is not the right verb here. p250 39-40: "Users should check whether info hints, for which new values were given, are used by the MPI implementation." I see where you are going with the phrase "for which new values were given" -- but there's no reference point/time in the text to define "new". I'd just leave that phrase out -- i.e., users should check for *all* values that they send in via COMM_SET_INFO. p365 20-23: "Some info hints allow the MPI library to change its behavior in order to improve performance or resource utilization. If an application provides such an info hint, it must be compatible with any changes in the behavior of the MPI library that are allowed by the info hint." What info hint -- assertion or otherwise -- exists other than to change an MPI implementation's behavior? I see where you're going with this text, but it's a bit fuzzy because *all* info hints are provided to allow an MPI implementation to change its behavior. And that change in behavior may not be for improving performance or resource utilization -- they may be for other reasons, but still may require the application to conform to new behavior. p415 44: MPI_COMM_GET_INFO should be MPI_WIN_GET_INFO. p500 42: MPI_COMM_GET_INFO should be MPI_FILE_GET_INFO. ------ Per discussion at the last MPI Forum meeting, do you have a followup proposal for fixing the train wreck that is MPI_COMM_SET_INFO / MPI_COMM_GET_INFO? These MPI assertion info keys are somewhat useless without it. > On May 6, 2016, at 8:56 PM, Jim Dinan <james.dinan(a)gmail.com> wrote: > > Hi All, > > I have attached the updated communicator info proposal. Based on the feedback at the last meeting, the proposal has been split into three parts with the following "ticket" labels: > > Errta -- MPI 3.1 errata to remove info propagation. This was motivated by George's presentation where we learned that the info hints and values that are propagated is not well defined. This was discovered by the OpenMPI development team. > > IDWI -- Add MPI_Comm_idup_with_info. This should be added to correct the gap introduced to the nonblocking API by the above errata. > > Info -- Proposal to allow info hints to provide assertions and add communicator info hints. > > In addition, default values for the info keys have also been added. > > The deadline to submit the proposal for the next meeting will be May 23. Please review and check if I missed anything. > > Cheers, > ~Jim. > <mpi-report.pdf>_______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0

Updated Comm. Info Proposal
by Jim Dinan 06 May '16

06 May '16

Hi All, I have attached the updated communicator info proposal. Based on the feedback at the last meeting, the proposal has been split into three parts with the following "ticket" labels: Errta -- MPI 3.1 errata to remove info propagation. This was motivated by George's presentation where we learned that the info hints and values that are propagated is not well defined. This was discovered by the OpenMPI development team. IDWI -- Add MPI_Comm_idup_with_info. This should be added to correct the gap introduced to the nonblocking API by the above errata. Info -- Proposal to allow info hints to provide assertions and add communicator info hints. In addition, default values for the info keys have also been added. The deadline to submit the proposal for the next meeting will be May 23. Please review and check if I missed anything. Cheers, ~Jim.

1 0

Meeting Today
by Jim Dinan 25 Apr '16

25 Apr '16

Hi All, At today's meeting, we will discuss the Communicator Info proposal split and any other updates in preparation for the next Forum meeting. ~Jim.

1 0

Re: [mpiwg-p2p] Removing Fortran datatypes from mpi.h when there is no Fortran support
by Jeff Hammond 23 Apr '16

23 Apr '16

> > Why are we discussing this in the P2P WG and not the Fortran WG? > > Jeff > > On Sat, Apr 23, 2016 at 5:30 AM, Jeff Squyres (jsquyres) < > jsquyres(a)cisco.com> wrote: > >> https://github.com/mpiwg-p2p/p2p-issues/issues/1#issuecomment-213727928 >> captures the straw votes from the March 2016 Forum meeting where we >> discussed removing Fortran datatypes from mpi.h when there is no Fortran >> support. >> >> Three things were decided: >> >> 1. Yes, we should remove Fortran datatypes when no Fortran support is >> available. >> >> 2. The datatypes should be removed altogether (e.g., MPI_INTEGER won't be >> defined in mpi.h at all). >> >> --> After the meeting, it was pointed out that we also need to remove >> MPI_F[08]_STATUS[ES]_IGNORE from mpi.h, too. Good point. >> >> 3. There should be an additional #define indicating that there are no >> Fortran datatypes available. >> >> --> I propose have a macro named MPI_FORTRAN_BINDINGS_SUPPORTED. >> It will always be defined, but it will have a value of 1 if any of the >> 3 flavors of MPI Fortran bindings are supported, and therefore the >> corresponding Fortran entities are declared in mpi.h (e.g., >> MPI_INTEGER). It will have a value of 0, otherwise. >> >> ========= >> >> One additional question has come up, however: what about the >> MPI_*_(F2C|C2F) functions? I see two options: >> >> 1. They should not be declared (just like MPI_INTEGER) >> >> 2. They should be defined to return specific values. E.g., if you are >> running with an implementation that has no Fortran support, calling >> MPI_Comm_f2c(0) would return MPI_DATATYPE_NULL. Similarly, calling >> MPI_Comm_c2f(MPI_COMM_WORLD) would return an invalid handle. >> >> It's not quite clear why an MPI application would be calling C2F or F2C >> functions if there's no Fortran support, but one way or another, we have to >> handle this case. >> >> I think I'm in favor of not declaring the MPI_*_(F2C|C2F) functions. >> >> Thoughts? >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p >> > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Removing Fortran datatypes from mpi.h when there is no Fortran support
by Jeff Squyres (jsquyres) 23 Apr '16

23 Apr '16

https://github.com/mpiwg-p2p/p2p-issues/issues/1#issuecomment-213727928 captures the straw votes from the March 2016 Forum meeting where we discussed removing Fortran datatypes from mpi.h when there is no Fortran support. Three things were decided: 1. Yes, we should remove Fortran datatypes when no Fortran support is available. 2. The datatypes should be removed altogether (e.g., MPI_INTEGER won't be defined in mpi.h at all). --> After the meeting, it was pointed out that we also need to remove MPI_F[08]_STATUS[ES]_IGNORE from mpi.h, too. Good point. 3. There should be an additional #define indicating that there are no Fortran datatypes available. --> I propose have a macro named MPI_FORTRAN_BINDINGS_SUPPORTED. It will always be defined, but it will have a value of 1 if any of the 3 flavors of MPI Fortran bindings are supported, and therefore the corresponding Fortran entities are declared in mpi.h (e.g., MPI_INTEGER). It will have a value of 0, otherwise. ========= One additional question has come up, however: what about the MPI_*_(F2C|C2F) functions? I see two options: 1. They should not be declared (just like MPI_INTEGER) 2. They should be defined to return specific values. E.g., if you are running with an implementation that has no Fortran support, calling MPI_Comm_f2c(0) would return MPI_DATATYPE_NULL. Similarly, calling MPI_Comm_c2f(MPI_COMM_WORLD) would return an invalid handle. It's not quite clear why an MPI application would be calling C2F or F2C functions if there's no Fortran support, but one way or another, we have to handle this case. I think I'm in favor of not declaring the MPI_*_(F2C|C2F) functions. Thoughts? -- 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: [mpiwg-p2p] Fortran datatypes in mpi.h
by Jeff Squyres (jsquyres) 04 Mar '16

04 Mar '16

Fair point. Changelog entry added. > On Mar 4, 2016, at 11:20 AM, Rolf Rabenseifner <rabenseifner(a)hlrs.de> wrote: > > As I can see, it looks nearly perfect, except probably missing change-log. > The discussion showed that there is an Impact for MPI implementations > and therefore there should be a change-log. > > Rolf > > ----- Original Message ----- >> From: "Jeff Squyres" <jsquyres(a)cisco.com> >> To: mpiwg-p2p(a)lists.mpi-forum.org >> Sent: Friday, March 4, 2016 4:20:36 PM >> Subject: [mpiwg-p2p] Fortran datatypes in mpi.h > >> FYI: I filed a working group issue + PR for the "Fortran datatypes in mpi.h" >> issue that was raised in Chicago yesterday: >> >> https://github.com/mpiwg-p2p/p2p-issues/issues/1 >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> mpiwg-p2p mailing list >> mpiwg-p2p(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p > > -- > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de > 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: Room 1.307) > _______________________________________________ > mpiwg-p2p mailing list > mpiwg-p2p(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpiwg-p2p -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/

1 0