For the scheduler issue, I would be happy with something like, if I ask
for support for X, disable support for Y, Z and W. I am assuming that
very rarely will someone use more than one scheduler.
Maxime
Le 2014-05-14 19:09, Ralph Castain a écrit :
Jeff and I have talked about this and are approaching a compromise. Still more thinking to do,
perhaps providing new configure options to "only build what I ask for" and/or a tool to
support a menu-driven selection of what to build - as opposed to today's "build everything you
don't tell me to not-build"
Tough set of compromises as it depends on the target audience. Sys admins prefer the "build
only what I say", while users (who frequently aren't that familiar with the inners of a
system) prefer the "build all" mentality.
On May 14, 2014, at 3:16 PM, Ralph Castain <r...@open-mpi.org> wrote:
Indeed, a quick review indicates that the new policy for scheduler support was
not uniformly applied. I'll update it.
To reiterate: we will only build support for a scheduler if the user
specifically requests it. We did this because we are increasingly seeing
distros include header support for various schedulers, and so just finding the
required headers isn't enough to know that the scheduler is intended for use.
So we wind up building a bunch of useless modules.
On May 14, 2014, at 3:09 PM, Ralph Castain <r...@open-mpi.org> wrote:
FWIW: I believe we no longer build the slurm support by default, though I'd
have to check to be sure. The intent is definitely not to do so.
The plan we adjusted to a while back was to *only* build support for schedulers
upon request. Can't swear that they are all correctly updated, but that was the
intent.
On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> wrote:
Here's a bit of our rational, from the README file:
Note that for many of Open MPI's --with-<foo> options, Open MPI will,
by default, search for header files and/or libraries for <foo>. If
the relevant files are found, Open MPI will built support for <foo>;
if they are not found, Open MPI will skip building support for <foo>.
However, if you specify --with-<foo> on the configure command line and
Open MPI is unable to find relevant support for <foo>, configure will
assume that it was unable to provide a feature that was specifically
requested and will abort so that a human can resolve out the issue.
In some cases, we don't need header or library files. For example, with SLURM
and LSF, our native support is actually just fork/exec'ing the SLURM/LSF
executables under the covers (e.g., as opposed to using rsh/ssh). So we can
basically *always* build them. So we do.
In general, OMPI builds support for everything that it can find on the rationale that a) we can't
know ahead of time exactly what people want, and b) most people want to just "./configure
&& make -j 32 install" and be done with it -- so build as much as possible.
On May 14, 2014, at 5:31 PM, Maxime Boissonneault
<maxime.boissonnea...@calculquebec.ca> wrote:
Hi Gus,
Oh, I know that, what I am refering to is that slurm and loadleveler support
are enabled by default, and it seems that if we're using Torque/Moab, we have
no use for slurm and loadleveler support.
My point is not that it is hard to compile it with torque support, my point is
that it is compiling support for many schedulers while I'm rather convinced
that very few sites actually use multiple schedulers at the same time.
Maxime
Le 2014-05-14 16:51, Gus Correa a écrit :
On 05/14/2014 04:25 PM, Maxime Boissonneault wrote:
Hi,
I was compiling OpenMPI 1.8.1 today and I noticed that pretty much every
single scheduler has its support enabled by default at configure (except
the one I need, which is Torque). Is there a reason for that ? Why not
have a single scheduler enabled and require to specify it at configure
time ?
Is there any reason for me to build with loadlever or slurm if we're
using torque ?
Thanks,
Maxime Boisssonneault
Hi Maxime
I haven't tried 1.8.1 yet.
However, for all previous versions of OMPI I tried, up to 1.6.5,
all it took to configure it with Torque support was to point configure
to the Torque installation directory (which is non-standard in my case):
--with-tm=/opt/torque/bla/bla
My two cents,
Gus Correa
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
---------------------------------
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Ph. D. en physique
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
_______________________________________________
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
--
---------------------------------
Maxime Boissonneault
Analyste de calcul - Calcul Québec, Université Laval
Ph. D. en physique
