It was never committed to OMPI - it became stuck in a side branch when the
developer graduated and took a job, and never came across. Given the age, I'd
suspect that side branch is way out-of-date and probably would need some
significant effort before it could be brought into the OMPI trunk,
On Apr 24, 2014, at 12:05 PM, Andreas Schäfer wrote:
> Hey,
>
> On 14:49 Thu 24 Apr , George Bosilca wrote:
>> On Thu, Apr 24, 2014 at 1:06 PM, Jeff Squyres (jsquyres)
>> wrote:
>>> The code is unused. It has been unused for a long time. It is
>>
The problem was not in the start but in the wait (hint: the status is
set in the wait). The difference I guess is r27880, which seems not to
be in the 1.8.
So, the 1.8 is not returning the correct status for persistent
inactive requests, but it does the right thing for MPI_PROC_NULL bound
George --
Any idea why it isn't failing on the v1.8 branch? The only major difference I
see between mpi/c/start.c between trunk and v1.8 is your change.
On Apr 24, 2014, at 2:08 PM, George Bosilca wrote:
> r31524 is fixing this corner case. The problem was that
Hey,
On 14:49 Thu 24 Apr , George Bosilca wrote:
> On Thu, Apr 24, 2014 at 1:06 PM, Jeff Squyres (jsquyres)
> wrote:
> > The code is unused. It has been unused for a long time. It is
> unlikely to be fixed.
We'd be using it, probably not in production, but in research
That looks good to me.
-Paul [the paranoid portability policeman]
On Thu, Apr 24, 2014 at 3:41 AM, Jeff Squyres (jsquyres) wrote:
> On Apr 23, 2014, at 6:38 PM, Paul Hargrove wrote:
>
> > -Paul [Who always does what the late W. Richard Stevens says
On Thu, Apr 24, 2014 at 1:06 PM, Jeff Squyres (jsquyres)
wrote:
> On Apr 24, 2014, at 12:54 PM, George Bosilca wrote:
>
>> There seems to be an opportunity to still have heterogeneous environment in
>> the future.
>>
r31524 is fixing this corner case. The problem was that persistent
request with MPI_RPOC_NULL were never activated, so the wait* function
was taking the if corresponding to inactive requests.
George.
On Thu, Apr 24, 2014 at 12:14 AM, Gilles Gouaillardet
wrote:
>
There seems to be an opportunity to still have heterogeneous environment in the
future.
http://www.enterprisetech.com/2014/04/23/ibm-google-show-power8-systems-openpower-efforts/
I don’t think it is fair to shift the burden on the original developer instead
of the committer who broke a feature.
Hi!
What is current status of mosix support in OpenMPI?
I have tried patches from
http://www.cs.huji.ac.il/wikis/MediaWiki/mosix/index.php/Process_migration_for_OpenMPI
but without any success, even on 1.6 branch.
With best regards,
Pavel.
Hi George,
Having looked again you're correct about the two 2buf reductions being wrong.
For now, I've updated my patch of nbc.c to copy buf1 into buf3 and then do buf3
OP= buf2 (see below).
Patching ompi_3buff_op_reduce to cope with user-defined operations is certainly
possible, but I don't
WHAT:
* Formalize well-known MCA parameters that can be used by any component to
represent external dependencies for this component.
* Component can set that well-known MCA r/o parameters to expose to the
end-users different setup related traits of the OMPI installation.
Example:
ompi_info can
Folks,
Here is attached an oversimplified version of the MPI_Recv_init_null_c
test from the
intel test suite.
the test works fine with v1.6, v1.7 and v1.8 branches but fails with the
trunk.
i wonder wether the bug is in OpenMPI or the test itself.
on one hand, we could consider there is a bug
13 matches
Mail list logo