OK, I infer from your answer that, yes, the two pmix libraries (internal on
ompi, external on slurm) are cooperating to run the jobs. My inclination would
be to configure ompi to use the same external pmix 1.2 as slurm (one ring to
rule them all), but apparently some people reported problems doing this, so
I'll stick with internal one for now.
On Wednesday, August 30, 2017 9:28 PM, "[email protected]"
<[email protected]> wrote:
SLURM currently supports PMIx v1.2, which is what you’d find in the OMPI v2.x
series. As long as you stay within that OMPI release series, you should be fine
as the internal OMPI library will match what you used for SLURM. I’m afraid
that OMPI will always use its internal version unless you explicitly configure
it with the external one.
We (over in PMIx land) are getting close to releasing “cross-version” support,
which means you won’t have to worry about matching PMIx versions. I imagine
we’ll say something on this mailing list when that becomes available.
Ralph
On Aug 30, 2017, at 6:15 PM, Phil K <[email protected]> wrote:
I've got slurm running with openmpi and pmi2 and pmix are working just fine.
I notice when using pmix,
e,g, srun --mpi=mpix_v1 ..., the slurm plugin mpi_pmix.so (mpi_pmix_v1.so) is
used which is itself.linked to the pmix library I have installed on the cluster
(libpmix.so.2). My openmpi installation,however, is built using its internal
version of pmix and not the external pmix library being called whenslurm is the
manager.
Does openmpi's internal pmix code interact with the external pmix library used
by slurm when ansrun --mpi=pmix call is invoked? How about when you use the
salloc/sbatch w/mpirun style oflaunching a job? I would think that ideally I
would want to have both openmpi and slurm usingthe same pmix code, i.e.
externally linked to the same pmix library, but for unrelated reaaons,
I am forced to use openmpi with its internal pmix and libevent code.
My interest is possible versioning constraints that this may introduce.
Thanks,
Phil
