Re: [OMPI devel] [devel-core] Open MPI v1.2.5rc1 has been posted

Argh, sorry about that... the website changes were checked into svn... but the main website wasn't svn up'ed... Open MPI v1.2.5rc1 is now there. Enjoy. On Dec 6, 2007 5:49 PM, Jeff Squyres wrote: > Tim -- > > I don't see 1.2.5rc1 posted there...? > > > > On Dec 6, 2007,

Re: [OMPI devel] === CREATE FAILURE ===

Fixed by r16884. george. On Dec 7, 2007, at 12:46 PM, MPI Team wrote: ERROR: Command returned a non-zero exist status make -j 4 distcheck Start time: Thu Dec 6 21:00:25 EST 2007 End time: Thu Dec 6 21:16:34 EST 2007 =

Re: [OMPI devel] opal_condition_wait

On Thu, Dec 06, 2007 at 09:46:45AM -0500, Tim Prins wrote: > Also, when we are using threads, there is a case where we do not > decrement the signaled count, in condition.h:84. Gleb put this in in > r9451, however the change does not make sense to me. I think that the > signal count should

Re: [OMPI devel] GROUP_EMPTY fixes break intel tests :-(

Done: r16872. On Dec 6, 2007, at 1:34 PM, Terry Dontje wrote: Jeff Squyres wrote: I should also note the following: - LAM/MPI does the same thing (increments refcount when GROUP_EMPTY is returned to the user, and allows GROUP_EMPTY in GROUP_FREE) - MPICH2 has the following comment in

Re: [OMPI devel] GROUP_EMPTY fixes break intel tests :-(

Jeff Squyres wrote: I should also note the following: - LAM/MPI does the same thing (increments refcount when GROUP_EMPTY is returned to the user, and allows GROUP_EMPTY in GROUP_FREE) - MPICH2 has the following comment in GROUP_FREE (and code to match): /* Cannot free the

Re: [OMPI devel] opal_condition_wait

On Thu, 6 Dec 2007, Tim Prins wrote: Tim Prins wrote: First, in opal_condition_wait (condition.h:97) we do not release the passed mutex if opal_using_threads() is not set. Is there a reason for this? I ask since this violates the way condition variables are supposed to work, and it seems like

Re: [OMPI devel] GROUP_EMPTY fixes break intel tests :-(

well, the best I could find is the following in section 5.2.1 "MPI_GROUP_EMPTY, which is a valid handle to an empty group, should not be confused with MPI_GROUP_NULL, which in turn is an invalid handle. The former may be used as an argument to group operations; the latter, which is returned

Re: [OMPI devel] GROUP_EMPTY fixes break intel tests :-(

I should also note the following: - LAM/MPI does the same thing (increments refcount when GROUP_EMPTY is returned to the user, and allows GROUP_EMPTY in GROUP_FREE) - MPICH2 has the following comment in GROUP_FREE (and code to match): /* Cannot free the predefined groups, but

Re: [OMPI devel] RTE Issue IV: RTE/MPI relative modex responsibilities

On 12/6/07 8:06 AM, "Shipman, Galen M." wrote: >>> >>> Do we really need a complete node map? A far as I can tell, it looks >>> like the MPI layer only needs a list of local processes. So maybe it >>> would be better to forget about the node ids at the mpi layer and just

Re: [OMPI devel] RTE Issue IV: RTE/MPI relative modex responsibilities

On 12/6/07 8:09 AM, "Shipman, Galen M." wrote: > Sorry, to be clear that should have been: > >> One option is for the RTE to just pass in an enviro variable with a >> comma-separated list of your local ranks, but that creates a problem down >> the road when trying to

Re: [OMPI devel] RTE Issue IV: RTE/MPI relative modex responsibilities

Sorry, to be clear that should have been: > One option is for the RTE to just pass in an enviro variable with a > comma-separated list of your local ranks, but that creates a problem down > the road when trying to integrate tighter with systems like SLURM where the > procs would get mass-launched

Re: [OMPI devel] RTE Issue IV: RTE/MPI relative modex responsibilities

>> >> Do we really need a complete node map? A far as I can tell, it looks >> like the MPI layer only needs a list of local processes. So maybe it >> would be better to forget about the node ids at the mpi layer and just >> return the local procs. > > I agree, though I don't think we want a

[OMPI devel] opal_condition_wait

Hi, A couple of questions. First, in opal_condition_wait (condition.h:97) we do not release the passed mutex if opal_using_threads() is not set. Is there a reason for this? I ask since this violates the way condition variables are supposed to work, and it seems like there are situations

Re: [OMPI devel] [PATCH] openib btl: remove excess ompi_btl_openib_connect_base_open call

:-) Nice catch. Please commit the fix. Pasha. Jeff Squyres wrote: Hah! Sweet; good catch -- feel free to delete that extra call. On Dec 5, 2007, at 6:42 PM, Jon Mason wrote: There is a double call to ompi_btl_openib_connect_base_open in mca_btl_openib_mca_setup_qps(). It looks like

Re: [OMPI devel] IB pow wow notes

On Dec 2, 2007, at 5:11 PM, Richard Graham wrote: One question – there is a mention a new pml that is essentially CM +matching. Why is this no just another instance of CM ? I'm not sure I understand your question -- the new proposed PML would be different than CM: it would have matching

Re: [OMPI devel] [PATCH] openib btl: remove excess ompi_btl_openib_connect_base_open call

Hah! Sweet; good catch -- feel free to delete that extra call. On Dec 5, 2007, at 6:42 PM, Jon Mason wrote: There is a double call to ompi_btl_openib_connect_base_open in mca_btl_openib_mca_setup_qps(). It looks like someone just forgot to clean-up the previous call when they added the

Re: [OMPI devel] Using MTT to test the newly added SCTP BTL

On Dec 5, 2007, at 1:42 PM, Karol Mroz wrote: Removal of .ompi_ignore should not create build problems for anyone who is running without some form of SCTP support. To test this claim, we built Open MPI with .ompi_ignore removed and no SCTP support on both an ubuntu linux and an OSX machine.