Ok
I was assuming that setting the ranks was done the same for Plist as for
the sparse groups (which calls translate_ranks)
For Plist i just forgot to add a check that the rank is not MPI_UNDEFINED,
before i do the lookup and set the rank.
I just commited the fix..
On Thu, August 16, 2007 10:53 a
George -
I think that check should be in *BOTH* the MPI layer and the group
code. The MPI layer should always be available, and the group code
should only do the check in OMPI_ENABLE_DEBUG (like it does today).
Having that check in the debug builds helped a bunch in debugging
some one-s
Can this patch be moved out of the ompi internals ? If possible it
should go in the MPI level functions somewhere. I looked into the mpi/
c/group_incl.c and we have a bunch of tests, but this particular one
is missing.
Long ago we decided to do most of the checking outside the internals
in
Mohamad,
2 process was plenty. Like I said, when running in debug mode, it tends
to 'work' since memory is initialized to \0 and we fall through. In an
optimized build, looking at the mtt results it looks like it segfaults
about 10% of the time.
But if you apply the patch I sent, it will tel
Hey Tim,
I understand what you are talking about.
Im trying to reproduce the problem. How many processes are your running
with, because with the default (4 for the group) it's passing..
Thanks,
Mohamad
On Thu, August 16, 2007 7:49 am, Tim Prins wrote:
> Sorry, I pushed the wrong button and sent
Sorry, I pushed the wrong button and sent this before it was ready
Tim Prins wrote:
Hi folks,
I am running into a problem with the ibm test 'group'. I will try to
explain what I think is going on, but I do not really understand the
group code so please forgive me if it is wrong...
The t
Hi folks,
I am running into a problem with the ibm test 'group'. I will try to
explain what I think is going on, but I do not really understand the
group code so please forgive me if it is wrong...
The test creates a group based on MPI_COMM_WORLD (group1), and a group
that has half the procs
