[Mpi-comments] Comments on MPI 3.0 draft 2

[Jeremiah Willcock]

On Thu, 23 Aug 2012, George Bosilca wrote:

>
> On Aug 18, 2012, at 20:13 , Jeremiah Willcock <jewillco at osl.iu.edu> wrote:
>
>> On page 84 line 42, "sizeof" should be inside \mathit.
>
> ?

"sizeof" appears to be in math mode, but since it's a multi-letter 
variable name, it needs to be wrapped in \mathit so that LaTeX doesn't 
think it's a multiplication.  "buf" on line 16 of that page has the same 
issue, while the version on line 14 doesn't.

>> On page 84 line 45, where does "i" come from?  Is the extent rounded to 
>> a multiple of k_i, or is the upper bound rounded (these differ when lb 
>> is not aligned)?  If extent is rounded, the +eps term should be moved 
>> to the computation of extent, not ub, unless that definition of ub is 
>> used somewhere else.
>
> Which i? The type_i or k_i?

Both -- nothing ever says what "i" means.

> The upper bound is increased in such a way that the extent is a multiple 
> of the biggest k_i (to solve all alignment issues in the case multiple 
> instances of the same datatype are considered).

That's for i = 0 ... n-1, right?  That is the part that is never explained 
in the text.

>> On page 95, why does MPI_TYPE_CREATE_SUBARRAY use zero-based indexing 
>> for Fortran; I believe many other places in MPI use one-based array 
>> indices when called from Fortran, even if they use zero-based indices 
>> from C.
>
> I can't find any text that correspond to this remark.

See page 96 lines 7-9 -- why is the function defined that way (requiring 
the n-1 modification to calls) for Fortran?

>> Also, is there a version of MPI_TYPE_CREATE_SUBARRAY that allows 
>> strided indexing in the dimensions (MPI_TYPE_CREATE_DARRAY looks more 
>> limited)?
>
> One can use a carefully hand-crafted datatype to achieve this.

That is a suggestion to put on the list for the future.

>> On page 115 line 44, it seems odd that adding MPI_BOTTOM to a valid 
>> address gives a valid address, since that allows me to create a valid 
>> address MPI_BOTTOM * n + v where n is nonnegative and v is a valid 
>> address.
>
> Too late to change now. We realized this few weeks ago, and we amended 
> the example 4.18.

This seems like it would be a serious problem for implementations that 
have MPI_BOTTOM != 0; why is it too late to fix?

-- Jeremiah Willcock