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

Re: [MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers
by Bill Long 29 Sep '10

29 Sep '10

N.M. Maclaren wrote: > >> Why is the dope-vector and all behind not defined in a way that it >> can handle >> - normal (scalar) varibles (as zero-ranked) >> - multidimensional arrays and subarrays >> - ***and*** ***also*** such assumed-size arrays? > > That was my proposal. Bill's CDESC would also solve this problem, and is > probably the minimal change to the TR that would. > Possibly a similarly minimal change, though one that would require careful wording, would be to allow an assumed-size actual to correspond to an assumed-rank dummy, with the rule that the extent of the last dimension in the descriptor be set to 1 in the caller. This would require careful words about overindexing, etc. But since assumed-rank is new, there should not be backwards compatibility problems. Basically, it boils down to a discussion of how to spell the attribute. Cheers, Bill -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers
by N.M. Maclaren 29 Sep '10

29 Sep '10

>In my earlier reply, I expanded on one of Nick's ideas by proposing the >CDESC attribute for the dummy argument declaration, probably with the >restriction that it is only allowed in a BIND(C) interface. Definitely only there :-) > Since we >can define the characteristics of the C descriptor, we could, for >example, have a field that would identify the corresponding actual >argument as assumed-size, and say that if that is set then the value of >the last extent is not usable. The compiler for the Fortran caller >would be required to generate code to correctly set this flag. I don't see much of a problem. It would also be useful for scalars. >In some sense, the CDESC attribute is comparable to the VALUE attribute >in a BIND(C) interface - it specifies a particular passing semantic that >the C function will understand. If this were implemented, >'assumed-rank' would not be needed for the MPI interfaces. I didn't read your proposal in detail, and think that it is a mistake. It would be a far better idea to have an orthogonal attribute that did nothing else than pass by descriptor. That would be cleanest and most future-proof. > I think >that, from the Fortran side, that would be cleaner than allowing >assumed-rank to correspond to an assumed-size actual. There are many >details to be worked out if we go this direction. Not really. All one would have to say is that CDESC could be used only in a declaration in an interface, and not one in a procedure definition! It would then be available only for calling into C. Regards, Nick.

1 0

Re: [MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers
by N.M. Maclaren 29 Sep '10

29 Sep '10

On Sep 28 2010, Rolf Rabenseifner wrote: > >yes, you are right. >It looks like that assumed-rank does not work as we expected. I am afraid so. I won't duplicate Bill's points. >To have a maximum of backward compatibility, >we have to use "impolicit interfaces" from mpif.h as a first basis. Yes. >>From this, argument checking with a declaration > > SUBROUTINE MPI_Send(buf, ...) > !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf > !$PRAGMA IGNORE_TKR buf > INTEGER , dimension(*) :: buf A separate comment is that it would be a good idea to drop those DEC- and Sun-specific directives, as they are very confusing and unsuitable for a portable specification. >At the same time, > the MPI standard can require, that the compilation script (i.e., mpif90, > mpicc, or whatever used) must switch on compiler options that guarantee > that for skalars, arrays and contiguous subarrays call-by-reference is > used (I know that the MPI standard does not require this, but the usage > of such a compiler for MPI applications can and should require this). Not at all. Just specify BIND(C). That's there for the purpose, and is in Fortran 90. > With this, we still have copy-in-copy-out for all non-contiguous > subarrays. Yes. And potentially others. >Why is the dope-vector and all behind not defined in a way that it >can handle > - normal (scalar) varibles (as zero-ranked) > - multidimensional arrays and subarrays > - ***and*** ***also*** such assumed-size arrays? That was my proposal. Bill's CDESC would also solve this problem, and is probably the minimal change to the TR that would. >Based on the compilation-reqeirement (call-by-ref whereever possible) >for MPI programming environments, we can give the hint that >an assumed-size array can be substituted by a fixed size array >or by its first element. No. Postitively NOT! The first element hack applies ONLY when sequence association is used, and that (in this context) applies only when the called procedure is declared with BIND(C), an assumed-size array and no other new attributes. Regards, Nick.

1 0

Re: [MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers
by Bill Long 28 Sep '10

28 Sep '10

Rolf Rabenseifner wrote: > > The next step is "USE mpi_f08" with > > SUBROUTINE MPI_Send(buf, ...) > TYPE(*), dimension(..) :: buf > > Here, I understand that for assumed size dummy arguments, > it is invalid to call with an actual argument that is itself an > assumed-size arrays (i.e. from one call level above). > Actual assumed-size is not compatible with assumed-shape (or assumed-rank, allocatable, or pointer) dummy. Assumed-size actual is OK with assumed-size dummy. > Why is the dope-vector and all behind not defined in a way that it > can handle > - normal (scalar) varibles (as zero-ranked) > - multidimensional arrays and subarrays > - ***and*** ***also*** such assumed-size arrays? > The basic issue is that the dope vector includes the extents in each dimension, and the extent for the last dimension of an assumed-size array is unknown. In Fortran-Fortran calls, dope vectors are used for assumed-shape, allocatable, pointer (and proposed assumed-rank) arrays. > Are you sure that this text (Fortran 2008, 12.5.2.4 paragraph 14) > > 14 If a dummy argument is an assumed-shape array, the > rank of the actual argument shall be the same as the rank > of the dummy argument; the actual argument shall not be > an assumed-size array (including an array element > designator or an array element substring designator). > This restriction dates back 20 years, to F90. > is also valid for assumed-rank dummy arguments? > The basic issue is still that the processor does not know what to put in for the extent in the last dimension. > If you are sure, then is there a chance to still fix it in Fortran 2008? > The fix would be in the TR on enhanced interoperability, which will be the main topic of the J3 meeting in 2 weeks, and is the current topic of discussion by email for the TR participants who are not members of J3. The F2008 standard has passed its final vote and is in the publication stage. No changes will occur there. The schedule for the TR calls for us to be close to done after the upcoming meeting (i.e. have a draft ready for voting), so if there is to be a significant change, it needs to be done soon. I suspect that the MPI group is also interested in a quick resolution. In my earlier reply, I expanded on one of Nick's ideas by proposing the CDESC attribute for the dummy argument declaration, probably with the restriction that it is only allowed in a BIND(C) interface. Since we can define the characteristics of the C descriptor, we could, for example, have a field that would identify the corresponding actual argument as assumed-size, and say that if that is set then the value of the last extent is not usable. The compiler for the Fortran caller would be required to generate code to correctly set this flag. In some sense, the CDESC attribute is comparable to the VALUE attribute in a BIND(C) interface - it specifies a particular passing semantic that the C function will understand. If this were implemented, 'assumed-rank' would not be needed for the MPI interfaces . I think that, from the Fortran side, that would be cleaner than allowing assumed-rank to correspond to an assumed-size actual. There are many details to be worked out if we go this direction. > If not, the MPI Forum has to discuss, whether we can live with this problem. > > Based on the compilation-reqeirement (call-by-ref whereever possible) > for MPI programming environments, we can give the hint that > an assumed-size array can be substituted by a fixed size array > or by its first element. > The usual workaround is to supply an array section, such as x(1:n), as the actual argument, where X is an assumed-size array in the caller context. By specifying the section, you are defining a length, and the extent problem above goes away. So the corresponding dummy can be assumed-shape or assumed-rank. Cheers, Bill > Best regards > Rolf > > > ----- Original Message ----- >> From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> >> To: mpi3-fortran(a)lists.mpi-forum.org >> Sent: Sunday, September 26, 2010 2:42:33 PM >> Subject: [MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers >> I am posting this to mpi3-fortran(a)lists.mpi-forum.org and >> interop-tr(a)j3-fortran.org separately, to avoid respondents on only one >> of those getting lots of rejection messages. People on both will get >> two copies. Sorry. >> >> It attempts to describe the problems to do with changing MPI to use >> the >> proposed assumed-rank facility, why what I believe to be the current >> approach cannot be made to work, and to propose something that will. >> I may have made a fundamental error, but I don't think so. >> >> And I know that I have over-simplified the situation, but I hope that >> what I have said is more-or-less correct in the context of MPI's use >> of Fortran! >> >> >> Regards, >> Nick Maclaren, >> University of Cambridge Computing Service, >> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. >> Email: nmm1(a)cam.ac.uk >> Tel.: +44 1223 334761 Fax: +44 1223 334679 >> >> _______________________________________________ >> mpi3-fortran mailing list >> mpi3-fortran(a)lists.mpi-forum.org >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran > -- Bill Long longb(a)cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101

1 0

Re: [MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers
by Rolf Rabenseifner 28 Sep '10

28 Sep '10

Nick and all, yes, you are right. It looks like that assumed-rank does not work as we expected. To have a maximum of backward compatibility, we have to use "impolicit interfaces" from mpif.h as a first basis. >From this, argument checking with a declaration SUBROUTINE MPI_Send(buf, ...) !DEC$ ATTRIBUTES NO_ARG_CHECK :: buf !$PRAGMA IGNORE_TKR buf INTEGER , dimension(*) :: buf looks fine (I still have not checked character data as actual argument). This can be the basis for current and future "USE mpi". At the same time, the MPI standard can require, that the compilation script (i.e., mpif90, mpicc, or whatever used) must switch on compiler options that guarantee that for skalars, arrays and contiguous subarrays call-by-reference is used (I know that the MPI standard does not require this, but the usage of such a compiler for MPI applications can and should require this). With this, we still have copy-in-copy-out for all non-contiguous subarrays. The next step is "USE mpi_f08" with SUBROUTINE MPI_Send(buf, ...) TYPE(*), dimension(..) :: buf Here, I understand that for assumed size dummy arguments, it is invalid to call with an actual argument that is itself an assumed-size arrays (i.e. from one call level above). Why is the dope-vector and all behind not defined in a way that it can handle - normal (scalar) varibles (as zero-ranked) - multidimensional arrays and subarrays - ***and*** ***also*** such assumed-size arrays? Are you sure that this text (Fortran 2008, 12.5.2.4 paragraph 14) 14 If a dummy argument is an assumed-shape array, the rank of the actual argument shall be the same as the rank of the dummy argument; the actual argument shall not be an assumed-size array (including an array element designator or an array element substring designator). is also valid for assumed-rank dummy arguments? If you are sure, then is there a chance to still fix it in Fortran 2008? If not, the MPI Forum has to discuss, whether we can live with this problem. Based on the compilation-reqeirement (call-by-ref whereever possible) for MPI programming environments, we can give the hint that an assumed-size array can be substituted by a fixed size array or by its first element. Best regards Rolf ----- Original Message ----- > From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > To: mpi3-fortran(a)lists.mpi-forum.org > Sent: Sunday, September 26, 2010 2:42:33 PM > Subject: [MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers > I am posting this to mpi3-fortran(a)lists.mpi-forum.org and > interop-tr(a)j3-fortran.org separately, to avoid respondents on only one > of those getting lots of rejection messages. People on both will get > two copies. Sorry. > > It attempts to describe the problems to do with changing MPI to use > the > proposed assumed-rank facility, why what I believe to be the current > approach cannot be made to work, and to propose something that will. > I may have made a fundamental error, but I don't think so. > > And I know that I have over-simplified the situation, but I hope that > what I have said is more-or-less correct in the context of MPI's use > of Fortran! > > > Regards, > Nick Maclaren, > University of Cambridge Computing Service, > New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. > Email: nmm1(a)cam.ac.uk > Tel.: +44 1223 334761 Fax: +44 1223 334679 > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

[MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers
by N.M. Maclaren 26 Sep '10

26 Sep '10

I am posting this to mpi3-fortran(a)lists.mpi-forum.org and interop-tr(a)j3-fortran.org separately, to avoid respondents on only one of those getting lots of rejection messages. People on both will get two copies. Sorry. It attempts to describe the problems to do with changing MPI to use the proposed assumed-rank facility, why what I believe to be the current approach cannot be made to work, and to propose something that will. I may have made a fundamental error, but I don't think so. And I know that I have over-simplified the situation, but I hope that what I have said is more-or-less correct in the context of MPI's use of Fortran! Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1(a)cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679

1 0

Re: [MPI3 Fortran] MPI 3 text is ready
by N.M. Maclaren 24 Sep '10

24 Sep '10

>thank you for your example. >I have overseen, that the MPI library must not copy >contiguous subarrays. That's not the worst problem, unfortunately. >When I understand correctly, the code will fail only if > - Fred is called with a non-contiguous subarray of wrong size, or > - MPI_Scatter makes internally a copy of its buffer although > the buffer is contiguous. I am afraid not. It is also likely to fail if it is passed a contiguous array of the wrong size. Fortran BOTH permits proper bounds checking (and good compilers do it), AND permits arbitrary argument-passing mechanisms (including several forms of copy-in/copy-out). Note that this is NOT under the control of the MPI library, as it is often done by the calling code. >Let us require that MPI_Scatter must not make a internal copy >based on the data in the dope-vector if the buffer is continguous. OK. But the data have to get there first. What you may have missed is that the new mechanism requires the MPI procedure to be declared with an interface that uses an assumed-shape array for the buffer, so the calling code knows that. >Three examples of correct calls: > > CALL MPI_Comm_procs(procs,error) > CALL MPI_Comm_rank(rank,error) > >A) > IF (rank == root) THEN > CALL Fred (array(1:size*procs), size, root) > ELSE > CALL Fred (array(1:size), size, root) > ENDIF Yes. >B) > IF (rank == root) THEN > CALL Fred (array(1), size, root) > ELSE > CALL Fred (array(1), size, root) > ENDIF NO!!! That is passing a scalar to assumed-shape, which is forbidden, and wouldn't work even if it weren't. Fortran 2008 12.5.2.4 paragraph 14. >C) > size=35 > IF (rank == root) THEN > CALL Fred (array(1:17), size, root) > ELSE > CALL Fred (array(1:17), size, root) > ENDIF NO!!! That is passing an array of the wrong length. The compiler may well copy 17 elements in and out, and will set up the array descriptor to be a 1-D array of length 17. >D) > IF (rank == root) THEN > CALL Fred (array(1:7*size*procs:7), size, root) > ELSE > CALL Fred (array(1:7*size:7), size, root) > ENDIF I am not sure what you mean. If array really is 7 times as large as need, and the intent is to use every 7th element, that is correct. Otherwise, it is spectacularly wrong, and will cause overwriting. >Examples A-C also work with mpif.h and implicit interfaces >as long as the compiler makes a call-by-reference for contiguous arrays. >The array size need not to be correct. That's not the point. Examples A-C work if the MPI procedure declares the array as assumed-size and the arguments are passed by sequence association. They will NOT work if it is declared as assumed-shape (which includes using the new mechanism). >Example D also work with mpif.h as long as the array size is >really correct, i.e., not to small. Not for non-blocking transfers, it won't! It is forbidden to pass array sections to ASYNCHRONOUS assumed-size arrays, and most compilers will use copy-in/copy-out. Fortran 2008 12.5.2.4 C1239. >With the dope-vector, it should also work, although the MPI library >may copy the data, because the array size must be correct. Or convert MPI_Scatter to MPI_Scatterv. > My conclusion is still: - the new methodeworks, - but we need to > explicitly state that contiguous arrays must not be copied. > >Is this now correct? I am afraid not, and I am afraid that it's unfixable using the current approach. Sorry, but .... Also, my point was that a HUGE amount of current code will break, which I don't regard as acceptable. One of the reasons that I was hoping to see a draft specification was that I was not sure what was being proposed, and still am not. I don't find the ticket mechanism at all clear. For example, one critical question is whether the intent is to allow programmers to use both module mpi and mpi-f08 in the same program. This would solve a lot of the above problems, but brings in the issue of the same MPI procedure being defined with two different interfaces, which is a serious no-no. While generics allow that, unfortunately they don't help with this case. There are also some other potential issues that are worth checking up on, where I may have appropriate knowledge. I will try to write a paper on possibilities for array passing ASAP, but I am afraid that I can't make it to Chicago. My schedule allows it, but my organisation's travel budget just about allows me to take a day trip within the UK and I am not keen on picking up the bill myself! Regards, Nick.

1 0

Re: [MPI3 Fortran] MPI 3 text is ready
by Rolf Rabenseifner 23 Sep '10

23 Sep '10

Nick, thank you for your example. I have overseen, that the MPI library must not copy contiguous subarrays. When I understand correctly, the code will fail only if - Fred is called with a non-contiguous subarray of wrong size, or - MPI_Scatter makes internally a copy of its buffer although the buffer is contiguous. Let us require that MPI_Scatter must not make a internal copy based on the data in the dope-vector if the buffer is continguous. Three examples of correct calls: CALL MPI_Comm_procs(procs,error) CALL MPI_Comm_rank(rank,error) A) IF (rank == root) THEN CALL Fred (array(1:size*procs), size, root) ELSE CALL Fred (array(1:size), size, root) ENDIF B) IF (rank == root) THEN CALL Fred (array(1), size, root) ELSE CALL Fred (array(1), size, root) ENDIF C) size=35 IF (rank == root) THEN CALL Fred (array(1:17), size, root) ELSE CALL Fred (array(1:17), size, root) ENDIF D) IF (rank == root) THEN CALL Fred (array(1:7*size*procs:7), size, root) ELSE CALL Fred (array(1:7*size:7), size, root) ENDIF Examples A-C also work with mpif.h and implicit interfaces as long as the compiler makes a call-by-reference for contiguous arrays. The array size need not to be correct. Example D also work with mpif.h as long as the array size is really correct, i.e., not to small. With the dope-vector, it should also work, although the MPI library may copy the data, because the array size must be correct. My conclusion is still: - the new methodeworks, - but we need to explicitly state that contiguous arrays must not be copied. Is this now correct? Best regards Rolf ----- Original Message ----- > From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Thursday, September 23, 2010 11:04:01 AM > Subject: Re: [MPI3 Fortran] MPI 3 text is ready > On Sep 22 2010, Rolf Rabenseifner wrote: > > > >Nick and Craig, are these asumptions fully correct? > > The issue isn't whether the individual assumptions are correct, but > whether > they fit together with the existing usage (Fortran and MPI). > > For example, if choice buffers use that mechanism, then the following > code > will fail (and is one of the most common ways of using MPI): > > SUBROUTINE Fred (array, size, root) > INTEGER, INTENT(INOUT) :: array(*) > INTEGER, INTENT(IN) :: size, root > INTEGER :: error > CALL Scatter(array,size,MPI_INTEGER,root,MPI_COMM_WORLD,error) > END SUBROUTINE Fred > > The failure is fundamental and unfixable in the current design of the > Interop TR - I proposed an alternative that would not fail, but it was > felt to be outside the TR's scope. The fix is a source change: > > SUBROUTINE Fred (array, size, root) > INTEGER, INTENT(INOUT) :: array(*) > INTEGER, INTENT(IN) :: size, root > INTEGER :: procs, rank, error > CALL MPI_Comm_procs(rank,error) > CALL MPI_Comm_rank(rank,error) > IF (rank == root) THEN > CALL Scatter(array(:procs*size),size,MPI_INTEGER, & > root,MPI_COMM_WORLD,error) > ELSE > CALL Scatter(array(:size),size,MPI_INTEGER, & > root,MPI_COMM_WORLD,error) > END IF > END SUBROUTINE Fred > > I assert that that level of incompatibility is a major issue. > > Regards, > Nick. > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0

Re: [MPI3 Fortran] MPI 3 text is ready
by N.M. Maclaren 23 Sep '10

23 Sep '10

On Sep 22 2010, Rolf Rabenseifner wrote: > >Nick and Craig, are these asumptions fully correct? The issue isn't whether the individual assumptions are correct, but whether they fit together with the existing usage (Fortran and MPI). For example, if choice buffers use that mechanism, then the following code will fail (and is one of the most common ways of using MPI): SUBROUTINE Fred (array, size, root) INTEGER, INTENT(INOUT) :: array(*) INTEGER, INTENT(IN) :: size, root INTEGER :: error CALL Scatter(array,size,MPI_INTEGER,root,MPI_COMM_WORLD,error) END SUBROUTINE Fred The failure is fundamental and unfixable in the current design of the Interop TR - I proposed an alternative that would not fail, but it was felt to be outside the TR's scope. The fix is a source change: SUBROUTINE Fred (array, size, root) INTEGER, INTENT(INOUT) :: array(*) INTEGER, INTENT(IN) :: size, root INTEGER :: procs, rank, error CALL MPI_Comm_procs(rank,error) CALL MPI_Comm_rank(rank,error) IF (rank == root) THEN CALL Scatter(array(:procs*size),size,MPI_INTEGER, & root,MPI_COMM_WORLD,error) ELSE CALL Scatter(array(:size),size,MPI_INTEGER, & root,MPI_COMM_WORLD,error) END IF END SUBROUTINE Fred I assert that that level of incompatibility is a major issue. Regards, Nick.

1 0

Re: [MPI3 Fortran] MPI 3 text is ready
by Rolf Rabenseifner 22 Sep '10

22 Sep '10

Nick and Craig, I attached the result-slides of our discussion at the MPI Forum meeting in Stuttgart. The tickets https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/229 through 253 reflect these decisions only partially. I have to correct these tickets. This will need more time. The major ticket https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/234 (F) is already mainly correct. As far as we know, Fortran will directly pass the reference of a standardised "dope-vector" that describes the buffer. The currently in this ticket mentioned CFI_update_cdesc() is not needed. We expect: The "dope-vector" has enough information that the MPI wrappers can make a contiguous copy of the possibly non-contiguous buffer (if the actual argument is a multi-dimensional triplet-subsript). This buffer is produced and under control of MPI. Call by reference is performed by the compiler. We expect: In the case of a vector-subscript (in some dimension, i.e. Fortran rank), the Fortran compiler will generate code that copies the non-contiguous buffer into a contiguous scratch buffer and the dope-vector describes this contiguous scratch buffer. This buffer is under control of the Fortran runtime. Call by in-copy and out-copy is performed. Nick and Craig, are these asumptions fully correct? Best regard Rolf ----- Original Message ----- > From: "N.M. Maclaren" <nmm1(a)cam.ac.uk> > To: "MPI-3 Fortran working group" <mpi3-fortran(a)lists.mpi-forum.org> > Sent: Wednesday, September 22, 2010 9:10:05 PM > Subject: Re: [MPI3 Fortran] MPI 3 text is ready > On Sep 13 2010, Jeff Squyres (jsquyres) wrote: > > > > Rolf and Craig and I want to present the entirety of the MPI 3 > > fortran > > stuff to the WG this week, in preparation for presenting it to the > > forum > > in the oct meeting. If all goes well, we could have a formal first > > reading in dec. > > > > Will you all be able to attend the fortran WG meeting this week and > > give > > us first-level feedback? > > No. Where is it? I shall probably not get time to analyse it in > detail, > but I am horribly afraid that there are going to be serious problems > with > the new Fortran bindings. There are a lot of incompatible assumptions > doing the rounds in this area. Both MPI and the Fortran Interop need > as > much analysis as possible. > > Regards, > Nick. > > > _______________________________________________ > mpi3-fortran mailing list > mpi3-fortran(a)lists.mpi-forum.org > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran -- Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner(a)hlrs.de High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30)

1 0