Please do not feel bad about reporting problems -- despite the fact
that it creates more work for us, it makes be OMPI better package.
So keep 'em coming!
Is there a way that you can share your code so that we can see what
is happening? I looked through the code for MPI_WAIT and
MPI_STARTALL and they seem to be doing the Right Things, at least in
terms of the persistent requests.
If you're getting error -105, it looks like we're not converting this
to a proper MPI error code before returning it to you (-105 ==
OMPI_ERR_REQUEST, but it should be converted to MPI_ERR_REQUEST
before it is returned). I'll poke around to see what's happening here.
On Oct 12, 2006, at 8:33 PM, Lisandro Dalcin wrote:
> I am getting errors using persistent communications (OMPI 1.1.1). I am
> trying to implement (in Python) example 2.32 from page 107 of MPI- The
> Complete Reference (V1, 2nd. edition).
> I think the problem is not in my wrappers (my script works fine with
> MPICH2). Below the two issues:
> 1 - MPI_Startall fails (returning a negative error code, -105, which
> in fact it seems to be out of range [MPI_SUCCESS...MPI_LASTCODE]).
> However, doing 'for r in reqlist: r.Start()' works.
> 2 - And then, calling MPI_Waitall (or even iterating over request
> array and calling MPI_Wait), the request seems to be deallocated (I
> get MPI_REQUEST_NULL upon return), so I cannot start them again. I
> understand this is wrong, the request handles should be marked as
> inactive, but not for deallocation.
> Please, ignore me if this was reported. I am really busy and I have
> not found the time to navigate the OMPI sources to get in touch with
> its internal, so I am always reporting problems, and never patches.
> Lisandro Dalcín
> Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC)
> Instituto de Desarrollo Tecnológico para la Industria Química (INTEC)
> Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET)
> PTLC - Güemes 3450, (3000) Santa Fe, Argentina
> Tel/Fax: +54-(0)342-451.1594
> devel mailing list
Server Virtualization Business Unit