- mpiwg-fortran - mailman3.cels.anl.gov

DRAFT: Chapter Committees ACTION NEEDED
by Jeff Squyres (jsquyres) 13 Dec '19

13 Dec '19

This is a DRAFT of what I'd like to send to the Forum to get all Chapter Committees to review the document-wide stuff that we need reviewed. Please send comments / suggestions to me. Thanks! ----------------------------------------- We need Chapter Committees to review their chapters in 2 sets of upcoming document-wide changes that are slated to be merged "soon". After you complete a review, please put an "X" in the corresponding row/column for your chapter and the specified PR in this Google spreadsheet. This will let us track what has been done / what still needs to be done: https://docs.google.com/spreadsheets/d/1qPAREYgeuSCMtU-EQniDilrHIYb8W0-f6Qz… ==> FIRST SET Bill Gropp (the MPI Standard document Editor) has two PRs with "ticket 0" changes. However, the changes are pervasive and touch a LOT of the document. We therefore need Chapter Committees to review their chapters in the following two PRs: 1a. "Ticket 0 changes for MPI-4.x" https://github.com/mpi-forum/mpi-standard/pull/145 1b. "Uniform style for Fortran code" https://github.com/mpi-forum/mpi-standard/pull/151 **** BILL: what deadline do you want to set? ==> SECOND SET The Pythonization group has Pythonized the bindings in the entire document. We've completed a first correctness pass over the work, but we need more eyes to compare the end result of our work to (at least) the MPI-3.1 document -- or, better yet, to the head of the mpi-4.x branch. See this wiki page for instructions: https://github.com/mpiwg-large-count/large-count-issues/wiki/pythonizing-in… Also please see the Pythonization slides presented at the Forum this week: https://docs.google.com/presentation/d/1QZyh6TbjDMu7mEcNqBFfe9fFOltaCtxgZ2Z… The Pythonization group needs your reviews BY *** 21 JAN 2020 *** to give us time to finalize everything before the T-2 week deadline for the Portland Forum meeting. NOTE: At the ABQ Forum meeting, I asked you to commit/PR your approvals.json file that resulted from running the tool. This is no longer necessary -- please just mark the google spreadsheet as described above. -- Jeff Squyres jsquyres(a)cisco.com

1 0

