Re: [OMPI devel] [OMPI svn] svn:open-mpi r19600

I think the point is that as a group, we consciously, deliberately, and painfully decided not to support multi-cluster. And as a result, we ripped out a lot of supporting code. Starting down this path again will likely result in a) re-opening all the discussions, b) re-adding a lot of

Re: [OMPI devel] [OMPI svn] svn:open-mpi r19600

Because: 1. last time we went through this, it all started with a single pebble in the pond - and I don't want to get engulfed again; and 2. if you bothered to read the email, then you would see that I pointed out this change doesn't even do what they are trying to do. The change needs

Re: [OMPI devel] [OMPI svn] svn:open-mpi r19600

Ralph, There is NO need to have this discussion again, it was painful enough last time. From my perspective I do not understand why are you making so much noise on this one. How a 4 lines change in some ALPS specific files (Cray system very specific to ORNL) can generate more than 3 A4

Re: [OMPI devel] [OMPI svn] svn:open-mpi r19600

There was a very long drawn-out discussion about this early in 2007. Rather than rehash all that, I'll try to summarize it here. It may get confusing - it helped a whole lot to be in a room with a whiteboard. There were also presentations on the subject - I believe the slides may still be

[OMPI devel] Commit access to 1.3 restricted to gatekeeper(s)

Hello All, As it became apparent this morning, it was well past the time to actually restrict commit access to the 1.3 branch. As of this afternoon, all changes to the 1.3 branch must occur via the CMR process we are all familiar with from the 1.2 branch. See:

Re: [OMPI devel] [OMPI svn] svn:open-mpi r19600

What Ken put in is what is needed for the limited multi-cluster capabilities we need, just one additional string. I don't think there is a need for any discussion of such a small change. Rich On 9/22/08 1:32 PM, "Ralph Castain" wrote: > We really should discuss that as a group

Re: [OMPI devel] proper way to shut down orted

Hmmm...well, there -used- to be a tool that was distributed with the 1.2 series for doing just that, but I don't see it in the 1.2.7 release. Not sure when or how that got dropped - probably fell through a crack. Unfortunately, minus that tool, there is no clean way to shut this down.

Re: [OMPI devel] [OMPI svn] svn:open-mpi r19600

We really should discuss that as a group first - there is quite a bit of code required to actually support multi-clusters that has been removed. Our operational model that was agreed to quite a while ago is that mpirun can -only- extend over a single "cell". You can connect/accept

Re: [OMPI devel] [OMPI svn] svn:open-mpi r19600

This check in was in error - I had not realized that the checkout was from the 1.3 branch, so we will fix this, and put these into the trunk (1.4). We are going to bring in some limited multi-cluster support - limited is the operative word. Rich On 9/22/08 12:50 PM, "Jeff Squyres"

Re: [OMPI devel] [OMPI svn] svn:open-mpi r19600

Whoa! We made a decision NOT to support multi-cluster apps in OMPI over a year ago! Please remove this from 1.3 - we should discuss if/when this would even be allowed in the trunk. Thanks Ralph On Sep 22, 2008, at 10:35 AM, mat...@osl.iu.edu wrote: Author: matney Date: 2008-09-22

[OMPI devel] proper way to shut down orted

Greetings, I have a manager/worker application. The manager is called "t2a" and the workers "w2d" I launch the manager and each worker with its own mpiexec with n=1. They connect using various calls including MPI_Open_port, MPI_Comm_accept, MPI_Comm_connect and MPI_Intercomm_merge. It works

Re: [OMPI devel] -display-map and mpi_spawn

We always output the entire map, so you'll see the parent procs as well as the child On Sep 16, 2008, at 12:52 PM, Greg Watson wrote: Hi Ralph, No I'm happy to get a map at the beginning and at every spawn. Do you send the whole map again, or only an update? Regards, Greg On Sep 11,