[Mpi-comments] Comments on MPI 3.0 draft 2

[George Bosilca]

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

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

One is inside and the other outside a math environment. Fixed.

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

Right. We used j above so it make sense to keep referring to them as _j and not _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).
> 
> That's for i = 0 ... n-1, right?  That is the part that is never explained in the text.

It is expressed on the definition of the Typemap few lines above.

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

Answered by Rajeev.

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

After reconsideration removing the last bullet in the list should be enough.

  george.

> 
> -- Jeremiah Willcock
> _______________________________________________
> mpi-comments mailing list
> mpi-comments at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-comments