Craig Rasmussen wrote:

On Sep 2, 2009, at 9:23 AM, Lionel, Steve wrote:

...

Overall, I think the mission statement is fine. I do have quibbles with some of the text further down on the page.

"As procedures can be overloaded in Fortran, there could be both function and subroutine interfaces provided in MPI 3."

This won't work - while you can overload procedures in Fortran, such overloads must be all subroutines or all functions - you cannot mix the two. In order to prevent errors, any new subroutine names must be distinct from existing MPI2 function names, including the generic name, if any, whether or not there are interfaces defined for the functions.

Yes, we've moved beyond that thought. Would you like to clean it up or should I?

...

As I have stated earlier, it would be a big mistake to rely on default integer (or other) kinds. The declarations need to specify the kind and this should be based on named constants in the MPI3 module which take values from those in ISO_C_BINDING (C_INT). The programmer would be encouraged to use the MPI kind values but not required to do so unless the default kind in their environment is a mismatch for what MPI is expecting.

I think this is currently the biggest bone of contention. I'm going to repost your statement so that we can open it up for discussion. Then we should take a email poll on the subject.

Steve, Jeff has been yanking my chain to start writing. You mentioned that you would like to help. Perhaps we could have a phone call when Jeff gets back to discuss how it all should go.

I think that the Fortran Programmers expect that these definitions are made in Fortran integers and not in C_INT's. They want to use Fortran and not C and they want that the Fortran compiler features are supported (such as expansion of integers, reals and double precisions). Hubert

-craig

...

Steve Lionel Intel Developer Support Nashua, NH

-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jeff Squyres Sent: Wednesday, September 02, 2009 6:52 AM To: MPI-3 Fortran working group Subject: [MPI3 Fortran] WG mission statement / bullets Importance: Low

