Le 2014-05-15 06:29, Jeff Squyres (jsquyres) a écrit :
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what they want and prefer to have everything
installed, and have OMPI auto-select at run time exactly what to use based on
the system on which it's running
We've traditionally catered to the b) crowd, and made some not-very-easy-to-use
capabilities for the a) crowd (i.e., you can manually disable each plugin you
don't want to build via configure, but the syntax is fairly laborious).
Ralph and I talked about the possibility of something analogous to "make
menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to pick
exactly what options you want/don't want. That will output a text config file that can
be fed to configure, something along the lines of
./configure --only-build-exactly-this-stuff=file-output-from-menuconfig
This idea is *very* rough; I anticipate that it will change quite a bit over
time, and it'll take us a bit of time to design and implement it.
A menu-like system is not going to be very useful at least for us, since
we script all of our installations. Scripting a menu is not very handy.
Maxime
On May 14, 2014, at 8:56 PM, Bennet Fauber <ben...@umich.edu> wrote:
I think Maxime's suggestion is sane and reasonable. Just in case
you're taking ha'penny's worth from the groundlings. I think I would
prefer not to have capability included that we won't use.
-- bennet
On Wed, May 14, 2014 at 7:43 PM, Maxime Boissonneault
<maxime.boissonnea...@calculquebec.ca> wrote:
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
_______________________________________________
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
