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" <[email protected]> To: [email protected] 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 [email protected] and [email protected] 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: [email protected] Tel.: +44 1223 334761 Fax: +44 1223 334679

_______________________________________________ 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./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101