> On Oct 17, 2018, at 3:32 AM, Stephan Krempel wrote:
>
>
> Hi Ralph.
>
One point that remains open and is interesting for me is if I can
achieve the same with the 3.1.2 release of OpenMPI. Is it somehow
possible to configure it as there were the "--with-ompi-pmix-rte"
Hi Ralph.
> > > One point that remains open and is interesting for me is if I can
> > > achieve the same with the 3.1.2 release of OpenMPI. Is it somehow
> > > possible to configure it as there were the "--with-ompi-pmix-rte"
> > > switch from version 4.x?
> >
> > I’m afraid we didn’t backport
> On Oct 12, 2018, at 6:15 AM, Ralph H Castain wrote:
>
>> One point that remains open and is interesting for me is if I can
>> achieve the same with the 3.1.2 release of OpenMPI. Is it somehow
>> possible to configure it as there were the "--with-ompi-pmix-rte"
>> switch from version 4.x?
>
I took a look at the following:
>> A remark to pmix at this point: pmix_bfrops_base_value_load() does
>> silently not handle PMIX_DATA_ARRAY type leading to not working makros
>> PMIX_VALUE_LOAD and PMIX_INFO_LOAD with that type. I think this is
>> unlucky and took me a while to figure out why it
Hi Stephan
> On Oct 12, 2018, at 2:25 AM, Stephan Krempel wrote:
>
> Hallo Ralph,
>
>> I assume this (--with-ompi-mpix-rte) is a typo as the correct option
>> is —with-ompi-pmix-rte?
>
> You were right, this was a typo, with the correct option I now managed
> to start an MPI helloworld
Hallo Ralph,
> I assume this (--with-ompi-mpix-rte) is a typo as the correct option
> is —with-ompi-pmix-rte?
You were right, this was a typo, with the correct option I now managed
to start an MPI helloworld program using OpenMPI and our own process
manager with pmix server.
> It all looks okay
I assume this (--with-ompi-mpix-rte) is a typo as the correct option is
—with-ompi-pmix-rte?
It all looks okay to me for the client, but I wonder if you remembered to call
register_nspace and register_client on your server prior to starting the
client? If not, the connection will be dropped -
Hi Ralf,
After studying prrte a little bit, I tried something new and followed
the description here using openmpi 4:
https://pmix.org/code/building-the-pmix-reference-server/
I configured openmpi 4.0.0rc3:
../configure --enable-debug --prefix [...] --with-pmix=[...] \
--with-libevent=/usr
Hi Stephan
Thanks for the clarification - that helps a great deal. You are correct that
OMPI’s orted daemons do more than just host the PMIx server library. However,
they are only active if you launch the OMPI processes using mpirun. This is
probably the source of the trouble you are seeing.
Ralph, Gilles,
thanks for your input.
Before I answer, let me shortly explain what my general intention is.
We do have our own resource manager and process launcher that supports
different MPI implementations in different ways. I want to adapt it to
PMIx to cleanly support OpenMPI and hopefully
Even PRRTE won’t allow you to stop the orted from initializing its PMIx server.
I’m not sure I really understand your objective. Remember, PMIx is just a
library - the orted opens it and uses it to interface to its client application
procs. It makes no sense to have some other process perform
Stephan,
Have you already checked https://github.com/pmix/prrte ?
This is the PMIx Reference RunTime Environment (PPRTE), which was built
on top of orted.
Long story short, it deploys the PMIx server and then you start your MPI
app with prun
An example is available at
12 matches
Mail list logo
