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, 2
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 f
Ken --
Can you please also apply this to the trunk?
Thanks.
On Sep 22, 2008, at 12:20 PM, mat...@osl.iu.edu wrote:
Author: matney
Date: 2008-09-22 12:20:18 EDT (Mon, 22 Sep 2008)
New Revision: 19599
URL: https://svn.open-mpi.org/trac/ompi/changeset/19599
Log:
Add #include for stdio.h to allo
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 12:35:5
I notice that Ken Matney (the committer) is not on the devel list; I
added him explicitly to the CC line.
Ken: please see below.
On Sep 22, 2008, at 12:46 PM, Ralph Castain wrote:
Whoa! We made a decision NOT to support multi-cluster apps in OMPI
over a year ago!
Please remove this from
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" wrote:
> I
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
multipl
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. How
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 first - there i
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:
https://svn.open-mpi.org/trac/ompi/w
The issue isn't with adding a string. The question is whether or not
OMPI is to support one job running across multiple clusters. We made a
conscious decision (after lengthy discussions on OMPI core and ORTE
mailing lists, plus several telecons) to not do so - we require that
the job execut
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 i
Sorry for delay - was on vacation and am now trying to work my way
back to the surface.
I'm not sure I can fix this one for two reasons:
1. In general, OMPI doesn't really care what name is used for the
node. However, the problem is that it needs to be consistent. In this
case, ORTE has al
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
pa
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 to
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 cod
16 matches
Mail list logo
