Sounds like a no-brainer to me (I agree). In a system of this complexity
a strong interface between MPI and the RTE layer is desirable, if for
no other reason than good software engineering. Such an abstraction
layer also increases flexibility, as it allows the RTE layer to be
a modular component
WHAT: Solicitation of feedback on the possibility of adding a runtime
services layer to Open MPI to abstract out the runtime.
WHY: To solidify the interface between OMPI and the runtime environment,
and to allow the use of different runtime systems, including different
versions of ORTE.
WHERE:
On Mon, Aug 13, 2007 at 08:04:39PM -0500, Dirk Eddelbuettel wrote:
> On 14 August 2007 at 00:08, Adrian Knoth wrote:
> | On Mon, Aug 13, 2007 at 04:26:31PM -0500, Dirk Eddelbuettel wrote:
> |
> | > > I'll now compile the 1.2.3 release tarball and see if I can reproduce
> |
> | The 1.2.3 release a
There was a problem with this particular version. Please update, and
the problem will vanish.
george.
On Aug 16, 2007, at 4:49 PM, Alexander Margolin wrote:
This question seems so simple - and yet i ask:
I tried following all the steps in the manual:
1) svn co http://svn.open-mpi.org/svn
Heh; sorry about that. This was a problem from a checkin last night
(a developer accidentally committed something that compiled/worked on
OSX but didn't compile on Linux); it's been fixed now. Do an "svn
up" and you should be ok.
On Aug 16, 2007, at 4:49 PM, Alexander Margolin wrote:
This question seems so simple - and yet i ask:
I tried following all the steps in the manual:
1) svn co http://svn.open-mpi.org/svn/ompi/trunk ompi
2) *
3) ./autogen.sh ; ./configure --prefix
4) make all install
what do I get? The following compilation error:
...
make[2]: Leaving directory `s
Jeff Squyres wrote:
On Aug 16, 2007, at 11:48 AM, Tim Prins wrote:
+#define ORTE_RML_TAG_UDAPL 25
+#define ORTE_RML_TAG_OPENIB 26
+#define ORTE_RML_TAG_MVAPI 27
I think that UDAPL, OPENIB, MVAPI should not appear anywhere in the
ORTE layer ...
Ok
I was assuming that setting the ranks was done the same for Plist as for
the sparse groups (which calls translate_ranks)
For Plist i just forgot to add a check that the rank is not MPI_UNDEFINED,
before i do the lookup and set the rank.
I just commited the fix..
On Thu, August 16, 2007 10:53 a
On Aug 16, 2007, at 11:48 AM, Tim Prins wrote:
+#define ORTE_RML_TAG_UDAPL 25
+#define ORTE_RML_TAG_OPENIB 26
+#define ORTE_RML_TAG_MVAPI 27
I think that UDAPL, OPENIB, MVAPI should not appear anywhere in the
ORTE layer ...
I tend to agree with
George -
I think that check should be in *BOTH* the MPI layer and the group
code. The MPI layer should always be available, and the group code
should only do the check in OMPI_ENABLE_DEBUG (like it does today).
Having that check in the debug builds helped a bunch in debugging
some one-s
Can this patch be moved out of the ompi internals ? If possible it
should go in the MPI level functions somewhere. I looked into the mpi/
c/group_incl.c and we have a bunch of tests, but this particular one
is missing.
Long ago we decided to do most of the checking outside the internals
in
Mohamad,
2 process was plenty. Like I said, when running in debug mode, it tends
to 'work' since memory is initialized to \0 and we fall through. In an
optimized build, looking at the mtt results it looks like it segfaults
about 10% of the time.
But if you apply the patch I sent, it will tel
George Bosilca wrote:
Was there a real reason for this commit ? Was the previous code
broken ?
I'm not aware of it ever breaking for anyone. However, it is a potential
problem if the right combination of networks are used, since multiple
btls are listening on the same tag.
It's not that I ha
Hey Tim,
I understand what you are talking about.
Im trying to reproduce the problem. How many processes are your running
with, because with the default (4 for the group) it's passing..
Thanks,
Mohamad
On Thu, August 16, 2007 7:49 am, Tim Prins wrote:
> Sorry, I pushed the wrong button and sent
Was there a real reason for this commit ? Was the previous code
broken ? It's not that I have anything against the fact that they all
have different RML tags, but I do have something against this snippet:
+#define ORTE_RML_TAG_UDAPL 25
+#define ORTE_RML_TAG_OPENIB
Sorry, I pushed the wrong button and sent this before it was ready
Tim Prins wrote:
Hi folks,
I am running into a problem with the ibm test 'group'. I will try to
explain what I think is going on, but I do not really understand the
group code so please forgive me if it is wrong...
The t
Hi folks,
I am running into a problem with the ibm test 'group'. I will try to
explain what I think is going on, but I do not really understand the
group code so please forgive me if it is wrong...
The test creates a group based on MPI_COMM_WORLD (group1), and a group
that has half the procs
17 matches
Mail list logo
