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

Rolf Rabenseifner rabenseifner at hlrs.de
Tue Sep 28 16:18:05 CDT 2010


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

-- 
Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner at 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)



More information about the mpiwg-fortran mailing list