<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hmmm - I think there may be something a little more subtle here. If you build your app and link it against “libpmi2”, and that library is actually the one from PMIx, then it won’t work with Slurm’s PMI2 plugin because the communication protocols are completely different.<div class=""><br class=""></div><div class="">So the fact is that if you want to use PMIx backward compatibility, you (a) need to link against either libpmix or the libpmi libraries we export (they are nothing more than symlinks to libpmix), and (b) specify --mpi=pmix on the srun cmd line.<div class=""><br class=""></div><div class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 21, 2017, at 11:44 AM, Philip Kovacs <<a href="mailto:pkdevel@yahoo.com" class="">pkdevel@yahoo.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><div style="background-color: rgb(255, 255, 255); font-family: "Helvetica Neue", Helvetica, Arial, "Lucida Grande", sans-serif; font-size: 13px;" class=""><div id="yui_3_16_0_ym19_1_1513885044325_2938" class="">OK, so slurm's libpmi2 is a functional superset of the libpmi2 provided by pmix 2.0+. That's good to know.</div><div id="yui_3_16_0_ym19_1_1513885044325_2939" class=""><br class=""></div><div id="yui_3_16_0_ym19_1_1513885044325_2940" class="">My point here is that, if you use slurm's mpi/pmi2 plugin, regardless of which libpmi2 is installed, </div><div dir="ltr" id="yui_3_16_0_ym19_1_1513885044325_2941" class="">slurm or pmix, you will always run the slurm pmi2 code since it is compiled directly into the plugin.</div> <div class="qtdSeparateBR"><br class=""><br class=""></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 13px;" class=""> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;" class=""> <div dir="ltr" class=""><font size="2" face="Arial" class=""> On Wednesday, December 20, 2017 10:47 PM, "<a href="mailto:rhc@open-mpi.org" class="">rhc@open-mpi.org</a>" <<a href="mailto:rhc@open-mpi.org" class="">rhc@open-mpi.org</a>> wrote:<br class=""></font></div> <br class=""><br class=""> <div class="y_msg_container"><div id="yiv8332649949" class=""><div class="">On Dec 20, 2017, at 6:21 PM, Philip Kovacs <<a rel="nofollow" shape="rect" class="yiv8332649949" ymailto="mailto:pkdevel@yahoo.com" target="_blank" href="mailto:pkdevel@yahoo.com">pkdevel@yahoo.com</a>> wrote:<br clear="none" class="yiv8332649949"><div class="yiv8332649949yqt6011650997" id="yiv8332649949yqt32988"><div class=""><blockquote class="yiv8332649949" type="cite"><br clear="none" class="yiv8332649949Apple-interchange-newline"><div class="yiv8332649949"><div class="yiv8332649949"><div class="yiv8332649949" style="background-color:rgb(255, 255, 255);"><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5702" style="">> -- slurm.spec: move libpmi to a separate package to solve a conflict with the<br clear="none" class="yiv8332649949" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5703"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5704" style="">> version provided by PMIx. This will require a separate change to PMIx as<br clear="none" class="yiv8332649949" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5705"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">> well.</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style=""><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">I see the intention behind this change since the pmix 2.0+ package provides libpmi/libpmi2</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">and there is a possible (installation) conflict with the Slurm implementation of those libraries. </div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">We've discussed that issue earlier.</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style=""><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">Now, suppose a user installs the pmix versions of libpmi/pmi2 with the expectation that pmi</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">calls will be forwarded to libpmix for greater speed, the so-called "backward compatibility" feature.</div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style=""><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">Shouldn't the Slurm mpi_pmi2 plugin attempt to link with libpmi2 instead of its internal </div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">implementation of pmi2? As it stands now, there won't be any forwarding of pmi2 code </div><div class="yiv8332649949" dir="ltr" id="yiv8332649949yui_3_16_0_ym19_1_1513820402811_5706" style="">to libpmix which I imagine users would expect in that scenario.</div></div></div></div></blockquote></div></div><br clear="none" class="yiv8332649949"><div class="yiv8332649949">Sadly, it isn’t quite that simple. Most of the standard PMI2 calls are covered by the backward compatibility libraries, so things like MPICH should work out-of-the-box.</div><div class="yiv8332649949"><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949">However, MVAPICH2 added a PMI2 extension call to the SLURM PMI2 library that they use and PMIx doesn’t cover (as there really isn’t an easy equivalent, and they called it PMIX_foo which causes a naming conflict), and so they would not work.</div><div class="yiv8332649949"><br clear="none" class="yiv8332649949"></div><div class="yiv8332649949"><br clear="none" class="yiv8332649949"></div></div></div><br class=""><br class=""></div> </div> </div> </div></div></div></div></blockquote></div><br class=""></div></div></body></html>