I think we would be opening a real can of worms with this idea. There are environments, for example, that use PBSPro for one part of the system (e.g., IO nodes), but something else for the compute section.
Personally, I'd rather follow Howard's suggestion. On Mon, Jan 25, 2016 at 10:21 AM, Nathan Hjelm <hje...@lanl.gov> wrote: > On Mon, Jan 25, 2016 at 05:55:20PM +0000, Jeff Squyres (jsquyres) wrote: > > Hmm. I'm of split mind here. > > > > I can see what Howard is saying here -- adding complexity is usually a > bad thing. > > > > But we have gotten these problem reports multiple times over the years: > someone *thinking* that they have built with launcher support X (e.g., TM, > LSF), but then figuring out later that things aren't running as expected, > and after a bunch of work, figure out that it's because they didn't build > with support X. > > > > Gilles idea actually sounds interesting -- if the tm module detect some > of the sentinel PBS/TM env variables, emit a show_help() if we don't have > full TM support compiled in. This would actually save some users a bunch > of time and frustration. > > > > --> Keep in mind that the SLRUM launcher is different, because it's all > CLI-based (not API-based) and therefore we always build it (because we > don't have to find headers and libraries). > > > > FWIW, we do have precedent of having extra MCA params for users to turn > off warnings that they don't want to see. > > > > I guess the question here is: is there a valid use case for running in > PBS/Torque and *not* wanting to use the TM launcher? > > Once case comes to mind. In the case of Cray systems that unfortunately > run Moab/Toque we can launch using either alps or torque (Howard correct > me if I am wrong). When Sam and I originally wrote the XE support we > used alps instead of torque. I am not entirely sure what we do now. > > -Nathan > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/01/18509.php >
