Hi, Yes, it appears that if p483:46-47 are to be interpreted literally, any implementation that does not provide all datatypes in all languages will be non-compliant with MPI-2.1. More on this below. For now, a bit of fun: Re C handle produced out of the Fortran MPI_REAL - imagine it's MPI_FLOAT. Will anything change for the MPI_Send? Probably, no. The datatype signature would be different if the struct was created directly in Fortran, but the MPI_Send would not suffer a jot. Re MPI_Fint, C++ defines to many C++ entities that have C equivalents, like MPI::REAL, MPI::SEEK_SET, etc. Why should the user rely on MPI_Fint then? More generally, where is the boundary between the C++ and C interfaces, or, how much of C++ should really look like C++? So far I was pulling your let a little. Now it's getting serious. There are four things to consider: 1) Language independent datatype definition - say, MPI_INTEGER (see p27:13). 2) Language binding for the datatype handle representing 1) in actual programs - say, C MPI_Datatype MPI_INTEGER, C++ MPI::INTEGER, and Fortran INTEGER MPI_INTEGER. 3) Internal representation of the MPI datatype inside the MPI library referenced by 1) and 2). 4) Actual format of the data in memory defined by the language and platform, and referenced by 1), 2), and 3). Note that distinction between 1) and 2) sort of justifies existence of so specifically C++ binding MPI::INTEGER for otherwise mundane entities in C and Fortran. The argument for MPI::Fint arises from this observation: if we started to do things C++ way, let's stick to this. And what I was talking about re example in p483 was basically a play between 2) and 4): what is different for the user may actually be the same thing for the platform, in this case - typically a machine word interpreted as a real value. See p. 490 for an acknowledgement of this fact (about nonportable possibility to receive MPI_INTEGER as an MPI_INT). Finally, at the moment a part of the standard (see pp. 27-28) does not seem to differentiate clearly between 1) and 2), while another part (see pp. 483-484) talks about making 1) available in all languages thru 2), and Appendix (pp 494-495) serves as the only definition of the datatype equivalence. This, in addition to practical aspects mentioned in earlier messages, is probably why so many implementations are noncompliant with MPI-2.1. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Jeff Squyres Sent: Friday, October 24, 2008 9:13 PM To: MPI 2.2 Subject: Re: [Mpi-22] Should all constants/types beavailablein all languagebindings? On Oct 24, 2008, at 2:03 PM, Supalov, Alexander wrote:

If this requirement is to be interpreted literally, then yes, the standard must define all datatypes in all languages. However, the example following this statement shows how an MPI_REAL is transformed into an equivalent C data type. Whether or not this is indeed MPI_REAL is not clear. It may well be an MPI_FLOAT.

I'm not sure what you mean -- Example 16.16 shows making a combined datatype with 1 C int and the 5 Fortran REALs. The C code never tries to use the values in the R array; it just MPI_SEND's them. Using the MPI_REAL type passed up from Fortran is the right thing to do here (vs. using MPI_FLOAT). Alternatively, if the C code knew that the buffer was 5 reals, it wouldn't need to have a type passed in from Fortran -- just the buffer. Then it could TYPE_CREATE_STRUCT with MPI_INT and MPI_REAL and send using the resulting datatype. That's exactly why the datatypes are supposed to be defined in all languages, right? Not for dereferencing, but for sending/receiving data that originally came from another language. The way I read Hubert's text (p483:46-47), none of us are 2.1 compliant because we don't offer *all* the datatypes in all languages. Right?

By the way, this example shows that MPI::Fint may be necessary: MPI_Fint is used here to pass Fortran datatype thru the C function boundary. Imagine a C++ function. There was a ticket #4 calling for removal of the MPI::Fint until it was redefined.

Why not use MPI_Fint? -- Jeff Squyres Cisco Systems _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- 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.