Fwd: [mpi-forum/mpi-issues] Deprecate MPI_SIZEOF in MPI-4.0 (#51)
by Jeff Squyres (jsquyres) 06 Dec '18

06 Dec '18

FYI / Woo hoo! Begin forwarded message: From: Wesley Bland <notifications(a)github.com<mailto:[email protected]>> Subject: Re: [mpi-forum/mpi-issues] Deprecate MPI_SIZEOF in MPI-4.0 (#51) Date: December 6, 2018 at 9:36:08 AM PST To: mpi-forum/mpi-issues <mpi-issues(a)noreply.github.com<mailto:[email protected]>> Cc: Jeff Squyres <jsquyres(a)cisco.com<mailto:[email protected]>>, Author <author(a)noreply.github.com<mailto:[email protected]>> Reply-To: mpi-forum/mpi-issues <reply+00096b64036b386a95564345ed3bc1dc70a6f58a497148d192cf000000011821200892a169ce08dce4c1(a)reply.github.com<mailto:reply+00096b64036b386a95564345ed3bc1dc70a6f58a497148d192cf000000011821200892a169ce08dce4c1@reply.github.com>> Passed second vote at San Jose meeting in December 2018 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://github.com/mpi-forum/mpi-issues/issues/51#issuecomment-444960373>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAlrZIz7WWdRm7AbgiwVfu_VV…>. -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]>

1 0

Re: [MPIWG Fortran] INTENT and ASYNCHRONOUS
by Jeff Squyres (jsquyres) 06 Jun '18

06 Jun '18

Yeah, we haven't had any other reports about this issue (it's specifically complaining about MPI_ACCUMULATE), and I don't think Open MPI's code has changed here in quite a while. I should note that Open MPI's definition of MPI_ACCUMULATE agrees with what is in MPI-3.1. I wanted to check to ensure that we didn't accidentally have a bug in MPI-3.1 that somehow worked in Open MPI with a variety of compilers for years, but was technically incorrect. > On Jun 6, 2018, at 11:37 AM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > > This works with other compilers as well... > > > $ for fc in ifort gfortran-8 pgfortran ; do ${fc} -c f08-intent-async.f90 && echo SUCCESS with $fc || echo FAILURE with $fc ; done > SUCCESS with ifort > SUCCESS with gfortran-8 > SUCCESS with pgfortran > > $ cat f08-intent-async.f90 > Subroutine csub (x) > real,intent(inout),asynchronous :: x > end Subroutine csub > > > > On Wed, Jun 6, 2018 at 8:29 AM, Bill Long <longb(a)cray.com> wrote: > > > On Jun 6, 2018, at 10:08 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > > > Fortran gurus -- > > > > We just got a problem report in Open MPI (https://www.mail-archive.com/[email protected]/msg32381.html) for a Fortran compile failure: > > > > ----- > > OMPI_FORTRAN_IGNORE_TKR_TYPE, INTENT(IN), ASYNCHRONOUS :: origin_addr > > ^ > > "../../../../../openmpi-master-201806060243-64a5baa/ompi/mpi/fortran/use-mpi-f08/accumulate_f08.F90", Line = 16, Column = 46: ERROR: Attributes ASYNCHRONOUS and INTENT must not appear in the same attribute list. > > ----- > > > > Is that Fortran compiler correct? I.e., does Fortran forbid the use of INTENT and ASYNCHRONOUS in the same attribute list? > > I don’t see a restriction like that, at least in F2018. I tried this: > > Subroutine csub (x) > real,intent(inout),asynchronous :: x > end Subroutine csub > > with maximum diagnostics and got no messages with the Cray compiler which is quite good at testing conformance. > > > > Or is this a compiler bug? > > > > It would appear to be the case. It might be the case that the usage in the routine is incompatible with INTENT(IN), but that message should be differently worded. Of course, OMPI_FORTRAN_IGNORE_TKR_TYPE is certainly not a valid type declaration. I assume they intend TYPE(*). > > Cheers, > Bill > > > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran > > Bill Long longb(a)cray.com > Principal Engineer, Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9143 > Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran > > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [MPIWG Fortran] INTENT and ASYNCHRONOUS
by Jeff Squyres (jsquyres) 06 Jun '18

06 Jun '18

On Jun 6, 2018, at 11:29 AM, Bill Long <longb(a)cray.com> wrote: > >> ----- >> OMPI_FORTRAN_IGNORE_TKR_TYPE, INTENT(IN), ASYNCHRONOUS :: origin_addr >> ^ >> "../../../../../openmpi-master-201806060243-64a5baa/ompi/mpi/fortran/use-mpi-f08/accumulate_f08.F90", Line = 16, Column = 46: ERROR: Attributes ASYNCHRONOUS and INTENT must not appear in the same attribute list. >> ----- > > I don’t see a restriction like that, at least in F2018. I tried this: > > Subroutine csub (x) > real,intent(inout),asynchronous :: x > end Subroutine csub > > with maximum diagnostics and got no messages with the Cray compiler which is quite good at testing conformance. Ok. Thanks. >> Or is this a compiler bug? > > It would appear to be the case. It might be the case that the usage in the routine is incompatible with INTENT(IN), but that message should be differently worded. Of course, OMPI_FORTRAN_IGNORE_TKR_TYPE is certainly not a valid type declaration. I assume they intend TYPE(*). Yeah, that's a #define. -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [MPIWG Fortran] INTENT and ASYNCHRONOUS
by Jeff Hammond 06 Jun '18

06 Jun '18

This works with other compilers as well... $ for fc in ifort gfortran-8 pgfortran ; do ${fc} -c f08-intent-async.f90 && echo SUCCESS with $fc || echo FAILURE with $fc ; done SUCCESS with ifort SUCCESS with gfortran-8 SUCCESS with pgfortran $ cat f08-intent-async.f90 Subroutine csub (x) real,intent(inout),asynchronous :: x end Subroutine csub On Wed, Jun 6, 2018 at 8:29 AM, Bill Long <longb(a)cray.com> wrote: > > > On Jun 6, 2018, at 10:08 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> > wrote: > > > > Fortran gurus -- > > > > We just got a problem report in Open MPI (https://www.mail-archive.com/ > users(a)lists.open-mpi.org/msg32381.html) for a Fortran compile failure: > > > > ----- > > OMPI_FORTRAN_IGNORE_TKR_TYPE, INTENT(IN), ASYNCHRONOUS :: origin_addr > > ^ > > "../../../../../openmpi-master-201806060243-64a5baa/ > ompi/mpi/fortran/use-mpi-f08/accumulate_f08.F90", Line = 16, Column = 46: > ERROR: Attributes ASYNCHRONOUS and INTENT must not appear in the same > attribute list. > > ----- > > > > Is that Fortran compiler correct? I.e., does Fortran forbid the use of > INTENT and ASYNCHRONOUS in the same attribute list? > > I don’t see a restriction like that, at least in F2018. I tried this: > > Subroutine csub (x) > real,intent(inout),asynchronous :: x > end Subroutine csub > > with maximum diagnostics and got no messages with the Cray compiler which > is quite good at testing conformance. > > > > Or is this a compiler bug? > > > > It would appear to be the case. It might be the case that the usage in > the routine is incompatible with INTENT(IN), but that message should be > differently worded. Of course, OMPI_FORTRAN_IGNORE_TKR_TYPE is certainly > not a valid type declaration. I assume they intend TYPE(*). > > Cheers, > Bill > > > > > > -- > > Jeff Squyres > > jsquyres(a)cisco.com > > > > _______________________________________________ > > mpiwg-fortran mailing list > > mpiwg-fortran(a)lists.mpi-forum.org > > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran > > Bill Long > longb(a)cray.com > Principal Engineer, Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9143 > Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425 > > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [MPIWG Fortran] INTENT and ASYNCHRONOUS
by Bill Long 06 Jun '18

06 Jun '18

> On Jun 6, 2018, at 10:08 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > Fortran gurus -- > > We just got a problem report in Open MPI (https://www.mail-archive.com/[email protected]/msg32381.html) for a Fortran compile failure: > > ----- > OMPI_FORTRAN_IGNORE_TKR_TYPE, INTENT(IN), ASYNCHRONOUS :: origin_addr > ^ > "../../../../../openmpi-master-201806060243-64a5baa/ompi/mpi/fortran/use-mpi-f08/accumulate_f08.F90", Line = 16, Column = 46: ERROR: Attributes ASYNCHRONOUS and INTENT must not appear in the same attribute list. > ----- > > Is that Fortran compiler correct? I.e., does Fortran forbid the use of INTENT and ASYNCHRONOUS in the same attribute list? I don’t see a restriction like that, at least in F2018. I tried this: Subroutine csub (x) real,intent(inout),asynchronous :: x end Subroutine csub with maximum diagnostics and got no messages with the Cray compiler which is quite good at testing conformance. > Or is this a compiler bug? > It would appear to be the case. It might be the case that the usage in the routine is incompatible with INTENT(IN), but that message should be differently worded. Of course, OMPI_FORTRAN_IGNORE_TKR_TYPE is certainly not a valid type declaration. I assume they intend TYPE(*). Cheers, Bill > -- > Jeff Squyres > jsquyres(a)cisco.com > > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran Bill Long longb(a)cray.com Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425

1 0

INTENT and ASYNCHRONOUS
by Jeff Squyres (jsquyres) 06 Jun '18

06 Jun '18

Fortran gurus -- We just got a problem report in Open MPI (https://www.mail-archive.com/[email protected]/msg32381.html) for a Fortran compile failure: ----- OMPI_FORTRAN_IGNORE_TKR_TYPE, INTENT(IN), ASYNCHRONOUS :: origin_addr ^ "../../../../../openmpi-master-201806060243-64a5baa/ompi/mpi/fortran/use-mpi-f08/accumulate_f08.F90", Line = 16, Column = 46: ERROR: Attributes ASYNCHRONOUS and INTENT must not appear in the same attribute list. ----- Is that Fortran compiler correct? I.e., does Fortran forbid the use of INTENT and ASYNCHRONOUS in the same attribute list? Or is this a compiler bug? -- Jeff Squyres jsquyres(a)cisco.com

1 0

Typo in MPI_STATUS_SET_CANCELLED F08 binding
by Jeff Squyres (jsquyres) 17 Apr '18

17 Apr '18

This seems like an obvious typo to me: https://github.com/mpi-forum/mpi-issues/issues/91 I submitted the corresponding pull request here: https://github.com/mpi-forum/mpi-standard/pull/36 I will not be at the next MPI Forum meeting to shepherd this through. Is anyone on this list going to be in Austin? -- Jeff Squyres jsquyres(a)cisco.com

1 0

Re: [MPIWG Fortran] [Mpi-comments] MPI_Comm_spawn_multiple: parameter description and Fortran bindings
by Bill Long 09 Feb '18

09 Feb '18

My reading of example 10.2 (in the 3.0 standard) is that the command array has 2 elements, (same as the value of count), but that an extra blank element is used to signal the end of the argument lists for each command in the array array_of_argv. That seems reasonable since the number of arguments would, in general, be different for each command. Here is how you do it in Fortran: CHARACTER*25 commands(2), array_of_argv(2, 3) commands(1) = ’ ocean ’ array_of_argv(1, 1) = ’ -gridfile ’ array_of_argv(1, 2) = ’ ocean1.grd’ array_of_argv(1, 3) = ’ ’ commands(2) = ’ atmos ’ array_of_argv(2, 1) = ’ atmos.grd ’ array_of_argv(2, 2) = ’ ’ call MPI_COMM_SPAWN_MULTIPLE(2, commands, array_of_argv, ...) Self-documentation of the declaration would be clearer if the command argument were declared command(count) instead of command(*). I suspect that the (*) declaration of the command dummy argument was done that way out of habit. Cheers, Bill > On Feb 9, 2018, at 12:26 AM, Gilles Gouaillardet <gilles.gouaillardet(a)gmail.com> wrote: > > Bill, > >>>> That being said, the standard does not state that, and it is unclear whether 'array_of_commands' should be >>>> >>>> NULL-terminated (so to speak) or not. >>>> >> >> Fortran characters are NOT null terminated. > > > I was referring the array and not the characters, so let me clarify this : > > > In example 10.2, the array of commands is > > CHARACTER*25 commands(2), > commands(1) = ' ocean ' > commands(2) = ' atmos ' > > By reading the standard literally, it was unclear to me whether this > should have been > > CHARACTER*25 commands(3), > commands(1) = ' ocean ' > commands(2) = ' atmos ' > commands(3) = ' ' > > > FWIW, Open MPI currently expects the latter form (see > https://github.com/open-mpi/ompi/issues/4788) > I initially thought it was a simple bug, but on second thought, I am > still on the fence whether this should be > regarded as a simple bug or a correct/literal interpretation of the standard. > > > Cheers, > > Gilles > > On Fri, Feb 9, 2018 at 7:07 AM, Bill Long <longb(a)cray.com> wrote: >> >>> On Feb 8, 2018, at 3:44 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >>> >>>> >>>> And the Fortran binding is >>>> >>>> MPI_COMM_SPAWN_MULTIPLE(COUNT, ARRAY_OF_COMMANDS, ...) >>>> INTEGER COUNT >>>> CHARACTER*(*) ARRAY_OF_COMMANDS(*) >>>> >> >> Note that the character*(*) syntax is archaic (as of 25+ years ago). The normal way of writing this is character(*). >> >>>> >>>> Intuitively, it seems obvious that 'array_of_commands' is an array of 'count' commands. >> >> That is what I would assume. The user would be responsible for declaring the array elements large enough to hold the longest command. (All the elements of the array have the same length). >> >>>> >>>> That being said, the standard does not state that, and it is unclear whether 'array_of_commands' should be >>>> >>>> NULL-terminated (so to speak) or not. >>>> >> >> Fortran characters are NOT null terminated. >> >>>> >>>> Back to the Fortran binding, the following prototype, which is somehow consistent with 'array_of_argv', >>>> >>>> could (help to) clear the confusion. The same comments also apply to the Fortran 2008 binding. >>>> >>>> >>>> CHARACTER*(*) ARRAY_OF_COMMANDS(COUNT) >> >> This is also fine, and clearer in terms of the expected minimum size of ARRAY_OF_COMMANDS. >> >> Cheers, >> Bill >> >> >>>> >>>> >> >> Bill Long longb(a)cray.com >> Principal Engineer, Fortran Technical Support & voice: 651-605-9024 >> Bioinformatics Software Development fax: 651-605-9143 >> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425 >> >> > _______________________________________________ > mpiwg-fortran mailing list > mpiwg-fortran(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran Bill Long longb(a)cray.com Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425

1 0

Re: [MPIWG Fortran] [Mpi-comments] MPI_Comm_spawn_multiple: parameter description and Fortran bindings
by Gilles Gouaillardet 09 Feb '18

09 Feb '18

Bill, >>> That being said, the standard does not state that, and it is unclear whether 'array_of_commands' should be >>> >>> NULL-terminated (so to speak) or not. >>> > > Fortran characters are NOT null terminated. I was referring the array and not the characters, so let me clarify this : In example 10.2, the array of commands is CHARACTER*25 commands(2), commands(1) = ' ocean ' commands(2) = ' atmos ' By reading the standard literally, it was unclear to me whether this should have been CHARACTER*25 commands(3), commands(1) = ' ocean ' commands(2) = ' atmos ' commands(3) = ' ' FWIW, Open MPI currently expects the latter form (see https://github.com/open-mpi/ompi/issues/4788) I initially thought it was a simple bug, but on second thought, I am still on the fence whether this should be regarded as a simple bug or a correct/literal interpretation of the standard. Cheers, Gilles On Fri, Feb 9, 2018 at 7:07 AM, Bill Long <longb(a)cray.com> wrote: > >> On Feb 8, 2018, at 3:44 PM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >>> >>> And the Fortran binding is >>> >>> MPI_COMM_SPAWN_MULTIPLE(COUNT, ARRAY_OF_COMMANDS, ...) >>> INTEGER COUNT >>> CHARACTER*(*) ARRAY_OF_COMMANDS(*) >>> > > Note that the character*(*) syntax is archaic (as of 25+ years ago). The normal way of writing this is character(*). > >>> >>> Intuitively, it seems obvious that 'array_of_commands' is an array of 'count' commands. > > That is what I would assume. The user would be responsible for declaring the array elements large enough to hold the longest command. (All the elements of the array have the same length). > >>> >>> That being said, the standard does not state that, and it is unclear whether 'array_of_commands' should be >>> >>> NULL-terminated (so to speak) or not. >>> > > Fortran characters are NOT null terminated. > >>> >>> Back to the Fortran binding, the following prototype, which is somehow consistent with 'array_of_argv', >>> >>> could (help to) clear the confusion. The same comments also apply to the Fortran 2008 binding. >>> >>> >>> CHARACTER*(*) ARRAY_OF_COMMANDS(COUNT) > > This is also fine, and clearer in terms of the expected minimum size of ARRAY_OF_COMMANDS. > > Cheers, > Bill > > >>> >>> > > Bill Long longb(a)cray.com > Principal Engineer, Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9143 > Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425 > >

1 0