[MPI3 Fortran] MPI-3, the Interoperability TR and choice buffers

[Bill Long]

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 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
>> 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 at cam.ac.uk
>> Tel.: +44 1223 334761 Fax: +44 1223 334679
>>
>> _______________________________________________
>> mpi3-fortran mailing list
>> mpi3-fortran at lists.mpi-forum.org
>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-fortran
> 

-- 
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