[MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers
longb at cray.com
Tue Sep 28 17:59:55 CDT 2010
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, 22.214.171.124 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
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.
> Best regards
> ----- Original Message -----
>> From: "N.M. Maclaren" <nmm1 at cam.ac.uk>
>> To: mpi3-fortran at 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 at lists.mpi-forum.org and
>> interop-tr at 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
>> 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!
>> Nick Maclaren,
>> University of Cambridge Computing Service,
>> New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
>> Email: nmm1 at cam.ac.uk
>> Tel.: +44 1223 334761 Fax: +44 1223 334679
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
Bill Long longb at 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
More information about the mpiwg-fortran