hi riccardo,
> I'm new to EasyBuild and I'm still trying to figure out how to use it
on our cluster. I understand that a toolchain needs to be defined before I
start compiling software. Now the questions:
1) How can I define a "ubuntu-12.04" toolchain that just uses the GCC,
OpenMPI, ATLAS, etc. provided by the standard Ubuntu packages, instead
of re-building EasyBuild's own versions? (I guess it would be the
"goalf" toolchain but build more like the "ictce" one, in that the
entire toolchain is distributed in binary form from EB's point of view.)
although in principle this can be done, usually there is no good reason
for it (eg ubuntu can update gcc or anything and you will loose control
of the dependency chain)
with the robot, it's easy to install it all at once. it might take some
time (esp atlas), and i'm not sure how smooth it will go given we mainly
test rhel/fedora, but we have others using it on ubuntu.
why do you want to use ubuntu's versions?
2) Conversely: we run a inhomogeneous cluster here, so -at the other
extreme- it would make sense to compile some programs with different
options / flags depending on the compute node architecture. Does
EasyBuild have provisions for this? In particular: can it generate
modulefiles that search different binary directories depending on the
host architecture or other features?
easybuild can use -march=native (gcc) or -xHOST (intel), so this can be
problematic.
what you will need to do is to make sure the installation path is
different for each node type (and install on all different types).
we have something similar on our clusters (they are homogenous, but
there are 7 of them now) and our install path contains the os-flavour
name and the cpu architecture, but these values are obtained through the
environment (and are set/generated in /etc/profile.d) and are picked up
in the easybuild config file
the modulepath is then set based on these values so all modules are seen
everywhere with the same names (ie user scripts can run everywhere
unmodified)
but this means we install the same software multiple times (once per
cluster)
3) Is there a versioning scheme for toolchains? Especially for the
EB-provided "goalf" and "ictce" one? In other words, if I locally
modify the "goalf" toolchain to use GCC 4.7 and use the version number
"1.2.0", do I run the risk of seeing it overwritten at the next EB
update?
yes and no. there is one, but not publicly documented atm. but kenneth
and/or jens are better placed to comment on this and they will add
documentation on the wiki. (but 1.2.0 makes sense)
stijn
Thank you very much for any answer and comment!
Cheers,
Riccardo
--
Riccardo Murri
http://www.gc3.uzh.ch/people/rm.html
Grid Computing Competence Centre
University of Zurich
Winterthurerstrasse 190, CH-8057 Zürich (Switzerland)
Tel: +41 44 635 4222
Fax: +41 44 635 6888
