[MPI3 Fortran] MPI 3 text is ready

[N.M. Maclaren]

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