Question about MPI_Status_f2f08() and _f082f()
MPI-3.1 Figure 17.1 (in section 17.2.5, starting on page 656) defines the following routines: 1. MPI_Status_c2f() (from MPI-2) 2. MPI_Status_f2c() (from MPI-2) 3. MPI_Status_c2f08() (new in MPI-3) 4. MPI_Status_f082c() (new in MPI-3) 5. MPI_Status_f2f08() (new in MPI-3) 6. MPI_Status_f082f() (new in MPI-3) All of the functions are fairly straightforward to implement in C. But per the bottom part of Figure 17.1, two of the routines are supposed to be implemented in Fortran: #5 and #6. Does this mean that TYPE(MPI_Status) needs to be defined in mpif.h and the mpi module? I'm not sure how an MPI application would be able to invoke functions #5 and #6 without a definition of TYPE(MPI_Status) -- or even have a variable of that type that they need to convert to INTEGER(MPI_STATUS_SIZE). -- Jeff Squyres [email protected]
That certainly was not my understanding - I expected that these would be defined only for F08, allowing code in F08 to move status data to/from the integer status array for the prior Fortran bindings. I am in favor of clarifying the standard to make this clear. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 9, 2020, at 7:54 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
MPI-3.1 Figure 17.1 (in section 17.2.5, starting on page 656) defines the following routines:
1. MPI_Status_c2f() (from MPI-2) 2. MPI_Status_f2c() (from MPI-2) 3. MPI_Status_c2f08() (new in MPI-3) 4. MPI_Status_f082c() (new in MPI-3) 5. MPI_Status_f2f08() (new in MPI-3) 6. MPI_Status_f082f() (new in MPI-3)
All of the functions are fairly straightforward to implement in C.
But per the bottom part of Figure 17.1, two of the routines are supposed to be implemented in Fortran: #5 and #6.
Does this mean that TYPE(MPI_Status) needs to be defined in mpif.h and the mpi module?
I'm not sure how an MPI application would be able to invoke functions #5 and #6 without a definition of TYPE(MPI_Status) -- or even have a variable of that type that they need to convert to INTEGER(MPI_STATUS_SIZE).
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
Gah. Closer reading shows that MPI-3.1 page 658 actually has mpif.h/mpi module bindings for MPI_Status_f2f08 and _f082f that include TYPE(MPI_Status) dummy parameters. So the standard text actually strongly infers that TYPE(MPI_Status) is supposed to be defined in mpif.h and the mpi module. Granted, a user *could* do something like this, but I can't believe that this is what we intended users to do: ----- ! This is super ugly IMNSHO use :: mpi_f08, only : MPI_Status implicit none include 'mpif.h' ----- Do we really want to change the spec to state that the _f2f08 and _f082f subroutines are only available in the mpi_f08 module? I think that that would be a *change*, not a *clarification*. That being said, we might be able to squint at this and call it an "error" in MPI-3.1. But *that* being said, it's *not* actually a technical error. It's just that we seemed to have missed the implication back then that TYPE(MPI_Status) would need to be defined in mpif.h and the mpi module. That's not a technical *problem* -- it's just a little weird.
On Jul 10, 2020, at 8:49 AM, William Gropp <[email protected]> wrote:
That certainly was not my understanding - I expected that these would be defined only for F08, allowing code in F08 to move status data to/from the integer status array for the prior Fortran bindings. I am in favor of clarifying the standard to make this clear.
Bill
William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 9, 2020, at 7:54 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
MPI-3.1 Figure 17.1 (in section 17.2.5, starting on page 656) defines the following routines:
1. MPI_Status_c2f() (from MPI-2) 2. MPI_Status_f2c() (from MPI-2) 3. MPI_Status_c2f08() (new in MPI-3) 4. MPI_Status_f082c() (new in MPI-3) 5. MPI_Status_f2f08() (new in MPI-3) 6. MPI_Status_f082f() (new in MPI-3)
All of the functions are fairly straightforward to implement in C.
But per the bottom part of Figure 17.1, two of the routines are supposed to be implemented in Fortran: #5 and #6.
Does this mean that TYPE(MPI_Status) needs to be defined in mpif.h and the mpi module?
I'm not sure how an MPI application would be able to invoke functions #5 and #6 without a definition of TYPE(MPI_Status) -- or even have a variable of that type that they need to convert to INTEGER(MPI_STATUS_SIZE).
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
Granted, an error, not a clarification. Does any implementation do this now (define Type_status in mpif.h/mpi module)? If not, it is easier to consider this an error. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 10, 2020, at 8:39 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:
Gah. Closer reading shows that MPI-3.1 page 658 actually has mpif.h/mpi module bindings for MPI_Status_f2f08 and _f082f that include TYPE(MPI_Status) dummy parameters.
So the standard text actually strongly infers that TYPE(MPI_Status) is supposed to be defined in mpif.h and the mpi module.
Granted, a user *could* do something like this, but I can't believe that this is what we intended users to do:
----- ! This is super ugly IMNSHO use :: mpi_f08, only : MPI_Status implicit none include 'mpif.h' -----
Do we really want to change the spec to state that the _f2f08 and _f082f subroutines are only available in the mpi_f08 module?
I think that that would be a *change*, not a *clarification*.
That being said, we might be able to squint at this and call it an "error" in MPI-3.1.
But *that* being said, it's *not* actually a technical error. It's just that we seemed to have missed the implication back then that TYPE(MPI_Status) would need to be defined in mpif.h and the mpi module. That's not a technical *problem* -- it's just a little weird.
On Jul 10, 2020, at 8:49 AM, William Gropp <[email protected]> wrote:
That certainly was not my understanding - I expected that these would be defined only for F08, allowing code in F08 to move status data to/from the integer status array for the prior Fortran bindings. I am in favor of clarifying the standard to make this clear.
Bill
William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 9, 2020, at 7:54 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
MPI-3.1 Figure 17.1 (in section 17.2.5, starting on page 656) defines the following routines:
1. MPI_Status_c2f() (from MPI-2) 2. MPI_Status_f2c() (from MPI-2) 3. MPI_Status_c2f08() (new in MPI-3) 4. MPI_Status_f082c() (new in MPI-3) 5. MPI_Status_f2f08() (new in MPI-3) 6. MPI_Status_f082f() (new in MPI-3)
All of the functions are fairly straightforward to implement in C.
But per the bottom part of Figure 17.1, two of the routines are supposed to be implemented in Fortran: #5 and #6.
Does this mean that TYPE(MPI_Status) needs to be defined in mpif.h and the mpi module?
I'm not sure how an MPI application would be able to invoke functions #5 and #6 without a definition of TYPE(MPI_Status) -- or even have a variable of that type that they need to convert to INTEGER(MPI_STATUS_SIZE).
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
On Jul 10, 2020, at 9:46 AM, William Gropp <[email protected]> wrote:
Granted, an error, not a clarification. Does any implementation do this now (define Type_status in mpif.h/mpi module)? If not, it is easier to consider this an error.
Open MPI does not -- this issue came up a few months ago in the Open MPI project and just re-surfaced again. It led me to a deeper read of MPI-3.1 about the definition of these functions. I don't immediately see it in MPICH, either. -- Jeff Squyres [email protected]
In the “change” section there is this txt: • Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added. 1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant). 2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular} Cheers, Bill
On Jul 9, 2020, at 7:54 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
MPI-3.1 Figure 17.1 (in section 17.2.5, starting on page 656) defines the following routines:
1. MPI_Status_c2f() (from MPI-2) 2. MPI_Status_f2c() (from MPI-2) 3. MPI_Status_c2f08() (new in MPI-3) 4. MPI_Status_f082c() (new in MPI-3) 5. MPI_Status_f2f08() (new in MPI-3) 6. MPI_Status_f082f() (new in MPI-3)
All of the functions are fairly straightforward to implement in C.
But per the bottom part of Figure 17.1, two of the routines are supposed to be implemented in Fortran: #5 and #6.
Does this mean that TYPE(MPI_Status) needs to be defined in mpif.h and the mpi module?
I'm not sure how an MPI application would be able to invoke functions #5 and #6 without a definition of TYPE(MPI_Status) -- or even have a variable of that type that they need to convert to INTEGER(MPI_STATUS_SIZE).
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
On Jul 10, 2020, at 11:18 AM, Bill Long <[email protected]> wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point. Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802. That being said: - the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1. I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h. However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings. -- Jeff Squyres [email protected]
On Jul 10, 2020, at 11:11 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
We have the same discussions in the Fortran committee about deleting things, or at least making them “obsolescent”, which seems functionally similar to deprecated in MPI. In the end, we specify certain archaic and now-redundant features as deleted with full knowledge that implementors will not remove the capabilities from compilers because of old codes. However, the Intent is to guide programmers writing new code in the direction of using the new (hopefully better) alternatives. And, relevant to the present discussion, deleting certain old stuff makes the standard document cleaner. Fundamentally, MPI is a C library. Other languages, like C++ and Python, don’t require separate bindings specified in the MPI spec because they can call C library routines. The whole mpi_f08 module exercise was to demonstrate that Fortran can now do the same. The whole idea of specifying a separate Fortran MPI interface needs to be rethought. Perhaps something like “This version of MPI specifies the contents of a vendor-required Fortran module for MPI that allows access to the underlying C specification. The separate language binding for Fortran has been deleted, but is still available for historical reference in the MPI-3 and earlier specifications.” That should allow for a significant simplification of the MPI specification document. Cheers, Bill Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
To help aid in the depreciation of mpif.h, perhaps Cray/HPE can contribute a source-to-source translation tool that can be recommended to the MPI user community. Jeff On Fri, Jul 10, 2020 at 9:54 AM Bill Long via mpiwg-fortran < [email protected]> wrote:
On Jul 10, 2020, at 11:11 AM, Jeff Squyres (jsquyres) < [email protected]> wrote:
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still
included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
We have the same discussions in the Fortran committee about deleting things, or at least making them “obsolescent”, which seems functionally similar to deprecated in MPI. In the end, we specify certain archaic and now-redundant features as deleted with full knowledge that implementors will not remove the capabilities from compilers because of old codes. However, the Intent is to guide programmers writing new code in the direction of using the new (hopefully better) alternatives. And, relevant to the present discussion, deleting certain old stuff makes the standard document cleaner.
Fundamentally, MPI is a C library. Other languages, like C++ and Python, don’t require separate bindings specified in the MPI spec because they can call C library routines. The whole mpi_f08 module exercise was to demonstrate that Fortran can now do the same. The whole idea of specifying a separate Fortran MPI interface needs to be rethought. Perhaps something like
“This version of MPI specifies the contents of a vendor-required Fortran module for MPI that allows access to the underlying C specification. The separate language binding for Fortran has been deleted, but is still available for historical reference in the MPI-3 and earlier specifications.”
That should allow for a significant simplification of the MPI specification document.
Cheers, Bill
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Hammond [email protected] http://jeffhammond.github.io/
Well, as I pointed out, vendors are not going to actually delete old stuff. But that should not be a reason to avoid cleaning up the spec. There are ways to “fix” the mpif.h problem: 1) Assuming that the legacy MPI module provides the same capabilities as mpif.h, you could jus supply an empty mpif.h file (avoids having to delete the include line from the source), and then have a compiler option to “auto-use” a module and have the compilation include that option, specifying the MPI module. (Advantage of not changing the actual source file.) 2) Have a program that checks for an include of mpif.h and deleting that line and including a USE statement instead that specifies the MPI module. (Disadvantage that the mpif.h file might be included indirectly, by being part of another file that is included or part of a user module.) 3) Same as 2 only check for actual calls to MPI routines or uses of MPI data types in the source file. I there are none, do not add the USE MPI statement. Compile with the option that forces IMPLICIT NONE to be sure there were no missed references to MPI stuff. 4) Much more difficult - have a whole program analyzer that would remove all of the MPI (and SHMEM) and replace it with the native stuff built into Fortran. Probably the right path for new code, and bets done by a person for an old code. The Cray/HPE Fortran compiler already provides the tools to implement option 1. Cheers, Bill
On Jul 10, 2020, at 9:52 PM, Jeff Hammond <[email protected]> wrote:
To help aid in the depreciation of mpif.h, perhaps Cray/HPE can contribute a source-to-source translation tool that can be recommended to the MPI user community.
Jeff
On Fri, Jul 10, 2020 at 9:54 AM Bill Long via mpiwg-fortran <[email protected]> wrote:
On Jul 10, 2020, at 11:11 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
We have the same discussions in the Fortran committee about deleting things, or at least making them “obsolescent”, which seems functionally similar to deprecated in MPI. In the end, we specify certain archaic and now-redundant features as deleted with full knowledge that implementors will not remove the capabilities from compilers because of old codes. However, the Intent is to guide programmers writing new code in the direction of using the new (hopefully better) alternatives. And, relevant to the present discussion, deleting certain old stuff makes the standard document cleaner.
Fundamentally, MPI is a C library. Other languages, like C++ and Python, don’t require separate bindings specified in the MPI spec because they can call C library routines. The whole mpi_f08 module exercise was to demonstrate that Fortran can now do the same. The whole idea of specifying a separate Fortran MPI interface needs to be rethought. Perhaps something like
“This version of MPI specifies the contents of a vendor-required Fortran module for MPI that allows access to the underlying C specification. The separate language binding for Fortran has been deleted, but is still available for historical reference in the MPI-3 and earlier specifications.”
That should allow for a significant simplification of the MPI specification document.
Cheers, Bill
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Hammond [email protected] http://jeffhammond.github.io/
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
When did Fortran start requiring function declarations? One of the issues we might see in legacy Fortran code is use of MPI functions without the header at all. Would it be legal to specify the contents of mpif.h be nothing more than "use mpi"? Jeff On Mon, Jul 13, 2020 at 8:53 AM Bill Long <[email protected]> wrote:
Well, as I pointed out, vendors are not going to actually delete old stuff. But that should not be a reason to avoid cleaning up the spec.
There are ways to “fix” the mpif.h problem:
1) Assuming that the legacy MPI module provides the same capabilities as mpif.h, you could jus supply an empty mpif.h file (avoids having to delete the include line from the source), and then have a compiler option to “auto-use” a module and have the compilation include that option, specifying the MPI module. (Advantage of not changing the actual source file.)
2) Have a program that checks for an include of mpif.h and deleting that line and including a USE statement instead that specifies the MPI module. (Disadvantage that the mpif.h file might be included indirectly, by being part of another file that is included or part of a user module.)
3) Same as 2 only check for actual calls to MPI routines or uses of MPI data types in the source file. I there are none, do not add the USE MPI statement. Compile with the option that forces IMPLICIT NONE to be sure there were no missed references to MPI stuff.
4) Much more difficult - have a whole program analyzer that would remove all of the MPI (and SHMEM) and replace it with the native stuff built into Fortran. Probably the right path for new code, and bets done by a person for an old code.
The Cray/HPE Fortran compiler already provides the tools to implement option 1.
Cheers, Bill
On Jul 10, 2020, at 9:52 PM, Jeff Hammond <[email protected]> wrote:
To help aid in the depreciation of mpif.h, perhaps Cray/HPE can contribute a source-to-source translation tool that can be recommended to the MPI user community.
Jeff
On Fri, Jul 10, 2020 at 9:54 AM Bill Long via mpiwg-fortran < [email protected]> wrote:
On Jul 10, 2020, at 11:11 AM, Jeff Squyres (jsquyres) < [email protected]> wrote:
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still
included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
We have the same discussions in the Fortran committee about deleting things, or at least making them “obsolescent”, which seems functionally similar to deprecated in MPI. In the end, we specify certain archaic and now-redundant features as deleted with full knowledge that implementors will not remove the capabilities from compilers because of old codes. However, the Intent is to guide programmers writing new code in the direction of using the new (hopefully better) alternatives. And, relevant to the present discussion, deleting certain old stuff makes the standard document cleaner.
Fundamentally, MPI is a C library. Other languages, like C++ and Python, don’t require separate bindings specified in the MPI spec because they can call C library routines. The whole mpi_f08 module exercise was to demonstrate that Fortran can now do the same. The whole idea of specifying a separate Fortran MPI interface needs to be rethought. Perhaps something like
“This version of MPI specifies the contents of a vendor-required Fortran module for MPI that allows access to the underlying C specification. The separate language binding for Fortran has been deleted, but is still available for historical reference in the MPI-3 and earlier specifications.”
That should allow for a significant simplification of the MPI specification document.
Cheers, Bill
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Hammond [email protected] http://jeffhammond.github.io/
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
-- Jeff Hammond [email protected] http://jeffhammond.github.io/
On Jul 13, 2020, at 11:37 AM, Jeff Hammond <[email protected]> wrote:
When did Fortran start requiring function declarations?
Visible interfaces are only required if the arguments or the function has specific characteristics. (PURE function, optional arguments, …). F66 functions do not have any of these characteristics, so do not require interfaces. (Though providing them anyway is a good programming practice.)
One of the issues we might see in legacy Fortran code is use of MPI functions without the header at all.
Would it be legal to specify the contents of mpif.h be nothing more than "use mpi”?
No. unfortunately that will not work, because the include line can be in a part of the program were a USE statement is not legal. Cheers, Bill
Jeff
On Mon, Jul 13, 2020 at 8:53 AM Bill Long <[email protected]> wrote: Well, as I pointed out, vendors are not going to actually delete old stuff. But that should not be a reason to avoid cleaning up the spec.
There are ways to “fix” the mpif.h problem:
1) Assuming that the legacy MPI module provides the same capabilities as mpif.h, you could jus supply an empty mpif.h file (avoids having to delete the include line from the source), and then have a compiler option to “auto-use” a module and have the compilation include that option, specifying the MPI module. (Advantage of not changing the actual source file.)
2) Have a program that checks for an include of mpif.h and deleting that line and including a USE statement instead that specifies the MPI module. (Disadvantage that the mpif.h file might be included indirectly, by being part of another file that is included or part of a user module.)
3) Same as 2 only check for actual calls to MPI routines or uses of MPI data types in the source file. I there are none, do not add the USE MPI statement. Compile with the option that forces IMPLICIT NONE to be sure there were no missed references to MPI stuff.
4) Much more difficult - have a whole program analyzer that would remove all of the MPI (and SHMEM) and replace it with the native stuff built into Fortran. Probably the right path for new code, and bets done by a person for an old code.
The Cray/HPE Fortran compiler already provides the tools to implement option 1.
Cheers, Bill
On Jul 10, 2020, at 9:52 PM, Jeff Hammond <[email protected]> wrote:
To help aid in the depreciation of mpif.h, perhaps Cray/HPE can contribute a source-to-source translation tool that can be recommended to the MPI user community.
Jeff
On Fri, Jul 10, 2020 at 9:54 AM Bill Long via mpiwg-fortran <[email protected]> wrote:
On Jul 10, 2020, at 11:11 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
We have the same discussions in the Fortran committee about deleting things, or at least making them “obsolescent”, which seems functionally similar to deprecated in MPI. In the end, we specify certain archaic and now-redundant features as deleted with full knowledge that implementors will not remove the capabilities from compilers because of old codes. However, the Intent is to guide programmers writing new code in the direction of using the new (hopefully better) alternatives. And, relevant to the present discussion, deleting certain old stuff makes the standard document cleaner.
Fundamentally, MPI is a C library. Other languages, like C++ and Python, don’t require separate bindings specified in the MPI spec because they can call C library routines. The whole mpi_f08 module exercise was to demonstrate that Fortran can now do the same. The whole idea of specifying a separate Fortran MPI interface needs to be rethought. Perhaps something like
“This version of MPI specifies the contents of a vendor-required Fortran module for MPI that allows access to the underlying C specification. The separate language binding for Fortran has been deleted, but is still available for historical reference in the MPI-3 and earlier specifications.”
That should allow for a significant simplification of the MPI specification document.
Cheers, Bill
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Hammond [email protected] http://jeffhammond.github.io/
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
-- Jeff Hammond [email protected] http://jeffhammond.github.io/
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
Doing so would break all the MPI applications what use the 'implicit' directive implicit none include 'mpif.h' is fine, but implicit none use mpi is not, it should be use mpi implicit none On Tue, Jul 14, 2020 at 1:45 AM Jeff Hammond via mpiwg-fortran <[email protected]> wrote:
When did Fortran start requiring function declarations? One of the issues we might see in legacy Fortran code is use of MPI functions without the header at all.
Would it be legal to specify the contents of mpif.h be nothing more than "use mpi"?
Jeff
On Mon, Jul 13, 2020 at 8:53 AM Bill Long <[email protected]> wrote:
Well, as I pointed out, vendors are not going to actually delete old stuff. But that should not be a reason to avoid cleaning up the spec.
There are ways to “fix” the mpif.h problem:
1) Assuming that the legacy MPI module provides the same capabilities as mpif.h, you could jus supply an empty mpif.h file (avoids having to delete the include line from the source), and then have a compiler option to “auto-use” a module and have the compilation include that option, specifying the MPI module. (Advantage of not changing the actual source file.)
2) Have a program that checks for an include of mpif.h and deleting that line and including a USE statement instead that specifies the MPI module. (Disadvantage that the mpif.h file might be included indirectly, by being part of another file that is included or part of a user module.)
3) Same as 2 only check for actual calls to MPI routines or uses of MPI data types in the source file. I there are none, do not add the USE MPI statement. Compile with the option that forces IMPLICIT NONE to be sure there were no missed references to MPI stuff.
4) Much more difficult - have a whole program analyzer that would remove all of the MPI (and SHMEM) and replace it with the native stuff built into Fortran. Probably the right path for new code, and bets done by a person for an old code.
The Cray/HPE Fortran compiler already provides the tools to implement option 1.
Cheers, Bill
On Jul 10, 2020, at 9:52 PM, Jeff Hammond <[email protected]> wrote:
To help aid in the depreciation of mpif.h, perhaps Cray/HPE can contribute a source-to-source translation tool that can be recommended to the MPI user community.
Jeff
On Fri, Jul 10, 2020 at 9:54 AM Bill Long via mpiwg-fortran <[email protected]> wrote:
On Jul 10, 2020, at 11:11 AM, Jeff Squyres (jsquyres) <[email protected]> wrote:
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
We have the same discussions in the Fortran committee about deleting things, or at least making them “obsolescent”, which seems functionally similar to deprecated in MPI. In the end, we specify certain archaic and now-redundant features as deleted with full knowledge that implementors will not remove the capabilities from compilers because of old codes. However, the Intent is to guide programmers writing new code in the direction of using the new (hopefully better) alternatives. And, relevant to the present discussion, deleting certain old stuff makes the standard document cleaner.
Fundamentally, MPI is a C library. Other languages, like C++ and Python, don’t require separate bindings specified in the MPI spec because they can call C library routines. The whole mpi_f08 module exercise was to demonstrate that Fortran can now do the same. The whole idea of specifying a separate Fortran MPI interface needs to be rethought. Perhaps something like
“This version of MPI specifies the contents of a vendor-required Fortran module for MPI that allows access to the underlying C specification. The separate language binding for Fortran has been deleted, but is still available for historical reference in the MPI-3 and earlier specifications.”
That should allow for a significant simplification of the MPI specification document.
Cheers, Bill
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Hammond [email protected] http://jeffhammond.github.io/
Bill Long [email protected] Principal Engineer, Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9143 Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
-- Jeff Hammond [email protected] http://jeffhammond.github.io/ _______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
Just to bring this thread back on-track about TYPE(MPI_Status)... Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more: On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...: MPI-3.1 - page 607 lines 18-24 require these types and the overloaded operators .EQ./.NE. for mpi_f08 module - page 609 lines 34-36 require these types and the overloaded operators .EQ./.NE. for mpi module - there is no such text on page 611-612 on mpif.h And page 802 lines 9-15 also Show that it was never intented to add These types anf routines to old mpif.h. It would be helpful, to add at least on page 657 line 11 C, some in both C and Fortran (only in the mpi_f08 and mpi modules). Can you fix this with an one-vote-bug-fix-issue? Because it is not good if the information must be taken from the change-log. --- Summary: Does this mean that TYPE(MPI_Status) [ and the Fortran routines MPI_STATUS_F2F08 and _F082F ] needs to be defined in - mpif.h? NO - and the mpi module? YES Bug-fix needed in MPI-3.1 page 657 line 11: add "(only in the mpi_f08 and mpi modules)" at the end. I hope this helps. Best regards Rolf So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module. I'm a little curious as to why we conspicuously left it out of mpif.h. Bill: this is somewhat counter to the clarification you proposed. Are you ok with this? I think the text in the standard supports what Rolf proposes. On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]<mailto:[email protected]>> wrote: On Jul 10, 2020, at 11:18 AM, Bill Long <[email protected]<mailto:[email protected]>> wrote: In the “change” section there is this txt: • Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added. Good point. Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802. That being said: - the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h 1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant). I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1. I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it) 2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular} I would love it if we could ditch -- at a minimum -- mpif.h. However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings. -- Jeff Squyres [email protected]<mailto:[email protected]> _______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Squyres [email protected]<mailto:[email protected]>
I’m ok with a clarification that excludes TYPE(MPI_Status) from mpif.h , as Rolf proposes. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 15, 2020, at 10:25 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...: MPI-3.1 - page 607 lines 18-24 require these types and the overloaded operators .EQ./.NE. for mpi_f08 module - page 609 lines 34-36 require these types and the overloaded operators .EQ./.NE. for mpi module - there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue? Because it is not good if the information must be taken from the change-log.
--- Summary:
Does this mean that TYPE(MPI_Status) [ and the Fortran routines MPI_STATUS_F2F08 and _F082F ] needs to be defined in
- mpif.h? NO - and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add "(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected] <mailto:[email protected]>> wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long <[email protected] <mailto:[email protected]>> wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [email protected] <mailto:[email protected]>
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected] <mailto:[email protected]> _______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
Ø I'm a little curious as to why we conspicuously left it out of mpif.h. When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08. I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h). Hubert From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f() Just to bring this thread back on-track about TYPE(MPI_Status)... Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more: On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...: MPI-3.1 - page 607 lines 18-24 require these types and the overloaded operators .EQ./.NE. for mpi_f08 module - page 609 lines 34-36 require these types and the overloaded operators .EQ./.NE. for mpi module - there is no such text on page 611-612 on mpif.h And page 802 lines 9-15 also Show that it was never intented to add These types anf routines to old mpif.h. It would be helpful, to add at least on page 657 line 11 C, some in both C and Fortran (only in the mpi_f08 and mpi modules). Can you fix this with an one-vote-bug-fix-issue? Because it is not good if the information must be taken from the change-log. --- Summary: Does this mean that TYPE(MPI_Status) [ and the Fortran routines MPI_STATUS_F2F08 and _F082F ] needs to be defined in - mpif.h? NO - and the mpi module? YES Bug-fix needed in MPI-3.1 page 657 line 11: add "(only in the mpi_f08 and mpi modules)" at the end. I hope this helps. Best regards Rolf So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module. I'm a little curious as to why we conspicuously left it out of mpif.h. Bill: this is somewhat counter to the clarification you proposed. Are you ok with this? I think the text in the standard supports what Rolf proposes. On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]<mailto:[email protected]>> wrote: On Jul 10, 2020, at 11:18 AM, Bill Long <[email protected]<mailto:[email protected]>> wrote: In the “change” section there is this txt: • Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added. Good point. Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802. That being said: - the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h 1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant). I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1. I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it) 2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular} I would love it if we could ditch -- at a minimum -- mpif.h. However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings. -- Jeff Squyres [email protected]<mailto:[email protected]> _______________________________________________ mpiwg-fortran mailing list [email protected]<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Squyres [email protected]<mailto:[email protected]> Click here<https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2CvP2Zmks-Y-w2Bv6lGox3acbEaKe314w5W2BPFL9JFA==> to report this email as spam.
Dear Hubert and Jeff,
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module. The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi.
... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module. But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area. And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h Best regards Rolf ----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08.
I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
Hubert
From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
MPI-3.1
- page 607 lines 18-24 require these types and the overloaded
operators .EQ./.NE. for mpi_f08 module
- page 609 lines 34-36 require these types and the overloaded
operators .EQ./.NE. for mpi module
- there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add
These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue?
Because it is not good if the information must be taken from the change-log.
---
Summary:
Does this mean that TYPE(MPI_Status)
[ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
needs to be defined in
- mpif.h? NO
- and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add
"(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards
Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected] ]
wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected] ] > wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
_______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam.
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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) .
Thanks Rolf, Hubert, and Bill. It all makes sense. Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11: (only in the mpi_f08 and mpi modules) This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h?
On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <[email protected]> wrote:
Dear Hubert and Jeff,
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module.
The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi.
... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module.
But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area.
And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h
Best regards Rolf
----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08.
I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
Hubert
From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
MPI-3.1
- page 607 lines 18-24 require these types and the overloaded
operators .EQ./.NE. for mpi_f08 module
- page 609 lines 34-36 require these types and the overloaded
operators .EQ./.NE. for mpi module
- there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add
These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue?
Because it is not good if the information must be taken from the change-log.
---
Summary:
Does this mean that TYPE(MPI_Status)
[ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
needs to be defined in
- mpif.h? NO
- and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add
"(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards
Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected] ]
wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected] ] > wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
_______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam.
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
Adding something to the MPI_Status_f2f08/f082f bindings to specify these are only for the MPI module is a good idea. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 16, 2020, at 9:19 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Thanks Rolf, Hubert, and Bill. It all makes sense.
Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11:
(only in the mpi_f08 and mpi modules)
This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h?
On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <[email protected]> wrote:
Dear Hubert and Jeff,
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module.
The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi.
... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module.
But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area.
And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h
Best regards Rolf
----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08.
I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
Hubert
From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
MPI-3.1
- page 607 lines 18-24 require these types and the overloaded
operators .EQ./.NE. for mpi_f08 module
- page 609 lines 34-36 require these types and the overloaded
operators .EQ./.NE. for mpi module
- there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add
These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue?
Because it is not good if the information must be taken from the change-log.
---
Summary:
Does this mean that TYPE(MPI_Status)
[ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
needs to be defined in
- mpif.h? NO
- and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add
"(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards
Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected] ]
wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected] ] > wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
_______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam.
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
Good idea. With the pythonizing, we have the additional header Fortran binding which could be substituted by Fortran binding (the following procedure is not available with mpif.h) And in A.4.12 we could write in front of the two routines also The following procedure is not available with mpif.h: I would not use the positive statement "only available in the mpi module", because the procedure itself is in mpi_f08 and mpi, and only this specific Interface only in the mpi module. I would use "with mpif.h" and not use "in mpif.h", because most/all MPI libraries do not provide procedure interfaces in mpif.h. Best regards Rolf ----- Original Message -----
From: "wgropp" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Rolf Rabenseifner" <[email protected]>, "Jeff Squyres" <[email protected]> Sent: Thursday, July 16, 2020 5:17:55 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Adding something to the MPI_Status_f2f08/f082f bindings to specify these are only for the MPI module is a good idea.
Bill
William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 16, 2020, at 9:19 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Thanks Rolf, Hubert, and Bill. It all makes sense.
Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11:
(only in the mpi_f08 and mpi modules)
This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h?
On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <[email protected]> wrote:
Dear Hubert and Jeff,
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module.
The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi.
... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module.
But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area.
And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h
Best regards Rolf
----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08.
I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
Hubert
From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
MPI-3.1
- page 607 lines 18-24 require these types and the overloaded
operators .EQ./.NE. for mpi_f08 module
- page 609 lines 34-36 require these types and the overloaded
operators .EQ./.NE. for mpi module
- there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add
These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue?
Because it is not good if the information must be taken from the change-log.
---
Summary:
Does this mean that TYPE(MPI_Status)
[ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
needs to be defined in
- mpif.h? NO
- and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add
"(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards
Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected] ]
wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected] ] > wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
_______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam.
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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) .
I just filed the issue: https://github.com/mpi-forum/mpi-issues/issues/298 And a first cut of the MPI-4.x PR: https://github.com/mpi-forum/mpi-standard/pull/255 I just added a statement in the text on the PR so far. I need to work with Martin R to get the Pythonization changes. I'll post back here when we have something for everyone to review. After that, we'll make a corresponding equivalent-looking PR for MPI-3.x. On Jul 16, 2020, at 12:07 PM, Rolf Rabenseifner <[email protected]<mailto:[email protected]>> wrote: Good idea. With the pythonizing, we have the additional header Fortran binding which could be substituted by Fortran binding (the following procedure is not available with mpif.h) And in A.4.12 we could write in front of the two routines also The following procedure is not available with mpif.h: I would not use the positive statement "only available in the mpi module", because the procedure itself is in mpi_f08 and mpi, and only this specific Interface only in the mpi module. I would use "with mpif.h" and not use "in mpif.h", because most/all MPI libraries do not provide procedure interfaces in mpif.h. Best regards Rolf ----- Original Message ----- From: "wgropp" <[email protected]<mailto:[email protected]>> To: "MPI-WG Fortran working group" <[email protected]<mailto:[email protected]>> Cc: "Rolf Rabenseifner" <[email protected]<mailto:[email protected]>>, "Jeff Squyres" <[email protected]<mailto:[email protected]>> Sent: Thursday, July 16, 2020 5:17:55 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f() Adding something to the MPI_Status_f2f08/f082f bindings to specify these are only for the MPI module is a good idea. Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Jul 16, 2020, at 9:19 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]<mailto:[email protected]>> wrote: Thanks Rolf, Hubert, and Bill. It all makes sense. Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11: (only in the mpi_f08 and mpi modules) This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h? On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <[email protected]<mailto:[email protected]>> wrote: Dear Hubert and Jeff, Ø I'm a little curious as to why we conspicuously left it out of mpif.h. I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module. The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi. ... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h). It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module. But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area. And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h Best regards Rolf ----- Original Message ----- From: "MPI-WG Fortran working group" <[email protected]<mailto:[email protected]>> To: "MPI-WG Fortran working group" <[email protected]<mailto:[email protected]>> Cc: "Hubert Ritzdorf" <[email protected]<mailto:[email protected]>> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f() Ø I'm a little curious as to why we conspicuously left it out of mpif.h. When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08. I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h). Hubert From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]<mailto:[email protected]>> Cc: Jeff Squyres (jsquyres) <[email protected]<mailto:[email protected]>> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f() Just to bring this thread back on-track about TYPE(MPI_Status)... Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more: On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...: MPI-3.1 - page 607 lines 18-24 require these types and the overloaded operators .EQ./.NE. for mpi_f08 module - page 609 lines 34-36 require these types and the overloaded operators .EQ./.NE. for mpi module - there is no such text on page 611-612 on mpif.h And page 802 lines 9-15 also Show that it was never intented to add These types anf routines to old mpif.h. It would be helpful, to add at least on page 657 line 11 C, some in both C and Fortran (only in the mpi_f08 and mpi modules). Can you fix this with an one-vote-bug-fix-issue? Because it is not good if the information must be taken from the change-log. --- Summary: Does this mean that TYPE(MPI_Status) [ and the Fortran routines MPI_STATUS_F2F08 and _F082F ] needs to be defined in - mpif.h? NO - and the mpi module? YES Bug-fix needed in MPI-3.1 page 657 line 11: add "(only in the mpi_f08 and mpi modules)" at the end. I hope this helps. Best regards Rolf So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module. I'm a little curious as to why we conspicuously left it out of mpif.h. Bill: this is somewhat counter to the clarification you proposed. Are you ok with this? I think the text in the standard supports what Rolf proposes. On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected]<mailto:[email protected]> ] wrote: On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected]<mailto:[email protected]> ] > wrote: In the “change” section there is this txt: • Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added. Good point. Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802. That being said: - the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h 1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant). I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1. I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it) 2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular} I would love it if we could ditch -- at a minimum -- mpif.h. However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings. -- Jeff Squyres [ mailto:[email protected] | [email protected]<mailto:[email protected]> ] _______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected]<mailto:[email protected]> ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ] -- Jeff Squyres [ mailto:[email protected] | [email protected]<mailto:[email protected]> ] Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam. _______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected]<mailto:[email protected]> . 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<http://www.hlrs.de/people/rabenseifner> . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . _______________________________________________ mpiwg-fortran mailing list [email protected]<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Jeff Squyres [email protected]<mailto:[email protected]> _______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected]<mailto:[email protected]> . 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<http://www.hlrs.de/people/rabenseifner> . Nobelstr. 19, D-70550 Stuttgart, Germany . . . . (Office: Room 1.307) . -- Jeff Squyres [email protected]<mailto:[email protected]>
Fortran WG: Ok, we have all the updates now. Can you please review the LaTeX and the rendered PDF? MPI-4.0 PR is here: https://github.com/mpi-forum/mpi-standard/pull/255 Rendered PDF from that PR is here: https://artprodcus3.artifacts.visualstudio.com/A2828b64d-12fe-4a97-80aa-ee05... In particular, look at: - page 755: lines 15 and 16 - page 756: new Fortran bindings for both functions - page 907: lines 15 and 19
On Jul 16, 2020, at 3:35 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
I just filed the issue:
https://github.com/mpi-forum/mpi-issues/issues/298
And a first cut of the MPI-4.x PR:
https://github.com/mpi-forum/mpi-standard/pull/255
I just added a statement in the text on the PR so far. I need to work with Martin R to get the Pythonization changes.
I'll post back here when we have something for everyone to review.
After that, we'll make a corresponding equivalent-looking PR for MPI-3.x.
On Jul 16, 2020, at 12:07 PM, Rolf Rabenseifner <[email protected]> wrote:
Good idea.
With the pythonizing, we have the additional header Fortran binding which could be substituted by Fortran binding (the following procedure is not available with mpif.h)
And in A.4.12 we could write in front of the two routines also
The following procedure is not available with mpif.h:
I would not use the positive statement "only available in the mpi module", because the procedure itself is in mpi_f08 and mpi, and only this specific Interface only in the mpi module.
I would use "with mpif.h" and not use "in mpif.h", because most/all MPI libraries do not provide procedure interfaces in mpif.h.
Best regards Rolf
----- Original Message -----
From: "wgropp" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Rolf Rabenseifner" <[email protected]>, "Jeff Squyres" <[email protected]> Sent: Thursday, July 16, 2020 5:17:55 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Adding something to the MPI_Status_f2f08/f082f bindings to specify these are only for the MPI module is a good idea.
Bill
William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 16, 2020, at 9:19 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Thanks Rolf, Hubert, and Bill. It all makes sense.
Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11:
(only in the mpi_f08 and mpi modules)
This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h?
On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <[email protected]> wrote:
Dear Hubert and Jeff,
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module.
The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi.
... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module.
But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area.
And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h
Best regards Rolf
----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08.
I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
Hubert
From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
MPI-3.1
- page 607 lines 18-24 require these types and the overloaded
operators .EQ./.NE. for mpi_f08 module
- page 609 lines 34-36 require these types and the overloaded
operators .EQ./.NE. for mpi module
- there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add
These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue?
Because it is not good if the information must be taken from the change-log.
---
Summary:
Does this mean that TYPE(MPI_Status)
[ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
needs to be defined in
- mpif.h? NO
- and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add
"(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards
Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected] ]
wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected] ] > wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
_______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam.
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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) .
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
One more update -- changelog entry added: https://github.com/mpi-forum/mpi-standard/files/4965729/mpi40-report-243eb86... In particular, look at: - page 755: lines 15 and 16 - page 756: new Fortran bindings for both functions - page 907: lines 15 and 19 - page 909: lines 27-29 If this seems ok, I'll make the corresponding MPI-3.1 errata PR. The goal will be to render (mostly?) the same as the v4.0 errata, but the back-end Latex will be different (because the mpi-4.x branch was Pythonized).
On Jul 20, 2020, at 3:02 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Fortran WG:
Ok, we have all the updates now. Can you please review the LaTeX and the rendered PDF?
MPI-4.0 PR is here: https://github.com/mpi-forum/mpi-standard/pull/255
Rendered PDF from that PR is here: https://artprodcus3.artifacts.visualstudio.com/A2828b64d-12fe-4a97-80aa-ee05...
In particular, look at:
- page 755: lines 15 and 16 - page 756: new Fortran bindings for both functions - page 907: lines 15 and 19
On Jul 16, 2020, at 3:35 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
I just filed the issue:
https://github.com/mpi-forum/mpi-issues/issues/298
And a first cut of the MPI-4.x PR:
https://github.com/mpi-forum/mpi-standard/pull/255
I just added a statement in the text on the PR so far. I need to work with Martin R to get the Pythonization changes.
I'll post back here when we have something for everyone to review.
After that, we'll make a corresponding equivalent-looking PR for MPI-3.x.
On Jul 16, 2020, at 12:07 PM, Rolf Rabenseifner <[email protected]> wrote:
Good idea.
With the pythonizing, we have the additional header Fortran binding which could be substituted by Fortran binding (the following procedure is not available with mpif.h)
And in A.4.12 we could write in front of the two routines also
The following procedure is not available with mpif.h:
I would not use the positive statement "only available in the mpi module", because the procedure itself is in mpi_f08 and mpi, and only this specific Interface only in the mpi module.
I would use "with mpif.h" and not use "in mpif.h", because most/all MPI libraries do not provide procedure interfaces in mpif.h.
Best regards Rolf
----- Original Message -----
From: "wgropp" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Rolf Rabenseifner" <[email protected]>, "Jeff Squyres" <[email protected]> Sent: Thursday, July 16, 2020 5:17:55 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Adding something to the MPI_Status_f2f08/f082f bindings to specify these are only for the MPI module is a good idea.
Bill
William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 16, 2020, at 9:19 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Thanks Rolf, Hubert, and Bill. It all makes sense.
Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11:
(only in the mpi_f08 and mpi modules)
This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h?
On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <[email protected]> wrote:
Dear Hubert and Jeff,
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module.
The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi.
... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module.
But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area.
And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h
Best regards Rolf
----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08.
I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
Hubert
From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
MPI-3.1
- page 607 lines 18-24 require these types and the overloaded
operators .EQ./.NE. for mpi_f08 module
- page 609 lines 34-36 require these types and the overloaded
operators .EQ./.NE. for mpi module
- there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add
These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue?
Because it is not good if the information must be taken from the change-log.
---
Summary:
Does this mean that TYPE(MPI_Status)
[ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
needs to be defined in
- mpif.h? NO
- and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add
"(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards
Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected] ]
wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected] ] > wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
_______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam.
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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) .
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
On Jul 23, 2020, at 8:06 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
One more update -- changelog entry added:
https://github.com/mpi-forum/mpi-standard/files/4965729/mpi40-report-2.....7...
Sorry -- that PDF had an error in it. Here is the corrected one: https://github.com/mpi-forum/mpi-standard/files/4965771/mpi40-report-2a6c782...
In particular, look at:
- page 755: lines 15 and 16 - page 756: new Fortran bindings for both functions - page 907: lines 15 and 19 - page 909: lines 27-29
If this seems ok, I'll make the corresponding MPI-3.1 errata PR. The goal will be to render (mostly?) the same as the v4.0 errata, but the back-end Latex will be different (because the mpi-4.x branch was Pythonized).
-- Jeff Squyres [email protected]
Thank you for the pdf. I want to remember that errata should have an own section in the changelog, as you could see MPI-3.1 B.1.1 / B.1.2 and B.2.1 and B.2.2 and so on. Please sort it into the errata, because this is not a non-backward compatible Change of the Standard. It is a clarification (i.e. errata) which changes the original text. Such errata refer to the sections and pages in the current Standard but also to the section page AND lines in the previous Standard. Here, I would reference "MPI-3.1 Section 17.2.5 on page 657 line 11". Best regards Rolf ----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Jeff Squyres" <[email protected]> Sent: Thursday, July 23, 2020 2:06:57 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
One more update -- changelog entry added:
https://github.com/mpi-forum/mpi-standard/files/4965729/mpi40-report-243eb86...
In particular, look at:
- page 755: lines 15 and 16 - page 756: new Fortran bindings for both functions - page 907: lines 15 and 19 - page 909: lines 27-29
If this seems ok, I'll make the corresponding MPI-3.1 errata PR. The goal will be to render (mostly?) the same as the v4.0 errata, but the back-end Latex will be different (because the mpi-4.x branch was Pythonized).
On Jul 20, 2020, at 3:02 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Fortran WG:
Ok, we have all the updates now. Can you please review the LaTeX and the rendered PDF?
MPI-4.0 PR is here: https://github.com/mpi-forum/mpi-standard/pull/255
Rendered PDF from that PR is here: https://artprodcus3.artifacts.visualstudio.com/A2828b64d-12fe-4a97-80aa-ee05...
In particular, look at:
- page 755: lines 15 and 16 - page 756: new Fortran bindings for both functions - page 907: lines 15 and 19
On Jul 16, 2020, at 3:35 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
I just filed the issue:
https://github.com/mpi-forum/mpi-issues/issues/298
And a first cut of the MPI-4.x PR:
https://github.com/mpi-forum/mpi-standard/pull/255
I just added a statement in the text on the PR so far. I need to work with Martin R to get the Pythonization changes.
I'll post back here when we have something for everyone to review.
After that, we'll make a corresponding equivalent-looking PR for MPI-3.x.
On Jul 16, 2020, at 12:07 PM, Rolf Rabenseifner <[email protected]> wrote:
Good idea.
With the pythonizing, we have the additional header Fortran binding which could be substituted by Fortran binding (the following procedure is not available with mpif.h)
And in A.4.12 we could write in front of the two routines also
The following procedure is not available with mpif.h:
I would not use the positive statement "only available in the mpi module", because the procedure itself is in mpi_f08 and mpi, and only this specific Interface only in the mpi module.
I would use "with mpif.h" and not use "in mpif.h", because most/all MPI libraries do not provide procedure interfaces in mpif.h.
Best regards Rolf
----- Original Message -----
From: "wgropp" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Rolf Rabenseifner" <[email protected]>, "Jeff Squyres" <[email protected]> Sent: Thursday, July 16, 2020 5:17:55 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Adding something to the MPI_Status_f2f08/f082f bindings to specify these are only for the MPI module is a good idea.
Bill
William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 16, 2020, at 9:19 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Thanks Rolf, Hubert, and Bill. It all makes sense.
Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11:
(only in the mpi_f08 and mpi modules)
This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h?
On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <[email protected]> wrote:
Dear Hubert and Jeff,
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module.
The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi.
... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module.
But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area.
And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h
Best regards Rolf
----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08.
I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
Hubert
From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
MPI-3.1
- page 607 lines 18-24 require these types and the overloaded
operators .EQ./.NE. for mpi_f08 module
- page 609 lines 34-36 require these types and the overloaded
operators .EQ./.NE. for mpi module
- there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add
These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue?
Because it is not good if the information must be taken from the change-log.
---
Summary:
Does this mean that TYPE(MPI_Status)
[ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
needs to be defined in
- mpif.h? NO
- and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add
"(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards
Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected] ]
wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected] ] > wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
_______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam.
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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) .
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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) .
Ok, with a few more (off-list) edits to get the changelog/errata entry right, I think we finally have a good PDF: https://artprodcus3.artifacts.visualstudio.com/A2828b64d-12fe-4a97-80aa-ee05... *** NOTE: Every change to a PR automatically generates a new PDF. You can download it by: • Click on "Show all checks" at the bottom of the PR • Click on "Details" • Click on "View more details on Azure Pipelines" • Click on "1 Published" • Click on the 3 dots to the far right of "Built PDF" • Select Download I know it's a lot of clicks, but it can be (a lot) easier than git cloning the PR branch and building the PDF yourself. Specifically: the URL I listed above is the unique URL for the PDF corresponding to commit 9defff9 on that PR.
On Jul 23, 2020, at 8:21 AM, Rolf Rabenseifner <[email protected]> wrote:
Thank you for the pdf.
I want to remember that errata should have an own section in the changelog, as you could see MPI-3.1 B.1.1 / B.1.2 and B.2.1 and B.2.2 and so on.
Please sort it into the errata, because this is not a non-backward compatible Change of the Standard. It is a clarification (i.e. errata) which changes the original text. Such errata refer to the sections and pages in the current Standard but also to the section page AND lines in the previous Standard.
Here, I would reference "MPI-3.1 Section 17.2.5 on page 657 line 11".
Best regards Rolf
----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Jeff Squyres" <[email protected]> Sent: Thursday, July 23, 2020 2:06:57 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
One more update -- changelog entry added:
https://github.com/mpi-forum/mpi-standard/files/4965729/mpi40-report-243eb86...
In particular, look at:
- page 755: lines 15 and 16 - page 756: new Fortran bindings for both functions - page 907: lines 15 and 19 - page 909: lines 27-29
If this seems ok, I'll make the corresponding MPI-3.1 errata PR. The goal will be to render (mostly?) the same as the v4.0 errata, but the back-end Latex will be different (because the mpi-4.x branch was Pythonized).
On Jul 20, 2020, at 3:02 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Fortran WG:
Ok, we have all the updates now. Can you please review the LaTeX and the rendered PDF?
MPI-4.0 PR is here: https://github.com/mpi-forum/mpi-standard/pull/255
Rendered PDF from that PR is here: https://artprodcus3.artifacts.visualstudio.com/A2828b64d-12fe-4a97-80aa-ee05...
In particular, look at:
- page 755: lines 15 and 16 - page 756: new Fortran bindings for both functions - page 907: lines 15 and 19
On Jul 16, 2020, at 3:35 PM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
I just filed the issue:
https://github.com/mpi-forum/mpi-issues/issues/298
And a first cut of the MPI-4.x PR:
https://github.com/mpi-forum/mpi-standard/pull/255
I just added a statement in the text on the PR so far. I need to work with Martin R to get the Pythonization changes.
I'll post back here when we have something for everyone to review.
After that, we'll make a corresponding equivalent-looking PR for MPI-3.x.
On Jul 16, 2020, at 12:07 PM, Rolf Rabenseifner <[email protected]> wrote:
Good idea.
With the pythonizing, we have the additional header Fortran binding which could be substituted by Fortran binding (the following procedure is not available with mpif.h)
And in A.4.12 we could write in front of the two routines also
The following procedure is not available with mpif.h:
I would not use the positive statement "only available in the mpi module", because the procedure itself is in mpi_f08 and mpi, and only this specific Interface only in the mpi module.
I would use "with mpif.h" and not use "in mpif.h", because most/all MPI libraries do not provide procedure interfaces in mpif.h.
Best regards Rolf
----- Original Message -----
From: "wgropp" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Rolf Rabenseifner" <[email protected]>, "Jeff Squyres" <[email protected]> Sent: Thursday, July 16, 2020 5:17:55 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Adding something to the MPI_Status_f2f08/f082f bindings to specify these are only for the MPI module is a good idea.
Bill
William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign
On Jul 16, 2020, at 9:19 AM, Jeff Squyres (jsquyres) via mpiwg-fortran <[email protected]> wrote:
Thanks Rolf, Hubert, and Bill. It all makes sense.
Rolf has proposed that we add the following at the end of the sentence on MPI-3.1 p657 line 11:
(only in the mpi_f08 and mpi modules)
This sounds reasonable to me, but do we need some additional annotation in the MPI_Status_f2f08 and _f082f bindings to indicate that the all-caps Fortran binding is only for the mpi module, and not mpif.h?
On Jul 15, 2020, at 3:08 PM, Rolf Rabenseifner via mpiwg-fortran <[email protected]> wrote:
Dear Hubert and Jeff,
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
I expect, we didn't want that mpif.h must include the overloading of the operators .NE. and .EQ. for all TYPE(MPI_....). I'm not sure whether such declaration is allowed outside of a module.
The use of mpif.h was already deprecated, i.e., if somebody wants to use mpi_f08 stuff in old code, he or she must first substitute the include mpif.h by use mpi.
... But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
It was intended that you can convert from old INTEGER variable or array to new TYPE(MPI_...) within source code using the mpi module or using the mpi_f08 module.
But we excluded mpif.h because it need not to provide compile-time argument checking and it use is therefore "strongly discouraged". Why should we add something to this "strongly discouraged" mpif.h area.
And, to add it in a later version of MPI is simple. To remove it later is not backward compatible. This may be another reason for not adding it to mpif.h
Best regards Rolf
----- Original Message -----
From: "MPI-WG Fortran working group" <[email protected]> To: "MPI-WG Fortran working group" <[email protected]> Cc: "Hubert Ritzdorf" <[email protected]> Sent: Wednesday, July 15, 2020 6:15:58 PM Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Ø I'm a little curious as to why we conspicuously left it out of mpif.h.
When I remember correctly, MPI_Status_f2f08() and _f082f() subroutines were for a smooth transition from Fortran 77 to Fortran 08.
I.e. if a programmer has changed some functions from old Fortran to Fortran 08 and uses other libraries or subroutines which still use the old Fortran status as input or output argument, it was possible to transfer the old Fortran status within the Fortran 08 subroutine. But it was never intended that the programmer does this transformation within the old Fortran subroutine (and old Fortran 77 compiler or using Fortran 77 language kind wouldn’t support Type(MPI_Status) in mpif.h).
Hubert
From: mpiwg-fortran [mailto:[email protected]] On Behalf Of Jeff Squyres (jsquyres) via mpiwg-fortran Sent: Wednesday, July 15, 2020 5:26 PM To: MPI Fortran WG <[email protected]> Cc: Jeff Squyres (jsquyres) <[email protected]> Subject: Re: [MPIWG Fortran] Question about MPI_Status_f2f08() and _f082f()
Just to bring this thread back on-track about TYPE(MPI_Status)...
Off list, I asked Rolf R. about this issue -- he cited the same things I did, plus a few more:
On your question on TYPE(MPI_Status), TYPE(MPI_Comm), ...:
MPI-3.1
- page 607 lines 18-24 require these types and the overloaded
operators .EQ./.NE. for mpi_f08 module
- page 609 lines 34-36 require these types and the overloaded
operators .EQ./.NE. for mpi module
- there is no such text on page 611-612 on mpif.h
And page 802 lines 9-15 also Show that it was never intented to add
These types anf routines to old mpif.h.
It would be helpful, to add at least on page 657 line 11
C, some in both C and Fortran (only in the mpi_f08 and mpi modules).
Can you fix this with an one-vote-bug-fix-issue?
Because it is not good if the information must be taken from the change-log.
---
Summary:
Does this mean that TYPE(MPI_Status)
[ and the Fortran routines MPI_STATUS_F2F08 and _F082F ]
needs to be defined in
- mpif.h? NO
- and the mpi module? YES
Bug-fix needed in MPI-3.1 page 657 line 11: add
"(only in the mpi_f08 and mpi modules)" at the end.
I hope this helps.
Best regards
Rolf
So I think there's at least a clarification here: the TYPE(MPI_Status) and associated functions is -- at a minimum -- supposed to be in the mpi module.
I'm a little curious as to why we conspicuously left it out of mpif.h.
Bill: this is somewhat counter to the clarification you proposed.
Are you ok with this? I think the text in the standard supports what Rolf proposes.
On Jul 10, 2020, at 12:11 PM, Jeff Squyres (jsquyres) via mpiwg-fortran < [ mailto:[email protected] | [email protected] ]
wrote:
On Jul 10, 2020, at 11:18 AM, Bill Long < [ mailto:[email protected] | [email protected] ] > wrote:
In the “change” section there is this txt:
• Within the mpi_08 Fortran module, the status was defined as TYPE(MPI_Status). Additionally, within both the mpi and the mpi_f08 modules, the constants MPI_STATUS_SIZE, MPI_SOURCE, MPI_TAG, MPI_ERROR, and TYPE(MPI_Status) are defined. New conversion routines were added: MPI_STATUS_F2F08, MPI_STATUS_F082F, MPI_Status_c2f08, and MPI_Status_f082c, In mpi.h, the new type MPI_F08_status, and the external variables MPI_F08_STATUS_IGNORE and MPI_F08_STATUSES_IGNORE were added.
Good point.
Just to be clear, you're referring to the changelog section in MPI-3.1, specifically bullet 30 on p802.
That being said:
- the changelog is non-binding ...but it does indicate our intent from that time - the changelog text states that the mpi module has TYPE(MPI_Status) -- but it does not say it was added to mpif.h
1) Why would the F08 status be defined different from the C definition? (If that were the case, conversions between f08 and C would be irrelevant).
I remember that there was a lot of discussion about this at the time, which is what resulted in Figure 17.1.
I know there were discussions about making the F08 and C statuses the same, but for some reason we chose not to mandate it. Perhaps we wanted to allow implementations to do whatever they wanted...? (e.g., allow Status_c2f08 be a no-op if the implementation wanted to, but not mandate it)
2) \begin{unpopular} Why are the legacy mpi module and mpif.h still included in the spec? These are embarrassingly obsolete. If this was fixed, none of the above mentioned conversion routines would be needed. \end(unpopular}
I would love it if we could ditch -- at a minimum -- mpif.h.
However, there's oodles of legacy code out there that uses it. That's why even deprecating it gets shouted down at Forum meetings.
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
_______________________________________________ mpiwg-fortran mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran | https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran ]
-- Jeff Squyres [ mailto:[email protected] | [email protected] ]
Click [ https://www.mailcontrol.com/sr/HjGlLo600jvGX2PQPOmvUuToodiywuSOXttD3rcwKg2Cv... | here ] to report this email as spam.
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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) .
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Jeff Squyres [email protected]
_______________________________________________ mpiwg-fortran mailing list [email protected] https://lists.mpi-forum.org/mailman/listinfo/mpiwg-fortran
-- Dr. Rolf Rabenseifner . . . . . . . . . .. email [email protected] . 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) .
-- Jeff Squyres [email protected]
participants (7)
-
Bill Long -
Gilles Gouaillardet -
Hubert Ritzdorf -
Jeff Hammond -
Jeff Squyres (jsquyres) -
Rolf Rabenseifner -
William Gropp