[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPI-2.1 ballot #2



Hi Rusty and Bill,

below my positive vote.

Thanks for doing this work and best regards 
Rolf


> Please sent us your votes by Friday, March 8.
> 
> _X_  I vote in favor of the changes and additions suggested below
> 
> ___  I vote against the changes and additions suggested below
> 
> ___  I would prefer a separate vote on item ___  (Please don't do this
>      lightly.)
> 
> There is already a backlog of new suggestions for clarifications that have
> been discussed in recent email.  We hope to get a ballot for those together
> shortly.
> 
> Regards,
> Rusty Lusk and Bill Gropp
> 
> ______________________________________________________________________
> 
> 1:  Add to page 36, after line 3
> 
> 3.2.11 MPI_GET_COUNT with zero-length datatypes
> 
> 
> The value returned as the count argument of
> MPI_GET_COUNT for a datatype of length zero where zero bytes
> have been transferred is zero.  If the number of bytes transfered is
> greater than zero, MPI_UNDEFINED is returned.
> 
> Rationale: 
> Zero-length datatypes may be created in a number of cases.  In MPI-2,
> an important case is MPI_TYPE_CREATE_DARRAY, where the
> definition of the particular darry results in an empty block on some
> MPI process.  Programs written in an SPMD style will not check for
> this special case and may want to use MPI_GET_COUNT to check
> the status.  
> End of Rationale: 
> 
> 
> 2:  Add to page 36, after 3.2.11 (above)
> 
> 3.2.12 MPI_GROUP_TRANSLATE_RANKS and MPI_PROC_NULL
> 
> MPI_PROC_NULL is a valid rank for input to
> MPI_GROUP_TRANSLATE_RANKS, which returns
> MPI_PROC_NULL as the translated rank.
> 
> 
> 
> 3:  Page 61, after line 36.  Add the following (paralleling the errata to
>   MPI-1.1):  
> 
> MPI_{COMM,WIN,FILE\_GET_ERRHANDLER} behave as if a 
> new error handler object is created.
> That is, once the error handler is no longer needed,
> MPI_ERRHANDLER_FREE should be called with the error handler returned
> from MPI_ERRHANDLER_GET or
> MPI_{COMM,WIN,FILE\_GET_ERRHANDLER}
> to mark the error handler for deallocation.
> This provides behavior similar to that of MPI_COMM_GROUP and
> MPI_GROUP_FREE. 
> 
> 
> 4:  On Page 78, after line 27, add:
> 
> MPI_BYTE should be used to send and receive data that is packed
> using MPI_PACK_EXTERNAL. 
> 
> Rationale: 
> MPI_PACK_EXTERNAL specifies that there is no header on the message
> and further 
> specifies the exact format of the data.  Since MPI_PACK may (and is
> allowed 
> to) use a header, the datatype MPI_PACKED cannot be used for data
> packed with 
> MPI_PACK_EXTERNAL.  
> End of Rationale: 
> 
> 
> % note, no mail discussing
> 5:  On page 93 after line 48, add
> 
> Many of the descriptions of the collective routines provide illustrations in
> terms of blocking MPI point-to-point routines.  These are intended solely to 
> indicate what data is sent or received by what process.  Many of these
> examples  
> are not correct MPI programs; for purposes of simplicity, they often
> assume infinite buffering.
> 
> 
> 
> 6:  Page 114, after line 4, add
> 
> MPI_PROC_NULL is a valid target rank in the MPI RMA calls
> MPI_ACCUMULATE, MPI_GET, and MPI_PUT.  The
> effect is the same as for MPI_PROC_NULL in MPI point-to-point
> communication. 
> 
> 
> 7:  Page 120, after line 13:
> 
> MPI_REPLACE, like the other predefined operations, is defined
> only for the predefined MPI datatypes. 
> 
> Rationale: 
> The rationale for this is that, for consistency, MPI_REPLACE
> should have the same limitations as the other operations.  Extending
> it to all datatypes doesn't provide any real benefit.
> End of Rationale: 
> 
> 
> 
> 8:  Page 162, line 48 reads
> 
> Both groups should provide the same count value.
> 
> but should read
> 
> Both groups should
> provide count and datatype arguments that specify the same type
> signature.
> 
> % no mail discussion online
> 9:  Page 199, after line 11, add:
> 
> Advice to implementors: 
> High quality implementations should raise an error when a keyval
> that was created by a call to MPI_XXX_CREATE_KEYVAL is
> used with an object of the wrong type with a call to
> MPI_YYY_GET_ATTR, MPI_YYY_SET_ATTR, MPI_YYY_DELETE_ATTR, or
> MPI_YYY_FREE_KEYVAL. To do so, it is necessary to maintain, with 
> each keyval, information on the type of the associated user
> function. 
> End of advice to implementors: 
> 
> 
> 10:  Page 221, after line 40, add
> 
> MPI_DISPLACEMENT_CURRENT is invalid unless the amode for the
> file has MPI_MODE_SEQUENTIAL set.  
> 
> 
> 
> 11:  Page 253, line 4 reads
> 
> typedef MPI::Datarep_extent_function(const MPI::Datatype& datatype,
> 
> 
> but should read
> 
> 
> typedef void MPI::Datarep_extent_function(const MPI::Datatype& datatype,
> 
> 
> 
> 12:  Page 334, line 22 read
> 
> void MPI::Win::Get(const void *origin_addr, int origin_count, const
> 
> but should read
> 
> void MPI::Win::Get(void *origin_addr, int origin_count, const
> 
> 
> 
> 13:  Page 341, line 18 reads
> 
> typedef MPI::Datarep_conversion_function(void* userbuf,
> 
> but should read
> 
> typedef void MPI::Datarep_conversion_function(void* userbuf,
> 
> 
> 
> 
> 14:  Page 341, line 22 reads
> 
> typedef MPI::Datarep_extent_function(const MPI::Datatype& Datatype,
> 
> but should read
> 
> typedef void MPI::Datarep_extent_function(const MPI::Datatype& Datatype,
> 
> 
> 
> 15:  Page 343, line 44
> 
> Remove the const from const MPI::Datatype.
> 
> 
> 
> 16:  Page 344, lines 13, 23, 32, 38, and 47
> 
> Remove the const from const MPI::Datatype.
> 
> 
> 17:  Page 345, lines 5 and 11
> 
> Remove the const from const MPI::Datatype.
> 
>  -=- MIME -=- 
> --=====================_26909103==_
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> 
> The URL is 
> http://www-unix.mcs.anl.gov/~gropp/projects/parallel/MPI/mpi-errata/index.html 
> .
> Bill
> --=====================_26909103==_
> Content-Type: text/plain; name="ballot2.txt";
>  x-mac-type="42494E41"; x-mac-creator="74747874"
> Content-Transfer-Encoding: base64
> Content-Disposition: attachment; filename="ballot2.txt"
> 
> CjE6ICBBZGQgdG8gcGFnZSAzNiwgYWZ0ZXIgbGluZSAzCgozLjIuMTEgTVBJX0dFVF9DT1VOVCB3
> aXRoIHplcm8tbGVuZ3RoIGRhdGF0eXBlcwoKClRoZSB2YWx1ZSByZXR1cm5lZCBhcyB0aGUgY291
> bnQgYXJndW1lbnQgb2YKTVBJX0dFVF9DT1VOVCBmb3IgYSBkYXRhdHlwZSBvZiBsZW5ndGggemVy
> byB3aGVyZSB6ZXJvIGJ5dGVzCmhhdmUgYmVlbiB0cmFuc2ZlcnJlZCBpcyB6ZXJvLiAgSWYgdGhl
> IG51bWJlciBvZiBieXRlcyB0cmFuc2ZlcmVkIGlzCmdyZWF0ZXIgdGhhbiB6ZXJvLCBNUElfVU5E
> RUZJTkVEIGlzIHJldHVybmVkLgoKUmF0aW9uYWxlOiAKWmVyby1sZW5ndGggZGF0YXR5cGVzIG1h
> eSBiZSBjcmVhdGVkIGluIGEgbnVtYmVyIG9mIGNhc2VzLiAgSW4gTVBJLTIsCmFuIGltcG9ydGFu
> dCBjYXNlIGlzIE1QSV9UWVBFX0NSRUFURV9EQVJSQVksIHdoZXJlIHRoZQpkZWZpbml0aW9uIG9m
> IHRoZSBwYXJ0aWN1bGFyIGRhcnJ5IHJlc3VsdHMgaW4gYW4gZW1wdHkgYmxvY2sgb24gc29tZQpN
> UEkgcHJvY2Vzcy4gIFByb2dyYW1zIHdyaXR0ZW4gaW4gYW4gU1BNRCBzdHlsZSB3aWxsIG5vdCBj
> aGVjayBmb3IKdGhpcyBzcGVjaWFsIGNhc2UgYW5kIG1heSB3YW50IHRvIHVzZSBNUElfR0VUX0NP
> VU5UIHRvIGNoZWNrCnRoZSBzdGF0dXMuICAKRW5kIG9mIFJhdGlvbmFsZTogCgoKMjogIEFkZCB0
> byBwYWdlIDM2LCBhZnRlciAzLjIuMTEgKGFib3ZlKQoKMy4yLjEyIE1QSV9HUk9VUF9UUkFOU0xB
> VEVfUkFOS1MgYW5kIE1QSV9QUk9DX05VTEwKCk1QSV9QUk9DX05VTEwgaXMgYSB2YWxpZCByYW5r
> IGZvciBpbnB1dCB0bwpNUElfR1JPVVBfVFJBTlNMQVRFX1JBTktTLCB3aGljaCByZXR1cm5zCk1Q
> SV9QUk9DX05VTEwgYXMgdGhlIHRyYW5zbGF0ZWQgcmFuay4KCgoKMzogIFBhZ2UgNjEsIGFmdGVy
> IGxpbmUgMzYuICBBZGQgdGhlIGZvbGxvd2luZyAocGFyYWxsZWxpbmcgdGhlIGVycmF0YSB0bwog
> IE1QSS0xLjEpOiAgCgpNUElfe0NPTU0sV0lOLEZJTEVcX0dFVF9FUlJIQU5ETEVSfSBiZWhhdmUg
> YXMgaWYgYSAKbmV3IGVycm9yIGhhbmRsZXIgb2JqZWN0IGlzIGNyZWF0ZWQuClRoYXQgaXMsIG9u
> Y2UgdGhlIGVycm9yIGhhbmRsZXIgaXMgbm8gbG9uZ2VyIG5lZWRlZCwKTVBJX0VSUkhBTkRMRVJf
> RlJFRSBzaG91bGQgYmUgY2FsbGVkIHdpdGggdGhlIGVycm9yIGhhbmRsZXIgcmV0dXJuZWQKZnJv
> bSBNUElfRVJSSEFORExFUl9HRVQgb3IKTVBJX3tDT01NLFdJTixGSUxFXF9HRVRfRVJSSEFORExF
> Un0KdG8gbWFyayB0aGUgZXJyb3IgaGFuZGxlciBmb3IgZGVhbGxvY2F0aW9uLgpUaGlzIHByb3Zp
> ZGVzIGJlaGF2aW9yIHNpbWlsYXIgdG8gdGhhdCBvZiBNUElfQ09NTV9HUk9VUCBhbmQKTVBJX0dS
> T1VQX0ZSRUUuIAoKCjQ6ICBPbiBQYWdlIDc4LCBhZnRlciBsaW5lIDI3LCBhZGQ6CgpNUElfQllU
> RSBzaG91bGQgYmUgdXNlZCB0byBzZW5kIGFuZCByZWNlaXZlIGRhdGEgdGhhdCBpcyBwYWNrZWQK
> dXNpbmcgTVBJX1BBQ0tfRVhURVJOQUwuIAoKUmF0aW9uYWxlOiAKTVBJX1BBQ0tfRVhURVJOQUwg
> c3BlY2lmaWVzIHRoYXQgdGhlcmUgaXMgbm8gaGVhZGVyIG9uIHRoZSBtZXNzYWdlCmFuZCBmdXJ0
> aGVyIApzcGVjaWZpZXMgdGhlIGV4YWN0IGZvcm1hdCBvZiB0aGUgZGF0YS4gIFNpbmNlIE1QSV9Q
> QUNLIG1heSAoYW5kIGlzCmFsbG93ZWQgCnRvKSB1c2UgYSBoZWFkZXIsIHRoZSBkYXRhdHlwZSBN
> UElfUEFDS0VEIGNhbm5vdCBiZSB1c2VkIGZvciBkYXRhCnBhY2tlZCB3aXRoIApNUElfUEFDS19F
> WFRFUk5BTC4gIApFbmQgb2YgUmF0aW9uYWxlOiAKCgolIG5vdGUsIG5vIG1haWwgZGlzY3Vzc2lu
> Zwo1OiAgT24gcGFnZSA5MyBhZnRlciBsaW5lIDQ4LCBhZGQKCk1hbnkgb2YgdGhlIGRlc2NyaXB0
> aW9ucyBvZiB0aGUgY29sbGVjdGl2ZSByb3V0aW5lcyBwcm92aWRlIGlsbHVzdHJhdGlvbnMgaW4K
> dGVybXMgb2YgYmxvY2tpbmcgTVBJIHBvaW50LXRvLXBvaW50IHJvdXRpbmVzLiAgVGhlc2UgYXJl
> IGludGVuZGVkIHNvbGVseSB0byAKaW5kaWNhdGUgd2hhdCBkYXRhIGlzIHNlbnQgb3IgcmVjZWl2
> ZWQgYnkgd2hhdCBwcm9jZXNzLiAgTWFueSBvZiB0aGVzZQpleGFtcGxlcyAgCmFyZSBub3QgY29y
> cmVjdCBNUEkgcHJvZ3JhbXM7IGZvciBwdXJwb3NlcyBvZiBzaW1wbGljaXR5LCB0aGV5IG9mdGVu
> CmFzc3VtZSBpbmZpbml0ZSBidWZmZXJpbmcuCgoKCjY6ICBQYWdlIDExNCwgYWZ0ZXIgbGluZSA0
> LCBhZGQKCk1QSV9QUk9DX05VTEwgaXMgYSB2YWxpZCB0YXJnZXQgcmFuayBpbiB0aGUgTVBJIFJN
> QSBjYWxscwpNUElfQUNDVU1VTEFURSwgTVBJX0dFVCwgYW5kIE1QSV9QVVQuICBUaGUKZWZmZWN0
> IGlzIHRoZSBzYW1lIGFzIGZvciBNUElfUFJPQ19OVUxMIGluIE1QSSBwb2ludC10by1wb2ludApj
> b21tdW5pY2F0aW9uLiAKCgo3OiAgUGFnZSAxMjAsIGFmdGVyIGxpbmUgMTM6CgpNUElfUkVQTEFD
> RSwgbGlrZSB0aGUgb3RoZXIgcHJlZGVmaW5lZCBvcGVyYXRpb25zLCBpcyBkZWZpbmVkCm9ubHkg
> Zm9yIHRoZSBwcmVkZWZpbmVkIE1QSSBkYXRhdHlwZXMuIAoKUmF0aW9uYWxlOiAKVGhlIHJhdGlv
> bmFsZSBmb3IgdGhpcyBpcyB0aGF0LCBmb3IgY29uc2lzdGVuY3ksIE1QSV9SRVBMQUNFCnNob3Vs
> ZCBoYXZlIHRoZSBzYW1lIGxpbWl0YXRpb25zIGFzIHRoZSBvdGhlciBvcGVyYXRpb25zLiAgRXh0
> ZW5kaW5nCml0IHRvIGFsbCBkYXRhdHlwZXMgZG9lc24ndCBwcm92aWRlIGFueSByZWFsIGJlbmVm
> aXQuCkVuZCBvZiBSYXRpb25hbGU6IAoKCgo4OiAgUGFnZSAxNjIsIGxpbmUgNDggcmVhZHMKCkJv
> dGggZ3JvdXBzIHNob3VsZCBwcm92aWRlIHRoZSBzYW1lIGNvdW50IHZhbHVlLgoKYnV0IHNob3Vs
> ZCByZWFkCgpCb3RoIGdyb3VwcyBzaG91bGQKcHJvdmlkZSBjb3VudCBhbmQgZGF0YXR5cGUgYXJn
> dW1lbnRzIHRoYXQgc3BlY2lmeSB0aGUgc2FtZSB0eXBlCnNpZ25hdHVyZS4KCiUgbm8gbWFpbCBk
> aXNjdXNzaW9uIG9ubGluZQo5OiAgUGFnZSAxOTksIGFmdGVyIGxpbmUgMTEsIGFkZDoKCkFkdmlj
> ZSB0byBpbXBsZW1lbnRvcnM6IApIaWdoIHF1YWxpdHkgaW1wbGVtZW50YXRpb25zIHNob3VsZCBy
> YWlzZSBhbiBlcnJvciB3aGVuIGEga2V5dmFsCnRoYXQgd2FzIGNyZWF0ZWQgYnkgYSBjYWxsIHRv
> IE1QSV9YWFhfQ1JFQVRFX0tFWVZBTCBpcwp1c2VkIHdpdGggYW4gb2JqZWN0IG9mIHRoZSB3cm9u
> ZyB0eXBlIHdpdGggYSBjYWxsIHRvCk1QSV9ZWVlfR0VUX0FUVFIsIE1QSV9ZWVlfU0VUX0FUVFIs
> IE1QSV9ZWVlfREVMRVRFX0FUVFIsIG9yCk1QSV9ZWVlfRlJFRV9LRVlWQUwuIFRvIGRvIHNvLCBp
> dCBpcyBuZWNlc3NhcnkgdG8gbWFpbnRhaW4sIHdpdGggCmVhY2gga2V5dmFsLCBpbmZvcm1hdGlv
> biBvbiB0aGUgdHlwZSBvZiB0aGUgYXNzb2NpYXRlZCB1c2VyCmZ1bmN0aW9uLiAKRW5kIG9mIGFk
> dmljZSB0byBpbXBsZW1lbnRvcnM6IAoKCjEwOiAgUGFnZSAyMjEsIGFmdGVyIGxpbmUgNDAsIGFk
> ZAoKTVBJX0RJU1BMQUNFTUVOVF9DVVJSRU5UIGlzIGludmFsaWQgdW5sZXNzIHRoZSBhbW9kZSBm
> b3IgdGhlCmZpbGUgaGFzIE1QSV9NT0RFX1NFUVVFTlRJQUwgc2V0LiAgCgoKCjExOiAgUGFnZSAy
> NTMsIGxpbmUgNCByZWFkcwoKdHlwZWRlZiBNUEk6OkRhdGFyZXBfZXh0ZW50X2Z1bmN0aW9uKGNv
> bnN0IE1QSTo6RGF0YXR5cGUmIGRhdGF0eXBlLAoKCmJ1dCBzaG91bGQgcmVhZAoKCnR5cGVkZWYg
> dm9pZCBNUEk6OkRhdGFyZXBfZXh0ZW50X2Z1bmN0aW9uKGNvbnN0IE1QSTo6RGF0YXR5cGUmIGRh
> dGF0eXBlLAoKCgoxMjogIFBhZ2UgMzM0LCBsaW5lIDIyIHJlYWQKCnZvaWQgTVBJOjpXaW46Okdl
> dChjb25zdCB2b2lkICpvcmlnaW5fYWRkciwgaW50IG9yaWdpbl9jb3VudCwgY29uc3QKCmJ1dCBz
> aG91bGQgcmVhZAoKdm9pZCBNUEk6Oldpbjo6R2V0KHZvaWQgKm9yaWdpbl9hZGRyLCBpbnQgb3Jp
> Z2luX2NvdW50LCBjb25zdAoKCgoxMzogIFBhZ2UgMzQxLCBsaW5lIDE4IHJlYWRzCgp0eXBlZGVm
> IE1QSTo6RGF0YXJlcF9jb252ZXJzaW9uX2Z1bmN0aW9uKHZvaWQqIHVzZXJidWYsCgpidXQgc2hv
> dWxkIHJlYWQKCnR5cGVkZWYgdm9pZCBNUEk6OkRhdGFyZXBfY29udmVyc2lvbl9mdW5jdGlvbih2
> b2lkKiB1c2VyYnVmLAoKCgoKMTQ6ICBQYWdlIDM0MSwgbGluZSAyMiByZWFkcwoKdHlwZWRlZiBN
> UEk6OkRhdGFyZXBfZXh0ZW50X2Z1bmN0aW9uKGNvbnN0IE1QSTo6RGF0YXR5cGUmIERhdGF0eXBl
> LAoKYnV0IHNob3VsZCByZWFkCgp0eXBlZGVmIHZvaWQgTVBJOjpEYXRhcmVwX2V4dGVudF9mdW5j
> dGlvbihjb25zdCBNUEk6OkRhdGF0eXBlJiBEYXRhdHlwZSwKCgoKMTU6ICBQYWdlIDM0MywgbGlu
> ZSA0NAoKUmVtb3ZlIHRoZSBjb25zdCBmcm9tIGNvbnN0IE1QSTo6RGF0YXR5cGUuCgoKCjE2OiAg
> UGFnZSAzNDQsIGxpbmVzIDEzLCAyMywgMzIsIDM4LCBhbmQgNDcKClJlbW92ZSB0aGUgY29uc3Qg
> ZnJvbSBjb25zdCBNUEk6OkRhdGF0eXBlLgoKCjE3OiAgUGFnZSAzNDUsIGxpbmVzIDUgYW5kIDEx
> CgpSZW1vdmUgdGhlIGNvbnN0IGZyb20gY29uc3QgTVBJOjpEYXRhdHlwZS4KCg==
> --=====================_26909103==_--
> 



Dr. Rolf Rabenseifner                      High Performance Computing
Parallel Computing                         Center Stuttgart    (HLRS)
Rechenzentrum Universitaet Stuttgart (RUS) Phone:    ++49 711 6855530
Allmandring 30                             FAX:      ++49 711 6787626
D-70550 Stuttgart                   rabenseifner@rus.uni-stuttgart.de
Germany                        http://www.hlrs.de/people/rabenseifner