Thank you! I've filed https://svn.open-mpi.org/trac/ompi/ticket/3437 about
this.
Do you have any Open MPI v1.6-specific patches that would be useful to merge
upstream? I've looked through my email and don't see any, but I could be
missing them.
On Dec 19, 2012, at 12:50 PM, marco atzeri wro
On 12/20/2012 1:59 PM, Jeff Squyres wrote:
Thank you! I've filed https://svn.open-mpi.org/trac/ompi/ticket/3437 about
this.
Do you have any Open MPI v1.6-specific patches that would be useful to merge
upstream? I've looked through my email and don't see any, but I could be
missing them.
(taking the liberty of moving this thread to the devel list...)
On Dec 19, 2012, at 9:22 AM, Siegmar Gross wrote:
>> I think the real shortcoming is that there is no Datatype.Resized
>> function. That can be fixed.
>
> Are you sure? That would at least solve one problem.
I think so. We "own"
Many thanks, Macro!
I'll examine these in January when I return from vacation. There certainly
won't be an OMPI 1.6.x release before then, anyway.
On Dec 20, 2012, at 8:18 AM, marco atzeri wrote:
> On 12/20/2012 1:59 PM, Jeff Squyres wrote:
>> Thank you! I've filed https://svn.open-mpi.org
Hi.
I have an issue with understanding /ompi_mpi_init() /logic. Could you
please tell me if you have any guesses about following behavior.
I wonder if I understand ringh, there is a block in /ompi_mpi_init()
/function for exchanging procs information between processes (denote
this block 'mod
Absolutely it will hang as the collective object passed into any grpcomm
operation (modex or barrier) is only allowed to be used once - any attempt to
reuse it will fail.
On Dec 20, 2012, at 6:57 AM, Victor Kocheganov
wrote:
> Hi.
>
> I have an issue with understanding ompi_mpi_init() logi
Thanks for fast answer, Ralph.
In my example I use different collective objects. I mean in every mentioned
block I call *coll = OBJ_NEW(orte_grpcomm_**collective_t);*
and *OBJ_RELEASE(coll);* , so all the grpcomm operations use unique
collective object.
On Thu, Dec 20, 2012 at 7:48 PM, Ralph Ca
On Dec 20, 2012, at 8:29 AM, Victor Kocheganov
wrote:
> Thanks for fast answer, Ralph.
>
> In my example I use different collective objects. I mean in every mentioned
> block I call coll = OBJ_NEW(orte_grpcomm_collective_t);
> and OBJ_RELEASE(coll); , so all the grpcomm operations use uniq
In every 'modex' block I use coll->id = orte_process_info.peer_modex; id
and in every 'barrier' block I use coll->id = orte_process_info.peer_init_
barrier; id.
P.s. In general (as I wrote in first letter), I use 'modex' term for
following code:
coll = OBJ_NEW(orte_grpcomm_collective_t);
Yeah, that won't work. The id's cannot be reused, so you'd have to assign a
different one in each case.
On Dec 20, 2012, at 9:12 AM, Victor Kocheganov
wrote:
> In every 'modex' block I use coll->id = orte_process_info.peer_modex; id
> and in every 'barrier' block I use coll->id =
> orte_p
10 matches
Mail list logo
