Jim,
so OpenMPI will not be updated before the MPI standard is updated.
as George pointed, you can simply :
mpirun --mca mpi_param_check 0 ...
in order to disable MPI parameter checks, and that is enough to get your
program working as is.
Cheers,
Gilles
On 1/15/2016 12:33 PM, George Bosilca wrote:
On Thu, Jan 14, 2016 at 7:49 PM, Jeff Hammond <jeff.scie...@gmail.com
<mailto:jeff.scie...@gmail.com>> wrote:
On Thu, Jan 14, 2016 at 3:05 PM, George Bosilca
<bosi...@icl.utk.edu <mailto:bosi...@icl.utk.edu>> wrote:
On Jan 13, 2016, at 19:57 , Jim Edwards <jedwa...@ucar.edu
<mailto:jedwa...@ucar.edu>> wrote:
George and all.
Back to OpenMPI, now the question is :
“Is OpenMPI going to be updated (and when) in order to
support an intuitive and user friendly feature, that is
currently explicitly prohibited by the MPI 3.1 standard, but
that might be part of the MPI-4 standard and that we already
know is not backward compatible (*) ?
If the MPI Forum agrees to amend the standard to allow this
[currently forbidden] behavior, we will be bound to adapt.
Meanwhile, I would assume that with regard to this particular
question the MPICH implementation is far too user-friendly and
only loosely standard compliant.
The MPI standard does not require implementations to catch ANY
invalid usage errors, so MPICH compliance is in no way affected by
allowing invalid usage. The error in question is completely
innocuous and there is no value whatsoever to crashing a user
application over it.
That certainly a way of seeing it. In which case set your
mpi_param_check to zero and let's close this discussion.
If you want to hop on the standard-compliance soapbox, let's start
with MPI-2 features like MPI_THREAD_MULTIPLE and RMA ;-)
(*) fwiw, mpich already “implements" this, so backward
incompatibility would only affect tools currently working
with OpenMPI but not with mpich."
i am a pragmatic guy, so i'd rather go for it, but here is
what i am gonna do :
unless George vetoes that, i will add this topic to the
weekly call agenda, and wait for the community to make a decision
(e.g. go / no go, and milestone if needed 1.10 series ? 2.0 ?
2.1 ? master only ?)
A pragmatic user will certainly appreciate in all
circumstances to type less characters (MPI_BYTE) instead of
MPI_DATATYPE_NULL when used in combination with a statically
known count of 0.
What is the type of NULL and nullptr?
Both because of static analysis and inferring MPI datatypes from
pointer types (as done in C++ codes), I'm not sure it's a good
idea to say that null buffers have a well-defined MPI type.
I fail to see the missing link between null pointers and MPI datatype,
especially in the case you promote where you call an MPI function with
a count of zero. Moreover, as mentioned by Bill on the MPI Forum
mailing list, NULL is a valid buffer for MPI functions, even when the
count is not ZERO when paired with the right datatype.
My point in that this is a matter for the MPI Forum, all discussion
outside that context are bound to be lost.
George.
Jeff
Cheers,
George.
Cheers,
Gilles
_______________________________________________
users mailing list
us...@open-mpi.org <mailto:us...@open-mpi.org>
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2016/01/28277.php
--
Jeff Hammond
jeff.scie...@gmail.com <mailto:jeff.scie...@gmail.com>
http://jeffhammond.github.io/
_______________________________________________
users mailing list
us...@open-mpi.org <mailto:us...@open-mpi.org>
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2016/01/28278.php
_______________________________________________
users mailing list
us...@open-mpi.org
Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users
Link to this post:
http://www.open-mpi.org/community/lists/users/2016/01/28280.php
