Re: [OMPI users] possible bug exercised by mpi4py
BTW, the changes prior to r26496 failed some of the MTT test runs on
several systems. So if the current implementation is deemed not
"correct" I suspect we will need to figure out if there are changes to
the tests that need to be done.
See http://www.open-mpi.org/mtt/index.php?do_redir=2066 for some of the
failures I think are due to r26495 reduce scatter changes.
--td
On 5/25/2012 12:27 AM, George Bosilca wrote:
On May 24, 2012, at 23:48 , Dave Goodell wrote:
On May 24, 2012, at 10:34 PM CDT, George Bosilca wrote:
On May 24, 2012, at 23:18, Dave Goodell wrote:
So I take back my prior "right". Upon further inspection of the text and the
MPICH2 code I believe it to be true that the number of the elements in the recvcounts
array must be equal to the size of the LOCAL group.
This is quite illogical, but it will not be the first time the standard is
lacking some. So, if I understand you correctly, in the case of an
intercommunicator a process doesn't know how much data it has to reduce, at
least not until it receives the array of recvcounts from the remote group.
Weird!
No, it knows because of the restriction that $sum_i^n{recvcounts[i]}$ yields
the same sum in each group.
I should have read the entire paragraph of the standard … including the
rationale. Indeed, the rationale describes exactly what you mentioned.
Apparently the figure 12 on the following [MPI Forum blessed] link is supposed
to clarify any potential misunderstanding regarding the reduce_scatter. Count
how many elements are on each side of the intercommunicator ;)
george.
The way it's implemented in MPICH2, and the way that makes this make a lot more
sense to me, is that you first do intercommunicator reductions to temporary
buffers on rank 0 in each group. Then rank 0 scatters within the local group.
The way I had been thinking about it was to do a local reduction followed by an
intercomm scatter, but that isn't what the standard is saying, AFAICS.
___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Terry D. Dontje | Principal Software Engineer
Developer Tools Engineering | +1.781.442.2631
Oracle *- Performance Technologies*
95 Network Drive, Burlington, MA 01803
Email terry.don...@oracle.com
Re: [OMPI users] MPI_COMPLEX16
Jeff Squyres cisco.com> writes: > > Sorry for taking so long to respond to this. > > Patrick -- I just created https://svn.open-mpi.org/trac/ompi/ticket/3109 to track this issue. Could > you attach your patch to that ticket? > Attached to ticket 3109 : Patch for openmpi-1.6.0 Fix missing MPI_COMPLEX8 and MPI_COMPLEX16 types. Add also MPI_COMPLEX32 even this last one still turned off by configure. Note for David : if you want to backport the fix on openmpi-1.5.* ompi/op/op.c should be updated too. Patrick -- $ hg diff diff -r 922a81be964b ompi/datatype/ompi_datatype_module.c --- a/ompi/datatype/ompi_datatype_module.c Thu May 10 14:03:17 2012 + +++ b/ompi/datatype/ompi_datatype_module.c Fri May 25 08:45:26 2012 +0200 @@ -467,6 +467,21 @@ DECLARE_MPI2_COMPOSED_STRUCT_DDT( &ompi_mpi_cplex.dt, OMPI_DATATYPE_COMPLEX, "MPI_COMPLEX", float, float, OMPI_DATATYPE_MPI_FLOAT, OMPI_DATATYPE_MPI_FLOAT, OMPI_DATATYPE_FLAG_DATA_FORTRAN | OMPI_DATATYPE_FLAG_DATA_FLOAT ); +#if OMPI_HAVE_FORTRAN_COMPLEX8 +DECLARE_MPI2_COMPOSED_STRUCT_DDT( &ompi_mpi_complex8.dt, OMPI_DATATYPE_COMPLEX8, "MPI_COMPLEX8", + float, float, OMPI_DATATYPE_MPI_FLOAT, OMPI_DATATYPE_MPI_FLOAT, + OMPI_DATATYPE_FLAG_DATA_FORTRAN | OMPI_DATATYPE_FLAG_DATA_FLOAT ); +#endif /* OMPI_HAVE_FORTRAN_COMPLEX8 */ +#if OMPI_HAVE_FORTRAN_COMPLEX16 +DECLARE_MPI2_COMPOSED_STRUCT_DDT( &ompi_mpi_complex16.dt, OMPI_DATATYPE_COMPLEX16, "MPI_COMPLEX16", + double, double, OMPI_DATATYPE_MPI_DOUBLE, OMPI_DATATYPE_MPI_DOUBLE, + OMPI_DATATYPE_FLAG_DATA_FORTRAN | OMPI_DATATYPE_FLAG_DATA_FLOAT ); +#endif /* OMPI_HAVE_FORTRAN_COMPLEX16 */ +#if OMPI_HAVE_FORTRAN_COMPLEX32 +DECLARE_MPI2_COMPOSED_STRUCT_DDT( &ompi_mpi_complex32.dt, OMPI_DATATYPE_COMPLEX32, "MPI_COMPLEX32", + long double, long double, OMPI_DATATYPE_MPI_LONG_DOUBLE, OMPI_DATATYPE_MPI_LONG_DOUBLE, + OMPI_DATATYPE_FLAG_DATA_FORTRAN | OMPI_DATATYPE_FLAG_DATA_FLOAT ); +#endif /* OMPI_HAVE_FORTRAN_COMPLEX32 */ DECLARE_MPI2_COMPOSED_STRUCT_DDT( &ompi_mpi_dblcplex.dt, OMPI_DATATYPE_DOUBLE_COMPLEX, "MPI_DOUBLE_COMPLEX", double, double, OMPI_DATATYPE_MPI_DOUBLE, OMPI_DATATYPE_MPI_DOUBLE, OMPI_DATATYPE_FLAG_DATA_FORTRAN | OMPI_DATATYPE_FLAG_DATA_FLOAT );
Re: [OMPI users] possible bug exercised by mpi4py
On May 24, 2012, at 23:48 , Dave Goodell wrote:
> On May 24, 2012, at 10:34 PM CDT, George Bosilca wrote:
>
>> On May 24, 2012, at 23:18, Dave Goodell wrote:
>>
>>> So I take back my prior "right". Upon further inspection of the text and
>>> the MPICH2 code I believe it to be true that the number of the elements in
>>> the recvcounts array must be equal to the size of the LOCAL group.
>>
>> This is quite illogical, but it will not be the first time the standard is
>> lacking some. So, if I understand you correctly, in the case of an
>> intercommunicator a process doesn't know how much data it has to reduce, at
>> least not until it receives the array of recvcounts from the remote group.
>> Weird!
>
> No, it knows because of the restriction that $sum_i^n{recvcounts[i]}$ yields
> the same sum in each group.
I should have read the entire paragraph of the standard … including the
rationale. Indeed, the rationale describes exactly what you mentioned.
Apparently the figure 12 on the following [MPI Forum blessed] link is supposed
to clarify any potential misunderstanding regarding the reduce_scatter. Count
how many elements are on each side of the intercommunicator ;)
george.
> The way it's implemented in MPICH2, and the way that makes this make a lot
> more sense to me, is that you first do intercommunicator reductions to
> temporary buffers on rank 0 in each group. Then rank 0 scatters within the
> local group. The way I had been thinking about it was to do a local
> reduction followed by an intercomm scatter, but that isn't what the standard
> is saying, AFAICS.
