This issue should be fixed starting from revision r20134. The patch
waits to be tested on SPARC64 before being pushed in the next 1.2 and
1.3 releases.
Thanks for the test application,
george.
On Dec 13, 2008, at 11:58 , George Bosilca wrote:
No. It fixes an issue when correctly rebuilding (i.e. with the real
displacements) the data-type on the remote side, but it didn't fix
the wrong values problem.
george.
On Dec 13, 2008, at 07:59 , Jeff Squyres wrote:
George -- you had a commit after this (r20123) -- did that fix the
problem?
On Dec 12, 2008, at 8:14 PM, George Bosilca wrote:
Dorian,
I looked into this again. So far I can confirm that the datatype
is correctly created, and always contain the correct values
(internally). If instead of one sided you use send/recv then the
output is exactly what you expect. With the one sided there are
several strange things. What I can say so far is that everything
works fine, except when the block indexed datatype is used as the
remote datatype in the MPI_Put operation. In this case the remote
memory is not modified.
george.
On Dec 12, 2008, at 08:20 , Dorian Krause wrote:
Hi again.
I adapted my testing program by overwriting the window buffer
complete with 1. This allows me to see at which places OpenMPI
writes.
The result is:
*** -DO1=1 -DV1=1 *** (displ 3,2,1,0 ,
MPI_Type_create_indexed_block)
mem[0] = { 0., 0., 0.}
mem[1] = { 0., 0., 0.}
mem[2] = { 0., 0., 0.}
mem[3] = { nan, nan, nan}
mem[4] = { nan, nan, nan}
mem[5] = { nan, nan, nan}
mem[6] = { nan, nan, nan}
mem[7] = { nan, nan, nan}
mem[8] = { nan, nan, nan}
mem[9] = { nan, nan, nan}
*** -DO1=1 -DV2=1 *** MPI_Type_contiguous(4, mpi_double3, &mpit)
mem[0] = { 0., 1., 2.}
mem[1] = { 3., 4., 5.}
mem[2] = { 6., 7., 8.}
mem[3] = { 9., 10., 11.}
mem[4] = { nan, nan, nan}
mem[5] = { nan, nan, nan}
mem[6] = { nan, nan, nan}
mem[7] = { nan, nan, nan}
mem[8] = { nan, nan, nan}
mem[9] = { nan, nan, nan}
*** -DO2=1 -DV1=1 *** (displ 0,1,2,3 ,
MPI_Type_create_indexed_block)
mem[0] = { 0., 0., 0.}
mem[1] = { 0., 0., 0.}
mem[2] = { 0., 0., 0.}
mem[3] = { 0., 0., 0.}
mem[4] = { nan, nan, nan}
mem[5] = { nan, nan, nan}
mem[6] = { nan, nan, nan}
mem[7] = { nan, nan, nan}
mem[8] = { nan, nan, nan}
mem[9] = { nan, nan, nan}
*** -DO2=1 -DV2=1 *** MPI_Type_contiguous(4, mpi_double3, &mpit)
mem[0] = { 0., 1., 2.}
mem[1] = { 3., 4., 5.}
mem[2] = { 6., 7., 8.}
mem[3] = { 9., 10., 11.}
mem[4] = { nan, nan, nan}
mem[5] = { nan, nan, nan}
mem[6] = { nan, nan, nan}
mem[7] = { nan, nan, nan}
mem[8] = { nan, nan, nan}
mem[9] = { nan, nan, nan}
Note that for the reversed ordering (3,2,1,0) only 3 lines are
written. If I use displacements 3,2,1,8
I get
*** -DO1=1 -DV1=1 ***
mem[0] = { 0., 0., 0.}
mem[1] = { 0., 0., 0.}
mem[2] = { 0., 0., 0.}
mem[3] = { nan, nan, nan}
mem[4] = { nan, nan, nan}
mem[5] = { nan, nan, nan}
mem[6] = { nan, nan, nan}
mem[7] = { nan, nan, nan}
mem[8] = { 0., 0., 0.}
mem[9] = { nan, nan, nan}
but 3,2,8,1 yields
*** -DO1=1 -DV1=1 ***
mem[0] = { 0., 0., 0.}
mem[1] = { 0., 0., 0.}
mem[2] = { 0., 0., 0.}
mem[3] = { nan, nan, nan}
mem[4] = { nan, nan, nan}
mem[5] = { nan, nan, nan}
mem[6] = { nan, nan, nan}
mem[7] = { nan, nan, nan}
mem[8] = { nan, nan, nan}
mem[9] = { nan, nan, nan}
Dorian
-Ursprüngliche Nachricht-
Von: "Dorian Krause"
Gesendet: 12.12.08 13:49:25
An: Open MPI Users
Betreff: Re: [OMPI users] Onesided + derived datatypes
Thanks George (and Brian :)).
The MPI_Put error is gone. Did you take a look at the problem
that with the block_indexed type the PUT doesn't work? I'm
still getting the following output (V1 corresponds to the datatype
created with MPI_Type_create_indexed_block while the V2 type
is created with MPI_Type_contiguous, the ordering doesn't care
anymore after
your fix) which confuses me
because I remember that (on one machine) MPI_Put with
MPI_Type_create_indexed
worked until the invalid datatype error showed up (after a
couple of timesteps).
*** -DO1=1 -DV1=1 ***
mem[0] = { 0., 0., 0.}
mem[1] = { 0., 0., 0.}
mem[2] = { 0., 0., 0.}
mem[3] = { 0., 0., 0.}
mem[4] = { 0., 0