Craig and I iterated a bit off-list and came up with a mission statement / list of goals for the MPI-3 Fortran working group (all MPI-3 WG's have been chartered to do this). This text is intended to be the "quickie description" of what the MPI-3 Fortran WG is working on; it will be published to people outside the MPI Forum.

I have put the text at the top of the MPI-3 Fortran wiki page (I just pushed everything else down; I didn't read/review anything else on the wiki page):

https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage

Please let us know if you have any comments, suggestions, etc. for this text.

Thanks!

-- Jeff Squyres [email protected]

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

BTW, my web browser complains about the security certificate on the referenced web page. (この Web サイトで提示されたセキュリティ証明書は、信頼された証明機関から発行されたものではありません。) Steve Lionel wrote:

Hubert Ritzdorf wrote:

...

I think that the Fortran Programmers expect that these definitions are made in Fortran integers and not in C_INT's. They want to use Fortran and not C and they want that the Fortran compiler features are supported (such as expansion > of integers, reals and double precisions).

Fortran programmers would be using Fortran integers. The KIND value just makes sure that they're the right kind of Fortran integers. I am not asking Fortran programmers to code in C and the fact that C_INT is used would be invisible. This is just a standard-conforming way of saying "give me this platform's default integer kind".

Well, actually, "give me the kind that matches this platform's C ``int''." As you wrote in another message, Fortran's default integer is not always 32-bit.

Using generics, it's possible to define a routine that accepts different signatures, if that seems appropriate. But the need for kind values remains.

I'd prefer us to provide generics (and not specifics) with the generics taking both 32-bit and 64-bit integer for the "default" integer arguments. Craig Rasmussen wrote:

I've been back and forth on this (as well as a few others I think). I'm currently leaning toward using default integers.

Well, that's just MPI_INT_KIND=KIND(0). It doesn't mean it should not be documented if we are going to have specifics (which I obviously don't favour). If we have specifics and not generics we absolutely want MPI_INT_KIND so people can write stuff that works with and without -double. And we surely need MPI_SIZE_KIND for buffer sizes in any case, right? - - - - A couple of random comments... I don't understand how or why we are ruling out optional arguments when there are optional arguments in the interface examples further down the page. I also don't understand "A discussion occurred at the April 2009 meeting about module use: should the module name be MPI3 or just MPI as it is now. Decision is to that the module name should be MPI to allow for continuity of users code. It is a quality of implementation issue of just what is in the module. " ...? I thought things were being changed, so how is this continuity preserved? I mean, if we are switching from magic integers to handles/opaque-type-constants, that's going to change the interface, right? Or is the user going to write MPI3_Recv instead of MPI_Recv (i.e. the "3" is on every call)? Cheers, -- ......................Malcolm Cohen, Nihon NAG, Tokyo.

-------------------------------------------------- From: "Jeff Squyres" <[email protected]> Sent: Thursday, September 03, 2009 3:32 PM To: "MPI-3 Fortran working group" <[email protected]> Subject: Re: [MPI3 Fortran] WG mission statement / bullets

See the notice here:

https://svn.mpi-forum.org/trac/mpi-forum-web/wiki

Forbidden You don't have permission to access /Facilities/FAQ/Mail/csci.crt on this server. Cheers, -- ......................Malcolm Cohen, Nihon NAG, Tokyo.

It's fixed; you should be able to get to the certificate now. On Sep 3, 2009, at 9:56 AM, Jeff Squyres wrote:

I've told the IU rep here at the Forum meeting; he'll contact the IU CS admins to fix that.

On Sep 3, 2009, at 9:38 AM, Malcolm Cohen wrote:

...

-------------------------------------------------- From: "Jeff Squyres" <[email protected]> Sent: Thursday, September 03, 2009 3:32 PM To: "MPI-3 Fortran working group" <[email protected]> Subject: Re: [MPI3 Fortran] WG mission statement / bullets

...

See the notice here:

https://svn.mpi-forum.org/trac/mpi-forum-web/wiki

Forbidden You don't have permission to access /Facilities/FAQ/Mail/csci.crt on this server.

Cheers, -- ......................Malcolm Cohen, Nihon NAG, Tokyo.

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- Jeff Squyres [email protected]

-- Jeff Squyres [email protected]

On Sep 3, 2009, at 5:14 AM, N.M. Maclaren wrote:

I haven't seen the mission statement for the same reason as Malcolm, but would favour MPI using Fortran default integers whereever they make sense. Fortran's semantic specification of them is still useful in a way that C's isn't.

I believe that the idea behind using C int (or, more generally, something like a MPI_DEFAULT_INT kind) was to allow people to build a library that would work regardless of whether the application is compiled with -i8. As it stands, the MPI Fortran library has to be compiled with -i8 if the application is. If people use an explicit kind for their integers, then one library can serve applications with and without -i8. There are, of course, other possible solutions to the problem. Is there one in particular that you favor? Or do you think the problem shouldn't be solved? Iain

Hi, Let's not forget about MPI datatypes. My personal favorite is MPI_2INT. 8 bytes in 32-bit mode, 16 bytes for -i8. This is just to highlight that the effect of the -i8, etc., upon MPI may spread well beyond the language interface as we normally know it. Best regards. Alexander -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bill Long Sent: Thursday, September 03, 2009 3:36 PM To: MPI-3 Fortran working group Subject: Re: [MPI3 Fortran] WG mission statement / bullets Iain Bason wrote:

On Sep 3, 2009, at 5:14 AM, N.M. Maclaren wrote:

...

I haven't seen the mission statement for the same reason as Malcolm, but would favour MPI using Fortran default integers whereever they make sense. Fortran's semantic specification of them is still useful in a way that C's isn't.

I believe that the idea behind using C int (or, more generally, something like a MPI_DEFAULT_INT kind) was to allow people to build a library that would work regardless of whether the application is compiled with -i8. As it stands, the MPI Fortran library has to be compiled with -i8 if the application is. If people use an explicit kind for their integers, then one library can serve applications with and without -i8.

With the current MPI setup, we (as a vendor) supply two sets of module/library, compiled with 32-bit and 64-bit defaults respectively. The compiler figures out which to use based on what the meaning of "default" is based on the compile options. This is extra work to maintain, but it works for the user (mostly). Until some clown wants -r8 -i4, in which case a third version is needed. The advantage of explicitly specifying a KIND for the MPI dummy arguments is that it encourages (forces) users to supply actual arguments with the correct kinds. This avoids hidden problems of supplying an actual argument with a value that is too large to fit into the 'int' that is used in the actual implementation routine. The downside is that some existing codes will start getting error messages about mismatched interfaces.

There are, of course, other possible solutions to the problem. Is there one in particular that you favor? Or do you think the problem shouldn't be solved?

I think the better alternative is to make the user-called names generic, and have the interface specify two specific interfaces, one for 32-bit and one for 64-bit. Both specifics would correspond to wrapper routines; in the wrappers you would cast the integer arguments to integer(c_int) before passing them on to the underlying C MPI functions. Perhaps you would need 3 specifics if you want to cover the dreaded -r8/-i4 case as well. The advantage of the generic version is that the vendor need only supply one MPI module and one library. This simplifies the implementation and also avoids errors such as the user forgetting to include the -i8 on the link command to trigger getting the 'right' library. Cheers, Bill

Iain

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- Bill Long [email protected] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120 _______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

On Sep 3 2009, Iain Bason wrote:

...

I haven't seen the mission statement for the same reason as Malcolm, but would favour MPI using Fortran default integers whereever they make sense. Fortran's semantic specification of them is still useful in a way that C's isn't.

I believe that the idea behind using C int (or, more generally, something like a MPI_DEFAULT_INT kind) was to allow people to build a library that would work regardless of whether the application is compiled with -i8. As it stands, the MPI Fortran library has to be compiled with -i8 if the application is. If people use an explicit kind for their integers, then one library can serve applications with and without -i8.

There are, of course, other possible solutions to the problem. Is there one in particular that you favor? Or do you think the problem shouldn't be solved?

I am not sure those are meaningful questions. Let's start by saying that I am not opposed to MPI_DEFAULT_INT. That's the simplest and safest solution (if the least convenient for users), as long as it is kept well separated from C int. It is specifically the latter that is such a bad idea. There are several good solutions that need no action by MPI at all; i.e. they are done entirely by the implementation. For example, many linkers allow symbols to have attributes, which are used for matching; some of them allow two symbols of the same name with different attributes to coexist even in the same executable. In others, the attributes are used to modify the names, so you are talking about (say) MPI_SEND#4 and MPI_SEND#8. But let's say that you are assuming a more primitive linker. Malcolm's proposal for generics is the clean way to do this - at least in cases where the compiler has the decency to use different values of KIND(0) when -i8 is specified and when it isn't. Building such a library would be a trifle tedious and system-specific, but not hard. Tying MPI's integers to C int doesn't actually help, anyway, as pointers can be of varying sizes, and PRECISELY the same arguments for wanting a single library apply to -m64 and -m32. Or a -r8 option to make REAL 8 bytes, which is quite common. Or even a -ascii/-unicode option for CHARACTER. Regards, Nick Maclaren.

Craig wrote:

I've been back and forth on this (as well as a few others I think). I'm currently leaning toward using default integers. Primarily because to do otherwise could potentially break countless lines of users code.

No, it won't, as long as the choice for the MPI integer kind matches C_INT, which is pretty much universal for default integer in Fortran implementations. Let me try an example. module MPI use, intrinsic :: ISO_C_BINDING integer, parameter :: MPI_INT_KIND = C_INT interface subroutine MPI_SUB (INTARG) import ! Makes the definition of MPI_INT_KIND visible here integer(MPI_INT_KIND), intent(IN) :: INTARG end subroutine MPI_SUB end module MPI User code: program test1 use MPI integer SOMEVAR1 call MPI_SUB (SOMEVAR1) end This is the "existing code" case. The compiler will have a kind for "default integer" - the number chosen for this kind value varies by implementation (usually 4 but not always) - let's say it's 4 here. For this combination of Fortran and a "companion C processor", C_INT is also 4, and thus so is MPI_INT_KIND. The declaration of SOMEVAR1 does not specify a kind, so it gets "default integer" or 4. No problem yet. Now let's say that this user has decided to compile her Fortran code with an option that changes the default integer kind to 8 (-i8 or similar). Now if the above code is compiled, there will be an error because the module, assuming it wasn't also compiled -i8, defines the argument as INTEGER(4) but SOMEVAR1 is now INTEGER(8). The user may have had a reason to use -i8 for other variables and now needs to figure out what to do. She reads the source of the MPI module, but if it just says INTEGER with no KIND value, she may be at a loss to figure out what to change. If it had been written like this: program test2 use MPI integer(MPI_INT_KIND) SOMEVAR2 call MPI_SUB (SOMEVAR2) end The call with SOMEVAR2 is ok in either case, because the explicit kind overrides the default integer kind in effect. Explicitly specifying the KIND value in the module helps documentation and encourages, but does not require, the programmer to specify the KIND value in their own code. It does no harm and does not force coding changes that wouldn't be needed otherwise. Using explicit kinds also helps make the code understandable. Regarding functions and subroutines, I think I would need a bit more background on the earlier discussion. I'll be glad to help on this and perhaps a phone call with you and Jeff would be in order when convenient. Steve Lionel Intel Developer Support Nashua, NH

Craig Rasmussen wrote:

I've fixed the wiki to better represent current thinking and cleaned up and added example code. I think we are pretty close to having most of the issues resolved. We still must come to terms with what to do with integer kinds. In the wiki, I've listed four possibilities; three of them have come up in recent discussions. I've listed them below, also see https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage

Please vote for one of the options. My personal view is that we need to open up the question to the entire MPI Forum to get reaction from a larger community (not just Fortran geeks). I'll do this at the next meeting in Portland.

I'm not convinced there is much real difference among these options.

1. Use the default integer kind. This has the least impact on existing codes. This causes problems when the size of default integers are promoted for user code and not also in the MPI library.

This is what we have today. If the vendor compiler allows two different sizes of "default integer" (via a switch like -i8), then they need to supply two different modules/interfaces, one for each default. The correct one is referenced based on the command line switch in effect. If the underlying MPI implementation requires the corresponding arguments be of the C type int, then wrappers for Fortran will be needed and the integer arguments cast to integer(c_int) before calling the underlying C routine.

2. Specify a named kind, e.g., MPI_INT_KIND. This provides the most specificity and the user will have a known way to code that will work under all circumstances. But this will cause problems for existing codes when compiler options are used that change the size of default integers.

Option 1 is recovered with the definition MPI_INT_KIND = KIND(0). Option 2 requires a name for an integer kind, but does not specify the value (such as "same as c_int"), nor does is specify that there is only one such value. In practice, you are likely back to two modules, with different values of MPI_INT_KIND. If this option explicitly required that MPI_INT_KIND be the value of the kind for integers that interoperate with the corresponding C dummy arguments [eliminating the casts in the wrappers], and hence that there be only one such value, then this option would have some teeth. It could even promote good programming. Except that vendors will probably ignore the restriction and continue to provide two modules because users do not want to fix codes that work.

3. Require the vendor to provide two interfaces, one for standard integers and one for long integers. This option works when integers are promoted and doesn't break existing codes.

This option omits the possibility that the vendor supports only one integer kind, for a 18-digit (usually 64-bit) integer. That is all that is actually required in the Fortran standard. But assuming there are two kinds supported, and they correspond to the two options for the kind of "default" integer, then this is the same as Option 1 again.

4. Specify a named kind in the Fortran interface (MPI_INT_KIND) but allow the vendor a choice as to how to address integer promotion (it would become a quality of implementation issue) if users use default integers in their codes. The vendor could provide an additional interface for promoted integers (not part of the MPI standard) or could provide a separate library to link against.

Again, I'm not really seeing the practical difference here. I see that the wiki page proposes MPI_DOUBLE_KIND. Is this intended to be the same as C_DOUBLE? Why is there no corresponding MPI_FLOAT_KIND? Both might be affected (in much the same way) by a switch like -r8. Of course, the ideal situation would be to outlaw completely the use of the -i8 and -r8 (and even worse, one and not the other) options. Perhaps this could be an MPI requirement - no program that uses MPI is allowed to use these switches. That would be an enormous step in the right direction. Cheers, Bill

-----------

I vote for number 4. I believe that a standard should provide specificity to the programmer. If the programmer uses MPI_INT_KIND, his/her program will always work even if integers are promoted or C_INT doesn't match up with default integers. Since users will have to change existing codes anyway (to use the new derived types, e.g., MPI_Comm) users can make the transition to specific kinds at this time. However, I also think the standard should also leave room for vendors to provide additional integer kinds via generics or separate compilation libraries.

-craig

On Sep 2, 2009, at 11:30 AM, Lionel, Steve wrote:

...

Craig wrote:

...

I've been back and forth on this (as well as a few others I think). I'm currently leaning toward using default integers. Primarily because to do otherwise could potentially break countless lines of users code.

No, it won't, as long as the choice for the MPI integer kind matches C_INT, which is pretty much universal for default integer in Fortran implementations.

Let me try an example.

module MPI use, intrinsic :: ISO_C_BINDING integer, parameter :: MPI_INT_KIND = C_INT

interface subroutine MPI_SUB (INTARG) import ! Makes the definition of MPI_INT_KIND visible here integer(MPI_INT_KIND), intent(IN) :: INTARG end subroutine MPI_SUB end module MPI

User code:

program test1 use MPI integer SOMEVAR1 call MPI_SUB (SOMEVAR1) end

This is the "existing code" case. The compiler will have a kind for "default integer" - the number chosen for this kind value varies by implementation (usually 4 but not always) - let's say it's 4 here. For this combination of Fortran and a "companion C processor", C_INT is also 4, and thus so is MPI_INT_KIND. The declaration of SOMEVAR1 does not specify a kind, so it gets "default integer" or 4. No problem yet.

Now let's say that this user has decided to compile her Fortran code with an option that changes the default integer kind to 8 (-i8 or similar). Now if the above code is compiled, there will be an error because the module, assuming it wasn't also compiled -i8, defines the argument as INTEGER(4) but SOMEVAR1 is now INTEGER(8). The user may have had a reason to use -i8 for other variables and now needs to figure out what to do. She reads the source of the MPI module, but if it just says INTEGER with no KIND value, she may be at a loss to figure out what to change.

If it had been written like this:

program test2 use MPI integer(MPI_INT_KIND) SOMEVAR2 call MPI_SUB (SOMEVAR2) end

The call with SOMEVAR2 is ok in either case, because the explicit kind overrides the default integer kind in effect.

Explicitly specifying the KIND value in the module helps documentation and encourages, but does not require, the programmer to specify the KIND value in their own code. It does no harm and does not force coding changes that wouldn't be needed otherwise. Using explicit kinds also helps make the code understandable.

Regarding functions and subroutines, I think I would need a bit more background on the earlier discussion. I'll be glad to help on this and perhaps a phone call with you and Jeff would be in order when convenient.

Steve Lionel Intel Developer Support Nashua, NH

_______________________________________________ mpi3-fortran mailing list [email protected] <mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

------------------------------------------------------------------------

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- Bill Long [email protected] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

N.M. Maclaren wrote:

On Sep 14 2009, Bill Long wrote:

...

Craig Rasmussen wrote:

...

Please vote for one of the options. ...

I'm not convinced there is much real difference among these options.

I agree, though for slightly different reasons.

I think that all four are a mistake, because they are conflating all MPI integers into one. I would use two names, one for integers that may scale with memory size and one where that would be overkill.

Note that the wiki page includes a proposed MPI_COUNT_KIND, which I think is the integer kind that scales with memory size. I assumed this discussion was for integer arguments other than the ones for which kind=MPI_COUNT_KIND is specified. It would help if that were clarified, especially if my assumption is wrong. I agree with Nick that an independent kind constant is needed for the size cases.

...

...

4. Specify a named kind in the Fortran interface (MPI_INT_KIND) but allow the vendor a choice as to how to address integer promotion if users use default integers in their codes. ...

Again, I'm not really seeing the practical difference here.

Why should it be promotion, anyway? What if the default integer KIND is 64-bit and MPI_INT_KIND is 32-bit?

Right. "promotion" is a poor term here. "conversion" would be better. Cheers, Bill -- Bill Long [email protected] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

I took yet another straw vote on MPI integer kind specifier today at the MPI Forum. The poll was essentially what this email group responded to earlier: 1. Maintain the status quo (default integers). 2. Use MPI_INTEGER_KIND. 3. Use generics. 4. Some reasonable combination of the above (e.g., generics option left to the MPI vendor as a quality of implementation issue). Results: 1. 10 votes 2. 0 votes 3. 0 votes 4. 0 votes (with 13 C geeks abstaining) I had a long conversation with Rolf Rabenseifner and he explained to me why maintaining the status quo is the correct response. I'll try to summarize: 1. Default integers are less complicated than specifying kinds and would have the least impact on user's code. 2. Default integers automatically work with whatever compiler options (including -i8) that were used to compile the MPI library. For example, there might be two mpif90 wrapper compilers, mpif90 (standard options) and mpif90_i8 (-i8 options). 3. If users explicitly specify the kind with MPI_INTEGER_KIND, it would be meaningless if the wrapper compiler is used, as MPI_INTEGER_KIND is always the kind of a default integer. 4. Suppose a user specifies MPI_INTEGER_KIND, uses the mpif90 wrapper compiler and specifies the -i8 option directly (rather than using mpif90_i8). This will produce incorrect results as the MPI_INTEGER datatype in MPI_Send (for example) would no longer be correct. Perhaps MPI_INTEGER4 and MPI_INTEGER8 could be used for a datatype but things start to get complicated in a hurry. Using the version of the wrapper compiler you want, combined with default integers seems a much simpler and error prone solution. 5. Use of generics doesn't seem to help. The generics would apply to integer parameters like tag, dest, ... but not to the datatype. Since the different wrapper compilers would have to used anyway, using generics only pollutes the interface without any real benefit. So given the vote of the MPI Forum, given that they have the only votes that count (and unless feedback from users at SuperComputing indicates otherwise) it looks like this issue is resolved in favor of the status quo. -craig

On Nov 13, 2009, at 5:27 PM, Aleksandar Donev wrote:

On Friday 13 November 2009, Craig Rasmussen wrote:

...

5. Use of generics doesn't seem to help. The generics would apply to integer parameters like tag, dest, ... but not to the datatype. Since the different wrapper compilers would have to used anyway I do not understand this one, please explain. Are you talking about MPI_Datatype and what does not apply to it? I thought the problem we were discussing were exactly the non-count integer parameters and generics cleanly resolve that problem. Aleks

Yes we were talking about the non-count integer parameters in the context of how it might be used to simplify things where the -i8 option is used. Outside of that, it makes no sense to change anything. Suppose I have the following code in file send.f90: integer :: dest, tag integer :: buf(100) call MPI_Send(buf, 100, MPI_INTEGER, dest, tag, MPI_COMM_WORLD) I can compile it with mpif90 and everything works fine: mpif90 send.f90 -o send But if I compile it with the -i8 switch (assuming generics) there is a problem: mpif90 -i8 send.f90 -o send The symbols 100, dest, and tag all work fine because of generic interfaces. However, my new buf array is now a different size than is specified by MPI_INTEGER. However the above code works fine if compiled with the same options as the MPI library was compiled with: mpif90_i8 send.f90 -o send or mpif90 send.f90 -o send I hope this is more clear. -craig

On Sep 14, 2009, at 2:01 PM, Bill Long wrote:

N.M. Maclaren wrote:

...

On Sep 14 2009, Bill Long wrote:

...

Craig Rasmussen wrote:

...

Please vote for one of the options. ...

I'm not convinced there is much real difference among these options. I agree, though for slightly different reasons. I think that all four are a mistake, because they are conflating all MPI integers into one. I would use two names, one for integers that may scale with memory size and one where that would be overkill.

Note that the wiki page includes a proposed MPI_COUNT_KIND, which I think is the integer kind that scales with memory size. I assumed this discussion was for integer arguments other than the ones for which kind=MPI_COUNT_KIND is specified. It would help if that were clarified, especially if my assumption is wrong. I agree with Nick that an independent kind constant is needed for the size cases.

To make this perfectly clear (I need to fix the wiki). Bill is correct. -craig

On Sep 15, 2009, at 11:40 AM, Craig Rasmussen wrote:

No intent really. It is just that the interface is not complete yet. I'm not sure there is a need for real kinds so perhaps MPI_DOUBLE_KIND should be removed. Jeff, any place for reals except in MPI users defined types?

The only C double that is passed in the MPI interface is the return value from MPI_WTICK and MPI_WTIME. -- Jeff Squyres [email protected]

Craig Rasmussen wrote:

On Sep 15, 2009, at 9:57 AM, Jeff Squyres wrote:

...

On Sep 15, 2009, at 11:40 AM, Craig Rasmussen wrote:

...

No intent really. It is just that the interface is not complete yet. I'm not sure there is a need for real kinds so perhaps MPI_DOUBLE_KIND should be removed. Jeff, any place for reals except in MPI users defined types?

The only C double that is passed in the MPI interface is the return value from MPI_WTICK and MPI_WTIME.

So let's get rid of MPI_DOUBLE_KIND. The compiler will do normal type conversion for return values so we don't really have the same issue we have with procedure arguments.

But what is the correct way to specify the result value? I believe DOUBLE PRECISION is frowned upon. I haven't been on the committee long enough to know the reason.

DOUBLE PRECISION is problematic, since the dreaded -r8 switch may turn this into a 128-bit floating point value. If the C interface explicitly says that the return value is 'double', then the Fortran interface should declare the return type as REAL(C_DOUBLE). That's the utility of having constants like C_DOUBLE in the iso_c_binding module. Cheers, Bill

-craig

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

-- Bill Long [email protected] Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc., 1340 Mendota Heights Rd., Mendota Heights, MN, 55120

On Sep 15, 2009, at 9:58 AM, Jeff Squyres wrote:

On Sep 15, 2009, at 11:40 AM, Craig Rasmussen wrote:

...

...

I think that all four are a mistake, because they are conflating all MPI integers into one. I would use two names, one for integers that may scale with memory size and one where that would be overkill.

As Jeff had replied, there will be at least two integers. One for integers that scale with memory size and others (like MPI tags) that don't.

Don't forget, too, that MPI_ADDRESS_KIND already exists (meant to be an integer type that is large enough to hold an address), as does MPI_OFFSET_KIND (for file offsets).

I'm not sure what you mean by already exists. I believe they are just used in our mpi3 test interfaces. I don't think they have been formally proposed yet. -craig

-- Jeff Squyres [email protected]

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

On Sep 15, 2009, at 10:07 AM, Jeff Squyres wrote:

On Sep 15, 2009, at 12:02 PM, Craig Rasmussen wrote:

...

...

Don't forget, too, that MPI_ADDRESS_KIND already exists (meant to be an integer type that is large enough to hold an address), as does MPI_OFFSET_KIND (for file offsets).

I'm not sure what you mean by already exists. I believe they are just used in our mpi3 test interfaces. I don't think they have been formally proposed yet.

They exist in MPI-2.2. IIRC, MPI_ADDRESS_KIND has existed since MPI-1.0; I think MPI_OFFSET_KIND was new in MPI-2.0...? I don't remember the exact history.

We'll good then, we have precedence for something like MPI_INT_KIND. -craig

On Sep 15, 2009, at 12:21 PM, N.M. Maclaren wrote:

Also, though it's not really related, and is clearly a trivially fixable oversight, MPI_ADDRESS_KIND is a pain, because it doesn't have an associated MPI type and so is not easy to transfer between processes. Teaching attributes is not simplified by that gotcha :-(

FWIW, it now exists in MPI-2.2 (although is problematic in heterogeneous scenarios): https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/18 Also, there was a major "attribute example" cleanup, especially with regards to inter-language operations: https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/55 -- Jeff Squyres [email protected]

Craig Rasmussen wrote:

Please vote for one of the options.

I don't see the option I prefer, viz all interfaces to be generic and not specific. Furthermore, that MPI_INT_KIND and default integer are both supported (if different). I guess option 4 might come closest to allowing the vendor to do that, but it's better if they are already generic to start with.

However, I also think the standard should also leave room for vendors to provide additional integer kinds via generics or separate compilation libraries

If MPI says they are (specific) procedures, then that does make a limitation. Why would anyone want to pass one of these as an actual argument anyway? That's the only "benefit" from them being specific procedures. Bill Long wrote:

Of course, the ideal situation would be to outlaw completely the use of the -i8 and -r8 (and even worse, one and not the other) options. Perhaps this could be an MPI requirement - no program that uses MPI is allowed to use these switches. That would be an enormous step in the right direction.

Use of -i8 without -r8 and vice versa are already prohibited by the Fortran standard, where it says that default integer and default real take the same storage size. I don't see what saying it again in MPI gains you. Another thread:

...

...

The only C double that is passed in the MPI interface is the return value from MPI_WTICK and MPI_WTIME.

So let's get rid of MPI_DOUBLE_KIND. The compiler will do normal type conversion for return values so we don't really have the same issue we have with procedure arguments.

But what is the correct way to specify the result value? I believe DOUBLE PRECISION is frowned upon. I haven't been on the committee long enough to know the reason.

DOUBLE PRECISION is problematic, since the dreaded -r8 switch may turn this into a 128-bit floating point value.

Or the compiler might naturally consider REAL to be 64-bit and DOUBLE PRECISION to be 128-bit. The existence of such compilers is the basis for the existing of -r8/-i8/-double in other compilers the first place. So,

...

DOUBLE PRECISION is frowned upon. I haven't been on the committee long enough to know the reason.

quite simply DOUBLE PRECISION just means twice the storage, and some more precision, than default real. That's all it means. 32/64, 36/72, 48/96, 60/120 and 64/128 have all been "popular" size pairs for default real and double precision (without any special compiler options). MPI could pick REAL(C_DOUBLE from ISO_C_BINDING) as Bill suggested, though C_DOUBLE is not guaranteed to be available, or REAL(REAL64 from ISO_FORTRAN_ENV), which is more likely to be available but not necessarily, or REAL(SELECTED_REAL_KIND(12)) if what is actually wanted is 12 decimal digits of precision - virtually certain to be available, or REAL(MPI_WTIME_KIND) which actually is certain to be available. Furthermore,

...

So let's get rid of MPI_DOUBLE_KIND. The compiler will do normal type conversion for return values so we don't really have the same issue we have with procedure arguments.

So when the user wants to declare a variable to hold one of these, your suggestion is that he do REAL(KIND(MPI_WTIME(whatever arguments that has if any))) wtime1,wtime2 ? That doesn't look like an improvement. Mind you, MPI_DOUBLE doesn't sound like a convincing name for the kind either - I'd suggest MPI_WTIME_KIND myself. Or pick one of the previous suggestions, but in any case it ought to be a documented value. Cheers, -- ......................Malcolm Cohen, Nihon NAG, Tokyo.

On Wednesday 16 September 2009, Malcolm Cohen wrote:

I don't see the option I prefer, viz all interfaces to be generic and not specific. Just to clarify for me here. The generic interface seems to me to mean nothing unless you specify exactly what it must include as specifics. It can of course include a lot more if it wishes. But what is the minimum. One specific that accepts MPI_INT_KIND (which is likely to be C_INT, I gather?) for *all* integer arguments other than counts, and, if different, at least one specific where *all* arguments are are default integers. Right? This sounds reasonable to me. The user can use either and the compiler module will do the right thing (provide a wrapper if some weird flag is specified etc.). Aleks

-- Aleksandar Donev, Ph.D. Luis W. Alvarez Postdoctoral Fellow Center for Computational Sciences and Engineering (https://ccse.lbl.gov) Lawrence Berkeley National Laboratory (http://www.lbl.gov) E-mail: [email protected] Phone: (510) 486-5782 Fax: (510) 486-6900 Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720 Web: http://cims.nyu.edu/~donev/

On Thursday 17 September 2009, Malcolm Cohen wrote:

In practice, I'd expect the vendor to provide one specific with 32-bit non-count integer arguments and one with 64-bit non-count integer arguments. �As you say, that way only one module is needed and the right wrapper (or none if it can be done directly) will be called whether the user did -i8 or not.

I propose Craig update his Wiki yet again and add this option (generic) to the list. Then I vote for it (and so did Bill and Malcolm already). Best, Aleks -- Aleksandar Donev, Ph.D. Luis W. Alvarez Postdoctoral Fellow Center for Computational Sciences and Engineering (https://ccse.lbl.gov) Lawrence Berkeley National Laboratory (http://www.lbl.gov) E-mail: [email protected] Phone: (510) 486-5782 Fax: (510) 486-6900 Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720 Web: http://cims.nyu.edu/~donev/

I vote for #4. This encourages good programming practice but allows programmers the option of omitting the kind in most circumstances. The wording of choice 2 is unreasonably restrictive, I believe, unless it is suggesting that vendors may not provide generics or promotion features. Steve Lionel Intel Developer Support Nashua, NH From: [email protected] [mailto:[email protected]] On Behalf Of Craig Rasmussen Sent: Monday, September 14, 2009 1:05 PM To: MPI-3 Fortran working group Subject: [MPI3 Fortran] Straw vote on integers kinds Importance: Low I've fixed the wiki to better represent current thinking and cleaned up and added example code. I think we are pretty close to having most of the issues resolved. We still must come to terms with what to do with integer kinds. In the wiki, I've listed four possibilities; three of them have come up in recent discussions. I've listed them below, also see https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage Please vote for one of the options. My personal view is that we need to open up the question to the entire MPI Forum to get reaction from a larger community (not just Fortran geeks). I'll do this at the next meeting in Portland. 1. Use the default integer kind. This has the least impact on existing codes. This causes problems when the size of default integers are promoted for user code and not also in the MPI library. 2. Specify a named kind, e.g., MPI_INT_KIND. This provides the most specificity and the user will have a known way to code that will work under all circumstances. But this will cause problems for existing codes when compiler options are used that change the size of default integers. 3. Require the vendor to provide two interfaces, one for standard integers and one for long integers. This option works when integers are promoted and doesn't break existing codes. 4. Specify a named kind in the Fortran interface (MPI_INT_KIND) but allow the vendor a choice as to how to address integer promotion (it would become a quality of implementation issue) if users use default integers in their codes. The vendor could provide an additional interface for promoted integers (not part of the MPI standard) or could provide a separate library to link against. ----------- I vote for number 4. I believe that a standard should provide specificity to the programmer. If the programmer uses MPI_INT_KIND, his/her program will always work even if integers are promoted or C_INT doesn't match up with default integers. Since users will have to change existing codes anyway (to use the new derived types, e.g., MPI_Comm) users can make the transition to specific kinds at this time. However, I also think the standard should also leave room for vendors to provide additional integer kinds via generics or separate compilation libraries. -craig On Sep 2, 2009, at 11:30 AM, Lionel, Steve wrote: Craig wrote: I've been back and forth on this (as well as a few others I think). I'm currently leaning toward using default integers. Primarily because to do otherwise could potentially break countless lines of users code. No, it won't, as long as the choice for the MPI integer kind matches C_INT, which is pretty much universal for default integer in Fortran implementations. Let me try an example. module MPI use, intrinsic :: ISO_C_BINDING integer, parameter :: MPI_INT_KIND = C_INT interface subroutine MPI_SUB (INTARG) import ! Makes the definition of MPI_INT_KIND visible here integer(MPI_INT_KIND), intent(IN) :: INTARG end subroutine MPI_SUB end module MPI User code: program test1 use MPI integer SOMEVAR1 call MPI_SUB (SOMEVAR1) end This is the "existing code" case. The compiler will have a kind for "default integer" - the number chosen for this kind value varies by implementation (usually 4 but not always) - let's say it's 4 here. For this combination of Fortran and a "companion C processor", C_INT is also 4, and thus so is MPI_INT_KIND. The declaration of SOMEVAR1 does not specify a kind, so it gets "default integer" or 4. No problem yet. Now let's say that this user has decided to compile her Fortran code with an option that changes the default integer kind to 8 (-i8 or similar). Now if the above code is compiled, there will be an error because the module, assuming it wasn't also compiled -i8, defines the argument as INTEGER(4) but SOMEVAR1 is now INTEGER(8). The user may have had a reason to use -i8 for other variables and now needs to figure out what to do. She reads the source of the MPI module, but if it just says INTEGER with no KIND value, she may be at a loss to figure out what to change. If it had been written like this: program test2 use MPI integer(MPI_INT_KIND) SOMEVAR2 call MPI_SUB (SOMEVAR2) end The call with SOMEVAR2 is ok in either case, because the explicit kind overrides the default integer kind in effect. Explicitly specifying the KIND value in the module helps documentation and encourages, but does not require, the programmer to specify the KIND value in their own code. It does no harm and does not force coding changes that wouldn't be needed otherwise. Using explicit kinds also helps make the code understandable. Regarding functions and subroutines, I think I would need a bit more background on the earlier discussion. I'll be glad to help on this and perhaps a phone call with you and Jeff would be in order when convenient. Steve Lionel Intel Developer Support Nashua, NH _______________________________________________ mpi3-fortran mailing list [email protected]<mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

Clear vote for number 1. As Bill already mentioned, the corresponding MPI module will detect problems with the size of default integers. There is not only the MPI library, there are also other libraries. Do you expect that the user programs have an MPI_INT_KIND, BLAS_INT_KIND, LIB1_INT_KIND, LIB2_INT_KIND, ... and the application programs has to handle all these different kinds of standard (or non-standard) integers, to copy between the different kind of library integers and to manage overflows between these different kinds ? Hubert Craig Rasmussen wrote:

I've fixed the wiki to better represent current thinking and cleaned up and added example code. I think we are pretty close to having most of the issues resolved. We still must come to terms with what to do with integer kinds. In the wiki, I've listed four possibilities; three of them have come up in recent discussions. I've listed them below, also see https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/FtnWikiPage

Please vote for one of the options. My personal view is that we need to open up the question to the entire MPI Forum to get reaction from a larger community (not just Fortran geeks). I'll do this at the next meeting in Portland.

1. Use the default integer kind. This has the least impact on existing codes. This causes problems when the size of default integers are promoted for user code and not also in the MPI library. 2. Specify a named kind, e.g., MPI_INT_KIND. This provides the most specificity and the user will have a known way to code that will work under all circumstances. But this will cause problems for existing codes when compiler options are used that change the size of default integers. 3. Require the vendor to provide two interfaces, one for standard integers and one for long integers. This option works when integers are promoted and doesn't break existing codes. 4. Specify a named kind in the Fortran interface (MPI_INT_KIND) but allow the vendor a choice as to how to address integer promotion (it would become a quality of implementation issue) if users use default integers in their codes. The vendor could provide an additional interface for promoted integers (not part of the MPI standard) or could provide a separate library to link against.

-----------

I vote for number 4. I believe that a standard should provide specificity to the programmer. If the programmer uses MPI_INT_KIND, his/her program will always work even if integers are promoted or C_INT doesn't match up with default integers. Since users will have to change existing codes anyway (to use the new derived types, e.g., MPI_Comm) users can make the transition to specific kinds at this time. However, I also think the standard should also leave room for vendors to provide additional integer kinds via generics or separate compilation libraries.

-craig

On Sep 2, 2009, at 11:30 AM, Lionel, Steve wrote:

...

Craig wrote:

...

I've been back and forth on this (as well as a few others I think). I'm currently leaning toward using default integers. Primarily because to do otherwise could potentially break countless lines of users code.

No, it won't, as long as the choice for the MPI integer kind matches C_INT, which is pretty much universal for default integer in Fortran implementations.

Let me try an example.

module MPI use, intrinsic :: ISO_C_BINDING integer, parameter :: MPI_INT_KIND = C_INT

interface subroutine MPI_SUB (INTARG) import ! Makes the definition of MPI_INT_KIND visible here integer(MPI_INT_KIND), intent(IN) :: INTARG end subroutine MPI_SUB end module MPI

User code:

program test1 use MPI integer SOMEVAR1 call MPI_SUB (SOMEVAR1) end

This is the "existing code" case. The compiler will have a kind for "default integer" - the number chosen for this kind value varies by implementation (usually 4 but not always) - let's say it's 4 here. For this combination of Fortran and a "companion C processor", C_INT is also 4, and thus so is MPI_INT_KIND. The declaration of SOMEVAR1 does not specify a kind, so it gets "default integer" or 4. No problem yet.

Now let's say that this user has decided to compile her Fortran code with an option that changes the default integer kind to 8 (-i8 or similar). Now if the above code is compiled, there will be an error because the module, assuming it wasn't also compiled -i8, defines the argument as INTEGER(4) but SOMEVAR1 is now INTEGER(8). The user may have had a reason to use -i8 for other variables and now needs to figure out what to do. She reads the source of the MPI module, but if it just says INTEGER with no KIND value, she may be at a loss to figure out what to change.

If it had been written like this:

program test2 use MPI integer(MPI_INT_KIND) SOMEVAR2 call MPI_SUB (SOMEVAR2) end

The call with SOMEVAR2 is ok in either case, because the explicit kind overrides the default integer kind in effect.

Explicitly specifying the KIND value in the module helps documentation and encourages, but does not require, the programmer to specify the KIND value in their own code. It does no harm and does not force coding changes that wouldn't be needed otherwise. Using explicit kinds also helps make the code understandable.

Regarding functions and subroutines, I think I would need a bit more background on the earlier discussion. I'll be glad to help on this and perhaps a phone call with you and Jeff would be in order when convenient.

Steve Lionel Intel Developer Support Nashua, NH

_______________________________________________ mpi3-fortran mailing list [email protected] <mailto:[email protected]> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

------------------------------------------------------------------------

_______________________________________________ mpi3-fortran mailing list [email protected] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran

On Thursday 03 September 2009, Bill Long wrote:

Following discussions at the last J3 meeting, we are seriously considering changing the rules to disallow this combination of BLOCK and VOLATILE (and ASYNCHRONOUS). Since some of us were not at the meeting (and I have yet to make it to reading the papers), can you explain to us what the problem is? Thanks, Aleks

-- Aleksandar Donev, Ph.D. Luis W. Alvarez Postdoctoral Fellow Center for Computational Sciences and Engineering (https://ccse.lbl.gov) Lawrence Berkeley National Laboratory (http://www.lbl.gov) E-mail: [email protected] Phone: (510) 486-5782 Fax: (510) 486-6900 Address: MS 50A-1148, LBL, 1 Cyclotron Rd., Berkeley, CA 94720 Web: http://cims.nyu.edu/~donev/