[Mpi-comments] Comments on MPI 3.0 draft 2

[George Bosilca]

On Aug 18, 2012, at 20:13 , Jeremiah Willcock <jewillco at osl.iu.edu> wrote:

> Chapter 4:
> 
> On page 83 line 23, "communication" should be "communications".
> 
> On page 83 line 34, "shape and size" should be "shapes and sizes".

Done.

> On page 84 line 42, "sizeof" should be inside \mathit.

?

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

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

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

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

> On page 103 line 18, MPI_ADDRESS has now been removed, not just deprecated.

Indeed.

> Is offset of a valid way to get displacements within C structs to use with MPI (rather than creating an object of that type and calling MPI_GET_ADDRESS on it and its individual fields)?

Absolutely.

> Wouldn't MPI_TYPE_SIZE and a way to "flatten" an MPI datatype into a datatype with the same primitive elements but sequential in memory (or using MPI_PACKED) be better than MPI_TYPE_TRUE_EXTENT for the example on page 108 line 29?

There are multiple ways to achieve the goal depicted in the example. MPI_Type_get_true_extent is a valid one, even if not the most optimal in terms of memory.

> On page 110 line 24, there should be a comma after "e.g.".
> 
> On page 111 line 42, there is some odd space at the end of the line.

Weird, I can't figure out how to get rid of this one. I'll investigate more.

> On page 112 line 7, there shouldn't be a space after "datatype".
> 
> On page 112 lines 11-14, should there be an MPI_TYPE_FREE added as well?

Pedantic(!).

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

> On page 128 line 32, example 4.18 uses "class" as a field name, which makes it impossible to compile with a C++ compiler.

Fixed.

  Thanks,
    george.