Re: [easybuild] toolchain which uses existing, optimized, MPI/ScaLAPACK and build environment?

[Ole Holm Nielsen]

>
for more information on how to create your own toolchain from
existing
compilers and libraries.


Ok, I'll try to understand the details how to set up a new
toolchain and go this path. I have found the GCC-system, which
seems to lead in the right direction. Would it be feasible to
extend GCC-system to include OpenMPI-system and OpenBLAS-system in
a similar fashion?


The GCC-system easyconfig file leverages the SystemCompiler easyblock.

To also support OpenMPI-system and OpenBLAS-system, a similar
SystemLibrary easyblock should be created that forces you to specify
the required information about the system library you would like to use.

Alan's suggestion of just grabbing the module file that is generated
using "--module-only --force" and adjusting it as needed is a good
one though, it may take you a long way...




And yes, these toolchains have infiniband support.

So, it would be very nice to know what optimizations are being
done at
your company that make the internal toolchain even better
optimized, so
all EasyBuild
users could all benefit from this knowledge and potentially
millions of
CPU hours could be saved.


I will see, whether they share the details with me, or if they
even have the details. As I understood, the cluster has been set
up and is maintained by an external company. When we discussed
today using the foss stack, I only got very discouraging answers:
infiniband couldn't be configured correctly using a generic MPI
installation procedure, BLAS would be an order of magnitude slower
unless you put in the correct parameters for the specific
architecture, etc.
Nevertheless, I am currently trying to set up the HPL benchmark,
and I will compare the results with easybuild's foss toolchain and
with the cluster's 'builtin' toolchain.


I'd very interested in hearing more about this, i.e. how the
benchmark results turned out, how the existing toolchains were
configured compared to how we tackle things in EasyBuild, etc.

It's certainly possible that there was some heavy tuning done w.r.t.
configuration parameters (in particular for the MPI); the downside
of the easyconfigs we include in EasyBuild is that we need to keep
them generic enough so that they'll work out of the box.
For OpenMPI specifically, it makes a lot of sense to tweak the
corresponding easyconfig file with additional/different
system-specific configure options.



I'm really serious here, if you can share this information, we
would
love to hear it so we can incorporate, but I do understand
that this
might be proprietary information.

TL;DR:
If you can share your highly optimized toolchains with us we
will be
pleased to support them in EasyBuild if they can help us
getting faster
software runtimes!


Also thanks for the other replies! I need to gain some more
experience with EasyBuild before I can make use of all your
suggestions.


Don't hesitate to let us know if you have any questions!



regards,

Kenneth




--
Ole Holm Nielsen
PhD, Manager of IT services
Department of Physics, Technical University of Denmark

Re: [easybuild] toolchain which uses existing, optimized, MPI/ScaLAPACK and build environment?

[Ole Holm Nielsen]

Hi Gunnar,

For OmniPath networks you *must* install and use the PSM2 library.  The 
old PSM library is used for the previous product PathScale.  The vanilla 
EB files do not contain the PSM2 configurations, so you just have to add 
a line or two.


I already gave you information about how to build OpenMPI with EB by 
adding configopts for PSM2 in the OpenMPI EB file.  You need to follow 
these instructions carefully.  The OmniPath software is downloaded from 
https://downloadcenter.intel.com/search?keyword=Omni-Path


Best regards,
Ole

On 02/01/2017 11:23 AM, Gunnar Sauer wrote:

Thanks for your suggestions, Jure and Ole. I had checked that the
OpenMPI version built by EasyBuild links to the same ibverbs and psm
(libpsm_infinipath.so) versions as the system OpenMPI. The only
difference is that the EasyBuild version links to hwloc, which the
system version doesn't. And psm2 appears not to be available on the system.

I understand that it is nearly impossible to figure out why the
EasyBuild version has such a bad MPI latency performance, because I
don't have the details of the system I am running on. For this reason I
am giving up further EasyBuild testing until I have access to a
different cluster with more available hardware+software information.

If anybody involved in EasyBuild documentation is reading this, I'd
appreciate if it were documented, which prerequisites the EasyBuild
toolchains have with respect to the Infiniband installation and which
configure options require checking prior to running the toolchain
installation. I find it very confusing that different people either say
that the foss toolchain takes care of an optimized OpenMPI installation,
others say that I need to set up correct psm and ibverbs linking, and in
the end it looks like the necessary options are included in the foss
toolchain, but they don't give the expected performance. I feel kind of
lost and give up for the moment. I'll return to testing EasyBuild in a
few weeks or after my internship.

Thank you
Gunnar

2017-01-31 8:51 GMT+01:00 Ole Holm Nielsen <ole.h.niel...@fysik.dtu.dk
<mailto:ole.h.niel...@fysik.dtu.dk>>:

Hi,

We use EasyBuild to provide OpenMPI in the "foss" toolchain.  We use
the Intel OmniPath fabric 100 Gbit/s.  To build OpenMPI with
OmniPath (and Slurm) support I simply add these files to the EB file:

# Support of Slurm
configopts += '--with-slurm --with-pmi=/usr/include/slurm
--with-pmi-libdir=/usr '
# Support of OmniPath PSM,
https://www.open-mpi.org/faq/?category=building#build-p2p
<https://www.open-mpi.org/faq/?category=building#build-p2p>
# Requires: yum install libpsm2 libpsm2-devel
# configopts += '--with-psm --with-psm2 '
configopts += '--with-psm2 '

With this OpenMPI build I obtain a bandwidth of about 99 Gbit/s and
a latency of 1.2 usec, using the OSU micro benchmarks.

I chose to ignore the Intel-supplied RPM for openmpi that comes with
their OmniPath support

I have further details in my Wiki page:
https://wiki.fysik.dtu.dk/niflheim/OmniPath#openmpi-configuration
<https://wiki.fysik.dtu.dk/niflheim/OmniPath#openmpi-configuration>

Best regards,
Ole



On 01/29/2017 02:51 PM, Gunnar Sauer wrote:

Hello Kenneth,
thanks for coming back to my question. I am sorry to say than I
cannot
follow the EasyBuild route anymore for the purpose of my
internship, but
I am definitely interested to solve the problems (described
below) for
myself and for my future career. (I'll have to buy access to
some public
cluster like Sabalcore or see whether I can work on our university
cluster without a specific project. So it may take 1-2 weeks
until I can
proceed.)

I have run the HPCC benchmark (version 1.5.0 from
http://icl.cs.utk.edu/hpcc/software/index.html
<http://icl.cs.utk.edu/hpcc/software/index.html>) once with the
preinstalled gcc/openmpi/openblas of the company's Xeon cluster, and
secondly with the foss/2016b toolchain built previously on the same
cluster. This was meant as a quick check whether the forum users
were
right, saying that it doesn't matter for the MPI performance
whether you
use and optimized OpenMPI version or the generic EasyBuild
OpenMPI built
from source - or whether our engineers were right, saying that
you have
to use the system tools including an OpenMPI that has been set
up for
the Infiniband hardware if you want any decent MPI performance.

When I presented the numbers below, showing ping pong latencies
of 1
us (EasyBuild) compared to 2 us (system tools), we had a quick
discussion, and my task is now to write a build script
independent from
EasyBuild, respecting 

Re: [easybuild] toolchain which uses existing, optimized, MPI/ScaLAPACK and build environment?

[Ole Holm Nielsen]

On 02/01/2017 11:44 AM, Jure Pečar wrote:

On Wed, 1 Feb 2017 11:30:50 +0100
Ole Holm Nielsen <ole.h.niel...@fysik.dtu.dk> wrote:


The OmniPath software is downloaded from
https://downloadcenter.intel.com/search?keyword=Omni-Path


Actually it is also available on github:
https://github.com/01org/opa-psm2 (along with a bunch of other interesting 
things from 01.org)

I don't know which version is more recent, intel supplied one or the one on 
github.

This makes possible to build a psm2 easyconfig. Question is do we want to 
introduce hardware specific pieces in easybuild toolchains? Or should we just 
presume that whatever host we're building on supplies those hw specific libs 
and that our toolchains will just pick them up automagically?

I like the state of things the way they are now, but as Gunnar said, this state assumes 
you have some knowledge about the hardware you're building on and hardware-specific libs 
required to utilize it fully. I guess right now this is a requirement if one wants to 
build "hw-optimized" easybuild toolchain.


To build OpenMPI with PSM2 support, you definitely need to add the line:
  configopts += '--with-psm2 '
in the EB file.

This PSM2 software component could perhaps be nice to have built-in 
always, but I have no experience whether it might cause problems for 
other OpenMPI installation.  PSM2 is not really a hardware-specific 
component, but currently it seems to be used only on Intel OmniPath fabrics.

Re: [easybuild] toolchain which uses existing, optimized, MPI/ScaLAPACK and build environment?

[Ole Holm Nielsen]

On 02/01/2017 11:41 AM, Gunnar Sauer wrote:

The system OpenMPI version runs fine without a link to psm2.


Well, who knows what the "system OpenMPI version" is.  It might be a 
generic OpenMPI that runs on top of Verbs, meaning the IP over 
Infiniband interface supported also on OmniPath fabrics.  However, the 
performance of Verbs with OmniPath is said to be not al all optimized. 
For OpenMPI on OmniPath, one therefore must use the PSM2 interface.

[easybuild] EB for Intel Distribution for Python?

[Ole Holm Nielsen]

I would like to provide an EB module for "Intel Distribution for 
Python", see 
https://software.intel.com/en-us/intel-distribution-for-python. 
However, Intel Python isn't on the EB List of supported software.


Question: Does anyone have EB files for creating modules of Intel Python 
2.7 and 3.5?


Thanks,
Ole

Re: [easybuild] EB for Intel Distribution for Python?

[Ole Holm Nielsen]

On 01/19/2017 03:39 PM, Siddiqui, Shahzeb wrote:

Please see issue:

https://github.com/hpcugent/easybuild-easyconfigs/issues/3922

I tried to build intel-python with IntelBase, it seems to be a trivial issue 
with license. Not sure how to fix this.

Can you please provide input on this


Yes, I hit the same issue with Intel licenses a while ago, and the 
configuration is described in my Wiki page:

https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#intel-compiler-toolchains

I hope this helps,
Ole

[easybuild] Difference between toolchains foss and goolf?

[Ole Holm Nielsen]

Dear EasyBuild users,

We're starting work on updating the easybuild-easyconfigs for our 
simulation packages ASE and GPAW in order to make the latest updates 
available to the EasyBuild community and on our Linux cluster.


We'll be needing a toolchain including modern versions of GCC, OpenMPI, 
OpenBLAS/LAPACK, ScaLAPACK(/BLACS), FFTW.  The target platform will be 
CentOS 7.2 which supplies GCC 4.8.5.


Question: Which of the two seemingly identical toolchains "foss" and 
"goolf" in the official toolchain list should we be using?


Thanks,
Ole

[easybuild] Re: How to install the Intel compiler toolchain?

[Ole Holm Nielsen]

I've tried to understand how EasyBuild handles the Intel compiler 
toolchain, and despite the apparent lack of documentation, I've made 
some progress as documented in our Wiki:

https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#intel-compiler-toolchain

Apparently one must download the ICC, IFORT and MKL tar-balls separately 
from Intel and copy them to the ~/sources/ixxx subdirectories.  In this 
way I've successfully built the modules:

icc/2016.3.210-GCC-5.4.0-2.26
ifort/2016.3.210-GCC-5.4.0-2.26

Unfortunately the MKL (imkl) module presents a problem: All the existing 
.eb files assume that some MPI framework is being used by MKL.  At our 
site we don't have "Intel® Parallel Studio XE 2016 Cluster Edition" 
which contains Intel MPI.


We just want to use MKL with the ICC or IFORT compilers on a single node.

Question: How may we build an MKL module without any MPI stuff?

I've experimented with some of the imkl*.eb files, but the building 
process always crashes when the building process wants to use mpicc or 
whatever.


Thanks for sharing your insights.

/Ole

On 07/19/2016 04:19 PM, Ole Holm Nielsen wrote:

I'm just getting started with EasyBuild, so excuse my limited
experience.  I would like to install some versions of the Intel compiler
toolchains as dependencies for other packages.  We do have valid
licenses for the Intel compilers, and they work well in our old
environment modules system.

I've searched in vain for any kind of documentation on how to install
the Intel compilers with EasyBuild.  The expected EasyBuild command
fails because I haven't provided the tar-balls from Intel:

$ eb intel-2016b.eb -r
== temporary log file in case of crash /tmp/eb-Zq7KyT/easybuild-Jnxhw0.log
== resolving dependencies ...
== processing EasyBuild easyconfig
/home/opt/modules/software/EasyBuild/2.8.2/lib/python2.7/site-packages/easybuild_easyconfigs-2.8.2-py2.7.egg/easybuild/easyconfigs/i/icc/icc-2016.3.210-GCC-5.4.0-2.26.eb

== building and installing icc/2016.3.210-GCC-5.4.0-2.26...
== fetching files...
== FAILED: Installation ended unsuccessfully (build directory:
/home/opt/modules/build/icc/2016.3.210/dummy-dummy-GCC-5.4.0-2.26):
build failed (first 300 chars): Couldn't find file
parallel_studio_xe_2016_composer_edition_for_cpp_update3.tgz anywhere,
and downloading it didn't work either... Paths attempted (in order):
/home/opt/modules/software/EasyBuild/2.8.2/lib/python2.7/site-packages/easybuild_easyconfigs-2.8.2-py2.7.egg/easybuild/easyconfigs/i/icc/i/ic

== Results of the build can be found in the log file(s)
/tmp/eb-Zq7KyT/easybuild-icc-2016.3.210-20160719.160648.OQPZr.log
ERROR: Build of
/home/opt/modules/software/EasyBuild/2.8.2/lib/python2.7/site-packages/easybuild_easyconfigs-2.8.2-py2.7.egg/easybuild/easyconfigs/i/icc/icc-2016.3.210-GCC-5.4.0-2.26.eb
failed (err: "build failed (first 300 chars): Couldn't find file
parallel_studio_xe_2016_composer_edition_for_cpp_update3.tgz anywhere,
and downloading it didn't work either... Paths attempted (in order):
/home/opt/modules/software/EasyBuild/2.8.2/lib/python2.7/site-packages/easybuild_easyconfigs-2.8.2-py2.7.egg/easybuild/easyconfigs/i/icc/i/ic")


Question: Can anyone provide documentation on what to do with the Intel
tar-balls so that the EasyBuild command "eb" will work correctly?

BTW, the latest tar-ball I downloaded from Intel is named:
   parallel_studio_xe_2016_composer_edition_update3.tgz
which doesn't match EasyBuild's search name:
   parallel_studio_xe_2016_composer_edition_for_cpp_update3.tgz

Thanks,
Ole

[easybuild] How to install the Intel compiler toolchain?

[Ole Holm Nielsen]

I'm just getting started with EasyBuild, so excuse my limited 
experience.  I would like to install some versions of the Intel compiler 
toolchains as dependencies for other packages.  We do have valid 
licenses for the Intel compilers, and they work well in our old 
environment modules system.


I've searched in vain for any kind of documentation on how to install 
the Intel compilers with EasyBuild.  The expected EasyBuild command 
fails because I haven't provided the tar-balls from Intel:


$ eb intel-2016b.eb -r
== temporary log file in case of crash /tmp/eb-Zq7KyT/easybuild-Jnxhw0.log
== resolving dependencies ...
== processing EasyBuild easyconfig 
/home/opt/modules/software/EasyBuild/2.8.2/lib/python2.7/site-packages/easybuild_easyconfigs-2.8.2-py2.7.egg/easybuild/easyconfigs/i/icc/icc-2016.3.210-GCC-5.4.0-2.26.eb

== building and installing icc/2016.3.210-GCC-5.4.0-2.26...
== fetching files...
== FAILED: Installation ended unsuccessfully (build directory: 
/home/opt/modules/build/icc/2016.3.210/dummy-dummy-GCC-5.4.0-2.26): 
build failed (first 300 chars): Couldn't find file 
parallel_studio_xe_2016_composer_edition_for_cpp_update3.tgz anywhere, 
and downloading it didn't work either... Paths attempted (in order): 
/home/opt/modules/software/EasyBuild/2.8.2/lib/python2.7/site-packages/easybuild_easyconfigs-2.8.2-py2.7.egg/easybuild/easyconfigs/i/icc/i/ic
== Results of the build can be found in the log file(s) 
/tmp/eb-Zq7KyT/easybuild-icc-2016.3.210-20160719.160648.OQPZr.log
ERROR: Build of 
/home/opt/modules/software/EasyBuild/2.8.2/lib/python2.7/site-packages/easybuild_easyconfigs-2.8.2-py2.7.egg/easybuild/easyconfigs/i/icc/icc-2016.3.210-GCC-5.4.0-2.26.eb 
failed (err: "build failed (first 300 chars): Couldn't find file 
parallel_studio_xe_2016_composer_edition_for_cpp_update3.tgz anywhere, 
and downloading it didn't work either... Paths attempted (in order): 
/home/opt/modules/software/EasyBuild/2.8.2/lib/python2.7/site-packages/easybuild_easyconfigs-2.8.2-py2.7.egg/easybuild/easyconfigs/i/icc/i/ic")


Question: Can anyone provide documentation on what to do with the Intel 
tar-balls so that the EasyBuild command "eb" will work correctly?


BTW, the latest tar-ball I downloaded from Intel is named:
   parallel_studio_xe_2016_composer_edition_update3.tgz
which doesn't match EasyBuild's search name:
   parallel_studio_xe_2016_composer_edition_for_cpp_update3.tgz

Thanks,
Ole

--
Ole Holm Nielsen
Department of Physics, Technical University of Denmark,

[easybuild] EB 2.9.0: Irresolvable dependencies for Python 3.5.2

[Ole Holm Nielsen]

I need to build Python 3.5 for the EB 2.9.0 toolchain foss-2016.09.
I copied the file Python-3.5.2-foss-2016.04.eb and replaced 04 by 09.

Unfortunately, irresolvable dependencies are found:

# eb Python-3.5.2-foss-2016.09.eb -r
== temporary log file in case of crash /tmp/eb-mvPeVH/easybuild-tixAOo.log
== resolving dependencies ...
ERROR: Irresolvable dependencies encountered: bzip2/1.0.6-foss-2016.09, 
zlib/1.2.8-foss-2016.09, libreadline/6.3-foss-2016.09, 
ncurses/6.0-foss-2016.09, SQLite/3.13.0-foss-2016.09, 
Tk/8.6.5-foss-2016.09, GMP/6.1.1-foss-2016.09, XZ/5.2.2-foss-2016.09, 
libffi/3.2.1-foss-2016.09


I suppose that these dependencies could be built independently of the 
foss toolchain.


Question: Does anyone have a working EB file Python-3.5.2-foss-2016.09.eb?

Thanks a lot,
Ole

[easybuild] How to build modules compiled for different hardware architectures?

[Ole Holm Nielsen]

We're installing EasyBuild 2.9.0 on our new cluster, and user 
application codes should be built on top of the latest foss-2016 toolchain.


Since our cluster has 4 different generations of Intel Xeon hardware 
(Nehalem, Sandy/Ivy Bridge, Haswell, Broadwell), users want to compile 
their application codes optimized for the compute node hardware (gcc 
-march=native).


Question: Is there a best practices method for providing EasyBuild 
modules which are compiled for different hardware architectures?


I can see some possible solutions:

1. Build totally separate and complete EB module trees for each of the 
architectures.  Mount the correct EB module tree by NFS on the same 
mount point (/home/modules, say) on compute nodes based upon its 
architecture.


2. Within a single EB hierarchy, build multiple versions of just the 
application code modules requiring optimized code.  This has the 
advantage of a shared module tree for all non-application-code modules. 
Users must then identify the compute node's architecture at run-time and 
load the correct module for that architecture (this sounds complicated 
for users).



Bonus question: What's the most portable, reliable and lightweight way 
to determine which Intel Xeon architecture you're working on?  Googling 
the question suggests using /proc/cpuinfo:


# grep "model name" /proc/cpuinfo | head -1
model name  : Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz

but then you must parse this string to discover whether you're on Xeon, 
Xeon v2, v3, v4, or v5 (from next year).


Thanks for sharing your insights,
Ole

Re: [easybuild] EB 2.9.0: Irresolvable dependencies for Python 3.5.2

[Ole Holm Nielsen]

On 09/29/2016 11:17 AM, Kenneth Hoste wrote:

I'm not sure what your question is w.r.t. documentation...
Do you mean your own (internal) documentation, or the EasyBuild
documentation at http://easybuild.readthedocs.io/?
The --try-* options don't have a dedicated entry in the EasyBuild docs
yet, but they're considered stable; unless you're taking it a bit too
far, way beyond just tweaking the toolchain (version), they should work
(that is, produce 'correct' easyconfigs, there are no guarantees that
the installation will actually work).


I'm referring to our own internal documentation: How may we ever 
remember how to build a specific application module or a toolchain, if 
we don't have an easyconfig file and don't remember some specific 
--try-toolchain.  That's why I think documentation may become an issue.


Thanks,
Ole


On 09/29/2016 10:48 AM, Kenneth Hoste wrote:

Hi Ole,

On 29/09/16 10:37, Pablo Escobar Lopez wrote:

have you tried "eb Python-3.5.2-foss-2016.04.eb
--try-toolchain=foss,2016.09 -r"   ?


+1 on this, the problem is that there are no easyconfigs available for
the dependencies of Python 3.5.2 with foss/2016.09.

If you combine --try-toolchain (or --try-toolchain-version) with
--robot, EasyBuild will first construct the full dependency graph using
the foss/2016.04, and then generate easyconfigs (in a temp dir) for each
of the components using foss/2016.09, and then proceed to building and
installing everything.


regards,

Kenneth


2016-09-29 8:55 GMT+02:00 Ole Holm Nielsen <ole.h.niel...@fysik.dtu.dk
<mailto:ole.h.niel...@fysik.dtu.dk>>:

I need to build Python 3.5 for the EB 2.9.0 toolchain foss-2016.09.
I copied the file Python-3.5.2-foss-2016.04.eb and replaced 04
by 09.

Unfortunately, irresolvable dependencies are found:

# eb Python-3.5.2-foss-2016.09.eb -r
== temporary log file in case of crash
/tmp/eb-mvPeVH/easybuild-tixAOo.log
== resolving dependencies ...
ERROR: Irresolvable dependencies encountered:
bzip2/1.0.6-foss-2016.09,
zlib/1.2.8-foss-2016.09, libreadline/6.3-foss-2016.09,
ncurses/6.0-foss-2016.09, SQLite/3.13.0-foss-2016.09,
Tk/8.6.5-foss-2016.09, GMP/6.1.1-foss-2016.09,
XZ/5.2.2-foss-2016.09,
libffi/3.2.1-foss-2016.09

I suppose that these dependencies could be built independently
of the
foss toolchain.

Question: Does anyone have a working EB file
Python-3.5.2-foss-2016.09.eb?

Thanks a lot,
Ole




--
Pablo Escobar López
HPC systems engineer
sciCORE, University of Basel
SIB Swiss Institute of Bioinformatics
http://scicore.unibas.ch








--
Ole Holm Nielsen
PhD, Manager of IT services
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

Re: [easybuild] EB 2.9.0: Irresolvable dependencies for Python 3.5.2

[Ole Holm Nielsen]

Pablo, Kenneth: Thanks a lot!  The --try-toolchain works correctly.

Question: Is --try-toolchain just a hack for testing out something new, 
or is it supposed to be used also for production modules?


If used for production, how may we remember/document the requirement for 
--try-toolchain with some older easyconfig?  Documentation would seem to 
become an issue.


Thanks,
Ole

On 09/29/2016 10:48 AM, Kenneth Hoste wrote:

Hi Ole,

On 29/09/16 10:37, Pablo Escobar Lopez wrote:

have you tried "eb Python-3.5.2-foss-2016.04.eb
--try-toolchain=foss,2016.09 -r"   ?


+1 on this, the problem is that there are no easyconfigs available for
the dependencies of Python 3.5.2 with foss/2016.09.

If you combine --try-toolchain (or --try-toolchain-version) with
--robot, EasyBuild will first construct the full dependency graph using
the foss/2016.04, and then generate easyconfigs (in a temp dir) for each
of the components using foss/2016.09, and then proceed to building and
installing everything.


regards,

Kenneth


2016-09-29 8:55 GMT+02:00 Ole Holm Nielsen <ole.h.niel...@fysik.dtu.dk
<mailto:ole.h.niel...@fysik.dtu.dk>>:

I need to build Python 3.5 for the EB 2.9.0 toolchain foss-2016.09.
I copied the file Python-3.5.2-foss-2016.04.eb and replaced 04 by 09.

Unfortunately, irresolvable dependencies are found:

# eb Python-3.5.2-foss-2016.09.eb -r
== temporary log file in case of crash
/tmp/eb-mvPeVH/easybuild-tixAOo.log
== resolving dependencies ...
ERROR: Irresolvable dependencies encountered:
bzip2/1.0.6-foss-2016.09,
zlib/1.2.8-foss-2016.09, libreadline/6.3-foss-2016.09,
ncurses/6.0-foss-2016.09, SQLite/3.13.0-foss-2016.09,
Tk/8.6.5-foss-2016.09, GMP/6.1.1-foss-2016.09, XZ/5.2.2-foss-2016.09,
libffi/3.2.1-foss-2016.09

I suppose that these dependencies could be built independently of the
foss toolchain.

Question: Does anyone have a working EB file
Python-3.5.2-foss-2016.09.eb?

Thanks a lot,
Ole




--
Pablo Escobar López
HPC systems engineer
sciCORE, University of Basel
SIB Swiss Institute of Bioinformatics
http://scicore.unibas.ch




--
Ole Holm Nielsen
PhD, Manager of IT services
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

[easybuild] EB 2.9.0 can't download GCC 6.2.0

[Ole Holm Nielsen]

I've bootstrapped EB 2.9.0 and I want to build the latest foss toolchain 
foss-2016.09.  Unfortunately, the download of GCC 6.2.0 fails:


# eb foss-2016.09.eb -r
== temporary log file in case of crash /tmp/eb-sQCexT/easybuild-Z08QX0.log
== resolving dependencies ...
== processing EasyBuild easyconfig 
/home/opt/modules/xeonv4/software/EasyBuild/2.9.0/lib/python2.7/site-packages/easybuild_easyconfigs-2.9.0-py2.7.egg/easybuild/easyconfigs/g/GCCcore/GCCcore-6.2.0.eb

== building and installing GCCcore/6.2.0...
== fetching files...
== FAILED: Installation ended unsuccessfully (build directory: 
/home/opt/modules/xeonv4/build/GCCcore/6.2.0/dummy-): build failed 
(first 300 chars): Couldn't find file gcc-6.2.0.tar.bz2 anywhere, and 
downloading it didn't work either... Paths attempted (in order): 
/home/opt/modules/xeonv4/software/EasyBuild/2.9.0/lib/python2.7/site-packages/easybuild_easyconfigs-2.9.0-py2.7.egg/easybuild/easyconfigs/g/GCCcore/g/GCCcore/gcc-6.2.0.tar.bz2, 
/home/o
== Results of the build can be found in the log file(s) 
/tmp/eb-sQCexT/easybuild-GCCcore-6.2.0-20160928.150813.vOptJ.log
ERROR: Build of 
/home/opt/modules/xeonv4/software/EasyBuild/2.9.0/lib/python2.7/site-packages/easybuild_easyconfigs-2.9.0-py2.7.egg/easybuild/easyconfigs/g/GCCcore/GCCcore-6.2.0.eb 
failed (err: "build failed (first 300 chars): Couldn't find file 
gcc-6.2.0.tar.bz2 anywhere, and downloading it didn't work either... 
Paths attempted (in order): 
/home/opt/modules/xeonv4/software/EasyBuild/2.9.0/lib/python2.7/site-packages/easybuild_easyconfigs-2.9.0-py2.7.egg/easybuild/easyconfigs/g/GCCcore/g/GCCcore/gcc-6.2.0.tar.bz2, 
/home/o")


I can download the gcc tarball without problems from the site 
http://mirrors.dotsrc.org/gnu/gcc/gcc-6.2.0/


In the logfile there are lots of errors, just an example:

== 2016-09-28 15:08:13,666 filetools.py:332 WARNING HTTPError occured 
while trying to download 
http://ftpmirror.gnu.org/gcccore/gcccore-6.2.0/gcc-6.2.0.tar.bz2 to 
/home/opt/modules/xeonv4/sources/g/GCCcore/gcc-6.2.0.tar.bz2: HTTP Error 
500: Internal Server Error
== 2016-09-28 15:08:13,667 filetools.py:341 INFO Attempt 1 of 
downloading 
http://ftpmirror.gnu.org/gcccore/gcccore-6.2.0/gcc-6.2.0.tar.bz2 to 
/home/opt/modules/xeonv4/sources/g/GCCcore/gcc-6.2.0.tar.bz2 failed, 
trying again...
== 2016-09-28 15:08:13,902 filetools.py:329 WARNING URL 
http://ftpmirror.gnu.org/gcccore/gcccore-6.2.0/gcc-6.2.0.tar.bz2 was not 
found (HTTP response code 404), not trying again



So there would seem to be some problem with the GCCcore-6.2.0.eb file. 
How can we fix the error?


Thanks,
Ole

Re: [easybuild] How to rebuild the foss-2016b toolchain with OpenMPI including Slurm support?

[Ole Holm Nielsen]

On 10/26/2016 06:43 PM, Kenneth Hoste wrote:

Question: How do I rebuild the OpenMPI module with proper Slurm support?


Rebuilding with --force should work, so for some reason your customized
EasyBuild was not picked up...
How did you provide it to EasyBuild exactly? Was it available in the
local directory where you ran the 'eb' command?

You can verify that the right easyconfig is picked up via a dry run
like: "eb OpenMPI-1.10.3-GCC-5.4.0-2.26.eb -Df", which will print the
path to the easyconfig files used.


The dry-run actually looks fine, and I can do the rebuild with --force 
correctly now (don't know why I had the problem in the first place).



Question: Can Slurm support please be included in future versions of
the OpenMPI module in the foss-201x tool chain?

This is a left as a site-specific customization, since including
--with-slurm hard would make the installation fail on any systems that
do not have SLURM.

We should have documentation on how to deal with site-specific
customisations well though.
Is anyone doing that (JSC, CSCS, TAMU?) up for writing up some
documentation for this?
The existing documentation has some examples hinting towards a possible
setup: http://easybuild.readthedocs.io/en/latest/Configuration.html#example


I have tested successfully adding this line to 
OpenMPI-1.10.3-GCC-5.4.0-2.26.eb:


configopts += '--with-slurm --with-pmi=/usr/include/slurm 
--with-pmi-libdir=/usr '  # Support of Slurm


Our cluster uses Slurm 16.05.5 on CentOS 7.2, and the Slurm RPMs slurm 
and slurm-devel install files in the above mentioned directories.


As for documentation of Slurm with OpenMPI, I have some notes in our 
Wiki: https://wiki.fysik.dtu.dk/niflheim/SLURM#mpi-setup


/Ole

Re: [easybuild] Any EasyBuild people at SC16?

[Ole Holm Nielsen]

On 11/08/2016 10:48 AM, Alvarez, Damian wrote:

Hey Ole,

I’ll be there. I’ll be presenting the “Scientific Software Management in Real 
Life: Deployment of EasyBuild on a Large Scale System.” at HUST’16 (one of the 
SC workshops) on Sunday. I’ll also be around at the Jülich Supercomputing 
Centre booth at the exhibition and the SC’16 information booth somewhere else 
during the conference.

Let me know if you intend to pass by and we’ll see if you can make it during my 
slots in the booths, or if we can talk at another moment during the conference.


Thanks for your suggestions.  I wasn't aware of the HUST16 workshop 
(http://hust16.github.io/), and my flight to SLC arrives after this 
workshop :-(  One must also register for workshops at SC16, see 
http://sc16.supercomputing.org/attendees/registration/


/Ole

[easybuild] Any EasyBuild people at SC16?

[Ole Holm Nielsen]

I wonder if any EasyBuild people are going to be present at the SC16 
conference in Salt Lake City next week?


Last year's BOF session on modules at SC15 was really great, IMHO! 
Perhaps some EasyBuild/Lmod people may be found in some booths at SC16 
some of the time?


See you,
Ole

Re: [easybuild] How to setup EB in the global /etc/profile.d/ ?

[Ole Holm Nielsen]

Hi Kenneth, Cc: Robert,

I've been trying to set up a default user environment with modules 
provided by EasyBuild (EB) and using Lmod.  We run CentOS 7.2. The EB 
discussion is in this thread: 
https://lists.ugent.be/wws/arc/easybuild/2016-10/msg00052.html


My goal is to automatically provide modules built by EB to every normal 
user, but not actually loading any modules, since users have different 
needs.


Following the Lmod documentation in 
http://lmod.readthedocs.io/en/latest/070_standard_modules.html I've come 
up with the following shell initialization file 
/etc/profile.d/z01_EasyBuild.sh which gets called after Lmod has been 
initialized (by z00_lmod.sh):


if [ -z "$__Init_Default_Modules" ]; then
   export __Init_Default_Modules=1
   export EASYBUILD_MODULES_TOOL=Lmod
   export EASYBUILD_PREFIX=/home/modules
   module use $EASYBUILD_PREFIX/modules/all
else
   module refresh
fi

(obviously, the EASYBUILD_PREFIX is site-dependent).  Please note that I 
refrain from calling the recommended "module --initial_load restore".  I 
believe this is unwarranted, unless the sysadmin actually wants users to 
always load some specific set of system default modules - which I don't 
want to do.  I also don't load the EasyBuild module, because only module 
builders need to do that, but not the normal users.


It seems to me that the above script would be a suitable minimum setup 
for automatic initialization of EB modules.


Question to the experts: Is this approach sound, or do you see any 
problems?


If it seems OK, could you perhaps consider adding the above example to 
the mentioned Lmod page as a convenient way to get started (at least 
when using EB).  I don't know if this usage example is appropriate for 
inclusion in the EB documentation, but as a newcomer to EB I certainly 
felt the need for a good way to provide EB modules to normal users, and 
I had to work hard to solve this problem.


In my Wiki page about Lmod and EasyBuild I've documented the above:
https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#global-setup-of-modules-for-all-users

Thanks,
Ole

--
Ole Holm Nielsen
PhD, Manager of IT services
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark

Re: [easybuild] How to setup EB in the global /etc/profile.d/ ?

[Ole Holm Nielsen]

On 10/14/2016 10:08 AM, Kenneth Hoste wrote:

Following the Lmod documentation in
http://lmod.readthedocs.io/en/latest/070_standard_modules.html I've
come up with the following shell initialization file
/etc/profile.d/z01_EasyBuild.sh which gets called after Lmod has been
initialized (by z00_lmod.sh):

if [ -z "$__Init_Default_Modules" ]; then
   export __Init_Default_Modules=1
   export EASYBUILD_MODULES_TOOL=Lmod
   export EASYBUILD_PREFIX=/home/modules
   module use $EASYBUILD_PREFIX/modules/all
else
   module refresh
fi

(obviously, the EASYBUILD_PREFIX is site-dependent).  Please note that
I refrain from calling the recommended "module --initial_load
restore".  I believe this is unwarranted, unless the sysadmin actually
wants users to always load some specific set of system default modules
- which I don't want to do.  I also don't load the EasyBuild module,
because only module builders need to do that, but not the normal users.

It seems to me that the above script would be a suitable minimum setup
for automatic initialization of EB modules.

Question to the experts: Is this approach sound, or do you see any
problems?


Defining $EASYBUILD_PREFIX by default is probably not something you want
to do for everyone, since that instructs EasyBuild to install software
in this location, and I expect that most users won't have write
permissions there?


That's a good point!  Can you enlighten me on how to provide globally 
available modules as I've done, while at the same time allowing normal 
users to build their own private modules in their $HOME?


I guess that end users could define in their .bashrc, for example,
  export EASYBUILD_PREFIX=$HOME/modules
When they do
  module use $EASYBUILD_PREFIX/modules/all
that should simply prepend their personal module path to the system-wide 
one I define above - or maybe I'm totally mistaken here?  I did a short 
test of this as a normal user, and it seems to work as expected.



I'm happy to include this in the EasyBuild documentation somewhere, any
suggestions for a particular location? Should it be a new page?
Are you up for making a pull request to the EasyBuild documentation for
this (see the 'docs' subdir in https://github.com/hpcugent/easybuild)?


I'd be happy to start working with Github, but it'll take some time for 
me to familiarize myself with this ecosystem.  But I don't see a natural 
place in the current EB documentation to make contributions.


Perhaps you could consider the possibility of making a new section in 
https://easybuild.readthedocs.io/en/latest/, for example, "EasyBuild for 
End Users" or similar.  I'm thinking that end users should know how to 
use EB modules, and sysadmins should think of ways to provide modules to 
end users.


If you provide a section according to your wishes, perhaps you could 
include my above script as an example?


Thanks,
Ole

--
Ole Holm Nielsen
PhD, Manager of IT services
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

Re: [easybuild] How to hide modules at the Lmod level?

[Ole Holm Nielsen]

Hi Pablo,

On 19-11-2016 13:50, Pablo Escobar Lopez wrote:

I think Lmod 6.x doesn't support using a modulerc file. This feature was
added in latest Lmod 7.0. See the changelog here
https://github.com/TACC/Lmod


Great, thanks for the clarification and suggestions.  I didn't realize 
that Lmod only supports .modulerc from version 7.0.



What Lmod 6.x supports is hidding a module if the version in the module
name starts by dot. e.g. a module like "zlib/.1.2.8" would be hidden by
Lmod. To list hidden and non-hidden modules you should do "module av
--show-hidden"


Yes, but it's a bit cumbersome to maintain such renamings xxx->.xxx. 
Maybe this is the simplest option at this time, however.



You can generate hidden modules with Easybuild (including the required
dot) using the --hide-deps option
http://easybuild.readthedocs.io/en/latest/Manipulating_dependencies.html?highlight=hidden#installing-dependencies-as-hidden-modules-using-hide-deps


You can also use the --hidden option (see build parameters)
http://easybuild.readthedocs.io/en/latest/version-specific/easyconfig_parameters.html?highlight=hidden


If you are using Lmod 6.x and you want to hide modules you will have to
regenerate the module files to add the required dot. For this the
--module-only option in easybuild can be useful. If you upgrade to Lmod
7.x you can use the modulerc file and avoid renaming module names.


IMHO, the --hidden option ought to be the EB default for all "system" 
modules which are irrelevant to end users.


/Ole

[easybuild] How to hide modules at the Lmod level?

[Ole Holm Nielsen]

I think that EB dependencies showing up in .../modules/all are confusing 
to end users.  We should avoid exposing dependency modules such as 
Bison, GCCcore, M4, zlib, etc.etc. to end users.


Lmod and Tmod apparently allow you to hide modules in a modulerc file. 
For Lmod 7.0 the syntax is "hide-module foo/3.2.1".


However, I can't get this to work.  If I create a file 
.../modules/all/.modulerc with the line "hide-module zlib/1.2.8", the 
zlib still shows up with "module avail".  I haven't been able to find 
any documentation of the function of MODULERCFILE or .modulerc in Lmod 
or Tmod.  We're using Lmod 6.5.1 on CentOS 7.2.


Question: Has anyone succeeded in hiding modules with Lmod in this way?

Thanks,
Ole

Re: [easybuild] Has anyone created EB files for the Intel 2017 compilers?

[Ole Holm Nielsen]

Hi Kenneth,

Thanks a lot, this is invaluable information!!  I'm downloading Parallel 
Studio 2016 update 1 now.


In the meantime another question:  The EB file license_file line doesn't 
seem to work as expected, I always get an error:


ERROR: Build of /home/camp/ohni/iomkl/icc-2016.3.210-GCC-5.4.0-2.26.eb 
failed (err: "build failed (first 300 chars): No viable license 
specifications found; specify 'license_file', or define 
$INTEL_LICENSE_FILE or $LM_LICENSE_FILE")


I tried to specify:

1. license_file = 'license.lic'   # Copy of Intel network license file
2. license_file = 'server.lic'# Network license file
3. First export INTEL_LICENSE_FILE=server.lic

There must be a secret trick to pass the license_file step, but I can't 
figure it out :-(


Thanks for any help,
Ole

On 11/02/2016 12:05 PM, Kenneth Hoste wrote:

Hi Ole,

There are some known issues with 2016 update 3 (and 2), see also
https://github.com/hpcugent/easybuild-easyconfigs/pull/2966#issuecomment-241603766
.


regards,

Kenneth

On 02/11/16 12:00, Ole Holm Nielsen wrote:

Thanks to Alan, Kenneth, Ake!  The EB files for Intel compiler 2017
would seem to be under development, so it's better to wait going for
2017?

Ake's comment on QM-espresso failing with Intel 2017 sounds
discouraging, and we're using scalapack/blacs as well.

Ake's working suite intel/2016a sounds like a good starting point,
though perhaps Parallel Studio 2016 update 3 ought to be less buggy?

Re: [easybuild] Has anyone created EB files for the Intel 2017 compilers?

[Ole Holm Nielsen]

Thanks to Alan, Kenneth, Ake!  The EB files for Intel compiler 2017 
would seem to be under development, so it's better to wait going for 2017?


Ake's comment on QM-espresso failing with Intel 2017 sounds 
discouraging, and we're using scalapack/blacs as well.


Ake's working suite intel/2016a sounds like a good starting point, 
though perhaps Parallel Studio 2016 update 3 ought to be less buggy?


/Ole

On 11/02/2016 11:26 AM, Kenneth Hoste wrote:

See https://github.com/hpcugent/easybuild-easyconfigs/pull/3543, note
that a small update to the IntelBase easyblock is required as well:
https://github.com/hpcugent/easybuild-easyblocks/pull/1012 .


regards,

Kenneth

On 02/11/16 11:09, Alan O'Cais wrote:

You can usually find things like this in the develop branch:
https://github.com/hpcugent/easybuild-easyconfigs/tree/develop/easybuild/easyconfigs/i/icc
https://github.com/hpcugent/easybuild-easyconfigs/tree/develop/easybuild/easyconfigs/i/ifort

On 2 November 2016 at 11:00, Ole Holm Nielsen
<ole.h.niel...@fysik.dtu.dk <mailto:ole.h.niel...@fysik.dtu.dk>> wrote:

I need to create the iomkl toolchain (we have no Intel MPI
license), and I'd prefer to use the latest and greatest Intel
compilers "Intel® Parallel Studio XE Composer Edition for Fortran
and C++ Linux* 2017 update 1".

Question: Has anyone created EB files for toolchains with the icc,
ifort etc?

Re: [easybuild] Has anyone created EB files for the Intel 2017 compilers?

[Ole Holm Nielsen]

On 11/03/2016 03:24 PM, Jens Timmerman wrote:

On 03/11/2016 12:07, Fotis Georgatos wrote:

Hi Ole, all,

On Nov 2, 2016, at 2:33 PM, Ole Holm Nielsen
<ole.h.niel...@fysik.dtu.dk> wrote:

On 11/02/2016 12:52 PM, Åke Sandgren wrote:

env INTEL_LICENSE_FILE=port@host eb intel-2016a.eb ...

Fantastic, this worked for me!  I wonder where the usage of
license_file and/or INTEL_LICENSE_FILE within EB might be documented?

It SHOULD ;-)

There’s one caveat with the port@host approach:

One day, Intel’s practices will force you to setup a second license
server
(either because you need to setup a new flexlm server version or,
because Intel has the nasty habit of silently deprecating old
components in new licenses
and you need to point to a test instance without touching your
production instance yet)

IMHO it's a good practice to let license server's hostnames be a cname
that points to an A record, you can then still easily switch servers if
you need to by moving the cname to point to a different A record. This
also makes it easier for your users, they don't need to


Is the conclusion on the Intel license question for EasyBuild then the 
following?


* License server is OK, provided you put all Intel licenses into the 
FlexLM license file.
* Otherwise use an Intel license file (must be updated when licenses are 
renewed).


In the lack of any documentation I have found out from the module files 
generated:


* The variable INTEL_LICENSE_FILE is hardcoded into the module files 
(for example .../modules/all/icc/2016.1.150-GCC-5.4.0-2.26) and may look 
like:


 - prepend-path INTEL_LICENSE_FILE 28518@
 - prepend-path INTEL_LICENSE_FILE <...>/licenses/intel/license.lic

It would be nice to have this documented properly somewhere in the 
EasyBuild pages.


Thanks,
Ole

Re: [easybuild] How to rebuild the foss-2016b toolchain with OpenMPI including Slurm support?

[Ole Holm Nielsen]

Hi Erik,

Thanks for your input.  I already discovered that I had to add to 
OpenMPI-1.10.3-GCC-5.4.0-2.26.eb this line:


configopts += '--with-slurm --with-pmi=/usr/include/slurm 
--with-pmi-libdir=/usr '  # Support of Slurm


Question: What's the difference when you add --rebuild to --force?

I was assuming that --force would rebuild the module completely, but 
perhaps I'm mistaken?


Thanks,
Ole

On 10/28/2016 08:50 AM, Erik Smeets wrote:

Hi Ole,

We've had a similar issue, but then for PBS. I created a new eb file and added 
with-tm specifying full-path:
configopts += '--with-tm=/full/path/to/pbs '

I then installed openmpi with --force --rebuild.

For some reason when not specifying the full path it doesn't work for us at the 
moment. I still need to look at this, as it is inconvenient having to update 
this file when we upgrade PBS. At least for now it does the trick.

Regards,
Erik




-Original Message-
From: easybuild-requ...@lists.ugent.be [mailto:easybuild-
requ...@lists.ugent.be] On Behalf Of Kenneth Hoste
Sent: Wednesday, October 26, 2016 6:43 PM
To: easybuild@lists.ugent.be
Subject: Re: [easybuild] How to rebuild the foss-2016b toolchain with
OpenMPI including Slurm support?

Hi Ole,

On 26/10/16 16:03, Ole Holm Nielsen wrote:

We use the foss-2016b toolchain, and we need OpenMPI to be built with
Slurm resource manager support.  It seems that the foss-2016b build
doesn't include Slurm:

# ml OpenMPI/1.10.3-GCC-5.4.0-2.26
# ompi_info | egrep -i 'slurm|pmi'
 MCA ess: slurm (MCA v2.0.0, API v3.0.0, Component
v1.10.3)
 MCA plm: slurm (MCA v2.0.0, API v2.0.0, Component
v1.10.3)
 MCA ras: slurm (MCA v2.0.0, API v2.0.0, Component
v1.10.3)

Our multi-node MPI jobs fail miserably, and I surmise that this is due
to the lacking Slurm support.

Slurm seems to require a build of OpenMPI with 1) --with-pmi and/or 2)
--with-slurm. References:

1) https://www.mail-

archive.com/easybuild@lists.ugent.be/msg01975.html

2) https://www.open-mpi.org/faq/?category=slurm

I tried making a copy of the EB file OpenMPI-1.10.3-GCC-5.4.0-2.26.eb
and appending a line:

configopts += '--with-slurm --with-pmi '

and rebuilding the module with eb --force.  Unfortunately, the
resulting module seems *not* to include my updated configopts (looking
at the file
$EASYBUILD_PREFIX/ebfiles_repo/OpenMPI/OpenMPI-1.10.3-GCC-5.4.0-

2.26.eb).


Question: How do I rebuild the OpenMPI module with proper Slurm

support?

Rebuilding with --force should work, so for some reason your customized
EasyBuild was not picked up...
How did you provide it to EasyBuild exactly? Was it available in the local
directory where you ran the 'eb' command?

You can verify that the right easyconfig is picked up via a dry run
like: "eb OpenMPI-1.10.3-GCC-5.4.0-2.26.eb -Df", which will print the path to
the easyconfig files used.


Question: Can Slurm support please be included in future versions of
the OpenMPI module in the foss-201x tool chain?

This is a left as a site-specific customization, since including --with-slurm 
hard
would make the installation fail on any systems that do not have SLURM.

We should have documentation on how to deal with site-specific
customisations well though.
Is anyone doing that (JSC, CSCS, TAMU?) up for writing up some
documentation for this?
The existing documentation has some examples hinting towards a possible
setup:
http://easybuild.readthedocs.io/en/latest/Configuration.html#example


regards,

Kenneth

-- The information contained in this communication and any attachments is 
confidential and may be privileged, and is for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. Unless explicitly stated otherwise in the body of this 
communication or the attachment thereto (if any), the information is provided 
on an AS-IS basis without any express or implied warranties or liabilities. To 
the extent you are relying on this information, you are doing so at your own 
risk. If you are not the intended recipient, please notify the sender 
immediately by replying to this message and destroy all copies of this message 
and any attachments. The sender nor the company/group of companies he or she 
represents shall be liable for the proper and complete transmission of the 
information contained in this communication, or for any delay in its receipt.

Re: [easybuild] Intel Parallel Studio components naming convention

[Ole Holm Nielsen]

Hi Davide,

When you update EB files, could you kindly add an explanation of the 
variable INTEL_LICENSE_FILE in each EB file, given the fact that it 
doesn't seems to be documented elsewhere and everybody will need to 
customize it?


My suggestion of text for adding to all Intel EB files:

# Intel license_file must be specified.  Select a long-term valid name.
# Can be overridden by setting the environment variable
# INTEL_LICENSE_FILE before running eb.
# Absolute path example:
# license_file = HOME + '/licenses/intel/license.lic'
# License server example:
# license_file = port-number@license-server

On 11/03/2016 11:10 PM, Vanzo, Davide wrote:

as you have probably seen I am updating the easybuild files for the new
Intel Parallel Studio XE 2017 Update 1.
I started working on the other tools in the suite other than the main
ones (compilers, MPI and MKL) and I am facing a naming dilemma. All main
components easyconfigs use versioning in the 2017.1 form. That is great
because it allows me to use version_major and version_minor to generate
the source tarball name. The additional components instead use the
"update1" version naming which brakes consistency across the whole
suite. What would you think about adopting a uniform naming convention
across the whole suite (and maybe also for the toolchains that use a
preceding zero to the minor version number)?


Thanks,
Ole

[easybuild] How to rebuild the foss-2016b toolchain with OpenMPI including Slurm support?

[Ole Holm Nielsen]

We use the foss-2016b toolchain, and we need OpenMPI to be built with 
Slurm resource manager support.  It seems that the foss-2016b build 
doesn't include Slurm:


# ml OpenMPI/1.10.3-GCC-5.4.0-2.26
# ompi_info | egrep -i 'slurm|pmi'
 MCA ess: slurm (MCA v2.0.0, API v3.0.0, Component v1.10.3)
 MCA plm: slurm (MCA v2.0.0, API v2.0.0, Component v1.10.3)
 MCA ras: slurm (MCA v2.0.0, API v2.0.0, Component v1.10.3)

Our multi-node MPI jobs fail miserably, and I surmise that this is due 
to the lacking Slurm support.


Slurm seems to require a build of OpenMPI with 1) --with-pmi and/or 2) 
--with-slurm. References:


1) https://www.mail-archive.com/easybuild@lists.ugent.be/msg01975.html
2) https://www.open-mpi.org/faq/?category=slurm

I tried making a copy of the EB file OpenMPI-1.10.3-GCC-5.4.0-2.26.eb 
and appending a line:


configopts += '--with-slurm --with-pmi '

and rebuilding the module with eb --force.  Unfortunately, the resulting 
module seems *not* to include my updated configopts (looking at the file 
$EASYBUILD_PREFIX/ebfiles_repo/OpenMPI/OpenMPI-1.10.3-GCC-5.4.0-2.26.eb).


Question: How do I rebuild the OpenMPI module with proper Slurm support?

Question: Can Slurm support please be included in future versions of the 
OpenMPI module in the foss-201x tool chain?


Thanks a lot,
Ole

Re: [easybuild] How to setup EB in the global /etc/profile.d/ ?

[Ole Holm Nielsen]

On 10/13/2016 05:15 PM, Kenneth Hoste wrote:

You need to move the 'module --initial_load restore' after the 'module
use', otherwise the EasyBuild module is indeed not available.
No Catch-22 imho...

And then you shouldn't need to load the EasyBuild module again, it
should be loaded via the restore...


Confirmed!  This initialization script works correctly:

if [ -z "$__Init_Default_Modules" ]; then
   export __Init_Default_Modules=1
   export EASYBUILD_MODULES_TOOL=Lmod
   export EASYBUILD_PREFIX=/home/modules
   module use $EASYBUILD_PREFIX/modules/all
   export LMOD_SYSTEM_DEFAULT_MODULES=EasyBuild
   module --initial_load restore
...

Thanks,
Ole

Re: [easybuild] How to setup EB in the global /etc/profile.d/ ?

[Ole Holm Nielsen]

On 10/13/2016 04:27 PM, Kenneth Hoste wrote:

I'm afraid I don't have one. We don't load Easybuild by default for our
users. But you should take a look at:
https://lmod.readthedocs.io/en/latest/070_standard_modules.html


Thanks, this page is actually useful and specific!  So I've created a
new file /etc/profile.d/z01_EasyBuild.sh (to be loaded *after* Lmod's
z00_* scripts) with this content:

if [ -z "$__Init_Default_Modules" ]; then
   export __Init_Default_Modules=1;
   # module --initial_load restore
   export EASYBUILD_MODULES_TOOL=Lmod
   export EASYBUILD_PREFIX=/home/modules
   module use $EASYBUILD_PREFIX/modules/all

Is this right?

Are the modules really in /home/modules/modules/all?


Yes, I NFS-mount /home/modules, and there are 5 EB directories there:

# ls -la /home/modules
total 16
drwxrwxr-x.  7 modules modules   80 Oct 13 12:17 .
drwxr-xr-x.  3 rootroot   0 Oct 13 16:34 ..
drwxrwxr-x.  2 modules modules6 Oct 13 14:21 build
drwxrwxr-x. 35 modules modules 4096 Oct 13 14:21 ebfiles_repo
drwxrwxr-x. 15 modules modules 4096 Oct 13 13:55 modules
drwxrwxr-x. 36 modules modules 4096 Oct 13 14:21 software
drwxrwxr-x. 16 modules modules 4096 Sep 29 15:28 sources

Are you suggesting that only the "modules" subdirectory will actually be 
needed by users?  Anyway, the EB module building requires access to all 
subdirectories, so it seems convenient to have all subdirectories 
exposed this way.  Am I making any mistakes here?



The recommended line "module --initial_load restore" generates an
unwarranted message:


The system default contains no modules
  (env var: LMOD_SYSTEM_DEFAULT_MODULES is empty)
  No changes in loaded modules


so I got rid of it by commenting this line out.


Well, you need to define $LMOD_SYSTEM_DEFAULT_MODULES :)


Do I really *need* to?  What's the point, and what should I do then?


Question: Does anyone see potential problems or bad side effects with
such a global setup of EB for all users?


Having a proper default setup in place makes sense, but users can easily
override it with their own config file or via environment variables.


That sounds like a "Good Thing" for advanced users, right?


The only thing we do is load Lmod itself (a symlink to init/bash in
/etc/profile.d).


Question: How do your users initialize the usage of EB?


They can define a config file, or define environment variables
(typically via .bashrc), up to them...


Ah, so it's DIY for your users!  I'm trying to make it easy for new 
users so that they don't need to manipulate .bashrc after reading some 
web documentation...  I guess that's a matter of taste.


/Ole

Re: [easybuild] matplotlib installation fails with ImportError

[Ole Holm Nielsen]

FWIW, we build matplotlib without problems using the foss2016b 
toolchain, see the attached easyconfig file, which is based upon the 
distribution file matplotlib-1.5.2-intel-2016b-Python-2.7.12.eb.


/Ole

On 10/13/2016 11:39 AM, Kenneth Hoste wrote:

Hi Maik,

On 13/10/16 11:37, Maik Schmidt wrote:

Hi Kenneth,

thanks for your input. I have tried with matplotlib 1.5.2 and 1.5.3,
but unfortunately, the error remains the same.

The numpy version in my Python 3.5.1 is the original one from the
respective easyconfig, namely 1.10.4. The matplotlib installer even
says so under

REQUIRED DEPENDENCIES AND EXTENSIONS
 numpy: yes [version 1.10.4]

however, during the installation process, it somehow seems to have
fetched and referenced a newer version of numpy (1.11.2) in a temp
directory as can be seen in the log:

/scratch/hpcsupport/easybuild-tmp/eb-i1onxx/easy_install-v0f9q0bi/numpy-1.11.2/setup.py


So I guess this is more a problem of the installer, always trying to
use the latest numpy version or so?


That's surprising... Why would it try to download/install it's own numpy
when it found one? I've never seen that happening (but maybe I just
overlooked it).

Can you share the easyconfig files you're using?


regards,

Kenneth


Kind regards,
Maik


Am 13.10.2016 um 11:00 schrieb Kenneth Hoste:

Hi Maik,

On 13/10/16 10:43, Maik Schmidt wrote:

Hi all,

I've installed Python-3.5.1-intel-2016a.eb (with
--try-toolchain="intel,2016.03-GCC-5.3" but that shouldn't be
relevant to the problem) and am now trying to install
matplotlib-1.5.1-intel-2016a-Python-3.5.1.eb, but it always fails on
installing the extension matplotlib.

== 2016-10-13 10:31:49,338 build_log.py:163 ERROR cmd "
/sw/taurus/eb/Python/3.5.1-intel-2016.03-GCC-5.3/bin/python setup.py
build " exited with exitcode 1 and output: ...

From the log I can see that an import exception is raised:

ImportError: No module named 'numpy._build_utils'

I have attached the full log.

Is this normal? Why does it try to access numpy._build_utils anways?
Isn't this just some internal module of the numpy installer and
shouldn't even be used by other modules? Any advice on how to get
rid of this problem would be much appreciated. Thanks in advance.



This looks relevant: https://github.com/numpy/numpy/issues/6551 .

It seems to suggest that the numpy version you have included in your
Python 3.5.1 installation is too new for matplotlib 1.5.1?

Maybe try with matplotlib 1.5.2, if that's an option?


regards,

Kenneth
easyblock = 'Bundle'

name = 'matplotlib'
version = '1.5.1'
versionsuffix = '-Python-%(pyver)s'

homepage = 'http://matplotlib.org'
description = """matplotlib is a python 2D plotting library which produces 
publication quality figures in a variety of
 hardcopy formats and interactive environments across platforms. matplotlib can 
be used in python scripts, the python
 and ipython shell, web application servers, and six graphical user interface 
toolkits."""

toolchain = {'name': 'foss', 'version': '2016b'}

# this is a bundle of Python packages
exts_defaultclass = 'PythonPackage'
exts_filter = ('python -c "import %(ext_name)s"', '')

dependencies = [
('Python', '3.5.2'),
('freetype', '2.6.3'),
('libpng', '1.6.23'),
]

exts_list = [
('Cycler', '0.9.0', {
'modulename': 'cycler',
'source_urls': ['https://pypi.python.org/packages/source/C/Cycler'],
'source_tmpl': 'cycler-%(version)s.tar.gz',
}),
(name, version, {
'source_urls': ['https://pypi.python.org/packages/source/m/matplotlib'],
'patches': ['matplotlib-1.5.1_fix-Tcl-Tk-libdir.patch'],
}),
]

# specify that Bundle easyblock should run a full sanity check, rather than 
just trying to load the module
full_sanity_check = True

sanity_check_paths = {
'files': [],
'dirs': ['lib/python%(pyshortver)s/site-packages'],
}

modextrapaths = {'PYTHONPATH': ['lib/python%(pyshortver)s/site-packages']}

moduleclass = 'vis'

Re: [easybuild] matplotlib installation fails with ImportError

[Ole Holm Nielsen]

Maik, we use Python 3.5.2 with the foss2016b toolchain.
/Ole

On 10/13/2016 12:13 PM, Maik Schmidt wrote:

Kenneth,
I'm using the unmodified easyconfig files from the EasyBuild
distribution (just with a different toolchain as I mentioned in my
original mail).

https://github.com/hpcugent/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/p/Python/Python-3.5.1-intel-2016a.eb

and
https://github.com/hpcugent/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/m/matplotlib/matplotlib-1.5.1-intel-2016a-Python-3.5.1.eb


Ole,
yes, the Python 2 installation works for me, too. It's just Python 3
that seems to have this problem, no idea why...

Regards,
Maik



Am 13.10.2016 um 11:44 schrieb Ole Holm Nielsen:

FWIW, we build matplotlib without problems using the foss2016b
toolchain, see the attached easyconfig file, which is based upon the
distribution file matplotlib-1.5.2-intel-2016b-Python-2.7.12.eb.

/Ole

On 10/13/2016 11:39 AM, Kenneth Hoste wrote:

Hi Maik,

On 13/10/16 11:37, Maik Schmidt wrote:

Hi Kenneth,

thanks for your input. I have tried with matplotlib 1.5.2 and 1.5.3,
but unfortunately, the error remains the same.

The numpy version in my Python 3.5.1 is the original one from the
respective easyconfig, namely 1.10.4. The matplotlib installer even
says so under

REQUIRED DEPENDENCIES AND EXTENSIONS
 numpy: yes [version 1.10.4]

however, during the installation process, it somehow seems to have
fetched and referenced a newer version of numpy (1.11.2) in a temp
directory as can be seen in the log:

/scratch/hpcsupport/easybuild-tmp/eb-i1onxx/easy_install-v0f9q0bi/numpy-1.11.2/setup.py



So I guess this is more a problem of the installer, always trying to
use the latest numpy version or so?


That's surprising... Why would it try to download/install it's own numpy
when it found one? I've never seen that happening (but maybe I just
overlooked it).

Can you share the easyconfig files you're using?


regards,

Kenneth


Kind regards,
Maik


Am 13.10.2016 um 11:00 schrieb Kenneth Hoste:

Hi Maik,

On 13/10/16 10:43, Maik Schmidt wrote:

Hi all,

I've installed Python-3.5.1-intel-2016a.eb (with
--try-toolchain="intel,2016.03-GCC-5.3" but that shouldn't be
relevant to the problem) and am now trying to install
matplotlib-1.5.1-intel-2016a-Python-3.5.1.eb, but it always fails on
installing the extension matplotlib.

== 2016-10-13 10:31:49,338 build_log.py:163 ERROR cmd "
/sw/taurus/eb/Python/3.5.1-intel-2016.03-GCC-5.3/bin/python setup.py
build " exited with exitcode 1 and output: ...

From the log I can see that an import exception is raised:

ImportError: No module named 'numpy._build_utils'

I have attached the full log.

Is this normal? Why does it try to access numpy._build_utils anways?
Isn't this just some internal module of the numpy installer and
shouldn't even be used by other modules? Any advice on how to get
rid of this problem would be much appreciated. Thanks in advance.



This looks relevant: https://github.com/numpy/numpy/issues/6551 .

It seems to suggest that the numpy version you have included in your
Python 3.5.1 installation is too new for matplotlib 1.5.1?

Maybe try with matplotlib 1.5.2, if that's an option?


regards,

Kenneth





--
Ole Holm Nielsen
PhD, Manager of IT services
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

Re: [easybuild] How to setup EB in the global /etc/profile.d/ ?

[Ole Holm Nielsen]

On 10/13/2016 01:54 PM, Ward Poelmans wrote:

On 13-10-16 13:48, Ole Holm Nielsen wrote:

I would like to enable the EB/Lmod modules to all users in a global
bash/tcsh setup script.  On CentOS 7.2 initialization is done using
scripts in /etc/profile.d/

Basically I want every user shell to execute these commands:

export EASYBUILD_MODULES_TOOL=Lmod
export EASYBUILD_PREFIX=/home/modules
module use $EASYBUILD_PREFIX/modules/all
module load EasyBuild


The settings you can put in a global config file? Much safer then
environment variables.

For loading Easybuild by default, I would use a Lmod default collection.


Could you possibly offer a specific example of what you mean?  Like a 
complete script to put into /etc/profile.d/ ?


Thanks,
Ole

Re: [easybuild] How to setup EB in the global /etc/profile.d/ ?

[Ole Holm Nielsen]

On 10/13/2016 03:28 PM, Ward Poelmans wrote:

For loading Easybuild by default, I would use a Lmod default collection.


Could you possibly offer a specific example of what you mean?  Like a
complete script to put into /etc/profile.d/ ?


I'm afraid I don't have one. We don't load Easybuild by default for our
users. But you should take a look at:
https://lmod.readthedocs.io/en/latest/070_standard_modules.html


Thanks, this page is actually useful and specific!  So I've created a 
new file /etc/profile.d/z01_EasyBuild.sh (to be loaded *after* Lmod's 
z00_* scripts) with this content:


if [ -z "$__Init_Default_Modules" ]; then
   export __Init_Default_Modules=1;
   # module --initial_load restore
   export EASYBUILD_MODULES_TOOL=Lmod
   export EASYBUILD_PREFIX=/home/modules
   module use $EASYBUILD_PREFIX/modules/all
   module load EasyBuild
else
   module refresh
fi

This seems to do what I want: Initialize EB with the specific usage of 
Lmod and our EASYBUILD_PREFIX.  N.B.: This is on CentOS 7.2.


The recommended line "module --initial_load restore" generates an 
unwarranted message:



The system default contains no modules
  (env var: LMOD_SYSTEM_DEFAULT_MODULES is empty)
  No changes in loaded modules


so I got rid of it by commenting this line out.

Question: Does anyone see potential problems or bad side effects with 
such a global setup of EB for all users?



The only thing we do is load Lmod itself (a symlink to init/bash in
/etc/profile.d).


Question: How do your users initialize the usage of EB?

/Ole

Re: [easybuild] How to build modules compiled for different hardware architectures?

[Ole Holm Nielsen]

The present thread contains many excellent suggestions.  In order to 
keep life simple, I've chosen to maintain separate EB trees for each 
CPU-architecture.


One question remains: How to determine the current host's 
CPU-architecture.  The best solution I've been able to find is to use 
GCC 4.9 or newer:


module load GCC
gcc -march=native -Q --help=target | grep march

The architecture can be made available to users with a script 
/etc/profile.d/cpu_arch.sh (for example):


  export CPU_ARCH="broadwell"

This has been summarized in our Wiki:
https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#setting-the-cpu-hardware-architecture

/Ole

On 04-10-2016 10:06, Kenneth Hoste wrote:

On 30/09/16 18:55, Martin wrote:

I think this is a recurring question.
My impression is that "HPC" seems to somehow imply that there's a
divide in people.

With quite some exxageration:
One group wants to squeeze out every possible CPU cycle and in turn is
willing to invest the time to recompile multiple times, even within
the same CPU Family (like here Xeon v1, v2, ..., v5)
The second group (like me) would like to simply have repeatable
builds. I'd rather prefer compiling against Pentium I but have
reliable builds that will run on all the hardware that is floating around.

Is this something that should be discussed more broadly?

Maybe whether testing should include different sets of CPU Flags? I'm
pretty sure Kenneth (or UGent) can't pull this off. Something where
volunteers could maybe provide build slaves or similiar. I'm
definitely having the constant problem that some easyconfigs seem to
work very well for most people. When I do a rollout at my current
client it works only on half the nodes due to illegal instruction errors.


We tend to test things with a default configuration (well, except for
using Lmod as modules tool, which will become the default soon), so we
optimize for the architecture we're building on.

Do you have examples of stuff that fails with illegal instruction errors?

Where are you building the software to be used anywhere, and using which
configuration? Are you using --optarch=GENERIC?
cfr.
http://easybuild.readthedocs.io/en/latest/Controlling_compiler_optimization_flags.html?highlight=GENERIC#optimizing-for-a-generic-processor-architecture-via-optarch-generic

Re: [easybuild] EB 3.4 build of foss-2017b fails due to dependencies

[Ole Holm Nielsen]

Thanks a lot for your support!  Problem solved.

/Ole

On 09/18/2017 10:10 AM, Kenneth Hoste wrote:

On 18/09/2017 10:06, Åke Sandgren wrote:

Known probles as of this weekend or thereabouts.

https://github.com/easybuilders/easybuild-easyconfigs/pull/5132


I think this change was made mid-August actually...

Ole: you can dance around this problem for now using "eb 
--ignore-osdeps" to instruct EasyBuild to assume that the required OS 
dependencies *are* there.


We will fix this in the upcoming EasyBuild v3.4.1.

[easybuild] EB 3.4 build of foss-2017b fails due to dependencies

[Ole Holm Nielsen]

With EB 3.4 I have successfully built foss-2017b and iomkl/2017b. 
However, on some older nodes without Infiniband (Ethernet only) the 
build fails immediately due to dependencies:


$ eb foss-2017b.eb -r
/usr/lib/python2.7/site-packages/keyring/backends/Gnome.py:6: 
PyGIWarning: GnomeKeyring was imported without specifying a version 
first. Use gi.require_version('GnomeKeyring', '1.0') before import to 
ensure that the right version gets loaded.

  from gi.repository import GnomeKeyring
== temporary log file in case of crash /tmp/eb-6GznMR/easybuild-dxtrTV.log
== resolving dependencies ...
ERROR: Failed to process easyconfig 
/home/modules/software/EasyBuild/3.4.0/lib/python2.7/site-packages/easybuild_easyconfigs-3.4.0-py2.7.egg/easybuild/easyconfigs/o/OpenMPI/OpenMPI-2.1.1-GCC-6.4.0-2.28.eb: 
One or more OS dependencies were not found: [('libibverbs-dev', 
'libibverbs-devel')]


However, the prerequisite seems to be provided by another RPM package 
rdma-core-devel:


# yum install libibverbs-devel
...
Package rdma-core-devel-13-7.el7.x86_64 already installed and latest version
Nothing to do

Can anyone explain what's going on and how to solve the problem?

Thanks,
Ole

Re: [easybuild] Install easybuild first time

[Ole Holm Nielsen]

Hi Udo,

You might want to consult my Wiki about EasyBuild on CentOS 7:
https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules

/Ole

On 08/21/2017 09:16 AM, Udo Schmidt wrote:

Dear all,
I tried to install the latest easybuild version for  the first time. Our 
OS is CentOS 7, EASYBUILD_MODULES_TOOL='EnvironmentModulesC'

There are no problems until the first tests:

python -m test.framework.suite

There is no other output  than EE...
It looks like a simple error. Can someone give me a hint?

Re: Should we skip foss/2018a (Re: [easybuild] 2018a toolchains)

[Ole Holm Nielsen]

On 12/08/2017 12:39 PM, Alvarez, Damian wrote:

+1 for going for 18.1. But the glibc issues (not kernel issues) have been 
solved already (https://access.redhat.com/errata/RHBA-2017:3296). This package 
should find its way into CentOS 7.4 real quick (maybe it is already there, I am 
not sure).


The CentOS 7.4 package glibc-2.17-196.el7_4.2.x86_64 dated December 5 
contains the packages mentioned in the RedHat erratum.


/Ole

Re: [easybuild] EB 3.6.0: Build of iomkl-2018.02.eb fails on Intel Omni-Path systems

[Ole Holm Nielsen]

Thanks Kenneth and Bart,

On 04/30/2018 03:24 PM, Kenneth Hoste wrote:

On 30/04/2018 15:12, Ole Holm Nielsen wrote:

On 04/30/2018 02:44 PM, Bart Oldeman wrote:

Hello Ole,

the issue is here:
ld: cannot find -lpciaccess
ld: cannot find -lxml2
to solve this you can either install OS packages (.rpm, .deb, etc.) 
for libpciaccess and libxml2, and perhaps add them as OS dependencies.


Yes, I thought about this, but these packages are already present on 
the system:


# rpm -q libxml2 libpciaccess
libxml2-2.9.1-6.el7_2.3.x86_64
libpciaccess-0.13.4-3.1.el7_4.x86_64


You may need to -devel versions of these...


I confirm that the OpenMPI build problem is solved if I install these 
CentOS 7 devel libraries prior to building:


yum install libxml2-devel libpciaccess-devel

Alternatively you can put in dependencies for ('libxml2', '2.9.8') 
and ('libpciaccess', '0.13.4'), where you would need to install 
libpciaccess using GCCcore instead of an intel or foss toolchain.


So you mean that I may need to install these libraries as modules 
using EB?


Yes, that's what Bart is suggesting.

I wonder why this hasn't popped up before though...

Do you mind opening an issue on this at 
https://github.com/easybuilders/easybuild-easyconfigs/issues?


I've opened a new issue 
https://github.com/easybuilders/easybuild-easyconfigs/issues/6257. 
Maybe an extra "osdependencies" would be the preferred solution?


Thanks a lot,
Ole

On Mon, 30 Apr 2018 at 05:31, Ole Holm Nielsen 
<ole.h.niel...@fysik.dtu.dk <mailto:ole.h.niel...@fysik.dtu.dk>> wrote:


    When we build on nodes with Intel Omni-Path software installed, the
    build of "iomkl" fails:

    $ eb iomkl-2018.02.eb -r
    == temporary log file in case of crash
    /tmp/eb-MDUNmr/easybuild-UxI3tr.log
    == resolving dependencies ...
    == processing EasyBuild easyconfig
/home/modules/software/EasyBuild/3.6.0/lib/python2.7/site-packages/easybuild_easyconfigs-3.6.0-py2.7.egg/easybuild/easyconfigs/o/OpenMPI/OpenMPI-2.1.3-iccifort-2018.2.199-GCC-6.4.0-2.28.eb 


    == building and installing
    OpenMPI/2.1.3-iccifort-2018.2.199-GCC-6.4.0-2.28...
    == fetching files...
    == creating build dir, resetting environment...
    == unpacking...
    == patching...
    == preparing...
    == configuring...
    == building...
    == FAILED: Installation ended unsuccessfully (build directory:
/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28):
    build failed (first 300 chars): cmd " make -j 48 " exited with exit
    code
    2 and output:
    Making all in config
    make[1]: Entering directory
`/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/config' 



    Intel Omni-Path systems
    make[1]: Nothing to be done for `all'.
    make[1]: Leaving directory `/home/modules/build/OpenMPI/2.1.3/icc
    == Results of the build can be found in the log file(s)
    /tmp/eb-MDUNmr/easybuild-OpenMPI-2.1.3-20180430.105741.vWNYR.log
    ERROR: Build of
/home/modules/software/EasyBuild/3.6.0/lib/python2.7/site-packages/easybuild_easyconfigs-3.6.0-py2.7.egg/easybuild/easyconfigs/o/OpenMPI/OpenMPI-2.1.3-iccifort-2018.2.199-GCC-6.4.0-2.28.eb 



    failed (err: 'build failed (first 300 chars): cmd " make -j 48 " 
exited
    with exit code 2 and output:\nMaking all in config\nmake[1]: 
Entering

    directory
`/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/config\'\nmake[1]: 



    Nothing to be done for `all\'.\nmake[1]: Leaving directory
    `/home/modules/build/OpenMPI/2.1.3/icc')

    The OpenMPI error log file contains near the end:

    CCLD libopen-pal.la <http://libopen-pal.la>
    ld: cannot find -lpciaccess
    ld: cannot find -lxml2
    make[2]: *** [libopen-pal.la <http://libopen-pal.la>] Error 1
    make[2]: Leaving directory
`/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/opal' 


    make[1]: *** [all-recursive] Error 1
    make[1]: Leaving directory
`/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/opal' 


    make: *** [all-recursive] Error 1
   (at easybuild/tools/run.py:501 in parse_cmd_output)
    == 2018-04-30 11:03:17,152 easyblock.py:2702 WARNING build failed
    (first
    300 chars): cmd " make -j 48 " exited with exit code 2 and output:
    Making all in config
    make[1]: Entering directory
    `/home/modules/build/OpenMPI/2.1.3/iccifort-
    Intel Omni-Path 
systems2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/config'

    make[1]: Nothing to be done for `all'.
    make[1]: Leaving directory `/home/modules/build/OpenMPI/2.1.3/icc
    == 2018-04-30 11:03:17,152 easyblock.py:280 INFO Closing log for
    application name OpenMPI version 2.1.3


    Question: Can anyone point to the cause of this error?  Did OpenMPI
    2.1.3 introduce this error?


    Extra information: The issue
    https://github.com/easybuilders/easybuild-eas

Re: [easybuild] EB 3.6.0: Build of iomkl-2018.02.eb fails on Intel Omni-Path systems

[Ole Holm Nielsen]

On 04/30/2018 03:24 PM, Kenneth Hoste wrote:

On 30/04/2018 15:12, Ole Holm Nielsen wrote:

On 04/30/2018 02:44 PM, Bart Oldeman wrote:

Hello Ole,

the issue is here:
ld: cannot find -lpciaccess
ld: cannot find -lxml2
to solve this you can either install OS packages (.rpm, .deb, etc.) 
for libpciaccess and libxml2, and perhaps add them as OS dependencies.


Yes, I thought about this, but these packages are already present on 
the system:


# rpm -q libxml2 libpciaccess
libxml2-2.9.1-6.el7_2.3.x86_64
libpciaccess-0.13.4-3.1.el7_4.x86_64


You may need to -devel versions of these...


Good point!  The -devel versions were absent, so I installed the RPMs 
now and will redo the build.


/Ole

[easybuild] EB 3.6.0: Build of iomkl-2018.02.eb fails on Intel Omni-Path systems

[Ole Holm Nielsen]

When we build on nodes with Intel Omni-Path software installed, the 
build of "iomkl" fails:


$ eb iomkl-2018.02.eb -r
== temporary log file in case of crash /tmp/eb-MDUNmr/easybuild-UxI3tr.log
== resolving dependencies ...
== processing EasyBuild easyconfig 
/home/modules/software/EasyBuild/3.6.0/lib/python2.7/site-packages/easybuild_easyconfigs-3.6.0-py2.7.egg/easybuild/easyconfigs/o/OpenMPI/OpenMPI-2.1.3-iccifort-2018.2.199-GCC-6.4.0-2.28.eb
== building and installing 
OpenMPI/2.1.3-iccifort-2018.2.199-GCC-6.4.0-2.28...

== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== FAILED: Installation ended unsuccessfully (build directory: 
/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28): 
build failed (first 300 chars): cmd " make -j 48 " exited with exit code 
2 and output:

Making all in config
make[1]: Entering directory 
`/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/config' 
Intel Omni-Path systems

make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/modules/build/OpenMPI/2.1.3/icc
== Results of the build can be found in the log file(s) 
/tmp/eb-MDUNmr/easybuild-OpenMPI-2.1.3-20180430.105741.vWNYR.log
ERROR: Build of 
/home/modules/software/EasyBuild/3.6.0/lib/python2.7/site-packages/easybuild_easyconfigs-3.6.0-py2.7.egg/easybuild/easyconfigs/o/OpenMPI/OpenMPI-2.1.3-iccifort-2018.2.199-GCC-6.4.0-2.28.eb 
failed (err: 'build failed (first 300 chars): cmd " make -j 48 " exited 
with exit code 2 and output:\nMaking all in config\nmake[1]: Entering 
directory 
`/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/config\'\nmake[1]: 
Nothing to be done for `all\'.\nmake[1]: Leaving directory 
`/home/modules/build/OpenMPI/2.1.3/icc')


The OpenMPI error log file contains near the end:

  CCLD libopen-pal.la
ld: cannot find -lpciaccess
ld: cannot find -lxml2
make[2]: *** [libopen-pal.la] Error 1
make[2]: Leaving directory 
`/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/opal'

make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/modules/build/OpenMPI/2.1.3/iccifort-2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/opal'

make: *** [all-recursive] Error 1
 (at easybuild/tools/run.py:501 in parse_cmd_output)
== 2018-04-30 11:03:17,152 easyblock.py:2702 WARNING build failed (first 
300 chars): cmd " make -j 48 " exited with exit code 2 and output:

Making all in config
make[1]: Entering directory `/home/modules/build/OpenMPI/2.1.3/iccifort- 
Intel Omni-Path systems2018.2.199-GCC-6.4.0-2.28/openmpi-2.1.3/config'

make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/modules/build/OpenMPI/2.1.3/icc
== 2018-04-30 11:03:17,152 easyblock.py:280 INFO Closing log for 
application name OpenMPI version 2.1.3



Question: Can anyone point to the cause of this error?  Did OpenMPI 
2.1.3 introduce this error?



Extra information: The issue 
https://github.com/easybuilders/easybuild-easyconfigs/issues/5805 is 
fixed with EB 3.6.0 and OpenMPI 2.1.3.  On our systems with Mellanox 
Infiniband software installed, the line in 
OpenMPI-2.1.3-iccifort-2018.2.199-GCC-6.4.0-2.28.eb *does* fix the issue 
5805 on this platform:


configopts += '--without-ucx '  # hard disable UCX, to dance around bug 
(https://github.com/open-mpi/ompi/issues/4345)


On the Intel Omni-Path system I tried to comment out this line, but the 
build still fails with the same error.


/Ole


On 03/05/2018 03:44 PM, Åke Sandgren wrote:

To clarify, it's a bug in the OpenMPI configure script when dealing with
UCX which they haven't fixed.

On 03/05/2018 03:36 PM, Balázs Hajgató wrote:

Dear Ole,

use
configopts += '--without-ucx '

in the OpenMPI easyconfig

Sincerely,

Balazs




Thanks for any suggestions!






--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

On 05/03/2018 15:27, Ole Holm Nielsen wrote:

Using EB 3.5.2 I'm trying to build the latest iomkl:

   eb iomkl-2018a.eb -r

This works like a charm on 2 of our 3 binary architectures, but on our
Sandy Bridge nodes with Mellanox Infiniband the build aborts:

# eb iomkl-2018a.eb -r
== temporary log file in case of crash
/tmp/eb-Dnjmix/easybuild-6WeIK9.log
== resolving dependencies ...
== processing EasyBuild easyconfig
/home/modules/software/EasyBuild/3.5.2/lib/python2.7/site-packages/easybuild_easyconfigs-3.5.2-py2.7.egg/easybuild/easyconfigs/o/OpenMPI/OpenMPI-2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28.eb

== building and installing
OpenMPI/2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28...
== fetching files...
== creating build dir, resetting environment...
== unpacking...
== pa

[easybuild] iomkl-2018b toolchain availability?

[Ole Holm Nielsen]

Dear EasyBuilders,

Is anyone looking to create an EB file for the iomkl-2018b toolchain?

With iomkl-2018a and iomkl-2018.02.eb there were a couple of issues:
* https://github.com/easybuilders/easybuild-easyconfigs/issues/5805
* https://github.com/easybuilders/easybuild-easyconfigs/issues/6257
Hopefully these could be addressed some time soon?

We need the Intel compilers and MKL, but can't afford the Intel MPI 
license.  The OpenMPI works very well for us, so iomkl is the obvious 
toolchain to use.


Furthermore, we're planning an EU tender for a significant expansion of 
our cluster, and the benchmarking cases are going to be based upon 
EasyBuild!  Do other sites use EB in their procurement benchmarks as 
well, and what are the experiences?


Thanks,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark,

Re: [easybuild] iomkl-2018b toolchain availability?

[Ole Holm Nielsen]

Hi Åke,

Thanks a lot, your work on iomkl will be highly appreciated!

/Ole

On 07/16/2018 05:45 PM, Åke Sandgren wrote:

I'm working on it at the moment.

On 07/16/2018 04:11 PM, Ole Holm Nielsen wrote:

Dear EasyBuilders,

Is anyone looking to create an EB file for the iomkl-2018b toolchain?

With iomkl-2018a and iomkl-2018.02.eb there were a couple of issues:
* https://github.com/easybuilders/easybuild-easyconfigs/issues/5805
* https://github.com/easybuilders/easybuild-easyconfigs/issues/6257
Hopefully these could be addressed some time soon?

We need the Intel compilers and MKL, but can't afford the Intel MPI
license.  The OpenMPI works very well for us, so iomkl is the obvious
toolchain to use.

Furthermore, we're planning an EU tender for a significant expansion of
our cluster, and the benchmarking cases are going to be based upon
EasyBuild!  Do other sites use EB in their procurement benchmarks as
well, and what are the experiences?

Re: [easybuild] iomkl-2018b toolchain availability?

[Ole Holm Nielsen]

Hi Bart,
On 07/16/2018 05:47 PM, Bart Oldeman wrote:

Hello Ole,

as far as I can see Intel MPI is free beer now (unless you want priority 
support of course), since 2018 update 2.

That doesn't mean iomkl is useless of course!


I don't see any free beer in the official Intel MPI homepage:
https://software.intel.com/en-us/intel-mpi-library
The trial version of the software doesn't count :-)

Do you have more details about Intel making Intel MPI freely available?

Thanks,
Ole

[easybuild] Build of iomkl-2018a.eb fails

[Ole Holm Nielsen]

Using EB 3.5.2 I'm trying to build the latest iomkl:

  eb iomkl-2018a.eb -r

This works like a charm on 2 of our 3 binary architectures, but on our 
Sandy Bridge nodes with Mellanox Infiniband the build aborts:


# eb iomkl-2018a.eb -r
== temporary log file in case of crash /tmp/eb-Dnjmix/easybuild-6WeIK9.log
== resolving dependencies ...
== processing EasyBuild easyconfig 
/home/modules/software/EasyBuild/3.5.2/lib/python2.7/site-packages/easybuild_easyconfigs-3.5.2-py2.7.egg/easybuild/easyconfigs/o/OpenMPI/OpenMPI-2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28.eb
== building and installing 
OpenMPI/2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28...

== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== FAILED: Installation ended unsuccessfully (build directory: 
/home/modules/build/OpenMPI/2.1.2/iccifort-2018.1.163-GCC-6.4.0-2.28): 
build failed (first 300 chars): cmd " make -j 16 " exited with exit code 
2 and output:

Making all in config
make[1]: Entering directory 
`/home/modules/build/OpenMPI/2.1.2/iccifort-2018.1.163-GCC-6.4.0-2.28/openmpi-2.1.2/config'

make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/modules/build/OpenMPI/2.1.2/icc
...

The end of the log file 
/tmp/eb-Dnjmix/easybuild-OpenMPI-2.1.2-20180305.144907.SAFtP.log contains:


libtool:   error: require no space between '-L' and '-lrt'
make[2]: *** [libmca_pml_ucx.la] Error 1
make[2]: Leaving directory 
`/home/modules/build/OpenMPI/2.1.2/iccifort-2018.1.163-GCC-6.4.0-2.28/openmpi-2.1.2/ompi/mca/pml/ucx'

make[1]: *** [all-recursive] Error 1

I can't make out what's causing this.  Perhaps the build server has a 
library installed triggering an error?


Thanks for any suggestions!

--
Ole Holm Nielsen

Re: [easybuild] Build of iomkl-2018a.eb fails

[Ole Holm Nielsen]

Building from PR 5949 worked for me:

$ eb --from-pr 5949 OpenMPI-2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28.eb
== temporary log file in case of crash /tmp/eb-WgkLyV/easybuild-d11n9L.log
== processing EasyBuild easyconfig 
/tmp/eb-WgkLyV/files_pr5949/o/OpenMPI/OpenMPI-2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28.eb
== building and installing 
OpenMPI/2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28...

== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== testing...
== installing...
== taking care of extensions...
== postprocessing...
== sanity checking...
== cleaning up...
== creating module...
== permissions...
== packaging...
== COMPLETED: Installation ended successfully
== Results of the build can be found in the log file(s) 
/home/modules/software/OpenMPI/2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28/easybuild/easybuild-OpenMPI-2.1.2-20180306.100945.log

== Build succeeded for 1 out of 1
== Temporary log file(s) /tmp/eb-WgkLyV/easybuild-d11n9L.log* have been 
removed.

== Temporary directory /tmp/eb-WgkLyV has been removed.

Thanks a lot!
/Ole

On 03/05/2018 03:43 PM, Kenneth Hoste wrote:

Dear Ole,

See also https://github.com/easybuilders/easybuild-easyconfigs/issues/5805.

Maybe we should just include --without-ucx in the easyconfig, since the 
installation can never work for OpenMPI 2.1.1 (and 2.1.2?) with UCX 
enabled?



regards,

Kenneth

On 05/03/2018 15:36, Balázs Hajgató wrote:

Dear Ole,

use
configopts += '--without-ucx '

in the OpenMPI easyconfig

Sincerely,

Balazs


On 05/03/2018 15:27, Ole Holm Nielsen wrote:

Using EB 3.5.2 I'm trying to build the latest iomkl:

  eb iomkl-2018a.eb -r

This works like a charm on 2 of our 3 binary architectures, but on 
our Sandy Bridge nodes with Mellanox Infiniband the build aborts:


# eb iomkl-2018a.eb -r
== temporary log file in case of crash 
/tmp/eb-Dnjmix/easybuild-6WeIK9.log

== resolving dependencies ...
== processing EasyBuild easyconfig 
/home/modules/software/EasyBuild/3.5.2/lib/python2.7/site-packages/easybuild_easyconfigs-3.5.2-py2.7.egg/easybuild/easyconfigs/o/OpenMPI/OpenMPI-2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28.eb 

== building and installing 
OpenMPI/2.1.2-iccifort-2018.1.163-GCC-6.4.0-2.28...

== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== FAILED: Installation ended unsuccessfully (build directory: 
/home/modules/build/OpenMPI/2.1.2/iccifort-2018.1.163-GCC-6.4.0-2.28): build 
failed (first 300 chars): cmd " make -j 16 " exited with exit code 2 
and output:

Making all in config
make[1]: Entering directory 
`/home/modules/build/OpenMPI/2.1.2/iccifort-2018.1.163-GCC-6.4.0-2.28/openmpi-2.1.2/config' 


make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/modules/build/OpenMPI/2.1.2/icc
...

The end of the log file 
/tmp/eb-Dnjmix/easybuild-OpenMPI-2.1.2-20180305.144907.SAFtP.log 
contains:


libtool:   error: require no space between '-L' and '-lrt'
make[2]: *** [libmca_pml_ucx.la] Error 1
make[2]: Leaving directory 
`/home/modules/build/OpenMPI/2.1.2/iccifort-2018.1.163-GCC-6.4.0-2.28/openmpi-2.1.2/ompi/mca/pml/ucx' 


make[1]: *** [all-recursive] Error 1

I can't make out what's causing this.  Perhaps the build server has a 
library installed triggering an error?


Thanks for any suggestions!

Re: [easybuild] EasyBuild requires Lmod >= v6.6.3

[Ole Holm Nielsen]

On 10/15/2018 01:54 PM, Loris Bennett wrote:
...

However, I found the following information regarding a newer version of
Lmod:

   https://lists.ugent.be/wws/arc/easybuild/2018-09/msg00030.html

and will try out version 6.6.3.


The RedHat bugzilla has sent me a notification today:


Lmod-6.6.3-1.el7 has been pushed to the Fedora EPEL 7 stable repository.


So the updated Lmod RPM should appear shortly in the EPEL mirror sites.

/Ole

[easybuild] EB file for Quantum Espresso?

[Ole Holm Nielsen]

We have a request to install the Quantum Espresso code, but the 
information in 
https://easybuild.readthedocs.io/en/latest/version-specific/Supported_software.html#list-software-quantumespresso-1375 
is obsolete.


Could someone kindly correct the homepage information from www.pwscf.org 
to https://www.quantum-espresso.org/download ?


The Quantum Espresso releases can be downloaded from Gitlab:
https://gitlab.com/QEF/q-e/-/archive/qe-6.3/q-e-qe-6.3.tar.gz
https://gitlab.com/QEF/q-e/-/archive/qe-6.2.1/q-e-qe-6.2.1.tar.gz
https://gitlab.com/QEF/q-e/-/archive/qe-6.2.0/q-e-qe-6.2.0.tar.gz

Question: Does anyone have a working EB file for recent versions (>6.2) 
and preferably using the intel-2018b toolchain which includes Intel MPI 
(free version)?


There was a question about Quantum Espresso in 
https://lists.ugent.be/wws/arc/easybuild/2017-12/msg00045.html


Thanks for any help,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

Re: [easybuild] EB file for Quantum Espresso?

[Ole Holm Nielsen]

Hi Åke,

Thanks a lot, the updated PR now works correctly for me.  This installs 
both the intel and foss versions of QuantumESPRESSO:


$ ml av QuantumESPRESSO

-- /home/modules/modules/all 
---

   QuantumESPRESSO/6.3-foss-2018bQuantumESPRESSO/6.3-intel-2018b (D)

Best regards,
Ole


On 11/02/2018 02:32 PM, Åke Sandgren wrote:

Ooops...
Too much cleaning when i origiinally made them.

Try again, now with URL to wannier in place.

If you want both the intel and foss builds, just do
eb --from-pr=6593 --robot

On 11/2/18 8:53 AM, Ole Holm Nielsen wrote:

Hi Åke,

Thanks for the .eb file name and command!  If one wants also foss/2018b,
what is the corresponding command?

The build fails due to a missing wannier90-2.1.0.tar.gz file:

== processing EasyBuild easyconfig
/tmp/eb-dlK3CF/files_pr6593/q/QuantumESPRESSO/QuantumESPRESSO-6.3-intel-2018b.eb

== building and installing QuantumESPRESSO/6.3-intel-2018b...
== fetching files...
== FAILED: Installation ended unsuccessfully (build directory:
/home/modules/build/QuantumESPRESSO/6.3/intel-2018b): build failed
(first 300 chars): Couldn't find file wannier90-2.1.0.tar.gz anywhere,
and downloading it didn't work either... Paths attempted (in order):
/tmp/eb-dlK3CF/files_pr6593/q/QuantumESPRESSO/q/QuantumESPRESSO/wannier90-2.1.0.tar.gz,
/tmp/eb-dlK3CF/files_pr6593/q/QuantumESPRESSO/QuantumESPRESSO/wannier90-2.1.0.tar.gz,
/tmp/
== Results of the build can be found in the log file(s)
/tmp/eb-dlK3CF/easybuild-QuantumESPRESSO-6.3-20181102.084709.TTGIh.log
ERROR: Build of
/tmp/eb-dlK3CF/files_pr6593/q/QuantumESPRESSO/QuantumESPRESSO-6.3-intel-2018b.eb
failed (err: "build failed (first 300 chars): Couldn't find file
wannier90-2.1.0.tar.gz anywhere, and downloading it didn't work
either... Paths attempted (in order):
/tmp/eb-dlK3CF/files_pr6593/q/QuantumESPRESSO/q/QuantumESPRESSO/wannier90-2.1.0.tar.gz,
/tmp/eb-dlK3CF/files_pr6593/q/QuantumESPRESSO/QuantumESPRESSO/wannier90-2.1.0.tar.gz,>>>>>









--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

/tmp/")

Perhaps your .eb file should include the download URL?

Thanks,
Ole

On 11/01/2018 07:57 PM, Åke Sandgren wrote:

If you only want the intel build from that pr do
eb --from-pr=6593 QuantumESPRESSO-6.3-intel-2018b.eb --robot

On 11/1/18 5:04 PM, Ole Holm Nielsen wrote:

Hi Åke,

That sounds good.  Since I'm not so experienced with EasyBuild, I wonder
if you could show me the eb command to use for building Quantum Espresso
using the intel/2018b toolchain?

Thanks a lot,
Ole

On 11/01/2018 04:05 PM, Åke Sandgren wrote:

It's ok to install, the autotools thing is a small problem for mergeing
it but not for using.

On 11/1/18 3:38 PM, Ole Holm Nielsen wrote:

Hi Åke,

Thanks a lot, we need to try out your PR.  Are you saying it's OK to
install it, or is the autotools problem blocking the build?

Thanks,
Ole

On 11/01/2018 03:11 PM, Åke Sandgren wrote:

There is a pending PR for QME 6.3,
https://github.com/easybuilders/easybuild-easyconfigs/pull/6593 it
works, but we're still discussing the best approach to solve the
autotools version clash.

On 11/1/18 1:35 PM, Ole Holm Nielsen wrote:

We have a request to install the Quantum Espresso code, but the
information in
https://easybuild.readthedocs.io/en/latest/version-specific/Supported_software.html#list-software-quantumespresso-1375



is obsolete.

Could someone kindly correct the homepage information from
www.pwscf.org
to https://www.quantum-espresso.org/download ?

The Quantum Espresso releases can be downloaded from Gitlab:
https://gitlab.com/QEF/q-e/-/archive/qe-6.3/q-e-qe-6.3.tar.gz
https://gitlab.com/QEF/q-e/-/archive/qe-6.2.1/q-e-qe-6.2.1.tar.gz
https://gitlab.com/QEF/q-e/-/archive/qe-6.2.0/q-e-qe-6.2.0.tar.gz

Question: Does anyone have a working EB file for recent versions
(>6.2)
and preferably using the intel-2018b toolchain which includes Intel
MPI
(free version)?

There was a question about Quantum Espresso in
https://lists.ugent.be/wws/arc/easybuild/2017-12/msg00045.html

Thanks for any help,
Ole

Re: [easybuild] Updated Lmod RPM package needed for EasyBuild v3.7.0

[Ole Holm Nielsen]

On 27-09-2018 09:57, Ole Holm Nielsen wrote:
On 09/26/2018 09:50 PM, Kenneth Hoste wrote:> It seems like there are 
some options for getting an RPM for Lmod 6.6.3,
but it turns out it's also reasonable to drop the required version a 
bit since running the EasyBuild framework tests on top of Lmod 6.5.1 
is not revealing any issues with that version (I tried a bunch of 
versions older than Lmod 6.6.3, but this apparently wasn't one of 
them...).


Sounds great!  I note that Fedora FC28 has a very recent version: 
Lmod-7.7.35-1.fc28.x86_64


I looked at the page 
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL and 
found the Lmod package page https://src.fedoraproject.org/rpms/Lmod. 
Then I wrote to the maintainer Orion Poplawski if he would be willing to 
make his Lmod package available also in EPEL[1].


The EPEL maintainer Orion Poplawski has been very kind and responded 
quickly to my request.  There is now an EPEL build of Lmod 6.6.3 in

https://koji.fedoraproject.org/koji/buildinfo?buildID=1148094
and an RPM package for testing at
https://kojipkgs.fedoraproject.org//packages/Lmod/6.6.3/1.el7/x86_64/Lmod-6.6.3-1.el7.x86_64.rpm

Would some EasyBuild sites running CentOS 7 systems kindly test this 
Lmod RPM and report any successes or failures back to me (or directly to 
the developer, only I don't know the appropriate feedback channel).


Thanks, Ole

Re: [easybuild] Updated Lmod RPM package needed for EasyBuild v3.7.0

[Ole Holm Nielsen]

The Lmod EPEL package maintainer Orion Poplawski has advised me to file 
a bug in the RedHat bugzilla requesting a version upgrade of the Lmod 
RPM, and you can all view it here:

https://bugzilla.redhat.com/show_bug.cgi?id=1633929

If your testing of the Lmod 6.6.3 RPM is successful, or if it gives 
problems for you, or if you have any comments, please add information to 
the bugzilla page.  If you don't have a login there, I can take your 
comments and add them.


When the testing of Lmod has been successful, the updated 6.6.3 RPM 
package should appear in the official EPEL repository.


/Ole


On 09/27/2018 09:00 PM, Ole Holm Nielsen wrote:

On 27-09-2018 09:57, Ole Holm Nielsen wrote:
On 09/26/2018 09:50 PM, Kenneth Hoste wrote:> It seems like there are 
some options for getting an RPM for Lmod 6.6.3,
but it turns out it's also reasonable to drop the required version a 
bit since running the EasyBuild framework tests on top of Lmod 6.5.1 
is not revealing any issues with that version (I tried a bunch of 
versions older than Lmod 6.6.3, but this apparently wasn't one of 
them...).


Sounds great!  I note that Fedora FC28 has a very recent version: 
Lmod-7.7.35-1.fc28.x86_64


I looked at the page 
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL and 
found the Lmod package page https://src.fedoraproject.org/rpms/Lmod. 
Then I wrote to the maintainer Orion Poplawski if he would be willing 
to make his Lmod package available also in EPEL[1].


The EPEL maintainer Orion Poplawski has been very kind and responded 
quickly to my request.  There is now an EPEL build of Lmod 6.6.3 in

https://koji.fedoraproject.org/koji/buildinfo?buildID=1148094
and an RPM package for testing at
https://kojipkgs.fedoraproject.org//packages/Lmod/6.6.3/1.el7/x86_64/Lmod-6.6.3-1.el7.x86_64.rpm 



Would some EasyBuild sites running CentOS 7 systems kindly test this 
Lmod RPM and report any successes or failures back to me (or directly to 
the developer, only I don't know the appropriate feedback channel).

Re: [easybuild] Updated Lmod RPM package needed for EasyBuild v3.7.0

[Ole Holm Nielsen]

Dear Kenneth,

Thanks a lot for the answer. Since CentOS 7 is a very popular HPC 
cluster OS, it would be great to obtain an authoritative RPM package for 
Lmod as required by EasyBuild.  It's very unfortunate that EPEL hasn't 
updated the Lmod RPM in 2 years.  Your .spec file for Lmod 6.6 seems to 
me not to be very much plug-and-play :-(


If no-one can provide an Lmod 6.6.3 RPM for CentOS 7, then it would save 
us a lot of trouble if EB could still use Lmod 6.5.1 until a newer RPM 
becomes available.


Thanks a lot,
Ole


On 26-09-2018 11:38, Kenneth Hoste wrote:

Dear Ole,

We build our own Lmod RPMs so we can stay on top of recent developments.

You can find our .spec file in https://github.com/hpcugent/Lmod-UGent.

If you go back in history a bit, you should be able to find a .spec file 
for Lmod 6.x.


Of course, you'll need to customize this w.r.t. Lmod configuration & such.

I should also mention that the Lmod 6.6.3 requirement may be a bit more 
than is strictly required...
In theory a slightly older Lmod 6.x should be fine too, but I kept 
running into problems left & right when testing on top of older Lmod 6.x 
versions, so I figured going with the latest 6.x was a reasonable 
compromise (I didn't want to force people to switch to Lmod 7).


If that's a big problem, I can try and reconsider that version 
requirement to loosen it up a bit (as long as all the tests pass, that 
it), and issue a quick EasyBuild 3.7.1.


On the other hand, this is good motivation to update your Lmod 
installation, there have been *a lot* of improvements to Lmod since 
version 6.5.1 (which was released Aug 2016...).



regards,

Kenneth

On 26/09/2018 11:25, Ole Holm Nielsen wrote:

Regarding upgrading to EB 3.7.0:

On 25-09-2018 15:09, Kenneth Hoste wrote:
Note that the minimal version requirement for Lmod has been bumped to 
6.6.3.


We use CentOS 7 and the 2 years old Lmod RPM package provided by the 
EPEL repository: Lmod-6.5.1-2.el7.x86_64.rpm


Can anyone suggest the best way to get or build an RPM package of a 
recent version of Lmod [1] that works well on CentOS 7?


Thanks,
Ole

[1] https://github.com/TACC/Lmod

[easybuild] Updated Lmod RPM package needed for EasyBuild v3.7.0

[Ole Holm Nielsen]

Regarding upgrading to EB 3.7.0:

On 25-09-2018 15:09, Kenneth Hoste wrote:

Note that the minimal version requirement for Lmod has been bumped to 6.6.3.


We use CentOS 7 and the 2 years old Lmod RPM package provided by the 
EPEL repository: Lmod-6.5.1-2.el7.x86_64.rpm


Can anyone suggest the best way to get or build an RPM package of a 
recent version of Lmod [1] that works well on CentOS 7?


Thanks,
Ole

[1] https://github.com/TACC/Lmod

Re: [easybuild] Updated Lmod RPM package needed for EasyBuild v3.7.0

[Ole Holm Nielsen]

On 09/26/2018 09:50 PM, Kenneth Hoste wrote:> It seems like there are 
some options for getting an RPM for Lmod 6.6.3,
but it turns out it's also reasonable to drop the required version a bit 
since running the EasyBuild framework tests on top of Lmod 6.5.1 is not 
revealing any issues with that version (I tried a bunch of versions 
older than Lmod 6.6.3, but this apparently wasn't one of them...).


Sounds great!  I note that Fedora FC28 has a very recent version: 
Lmod-7.7.35-1.fc28.x86_64


I looked at the page 
https://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL and 
found the Lmod package page https://src.fedoraproject.org/rpms/Lmod. 
Then I wrote to the maintainer Orion Poplawski if he would be willing to 
make his Lmod package available also in EPEL[1].


I've just opened a PR to lower the required Lmod version, see 
https://github.com/easybuilders/easybuild-framework/pull/2593, to be 
included in EasyBuild v3.7.1 .


It should be safe to patch your EasyBuild 3.7.0 installation to lower 
the required Lmod version to 6.5.1 (in easybuild/tools/modules.py in the 
easybuild-framework installation).


I located this file as:

~modules/software/EasyBuild/3.7.0/lib/python2.7/site-packages/easybuild_framework-3.7.0-py2.7.egg/easybuild/tools/modules.py

and replaced the string 6.6.3 by 6.5.1.  I can now run the "eb" command 
successfully :-)


Best regards,
Ole

[1] https://fedoraproject.org/wiki/EPEL

Re: [easybuild] Canonical setup for Lmod installed via EB?

[Ole Holm Nielsen]

On 1/23/19 10:56 AM, Loris Bennett wrote:

On Centos 7 I installed EB using the system version of Lmod (6.6.3).  I
have now installed Lmod 7.3 via its easyconfig.  I now have the
directory


We could always hope that the EPEL maintainers would eventually agree to 
my request to update Lmod to 7.8 in EPEL, see 
https://bugzilla.redhat.com/show_bug.cgi?id=1651546


It might be beneficial if other sites would add arguments to my request 
in the Bugzilla, hoping that its priority might be increased.


Thanks,
Ole

Re: [easybuild] Canonical setup for Lmod installed via EB?

[Ole Holm Nielsen]

On 1/23/19 12:31 PM, Josef Dvoracek wrote:>  > On Centos 7 I installed 
EB using the system version of Lmod (6.6.3).


why not use less ancient lmod from openHPC ( ATM 
"lmod-ohpc-7.7.14-3.1.x86_64" ) ?
I consider openHPC as trusted-enough source of RPMs, especially in HPC 
env...


Where might the associated Yum repository or just the RPMs be found?

Thanks, Ole

Re: [easybuild] The fontconfig/2.12.4-GCCcore-6.4.0 module makes /usr/bin/gedit crash on CentOS 7.6

[Ole Holm Nielsen]

Hi Kenneth,

Thanks a lot for your analysis of the problem.  We have upgraded our 
modules (GPAW and ASE) to use the intel-2018b or foss-2018b toolchain 
which loads fontconfig 2.13.  This solves the problem with gedit (and 
emacs) on CentOS 7.6.


Best regards,
Ole

On 12/7/18 2:10 PM, Kenneth Hoste wrote:

Dear Ole,

Based on https://bbs.archlinux.org/viewtopic.php?id=235716, it seems 
like the solution would be to update to fontconfig 2.13.0...


In other words, the gedit build in CentOS 6 requires fontconfig 2.13.0, 
which is why it fails when an older fontconfig module is loaded.


Since the problem actually comes from Pango, one solution you can try is 
to also load Pango/1.41.1-foss-2018a (which uses fontconfig 2.12.6).


Bottom line here is that the use of $LD_LIBRARY_PATH is the troublemaker 
here, since that makes gedit pick up older fontconfig libraries...



regards,

Kenneth

On 07/12/2018 11:35, Ole Holm Nielsen wrote:
After we upgraded our login-nodes from CentOS 7.5 to 7.6, the 
/usr/bin/gedit editor suddenly crashes with an error message:


$ gedit
gedit: symbol lookup error: /lib64/libpangoft2-1.0.so.0: undefined 
symbol: FcWeightFromOpenTypeDouble


I've localized the error to the loading of any one of the following 
modules:


fontconfig/2.12.4-GCCcore-6.4.0
fontconfig/2.12.6-GCCcore-6.4.0

However, the latest module fontconfig/2.13.0-GCCcore-7.3.0 doesn't 
cause the error.


How to reproduce:

$ module load fontconfig/2.12.4-GCCcore-6.4.0
$ gedit
gedit: symbol lookup error: /lib64/libpangoft2-1.0.so.0: undefined 
symbol: FcWeightFromOpenTypeDouble


The following modules get loaded:

$ module list

Currently Loaded Modules:
   1) GCCcore/6.4.0   5) libpng/1.6.32-GCCcore-6.4.0
   2) expat/2.2.4-GCCcore-6.4.0   6) freetype/2.8-GCCcore-6.4.0
   3) bzip2/1.0.6-GCCcore-6.4.0   7) fontconfig/2.12.4-GCCcore-6.4.0
   4) zlib/1.2.11-GCCcore-6.4.0

The error goes away after unloading fontconfig/2.12.4-GCCcore-6.4.0.

I've rebuilt the fontconfig/2.12.4-GCCcore-6.4.0 module on the CentOS 
7.6 node, but the error is still the same :-(


Has anyone else encountered this problem, and possibly found a solution?

[easybuild] The fontconfig/2.12.4-GCCcore-6.4.0 module makes /usr/bin/gedit crash on CentOS 7.6

[Ole Holm Nielsen]

After we upgraded our login-nodes from CentOS 7.5 to 7.6, the 
/usr/bin/gedit editor suddenly crashes with an error message:


$ gedit
gedit: symbol lookup error: /lib64/libpangoft2-1.0.so.0: undefined 
symbol: FcWeightFromOpenTypeDouble


I've localized the error to the loading of any one of the following modules:

fontconfig/2.12.4-GCCcore-6.4.0
fontconfig/2.12.6-GCCcore-6.4.0

However, the latest module fontconfig/2.13.0-GCCcore-7.3.0 doesn't cause 
the error.


How to reproduce:

$ module load fontconfig/2.12.4-GCCcore-6.4.0
$ gedit
gedit: symbol lookup error: /lib64/libpangoft2-1.0.so.0: undefined 
symbol: FcWeightFromOpenTypeDouble


The following modules get loaded:

$ module list

Currently Loaded Modules:
  1) GCCcore/6.4.0   5) libpng/1.6.32-GCCcore-6.4.0
  2) expat/2.2.4-GCCcore-6.4.0   6) freetype/2.8-GCCcore-6.4.0
  3) bzip2/1.0.6-GCCcore-6.4.0   7) fontconfig/2.12.4-GCCcore-6.4.0
  4) zlib/1.2.11-GCCcore-6.4.0

The error goes away after unloading fontconfig/2.12.4-GCCcore-6.4.0.

I've rebuilt the fontconfig/2.12.4-GCCcore-6.4.0 module on the CentOS 
7.6 node, but the error is still the same :-(


Has anyone else encountered this problem, and possibly found a solution?

Thanks,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

Re: [easybuild] Retrospectively hiding modules / hiding by default

[Ole Holm Nielsen]

I completely agree with Loris!  I have been wanting to hide irrelevant 
modules from the listing of "module avail" for a very long time (the 
curious users can always use "module spider").  The "module list" should 
list all loaded modules, hidden or not.


At the recent Supercomputing 2018 conference I asked Davide Vanzo 
(EasyBuild) and Robert McLay (Lmod) exactly this question, and Davide's 
answer is that you must rebuild all of the module .lua files with 
--module-only and --hide-deps.  You *do not* have to rebuild the 
software itself!


It's also possible to hide modules by configuring Lmod, see the 
isVisibleHook function in 
https://lmod.readthedocs.io/en/latest/170_hooks.html


I think Davide's solution of rebuilding the module files is the simplest 
way forward.  However, it isn't trivial to do correctly on a running 
system, because you will be messing with the locations of modules in the 
.lua files which could break user jobs.  It is strongly recommended to 
make a copy of the module tree and work on this without impacting the 
production system.  When completed, you can point users to the location 
of the new module tree (on a shared file system, I presume).


This leads us to an interesting project for interested EasyBuild sites. 
Can we design some tools to perform:


1. Create a configuration file with "system" module names (not end-user 
applications) that we want to hide.  My favorites include all module 
names beginning with:
Autoconf, Automake, Autotools, Bison, CMake, LibTIFF, LibUUID, M4, Szip, 
Tcl, Tk, Tkinter, XML-Parser, XZ, bzip2, binutils, cURL, expat, flex, 
fontconfig, freetype, gettext, help2man, hwloc, lib*, ncurses, numactl, 
pkg-config, tmux, util-linux, zlib


2. Write a script that traverses all directories in 
$EASYBUILD_PREFIX/modules/all and rebuilds all the .lua files using "eb 
--module-only --hide-deps".  Maybe the above "system" module names must 
be rebuilt with --hidden, whereas end-user applications must be rebuilt 
with a --hide-deps list equal to the desired hidden modules.  I'm unsure 
of the correct logic here, but maybe EasyBuild experts can comment on this?


The "eb --help" explains how to hide modules:

 --hidden  Install 'hidden' module file(s) by prefixing their 
version with '.' (def False)
 --hide-deps=HIDE-DEPS  Comma separated list of dependencies that you 
want automatically hidden, (e.g. --hide-deps=zlib,ncurses) 
 (type comma-separated list)


Does anyone have the time and courage to work on a setup with such a 
functionality?


Best regards,
Ole


On 11/23/2018 10:17 AM, Loris Bennett wrote:

Hi Sam,

Thanks for the info about rebuilding the module files.

Regarding the visibility of modules, I just want to exclude some from
the results of 'module av'.  I assume 'module list' will still show all
the modules which are loaded, hidden or not.  That doesn't bother me,
since, as far as I know, very few of our users look at the output of
'module list' anyway.

Cheers,

Loris

Sam Moors  writes:


Hi Loris,

You can instruct EB to only rebuild the modules with the '--module-only' option.
I don't know about your second question though.

That said, are you sure you want to hide the dependencies?



I think it is useful for the users to know which deps are loaded, so
they can avoid conflicts with other modules, even if it may look
daunting to see 50+ modules loaded in some cases.

Cheers,
Sam

On Fri, Nov 23, 2018 at 8:25 AM Loris Bennett  
wrote:

  Hi,

  Now that I have installed a couple of packages with easybuild I have a
  surprising number of modules and realise that I should have been using
  --hide-deps. I have two questions about this:

  1. Is there any way to retrospectively hide modules, other than tweaking
  the module files by hand, say, rebuilding the modules?
  2. Can a set of modules be defined which will be hidden by default?

  Cheers,

  Loris

  --
  Dr. Loris Bennett (Mr.)
  ZEDAT, Freie Universität Berlin Email loris.benn...@fu-berlin.de




--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

Re: [easybuild] Retrospectively hiding modules / hiding by default

[Ole Holm Nielsen]

On 11/23/2018 11:44 AM, Alvarez, Damian wrote:

A few notes of caution when rebuilding the whole stack:

-Doing --module-only is not guaranteed to work in all cases. Sometimes 
variables are computed during the build, and might have an effect on the module 
created. EB will print a diff if the module already exist, pay attention to it.
-However, if you are reinstalling a newly hidden module, EB won't find the old 
one (since it will look for module/version, instead of module/.version) and so 
the diff won't be printed and you can potentially miss something.
-You will need to manually delete the old non-hidden modules carefully.
-You have to be careful and filter out the hidden dependencies, you can't say "eb 
$MY_EB_REPO/*eb --module-only", or you'll be recreating already existing and visible 
modules.


Thanks very much for your important words of caution!  Dragons are 
obviously lurking in this field!


In this case, hiding of existing modules seems to be an error prone or 
impossible task.  It may be better to develop an entirely new EasyBuild 
module stack from scratch.  Then one can have two disjoint module stacks 
"old" and "current" available for the users, and users should be 
migrated slowly to the "current" stack until the "old" stack can be 
removed after a year or two.  Does this sound like a good approach?


We still need documentation of EASYBUILD_HIDE_DEPS and examples of usage 
for building a new stack.



In my opinion, for a full stack makes more sense to use the rc files from lmod, 
as Markus said.


Thanks.  Robert McLay (the author of Lmod) did recommend the 
isVisibleHook though when I asked him at the Supercomputing 2018 conference.


Thanks,
Ole

Re: [easybuild] Retrospectively hiding modules / hiding by default

[Ole Holm Nielsen]

On 11/23/2018 10:44 AM, Alan O'Cais wrote:> Installing hidden modules 
after the fact won't help you here unless you
rebuild your entire stack of modules (since all modules will need to be 
rewritten to include the now-hidden dependencies). We use a config 
option to define a default set of hidden modules:


EASYBUILD_HIDE_DEPS=ANTLR,APR,APR-util,AT-SPI2-ATK,AT-SPI2-core,ATK,Autoconf,Automake,adwaita-icon-theme,ant,assimp,Bison,babl,binutils,byacc,bzip2,CUSP,Coreutils,cairo,cling,configurable-http-proxy,DB,DBus,DocBook-XML,Dyninst,dbus-glib,damageproto,ETSF_IO,Exiv2,eudev,expat,FFmpeg,FLTK,FTGL,FoX,fixesproto,fontsproto,fontconfig,freeglut,freetype,GCCcore,GDAL,GEGL,GL2PS,GLEW,GLM,GLib,GLPK,GPC,GObject-Introspection,GTI,GTK+,GTS,Gdk-Pixbuf,Ghostscript,GraphicsMagick,GtkSourceView,g2clib,g2lib,gc,gexiv2,gflags,glog,glproto,googletest,gperf,guile,grib_api,gsettings-desktop-schemas,gettext,gzip,HarfBuzz,icc,ifort,inputproto,intltool,itstool,JUnit,JSON-C,JSON-GLib,JasPer,jhbuild,kbproto,LMDB,LZO,LevelDB,LibTIFF,LibUUID,Libint,LittleCMS,libGLU,libICE,libSM,libX11,libXau,libXaw,libXcursor,libXdamage,libXdmcp,libXext,libXfixes,libXfont,libXft,libXi,libXinerama,libXmu,libXp,libXpm,libXrandr,libXrender,libXt,libXtst,libcerf,libcroco,libctl,libdap,libdrm,libdwarf,libelf,libepoxy,libevent,libffi,libfontenc,libgd,libgeotiff,libglade,libidn,libjpeg-turbo,libmatheval,libmypaint,libpng,libpciaccess,libpthread-stubs,libreadline,librsvg,libsndfile,libspatialindex,libtool,libunistring,libunwind,libyaml,libxcb,libxkbcommon,libxml2,libxslt,libyuv,M4,MATIO,Mesa,makedepend,motif,msgpack-c,NASM,NLopt,ncurses,nettle,nodejs,nvenc_sdk,nvidia,OPARI2,OTF2,PCRE,PDT,PROJ,Pango,Pmw,PnMPI,PyCairo,PyGObject,Python-Xpra,patchelf,pixman,pkg-config,pkgconfig,popt,printproto,protobuf,pscom,pybind11,Qhull,Qt,Qt5,qrupdate,randrproto,recordproto,renderproto,S-Lang,SCons,SIP,SQLite,SWIG,Serf,Szip,scrollkeeper,snappy,Tk,texinfo,UDUNITS,util-linux,vpx,wxPropertyGrid,wxWidgets,XML-Parser,XZ,XKeyboardConfig,x264,x265,xbitmaps,xcb-proto,xcb-util,xcb-util-image,xcb-util-keysyms,xcb-util-renderutil,xcb-util-wm,xextproto,xineramaproto,xorg-macros,xprop,xproto,xtrans,Yasm,zlib



Can you kindly point to any documentation of EASYBUILD_HIDE_DEPS and any 
examples of usage?  I haven't been able to find it with Google or in 
https://easybuild.readthedocs.io/en/latest/


When you define a default set of hidden modules, this only applies to 
any new modules which you build, right?  All previous unhidden modules 
will still appear in the "module avail" list, right?


Would you agree that the module stack has to be rebuilt in order to hide 
already existing modules?  There are no magic tricks?


Thanks,
Ole

Re: [easybuild] Retrospectively hiding modules / hiding by default

[Ole Holm Nielsen]

On 11/23/2018 10:53 AM, Markus Geimer wrote:> You don't even need an 
Lmod hook.  Just put something like


hide-version foo/42.0

in a global rc file evaluated by Lmod (I believe it has to be TCL).
This can easily be done after the fact.  I'm using this for quite a
while now and it works like a charm.  See also

https://lmod.readthedocs.io/en/latest/040_FAQ.html?highlight=hide-version


Thanks for suggesting the use of Lmod "hide-version" for hiding 
unwanted/obsolete/system modules from the "module avail" command!  There 
are also some useful hints in 
https://github.com/TACC/Lmod/blob/master/Transition_to_Lmod7.txt.


IMHO, this is the best available solution in stead of rebuilding your 
entire module tree from scratch (which may still be what we want to do 
in the long term).


I've written the attached script for conveniently generating a 
~/.modulerc file from a list of module name patterns which you want to 
hide.  On a CentOS 7 system with the Lmod RPM from EPEL, you can copy 
the .modulerc file to the Lmod system default file /usr/share/lmod/etc/rc.


For the record, I've also documented this procedure and the script in my 
EasyBuild Wiki page at 
https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#hiding-modules-with-lmod


/Ole
#!/bin/sh

# Create ~/.modulerc file with module hide-version information
# The hidden modules will not be shown by "module avail".
# List system-wide modulerc file by:
# $ module --config 2>&1 | grep MODULERCFILE
# MODULERCFILE /usr/share/lmod/etc/rc
MODULERC=~/.modulerc

# List available modules
TEMP=/tmp/modulerc.$$
rm -f $TEMP
module --terse --show-hidden avail > $TEMP 2>&1

# Generate a hide list

cat < $MODULERC
#%Module
# Documentation of hide-version:
# https://lmod.readthedocs.io/en/latest/040_FAQ.html?highlight=hide-version
# and https://github.com/TACC/Lmod/blob/master/Transition_to_Lmod7.txt
global env
if { [info exists env(LMOD_VERSION_MAJOR)]} {
EOF

# Define patterns for which modules to hide

cat <> $MODULERC
GCCcore-5.4.0
GCCcore-6.1.0
GCCcore/5.4.0
GCCcore/6.1.0
GCC-5.4.0-2.26
GCC-6.3.0-2.27
foss/2016a
foss-2016a
foss/2016b
foss-2016b
Autoconf
Automake
Autotools
Bison
CMake
LibTIFF
LibUUID
M4
Szip
Tcl/
Tk/
Tkinter
XML-Parser
XZ
bzip2
binutils
cURL
expat
flex
fontconfig
freetype
gettext
gompi-2016b
gompi/2016b
gperf
help2man
hwloc
libevent
libffi
libjpeg-turbo
libpng
libreadline
LibTIFF
libtool
LibUUID
libxml2
ncurses
numactl
pkg-config
tmux
util-linux
zlib
EOF

# Terminating bracket
echo "}" >> $MODULERC

echo File $MODULERC has been created

rm -f $TEMP

Re: [easybuild] Retrospectively hiding modules / hiding by default

[Ole Holm Nielsen]

(Resending because it seems that my reply got trapped by our spam-filter).
On 11/23/2018 10:53 AM, Markus Geimer wrote:
> You don't even need an Lmod hook.  Just put something like


hide-version foo/42.0

in a global rc file evaluated by Lmod (I believe it has to be TCL).
This can easily be done after the fact.  I'm using this for quite a
while now and it works like a charm.  See also

https://lmod.readthedocs.io/en/latest/040_FAQ.html?highlight=hide-version


Thanks for suggesting the use of Lmod "hide-version" for hiding 
unwanted/obsolete/system modules from the "module avail" command!  There 
are also some useful hints in 
https://github.com/TACC/Lmod/blob/master/Transition_to_Lmod7.txt.


IMHO, this is the best available solution in stead of rebuilding your 
entire module tree from scratch (which may still be what we want to do 
in the long term).


I've written the attached script for conveniently generating a 
~/.modulerc file from a list of module name patterns which you want to 
hide.  On a CentOS 7 system with the Lmod RPM from EPEL, you can copy 
the .modulerc file to the Lmod system default file /usr/share/lmod/etc/rc.


For the record, I've also documented this procedure and the script in my 
EasyBuild Wiki page at 
https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#hiding-modules-with-lmod


/Ole

#!/bin/sh

# Create ~/.modulerc file with module hide-version information
# The hidden modules will not be shown by "module avail".
# List system-wide modulerc file by:
# $ module --config 2>&1 | grep MODULERCFILE
# MODULERCFILE /usr/share/lmod/etc/rc
MODULERC=~/.modulerc

# List available modules
TEMP=/tmp/modulerc.$$
rm -f $TEMP
module --terse --show-hidden avail > $TEMP 2>&1

# Generate a hide list

cat < $MODULERC
#%Module
# Documentation of hide-version:
# https://lmod.readthedocs.io/en/latest/040_FAQ.html?highlight=hide-version
# and https://github.com/TACC/Lmod/blob/master/Transition_to_Lmod7.txt
global env
if { [info exists env(LMOD_VERSION_MAJOR)]} {
EOF

# Define patterns for which modules to hide

cat <> $MODULERC
GCCcore-5.4.0
GCCcore-6.1.0
GCCcore/5.4.0
GCCcore/6.1.0
GCC-5.4.0-2.26
GCC-6.3.0-2.27
foss/2016a
foss-2016a
foss/2016b
foss-2016b
Autoconf
Automake
Autotools
Bison
CMake
LibTIFF
LibUUID
M4
Szip
Tcl/
Tk/
Tkinter
XML-Parser
XZ
bzip2
binutils
cURL
expat
flex
fontconfig
freetype
gettext
gompi-2016b
gompi/2016b
gperf
help2man
hwloc
libevent
libffi
libjpeg-turbo
libpng
libreadline
LibTIFF
libtool
LibUUID
libxml2
ncurses
numactl
pkg-config
tmux
util-linux
zlib
EOF

# Terminating bracket
echo "}" >> $MODULERC

echo File $MODULERC has been created

rm -f $TEMP

[easybuild] EB bootstrap fails: Installed distribution setuptools 0.9.8 conflicts with requirement setuptools>=17.1

[Ole Holm Nielsen]

I'm setting up EasyBuild on a new Intel Xeon Skylake node which is 
running CentOS 7.6.  This OS comes with python-setuptools 0.9.8:


$ rpm -q python-setuptools
python-setuptools-0.9.8-7.el7.noarch

Unfortunately the EB bootstrap script for some reason is not working, 
even though the minimum version should be 0.6, see

https://easybuild.readthedocs.io/en/latest/Installation.html#required-python-packages

I get the error shown below:

$ python bootstrap_eb.py $EASYBUILD_PREFIX
[[INFO]] EasyBuild bootstrap script (version 20180531.01, MD5: 
3968c2d88c53f96523486494bca11b4c)
[[INFO]] Found Python 2.7.5 (default, Oct 30 2018, 23:45:53) ; [GCC 
4.8.5 20150623 (Red Hat 4.8.5-36)]


[[INFO]] Installation prefix /home/modules
[[INFO]] Using modules tool specified by $EASYBUILD_MODULES_TOOL: Lmod
[[INFO]] Suitable setuptools installation already found, skipping stage 0...


[[INFO]] +++ STAGE 1: installing EasyBuild in temporary dir with 
easy_install...


[[INFO]] installing EasyBuild with 'easy_install --quiet --upgrade 
--prefix=/tmp/tmp5WimMe/eb_stage1 easybuild'
[[ERROR]] Running 'easy_install --quiet --upgrade 
--prefix=/tmp/tmp5WimMe/eb_stage1 easybuild' failed: error: Installed 
distribution setuptools 0.9.8 conflicts with requirement setuptools>=17.1

Traceback (most recent call last):
  File "bootstrap_eb.py", line 360, in run_easy_install
easy_install.main(args)
  File 
"/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", 
line 1992, in main

with_ei_usage(lambda:
  File 
"/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", 
line 1979, in with_ei_usage

return f()
  File 
"/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", 
line 1996, in 

distclass=DistributionWithoutHelpCommands, **kw
  File "/usr/lib64/python2.7/distutils/core.py", line 169, in setup
raise SystemExit, "error: " + str(msg)
SystemExit: error: Installed distribution setuptools 0.9.8 conflicts 
with requirement setuptools>=17.1


I wonder hos the 17.1 requirement comes up?  Perhaps this requirement 
makes sense with Python 3.x?


Can anyone suggest a fix so that I can get started?

Thanks,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

Re: [easybuild] EB bootstrap fails: Installed distribution setuptools 0.9.8 conflicts with requirement setuptools>=17.1

[Ole Holm Nielsen]

For the record:  The problem is solved by installing this CentOS RPM 
package before bootstrapping EasyBuild:


yum install python-mock

/Ole

On 1/10/19 10:41 AM, Kenneth Hoste wrote:

Dear Ole,

Since you've also reported this at 
https://github.com/easybuilders/easybuild-framework/issues/2712, let's 
follow up there to avoid fragmenting the discussion.



regards,

Kenneth

On 10/01/2019 10:00, Ole Holm Nielsen wrote:
I'm setting up EasyBuild on a new Intel Xeon Skylake node which is 
running CentOS 7.6.  This OS comes with python-setuptools 0.9.8:


$ rpm -q python-setuptools
python-setuptools-0.9.8-7.el7.noarch

Unfortunately the EB bootstrap script for some reason is not working, 
even though the minimum version should be 0.6, see
https://easybuild.readthedocs.io/en/latest/Installation.html#required-python-packages 



I get the error shown below:

$ python bootstrap_eb.py $EASYBUILD_PREFIX
[[INFO]] EasyBuild bootstrap script (version 20180531.01, MD5: 
3968c2d88c53f96523486494bca11b4c)
[[INFO]] Found Python 2.7.5 (default, Oct 30 2018, 23:45:53) ; [GCC 
4.8.5 20150623 (Red Hat 4.8.5-36)]


[[INFO]] Installation prefix /home/modules
[[INFO]] Using modules tool specified by $EASYBUILD_MODULES_TOOL: Lmod
[[INFO]] Suitable setuptools installation already found, skipping 
stage 0...



[[INFO]] +++ STAGE 1: installing EasyBuild in temporary dir with 
easy_install...


[[INFO]] installing EasyBuild with 'easy_install --quiet --upgrade 
--prefix=/tmp/tmp5WimMe/eb_stage1 easybuild'
[[ERROR]] Running 'easy_install --quiet --upgrade 
--prefix=/tmp/tmp5WimMe/eb_stage1 easybuild' failed: error: Installed 
distribution setuptools 0.9.8 conflicts with requirement setuptools>=17.1

Traceback (most recent call last):
   File "bootstrap_eb.py", line 360, in run_easy_install
 easy_install.main(args)
   File 
"/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", 
line 1992, in main

 with_ei_usage(lambda:
   File 
"/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", 
line 1979, in with_ei_usage

 return f()
   File 
"/usr/lib/python2.7/site-packages/setuptools/command/easy_install.py", 
line 1996, in 

 distclass=DistributionWithoutHelpCommands, **kw
   File "/usr/lib64/python2.7/distutils/core.py", line 169, in setup
 raise SystemExit, "error: " + str(msg)
SystemExit: error: Installed distribution setuptools 0.9.8 conflicts 
with requirement setuptools>=17.1


I wonder hos the 17.1 requirement comes up?  Perhaps this requirement 
makes sense with Python 3.x?


Can anyone suggest a fix so that I can get started?

Thanks,
Ole

[easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

[Ole Holm Nielsen]

I'm trying to build the foss-2019a toolchain with EB 3.8.1 on a new 
Intel Skylake node (40 cores + hyperthreading = 80 cores) but it fails 
in binutils-2.31.1.eb as shown below.  I've tried to increase some 
system limits, but that doesn't seem to help.  My current limits are:


$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) 5000
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 3088986
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) 5000
open files  (-n) 2500
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 4000
cpu time   (seconds, -t) 3
max user processes  (-u) 2000
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

Output from the build process:

$ eb foss-2019a.eb -r
== temporary log file in case of crash /tmp/eb-dyNH9x/easybuild-u8cWAg.log
== resolving dependencies ...
== processing EasyBuild easyconfig 
/home/modules/software/EasyBuild/3.8.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.8.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.31.1.eb

== building and installing binutils/2.31.1...
== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== FAILED: Installation ended unsuccessfully (build directory: 
/home/modules/build/binutils/2.31.1/dummy-): build failed (first 300 
chars): cmd " env LIBS='-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64'  make 
-j 80  CFLAGS="-g -O2 -fPIC" " exited with exit code 2 and output:
make[1]: Entering directory 
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'

make[1]: Nothing to be done for `all-target'.
Configuring in ./libiberty
Config
== Results of the build can be found in the log file(s) 
/tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log
ERROR: Build of 
/home/modules/software/EasyBuild/3.8.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.8.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.31.1.eb 
failed (err: 'build failed (first 300 chars): cmd " env 
LIBS=\'-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64\'  make -j 80 
CFLAGS="-g -O2 -fPIC" " exited with exit code 2 and output:\nmake[1]: 
Entering directory 
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1\'\nmake[1]: 
Nothing to be done for `all-target\'.\nConfiguring in ./libiberty\nConfig')


Can anyone help me fix this issue?

Thanks,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

[easybuild] Re: Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

[Ole Holm Nielsen]

I should add that binutils-2.31.1.eb builds and installs without 
problems on other nodes with an identical CentOS 7.6 setup, but these 
nodes contain older Sandy Bridge and Nehalem CPUs.


/Ole

On 2/20/19 2:18 PM, Ole Holm Nielsen wrote:
I'm trying to build the foss-2019a toolchain with EB 3.8.1 on a new 
Intel Skylake node (40 cores + hyperthreading = 80 cores) but it fails 
in binutils-2.31.1.eb as shown below.  I've tried to increase some 
system limits, but that doesn't seem to help.  My current limits are:


$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) 5000
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 3088986
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) 5000
open files  (-n) 2500
pipe size    (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 4000
cpu time   (seconds, -t) 3
max user processes  (-u) 2000
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

Output from the build process:

$ eb foss-2019a.eb -r
== temporary log file in case of crash /tmp/eb-dyNH9x/easybuild-u8cWAg.log
== resolving dependencies ...
== processing EasyBuild easyconfig 
/home/modules/software/EasyBuild/3.8.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.8.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.31.1.eb 


== building and installing binutils/2.31.1...
== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== FAILED: Installation ended unsuccessfully (build directory: 
/home/modules/build/binutils/2.31.1/dummy-): build failed (first 300 
chars): cmd " env LIBS='-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64'  make 
-j 80  CFLAGS="-g -O2 -fPIC" " exited with exit code 2 and output:
make[1]: Entering directory 
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'

make[1]: Nothing to be done for `all-target'.
Configuring in ./libiberty
Config
== Results of the build can be found in the log file(s) 
/tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log
ERROR: Build of 
/home/modules/software/EasyBuild/3.8.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.8.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.31.1.eb 
failed (err: 'build failed (first 300 chars): cmd " env 
LIBS=\'-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64\'  make -j 80 
CFLAGS="-g -O2 -fPIC" " exited with exit code 2 and output:\nmake[1]: 
Entering directory 
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1\'\nmake[1]: 
Nothing to be done for `all-target\'.\nConfiguring in ./libiberty\nConfig')


Can anyone help me fix this issue?

Thanks,
Ole

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

[Ole Holm Nielsen]

On 2/20/19 2:45 PM, Åke Sandgren wrote:

What is the actual error? Look in
/tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log


It's:

$ tail /tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log
config.status: executing default commands
make[1]: Leaving directory 
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'

make: *** [all] Error 2
 (at easybuild/tools/run.py:501 in parse_cmd_output)
== 2019-02-20 14:02:45,435 easyblock.py:2870 WARNING build failed (first 
300 chars): cmd " env LIBS='-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64' 
make -j 80  CFLAGS="-g -O2 -fPIC" " exited with exit code 2 and output:
make[1]: Entering directory 
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'

make[1]: Nothing to be done for `all-target'.
Configuring in ./libiberty
Config
== 2019-02-20 14:02:45,435 easyblock.py:288 INFO Closing log for 
application name binutils version 2.31.1





On 2/20/19 2:18 PM, Ole Holm Nielsen wrote:

I'm trying to build the foss-2019a toolchain with EB 3.8.1 on a new
Intel Skylake node (40 cores + hyperthreading = 80 cores) but it fails
in binutils-2.31.1.eb as shown below.  I've tried to increase some
system limits, but that doesn't seem to help.  My current limits are:

$ ulimit -a
core file size  (blocks, -c) 0
data seg size   (kbytes, -d) 5000
scheduling priority (-e) 0
file size   (blocks, -f) unlimited
pending signals (-i) 3088986
max locked memory   (kbytes, -l) 64
max memory size (kbytes, -m) 5000
open files  (-n) 2500
pipe size    (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority  (-r) 0
stack size  (kbytes, -s) 4000
cpu time   (seconds, -t) 3
max user processes  (-u) 2000
virtual memory  (kbytes, -v) unlimited
file locks  (-x) unlimited

Output from the build process:

$ eb foss-2019a.eb -r
== temporary log file in case of crash /tmp/eb-dyNH9x/easybuild-u8cWAg.log
== resolving dependencies ...
== processing EasyBuild easyconfig
/home/modules/software/EasyBuild/3.8.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.8.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.31.1.eb

== building and installing binutils/2.31.1...
== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== FAILED: Installation ended unsuccessfully (build directory:
/home/modules/build/binutils/2.31.1/dummy-): build failed (first 300
chars): cmd " env LIBS='-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64'  make
-j 80  CFLAGS="-g -O2 -fPIC" " exited with exit code 2 and output:
make[1]: Entering directory
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'
make[1]: Nothing to be done for `all-target'.
Configuring in ./libiberty
Config
== Results of the build can be found in the log file(s)
/tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log
ERROR: Build of
/home/modules/software/EasyBuild/3.8.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.8.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.31.1.eb
failed (err: 'build failed (first 300 chars): cmd " env
LIBS=\'-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64\'  make -j 80
CFLAGS="-g -O2 -fPIC" " exited with exit code 2 and output:\nmake[1]:
Entering directory
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1\'\nmake[1]:
Nothing to be done for `all-target\'.\nConfiguring in ./libiberty\nConfig')

Can anyone help me fix this issue?

Thanks,
Ole





--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark,
Building 307, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Tel: (+45) 4525 3187 / Mobile (+45) 5180 1620

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

[Ole Holm Nielsen]

Hi Åke,

The make actually fails as shown below.  There are hundreds of configure 
and checking lines above the lines I display, and the first make command 
fails as shown in the output.


Can you suggest anything else to check?  Are there issues with AVX512 on 
Skylake, and if so, how to work around it?


FYI, the foss-2018a and foss-2018b toolchains have been built without 
problems on the Skylake node.


Thanks,
Ole


On 20-02-2019 18:01, Åke Sandgren wrote:

That's not the real problem.
You have to look through that log and figure out what it really is.
I.e., where does the make actually fail.

On 2/20/19 4:10 PM, Ole Holm Nielsen wrote:

On 2/20/19 2:45 PM, Åke Sandgren wrote:

What is the actual error? Look in
/tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log


It's:

$ tail /tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log
config.status: executing default commands
make[1]: Leaving directory
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'
make: *** [all] Error 2
  (at easybuild/tools/run.py:501 in parse_cmd_output)
== 2019-02-20 14:02:45,435 easyblock.py:2870 WARNING build failed (first
300 chars): cmd " env LIBS='-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64'
make -j 80  CFLAGS="-g -O2 -fPIC" " exited with exit code 2 and output:
make[1]: Entering directory
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'
make[1]: Nothing to be done for `all-target'.
Configuring in ./libiberty
Config
== 2019-02-20 14:02:45,435 easyblock.py:288 INFO Closing log for
application name binutils version 2.31.1

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

[Ole Holm Nielsen]

On 2/22/19 1:24 PM, Lars Viklund wrote:

A system C and C++ compiler is documented as a required dependency of EasyBuild
if you are to install toolchains with it:

   
https://easybuild.readthedocs.io/en/latest/Installation.html#required-dependencies

As such, I would argue that it's not worth declaring it up-front in 
osdependencies
in all software that needs a system compiler, particularly as the package
will be named differently on different distros.


Thanks for pointing this out!  I agree with you.

It's all too easy to miss the general EB prerequisites/dependencies when 
installing a new node.  I've added the CentOS 7 specifics to my EB Wiki 
page:

https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#easybuild-prerequisites

/Ole


From: easybuild-requ...@lists.ugent.be  on behalf 
of Ole Holm Nielsen 
Sent: Friday, February 22, 2019 09:11
To: easybuild@lists.ugent.be
Subject: Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb 
(Skylake node)

Hi Olivier,

On 2/20/19 10:18 PM, Olivier Mattelaer wrote:

I actually face the same issue.

The actual error message is this one:

configure: error: in
`/usr/local/Software/build/lm3-w091/binutils/2.31.1/dummy-/binutils-2.31.1/gold':
configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details
yes
checking whether compiling a cross-assembler... no
checking for size_t... checking locale.h usability... make[1]: ***
[configure-gold] Error 1
make[1]: *** Waiting for unfinished jobs


I guess that doing: "yum install gcc-c++" would solve the issue.
But I have not tested yet. But does it make sense to do that?


Your suggestion fixed the problem with binutils: yum install gcc-c++
Now it build correctly, and the foss-2019a build process is continuing.

What's the root cause of this issue?  I'm guessing that the EB file
.../EasyBuild/3.8.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.8.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.31.1.eb

must include gcc-c++ as an osdependencies package.

If this guess is correct, I could open an issue.

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

[Ole Holm Nielsen]

Hi Olivier,

On 2/20/19 10:18 PM, Olivier Mattelaer wrote:

I actually face the same issue.

The actual error message is this one:

configure: error: in 
`/usr/local/Software/build/lm3-w091/binutils/2.31.1/dummy-/binutils-2.31.1/gold':

configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details
yes
checking whether compiling a cross-assembler... no
checking for size_t... checking locale.h usability... make[1]: *** 
[configure-gold] Error 1

make[1]: *** Waiting for unfinished jobs


I guess that doing: "yum install gcc-c++" would solve the issue.
But I have not tested yet. But does it make sense to do that?


Your suggestion fixed the problem with binutils: yum install gcc-c++
Now it build correctly, and the foss-2019a build process is continuing.

What's the root cause of this issue?  I'm guessing that the EB file
.../EasyBuild/3.8.1/lib/python2.7/site-packages/easybuild_easyconfigs-3.8.1-py2.7.egg/easybuild/easyconfigs/b/binutils/binutils-2.31.1.eb

must include gcc-c++ as an osdependencies package.

If this guess is correct, I could open an issue.

Thanks,
Ole

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

[Ole Holm Nielsen]

Hi Olivier,

Looking further for errors in the logfile I see the same as you point out:

== 2019-02-20 14:02:32,930 build_log.py:251 INFO building...
== 2019-02-20 14:02:32,930 easyblock.py:2616 INFO Starting build step
== 2019-02-20 14:02:32,931 easyblock.py:2622 INFO Running method 
build_step part of step build
== 2019-02-20 14:02:32,931 run.py:192 INFO running cmd:  env 
LIBS='-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64'  make -j 80  CFLAGS="-g 
-O2 -fPIC"
== 2019-02-20 14:02:45,434 build_log.py:162 ERROR EasyBuild crashed with 
an error (at ?:124 in __init__): cmd " env LIBS='-Wl,-rpath=/usr/lib 
-Wl,-rpath=/usr/lib64'  make -j 80  CFLAGS="-g -O2 -fPIC" " exited with 
exit code 2 and output:
make[1]: Entering directory 
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'

make[1]: Nothing to be done for `all-target'.

...

checking for working alloca.h... checking elf-hints.h usability... 
checking locale.h usability... configure: error: in 
`/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1/gold':

configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details

...

In the binutils config.log file there are more details:

configure:5044: gcc -o conftest -g -O2 -fPICconftest.c 
-Wl,-rpath=/usr/lib -Wl,-rpath=/usr/lib64 >&5

/tmp/eb-dyNH9x/cclfs0Uf.o: In function `main':
/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1/gold/conftest.c:40: 
undefined reference to `dlsym'

collect2: error: ld returned 1 exit status
configure:5044: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "gold"
| #define PACKAGE_TARNAME "gold"
| #define PACKAGE_VERSION "0.1"
| #define PACKAGE_STRING "gold 0.1"

Also, the CentOS 7 built-in GCC is used, I don't know if that's intended:
gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC)


Can anyone shed light on this issue?

Thanks,
Ole

On 2/20/19 10:18 PM, Olivier Mattelaer wrote:

Hi Ole, Mikael,

I actually face the same issue.

The actual error message is this one:

configure: error: in 
`/usr/local/Software/build/lm3-w091/binutils/2.31.1/dummy-/binutils-2.31.1/gold':

configure: error: C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details
yes
checking whether compiling a cross-assembler... no
checking for size_t... checking locale.h usability... make[1]: *** 
[configure-gold] Error 1

make[1]: *** Waiting for unfinished jobs


I guess that doing: "yum install gcc-c++" would solve the issue.
But I have not tested yet. But does it make sense to do that?

Olivier





On 20 Feb 2019, at 21:27, Mikael Öhman <mailto:micket...@gmail.com>> wrote:


Hi Ole,

That still isn't the error; there should be the actual line, doing 
whatever compilation or linking, that failed. They just tend to be 
somewhere in middle of the huge output from the make command (even 
worse with parallel builds).
You can put the entire log in some pastebin and someone is  (probably) 
willing to take a look.


I've built the entire 2019a toolchains on skylake server (with 
AVX512), without any modifications to any configs or blocks (on a 
virtual machine though, but all CPU features were exposed to the VM)


Best regards, Mikael


On Wed, Feb 20, 2019 at 8:58 PM Ole Holm Nielsen 
mailto:ole.h.niel...@fysik.dtu.dk>> wrote:


Hi Åke,

The make actually fails as shown below.  There are hundreds of
configure
and checking lines above the lines I display, and the first make
command
fails as shown in the output.

Can you suggest anything else to check?  Are there issues with
AVX512 on
Skylake, and if so, how to work around it?

FYI, the foss-2018a and foss-2018b toolchains have been built without
problems on the Skylake node.

Thanks,
Ole


On 20-02-2019 18:01, Åke Sandgren wrote:
> That's not the real problem.
> You have to look through that log and figure out what it really is.
> I.e., where does the make actually fail.
>
> On 2/20/19 4:10 PM, Ole Holm Nielsen wrote:
>> On 2/20/19 2:45 PM, Åke Sandgren wrote:
>>> What is the actual error? Look in
>>> /tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log
>>
>> It's:
>>
>> $ tail
/tmp/eb-dyNH9x/easybuild-binutils-2.31.1-20190220.140138.qdBpn.log
>> config.status: executing default commands
>> make[1]: Leaving directory
>> `/home/modules/build/binutils/2.31.1/dummy-/binutils-2.31.1'
>> make: *** [all] Error 2
>>   (at easybuild/tools/run.py:501 in parse_cmd_output)
>> == 2019-02-20 14:02:45,435 easyblock.py:2870 WARNING build
failed (first
>> 300 chars): cmd " env LIBS='-Wl,-rpath=/usr/lib
-Wl,-rpath=/usr/lib64'
>> make -j 80  CFLAGS="-g

Re: [easybuild] Building foss-2019a fails in binutils-2.31.1.eb (Skylake node)

[Ole Holm Nielsen]

On 2/26/19 11:24 AM, Kenneth Hoste wrote:

On 22/02/2019 14:40, Ole Holm Nielsen wrote:

On 2/22/19 1:24 PM, Lars Viklund wrote:
A system C and C++ compiler is documented as a required dependency of 
EasyBuild

if you are to install toolchains with it:

https://easybuild.readthedocs.io/en/latest/Installation.html#required-dependencies 



As such, I would argue that it's not worth declaring it up-front in 
osdependencies
in all software that needs a system compiler, particularly as the 
package

will be named differently on different distros.


Thanks for pointing this out!  I agree with you.

It's all too easy to miss the general EB prerequisites/dependencies 
when installing a new node.  I've added the CentOS 7 specifics to my 
EB Wiki page:
https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#easybuild-prerequisites 




One easy thing we could do is make the binutils easyblock check whether 
both 'gcc' and 'g++' are present, and emit a clear warning if they're 
missing?
That would help significantly, since pinpointing the underlying problem 
is clearly not trivial.


Not sure we should make that a hard failure though, as there may be 
situation where not having gcc/g++ is actually fine (e.g. when 'cc' and 
'c++' compilers are available, and can be used to compile binutils).


One other option could be to detect that the build failed because g++ is 
not there (by recognizing the pattern in the configure output or in 
config.log).


Same applies for GCC(core), where you also need a system C++ compiler 
with sufficiently recent versions...


I'm definitely voting for such a check!!  This would have saved me a lot 
of time when binutils refused to build (due to my own error, as it 
turned out).  I don't know the best solution, I'll leave that to the EB 
experts.


Thanks,
Ole

[easybuild] Lmod 7.8 is now available from the EPEL repository

[Ole Holm Nielsen]

Thanks to the kind Lmod maintainer (Orion Poplawski) of the Fedora/EPEL 
repository, the Lmod version in EPEL has been updated today from 6.6.3 
to 7.8.16!  Thanks also to the people who added to the Bugzilla request 
shown below!


A modern version of Lmod has been a very long-standing wish from many 
sites running CentOS/RHEL 7.  No longer do sites need to build their own 
locally customized up-to-date version of Lmod, if they are satisfied 
with the EPEL version.


Instructions for installing Lmod from EPEL is in my Wiki:
https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#install-lmod

Best regards,
Ole

On 1/23/19 12:17 PM, Loris Bennett wrote:

On Centos 7 I installed EB using the system version of Lmod (6.6.3).  I
have now installed Lmod 7.3 via its easyconfig.  I now have the
directory


We could always hope that the EPEL maintainers would eventually agree to my
request to update Lmod to 7.8 in EPEL, see
https://bugzilla.redhat.com/show_bug.cgi?id=1651546

It might be beneficial if other sites would add arguments to my request in the
Bugzilla, hoping that its priority might be increased.


I have seconded your request.

Cheers,

Loris



--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

Re: [easybuild] Lmod 7.8 is now available from the EPEL repository

[Ole Holm Nielsen]

On 2/20/19 11:19 AM, Jure Pečar wrote:

On Wed, 20 Feb 2019 10:14:29 +0100
Ole Holm Nielsen  wrote:


Thanks to the kind Lmod maintainer (Orion Poplawski) of the Fedora/EPEL
repository, the Lmod version in EPEL has been updated today from 6.6.3
to 7.8.16!  Thanks also to the people who added to the Bugzilla request
shown below!


Good news! Any gotchas when moving from 6.6 to 7.8?


Yes, it's great to finally have a modern Lmod via an RPM installation!

I had one minor gotcha, namely an incompatible .modulerc file containing 
"hide-module zlib/1.2.8".  Removing that file solved the problem.


/Ole

Re: [easybuild] Lmod 7.8 is now available from the EPEL repository

[Ole Holm Nielsen]

On 2/20/19 11:35 AM, Kenneth Hoste wrote:

On 20/02/2019 11:25, Ole Holm Nielsen wrote:

On 2/20/19 11:19 AM, Jure Pečar wrote:

On Wed, 20 Feb 2019 10:14:29 +0100
Ole Holm Nielsen  wrote:


Thanks to the kind Lmod maintainer (Orion Poplawski) of the Fedora/EPEL
repository, the Lmod version in EPEL has been updated today from 6.6.3
to 7.8.16!  Thanks also to the people who added to the Bugzilla request
shown below!


Good news! Any gotchas when moving from 6.6 to 7.8?


Yes, it's great to finally have a modern Lmod via an RPM installation!

I had one minor gotcha, namely an incompatible .modulerc file 
containing "hide-module zlib/1.2.8".  Removing that file solved the 
problem.


Welcome to the future! (well, Lmod 7.0 was released Nov 2016, so...)


There was a substantial barrier in building one's own home-grown RPM 
package for Lmod :-(  I certainly didn't feel knowledgeable enough to 
build my own, as many other sites have done it.


Each Lmod RPM I've seen has been customized to very specific site 
setups.  The people of TACC apparently don't want to provide a public 
RPM, which is perhaps quite understandable.  So thank God for EPEL!


There's a couple of other gotchas: the format/filename of the Lmod 
spider cache file has changed, and the internal format for module 
collections has changed.


See also https://github.com/TACC/Lmod/blob/master/README.md#lmod-70 and 
https://sourceforge.net/p/lmod/mailman/message/35489261/


Thanks for the heads-up!

/Ole

Re: [easybuild] Openblas(foss) matrix issue

[Ole Holm Nielsen]

Hi Pablo,

Thanks for the good news!  For those of us who are not experts, could 
you kindly describe the commands required to update our currently 
installed OpenBLAS modules correctly?  Are there any caveats with 
updating an existing module in a toolchain (foss)?


We currently have these OpenBLAS modules installed:

$ ml av OpenBLAS/

-- /home/modules/modules/all 
---

   OpenBLAS/0.2.20-GCC-6.4.0-2.28OpenBLAS/0.3.5-GCC-8.2.0-2.31.1 (D)
   OpenBLAS/0.3.1-GCC-7.3.0-2.30

So is the update command simply this one?

eb --rebuild OpenBLAS-0.3.5-GCC-8.2.0-2.31.1.eb 
OpenBLAS-0.3.1-GCC-7.3.0-2.30.eb OpenBLAS-0.2.20-GCC-6.4.0-2.28.eb


Is the --force flag also required?

I suppose that we do not have to rebuild the ScaLAPACK modules as well?

Thanks a lot,
Ole



On 5/28/19 5:14 PM, Pablo Escobar Lopez wrote:

thank you Carlos! You did a great job figuring out this fix :)

I can confirm that after applying this patch in our cluster the issue 
seems to be solved for us. Now we pass these tests with 
"OpenBLAS/0.3.1-GCC-7.3.0-2.30":

https://github.com/eylenth/Openblas_matrix_issue
https://github.com/xianyi/BLAS-Tester

I also got a confirmation from a colleague in our user support team that 
a problem he was trying to debug with some R code is solved after this 
fix was applied.


I have sent a PR with the fix upstream:
https://github.com/easybuilders/easybuild-easyconfigs/pull/8396

In case anyone else test the workaround it would be nice if you report 
in the mailing list or in the pull request in github if it's working 
fine for you too.


regards,
Pablo


On Tue, May 28, 2019 at 2:32 PM Carlos Fenoy > wrote:


Hi,

After fighting a long time with this, we managed to get a solution
that passes both the "Openblas_matrix_issue" and "BLAS_tester" test
suites.

To solve the issue we had to apply a patch and add a new build
parameter (USE_SIMPLE_THREADED_LEVEL3=1) to OpenBLAS to make it work
with multiple openmp threads.

This is how the buildopts line looks like for us:

buildopts = ' USE_SIMPLE_THREADED_LEVEL3=1 BINARY=64 USE_THREAD=1
USE_OPENMP=1 CC="$CC" FC="$F77" DYNAMIC_ARCH=1'

And the patch, we got it from this commit on the OpenBLAS repo:

https://github.com/xianyi/OpenBLAS/commit/b14f44d2adbe1ec8ede0cdf06fb8b09f3c4b6e43
 (you
can get the patch by adding .patch at the end of the URL)

Regards,
Carlos

On Mon, May 27, 2019 at 6:15 PM Pablo Escobar Lopez
mailto:pablo.escobarlo...@unibas.ch>>
wrote:

Hi,

did anyone found a working patch or workaround for the matrix
issue when using OpenBLAS-0.3.1 ?

After a lot of try I couldn't pass the tests in
https://github.com/eylenth/Openblas_matrix_issue when using

https://github.com/easybuilders/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/o/OpenBLAS/OpenBLAS-0.3.1-GCC-7.3.0-2.30.eb
 .
No matter what patches, toolchainopts or buildopts I use (and I
have tried few different combinations) . Is anyone able to pass
the tests using openblas-0.3.1 ?

I could pass the tests using openblas-0.3.5 but upgrading my
foss/2018b toolchain would be quite messy because I use RPATH.
The less intrusive solution for my users would be to be able to
patch openblas-0.3.1 somehow but I couldn't find a working
solution. Any suggestions?

regards,
Pablo.

p.s. in a related topic, IMHO unless there is a proper
workaround I would suggest to stop providing openblas-0.3.1 with
easybuild. Right now we are distributing a broken library


On Tue, May 7, 2019 at 6:34 PM Mikael Öhman mailto:micket...@gmail.com>> wrote:

Hi Thomas,

I can also confirm these issues. I tried rebuilding
OpenBLAS+R after the fix in #7180, but I still saw the same
problems.
Very large matrix-matrix multiplications randomly gave the
wrong result. Very large errors. The larger the matrix, the
more frequent the errors.

In the end, I compiled an intel-version (but I had to remove
a few extensions that didn't build) and removed my Foss
version from our installations.

Perhaps it's related to hardware; I saw this on happen
skylake servers. I haven't had time to check if this
https://github.com/easybuilders/easybuild-easyconfigs/issues/8197
also affects 0.3.1

Best regards, Mikael


On Tue, May 7, 2019 at 6:12 PM Thomas Eylenbosch
mailto:thomas.eylenbosch@agro.basf-se.com>> wrote:

Hello

__ __

Some of our end users reported a calculation issue with
matrices when they are working with a foss/2018b module

__ __

Re: [easybuild] Unable to install Eb on CentOS 7.6

[Ole Holm Nielsen]

On 6/18/19 2:25 PM, Yann Sagon wrote:

I'm trying to install EasyBuild as user in CentOS 7.6.

I tried this procedure:
https://easybuild.readthedocs.io/en/latest/Installation.html#bootstrapping-procedure

which complains about vsc-install.


You should first check the Requirements:
https://easybuild.readthedocs.io/en/latest/Installation.html#requirements
https://easybuild.readthedocs.io/en/latest/Installation.html#required-python-packages

Then it should work just fine :-)

/Ole

[easybuild] Re: Missing features in ABINIT/8.10.3-intel-2018b

[Ole Holm Nielsen]

Hi Jean-Michel,

Thanks very much for your fine analysis of our user's attempts to 
configure ABINIT (incorrectly, as it turned out)!  I have made a copy of 
the ABINIT-8.10.3-intel-2018b.eb file and added the two configopts which 
you recommend below.


Unfortunately it seems that I miss something because the build fails due 
to a missing source file "libxml/parser.h".  Error messages in the log 
file are:


mpiifort -DHAVE_CONFIG_H -I. -I../..  -I../../src/77_ddb 
-I../../src/77_ddb -I../../src/32_util -I../../src/32_util 
-I../../src/44_abitools -I../../src/44_abitools 
-I../../src/27_toolbox_oop -I../../src/27_toolbox_oop 
-I../../src/44_abitypes_defs -I../../src/44_abitypes_defs 
-I../../src/72_response -I../../src/72_response -I../../src/16_hideleave 
-I../../src/16_hideleave -I../../src/42_parser -I../../src/42_parser 
-I../../src/55_abiutil -I../../src/55_abiutil -I../../src/41_geometry 
-I../../src/41_geometry -I../../src/45_geomoptim 
-I../../src/45_geomoptim -I../../src/12_hide_mpi -I../../src/12_hide_mpi 
-I../../src/10_defs -I../../src/10_defs -I../../src/14_hidewrite 
-I../../src/14_hidewrite -I../../src/57_iovars -I../../src/57_iovars 
-I../../src/28_numeric_noabirule -I../../src/28_numeric_noabirule 
-I../../src/incs -I../../src/incs 
-I/home/modules/software/netCDF/4.6.1-intel-2018b/include 
-I/home/modules/software/netCDF-Fortran/4.4.4-intel-2018b/include 
-I/home/modules/build/ABINIT/8.10.3/intel-2018b/abinit-8.10.3/fallbacks/exports/include 
  -free -module 
/home/modules/build/ABINIT/8.10.3/intel-2018b/abinit-8.10.3/src/mods 
-O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC -c -o 
m_mathfuncs.o m_mathfuncs.F90
effpot_xml.c(29): catastrophic error: cannot open source file 
"libxml/parser.h"

  #include 
^
compilation aborted for effpot_xml.c (code 4)

Can you help adding the missing file to the build somehow?

Thanks a lot,
Ole


On 8/26/19 6:45 PM, Jean-Michel Beuken wrote:

Add blue lines in ABINIT/8.10.3-intel-2018b config

-

# ensure mpi and intel toolchain
configopts = '--enable-mpi '

*# xml support*
*configopts += '--enable-xml '*
*
*
*# openmp support*
*configopts += '--enable-openmp '*

# linalg & fft




--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

[easybuild] Re: Missing features in ABINIT/8.10.3-intel-2018b

[Ole Holm Nielsen]

Hi Jean-Michel,

On 8/27/19 11:24 AM, Jean-Michel Beuken wrote:

it seems a problem of dependency...

you need to install  ( for CentOS )

libxml2-2.9.1-6.el7_2.3.x86_64
libxml2-devel-2.9.1-6.el7_2.3.x86_64

and add this two environment variables in the config file

configopts += 'CFLAGS_EXTRA="-I/usr/include/libxml2" '
configopts += 'FC_LIBS_EXTRA="-lxml2 -lz -lm -ldl" '


Actually we already have the libxml2 EB module installed, so I changed 
ABINIT-8.10.3-intel-2018b.eb to contain an extra line for a libxml2 
dependency and added your suggested configopts lines:


...
dependencies = [
('libxc', '3.0.1'),
('netCDF', '4.6.1'),
('netCDF-Fortran', '4.4.4'),
('HDF5', '1.10.2'),
('Wannier90', '2.0.1.1', '-abinit'),
('AtomPAW', '4.1.0.5'),
('libxml2', '2.9.8'),
]

# ensure mpi and intel toolchain
configopts = '--enable-mpi '

# xml support
configopts += '--enable-xml '
configopts += 'FC_LIBS_EXTRA="-lxml2 -lz -lm -ldl" '

# openmp support
configopts += '--enable-openmp '
...

Now ABINIT builds successfully!  Do you think it is a good idea to add 
the XML support to the ABINIT .eb file in EasyBuild?


Thanks a lot for your support!

Best regards,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

[easybuild] Re: Missing features in ABINIT/8.10.3-intel-2018b

[Ole Holm Nielsen]

Hi Jean-Michel,

Our user requiring ABINIT with XML has now hit a new error:

--- !ERROR
src_file: m_pspheads.F90
src_line: 226
mpi_rank: 0
message: |
XML norm-conserving pseudopotential has been input, but abinit is 
not compiled with libPSML support. Reconfigure and recompile.

...

Question: How do I build ABINIT with libpsml support?

I noticed that EB includes an old libpsml version:

$ eb -S libpsml
CFGS1=/home/modules/software/EasyBuild/3.9.4/lib/python2.7/site-packages/easybuild_easyconfigs-3.9.4-py2.7.egg/easybuild/easyconfigs/l/libpsml
 * $CFGS1/libpsml-1.1.7-foss-2016b.eb
 * $CFGS1/libpsml-1.1.7-foss-2017a.eb

Maybe such a module could be used?

Thanks,
Ole

On 8/27/19 12:47 PM, Ole Holm Nielsen wrote:

Hi Jean-Michel,

On 8/27/19 11:24 AM, Jean-Michel Beuken wrote:

it seems a problem of dependency...

you need to install  ( for CentOS )

libxml2-2.9.1-6.el7_2.3.x86_64
libxml2-devel-2.9.1-6.el7_2.3.x86_64

and add this two environment variables in the config file

configopts += 'CFLAGS_EXTRA="-I/usr/include/libxml2" '
configopts += 'FC_LIBS_EXTRA="-lxml2 -lz -lm -ldl" '


Actually we already have the libxml2 EB module installed, so I changed 
ABINIT-8.10.3-intel-2018b.eb to contain an extra line for a libxml2 
dependency and added your suggested configopts lines:


...
dependencies = [
     ('libxc', '3.0.1'),
     ('netCDF', '4.6.1'),
     ('netCDF-Fortran', '4.4.4'),
     ('HDF5', '1.10.2'),
     ('Wannier90', '2.0.1.1', '-abinit'),
     ('AtomPAW', '4.1.0.5'),
     ('libxml2', '2.9.8'),
]

# ensure mpi and intel toolchain
configopts = '--enable-mpi '

# xml support
configopts += '--enable-xml '
configopts += 'FC_LIBS_EXTRA="-lxml2 -lz -lm -ldl" '

# openmp support
configopts += '--enable-openmp '
...

Now ABINIT builds successfully!  Do you think it is a good idea to add 
the XML support to the ABINIT .eb file in EasyBuild?


Thanks a lot for your support!

Best regards,
Ole

Re: [easybuild] Re: Missing features in ABINIT/8.10.3-intel-2018b

[Ole Holm Nielsen]

Hi Yann,

Thanks very much for your insightful advice!  I've modified 
ABINIT-8.10.3-intel-2018b.eb to contain flags pointing to the CentOS 
system libxml2 headers:


dependencies = [
('libxc', '3.0.1'),
('netCDF', '4.6.1'),
('netCDF-Fortran', '4.4.4'),
('HDF5', '1.10.2'),
('Wannier90', '2.0.1.1', '-abinit'),
('AtomPAW', '4.1.0.5'),
]

# ensure mpi and intel toolchain
configopts = '--enable-mpi '

# xml support
configopts += '--enable-xml '
configopts += 'CFLAGS_EXTRA="-I/usr/include/libxml2" '
configopts += 'FC_LIBS_EXTRA="-lxml2 -lz -lm -ldl" '

# openmp support
configopts += '--enable-openmp '
...

The RPM packages were already installed on our CentOS 7.6 system:

$ rpm -q libxml2 libxml2-devel
libxml2-2.9.1-6.el7_2.3.x86_64
libxml2-devel-2.9.1-6.el7_2.3.x86_64

Unfortunately, the build now crashes with this error in the log file:

mpiifort -DHAVE_CONFIG_H -I. -I../..  -I../../src/77_ddb 
-I../../src/77_ddb -I../../src/32_util -I../../src/32_util 
-I../../src/44_abitools -I../../src/44_abitools 
-I../../src/27_toolbox_oop -I../../src/27_toolbox_oop 
-I../../src/44_abitypes_defs -I../../src/44_abitypes_defs 
-I../../src/72_response -I../../src/72_response -I../../src/16_hideleave 
-I../../src/16_hideleave -I../../src/42_parser -I../../src/42_parser 
-I../../src/55_abiutil -I../../src/55_abiutil -I../../src/41_geometry 
-I../../src/41_geometry -I../../src/45_geomoptim 
-I../../src/45_geomoptim -I../../src/12_hide_mpi -I../../src/12_hide_mpi 
-I../../src/10_defs -I../../src/10_defs -I../../src/14_hidewrite 
-I../../src/14_hidewrite -I../../src/57_iovars -I../../src/57_iovars 
-I../../src/28_numeric_noabirule -I../../src/28_numeric_noabirule 
-I../../src/incs -I../../src/incs 
-I/home/modules/software/netCDF/4.6.1-intel-2018b/include 
-I/home/modules/software/netCDF-Fortran/4.4.4-intel-2018b/include 
-I/home/modules/build/ABINIT/8.10.3/intel-2018b/abinit-8.10.3/fallbacks/exports/include 
  -free -module 
/home/modules/build/ABINIT/8.10.3/intel-2018b/abinit-8.10.3/src/mods 
-O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC -c -o 
m_spin_reciprocal.o m_spin_reciprocal.F90
m_multibinit_dataset.F90(2032): remark #8291: Recommended relationship 
between field width 'W' and the number of fractional digits 'D' in this 
edit descriptor is 'W>=D+7'.


if(multibinit_dtset%strcpling==2)write(nunit,'(3x,a9,3es8.2)')'delta_df',multibinit_dtset%delta_df
---^
effpot_xml.c(29): catastrophic error: cannot open source file 
"libxml/parser.h"

  #include 
^
compilation aborted for effpot_xml.c (code 4)

The missing source file libxml/parser.h is actually installed on the system:

$ rpm -qf /usr/include/libxml2/libxml/parser.h
libxml2-devel-2.9.1-6.el7_2.3.x86_64

Could you kindly suggest some additional configopts to solve this problem?

Thanks a lot,
Ole

On 8/27/19 11:33 PM, Yann Pouillon wrote:

Dear Ole,

If you use the --enable-xml option, the configure script of ABINIT assumes
that you have the development files of LibXML2 installed on your system.

I don't know if there is a specific EasyConfig for LibXML2 or if this should
be marked as "system dependency". In any case, EasyBuild should be informed
that the XML header files are required.

Re: [easybuild] Re: Missing features in ABINIT/8.10.3-intel-2018b

[Ole Holm Nielsen]

Hi Yann,

I now have these lines in the .eb file:

# xml support
configopts += '--enable-xml '
configopts += 'CFLAGS_EXTRA="-I/usr/include/libxml2" '
configopts += 'CPPFLAGS_EXTRA="-I/usr/include/libxml2" '
configopts += 'FC_LIBS_EXTRA="-lxml2 -lz -lm -ldl" '

but unfortunately I still get the same error about the missing file:

mpiifort -DHAVE_CONFIG_H -I. -I../..  -I../../src/77_ddb 
-I../../src/77_ddb -I../../src/32_util -I../../src/32_util 
-I../../src/44_abitools -I../../src/44_abitools 
-I../../src/27_toolbox_oop -I../../src/27_toolbox_oop 
-I../../src/44_abitypes_defs -I../../src/44_abitypes_defs 
-I../../src/72_response -I../../src/72_response -I../../src/16_hideleave 
-I../../src/16_hideleave -I../../src/42_parser -I../../src/42_parser 
-I../../src/55_abiutil -I../../src/55_abiutil -I../../src/41_geometry 
-I../../src/41_geometry -I../../src/45_geomoptim 
-I../../src/45_geomoptim -I../../src/12_hide_mpi -I../../src/12_hide_mpi 
-I../../src/10_defs -I../../src/10_defs -I../../src/14_hidewrite 
-I../../src/14_hidewrite -I../../src/57_iovars -I../../src/57_iovars 
-I../../src/28_numeric_noabirule -I../../src/28_numeric_noabirule 
-I../../src/incs -I../../src/incs 
-I/home/modules/software/netCDF/4.6.1-intel-2018b/include 
-I/home/modules/software/netCDF-Fortran/4.4.4-intel-2018b/include 
-I/home/modules/build/ABINIT/8.10.3/intel-2018b/abinit-8.10.3/fallbacks/exports/include 
  -free -module 
/home/modules/build/ABINIT/8.10.3/intel-2018b/abinit-8.10.3/src/mods 
-O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC -c -o 
m_spin_hist.o m_spin_hist.F90
mpiifort -DHAVE_CONFIG_H -I. -I../..  -I../../src/77_ddb 
-I../../src/77_ddb -I../../src/32_util -I../../src/32_util 
-I../../src/44_abitools -I../../src/44_abitools 
-I../../src/27_toolbox_oop -I../../src/27_toolbox_oop 
-I../../src/44_abitypes_defs -I../../src/44_abitypes_defs 
-I../../src/72_response -I../../src/72_response -I../../src/16_hideleave 
-I../../src/16_hideleave -I../../src/42_parser -I../../src/42_parser 
-I../../src/55_abiutil -I../../src/55_abiutil -I../../src/41_geometry 
-I../../src/41_geometry -I../../src/45_geomoptim 
-I../../src/45_geomoptim -I../../src/12_hide_mpi -I../../src/12_hide_mpi 
-I../../src/10_defs -I../../src/10_defs -I../../src/14_hidewrite 
-I../../src/14_hidewrite -I../../src/57_iovars -I../../src/57_iovars 
-I../../src/28_numeric_noabirule -I../../src/28_numeric_noabirule 
-I../../src/incs -I../../src/incs 
-I/home/modules/software/netCDF/4.6.1-intel-2018b/include 
-I/home/modules/software/netCDF-Fortran/4.4.4-intel-2018b/include 
-I/home/modules/build/ABINIT/8.10.3/intel-2018b/abinit-8.10.3/fallbacks/exports/include 
  -free -module 
/home/modules/build/ABINIT/8.10.3/intel-2018b/abinit-8.10.3/src/mods 
-O2 -xHost -ftz -fp-speculation=safe -fp-model source -fPIC -c -o 
m_spin_reciprocal.o m_spin_reciprocal.F90
m_multibinit_dataset.F90(2032): remark #8291: Recommended relationship 
between field width 'W' and the number of fractional digits 'D' in this 
edit descriptor is 'W>=D+7'.


if(multibinit_dtset%strcpling==2)write(nunit,'(3x,a9,3es8.2)')'delta_df',multibinit_dtset%delta_df
---^
effpot_xml.c(29): catastrophic error: cannot open source file 
"libxml/parser.h"

  #include 
^

compilation aborted for effpot_xml.c (code 4)

Do you have any other suggestions?

Thanks,
Ole


On 8/28/19 12:42 PM, Yann Pouillon wrote:

On Wed, 28 Aug 2019 12:11:44 +0200
Ole Holm Nielsen  wrote:


Unfortunately, the build now crashes with this error in the log file:

[...]

---^
effpot_xml.c(29): catastrophic error: cannot open source file
"libxml/parser.h"
#include 
  ^
compilation aborted for effpot_xml.c (code 4)

The missing source file libxml/parser.h is actually installed on the system:

$ rpm -qf /usr/include/libxml2/libxml/parser.h
libxml2-devel-2.9.1-6.el7_2.3.x86_64

Could you kindly suggest some additional configopts to solve this problem?


I hadn't realized this is ABINIT 8.10.3, where the build system still has
some issues with mixing C and Fortran.

The following configopt might help:

   CPPFLAGS_EXTRA="-I/usr/include/libxml2"

It will be automatically searched for in future versions.

[easybuild] Missing features in ABINIT/8.10.3-intel-2018b

[Ole Holm Nielsen]

Could I ask any ABINIT/EasyBuild experts out there for help in adding 
some features to the ABINIT/8.10.3-intel-2018b module installed with 
EasyBuild?


We have an ABINIT user who wrote to me about some features which he is 
missing, and which were apparently described during the "ABINIT Hands-on 
2019" session named "Installing ABINIT":


But for PAW based datasets only ‘.xml’ formatted pseudopotentials are available. So we need to activate ‘xml’ during configure. 


Listed below please find suggested setups during configure (xml, LAPACK, libxc 
are necessary, mpi and OpenMP are suggested and can work together, I'm not sure 
the compilers, CXX=mpicxx, FC=mpif90, CC=mpicc are suitable for our platform or 
not):

./configure --prefix=/path/to/be/installed \
--enable-xml=yes \
--enable-LAPACK=yes \
--enable-libxc=yes \
--enable-mpi=yes \
--enable-OpenMP=yes \
--enable-FFTW=yes \
--enable-64bit-flags \
--enable-netcdf=yes \
--with-dft-flavor=libxc \
--with-linalg-flavor=netCDF \
--enable-bigdft=yes \
--with-trio-flavor=netcdf \
--with-timer-flavor=abinit \
CXX=mpicxx FC=mpif90 CC=mpicc \


I'm not sure if this request is simple to satisfy, and whether one just 
needs to add something to the file 
$CFGS1/a/ABINIT/ABINIT-8.10.3-intel-2018b.eb.  Under any circumstances I 
need an ABINIT expert to review the above request and suggest possible 
ways in which we can satisfy our user.


Thanks for sharing any insights!

/Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

Re: [easybuild] EasyBuild in a heterogeneous HPC centre

[Ole Holm Nielsen]

Hi Douglas,

For our Linux cluster with 4 generations of hardware, I chose to make 
completely separate module trees for each type.


IMHO, this is the simplest and most easily maintainable solution, 
although it is slightly wasteful of storage space on our central NFS 
server.  It has worked well for several years now.


I documented my approach in a Wiki page:
https://wiki.fysik.dtu.dk/niflheim/EasyBuild_modules#automounting-the-cpu-architecture-dependent-modules-directory

Best regards,
Ole

On 11/7/19 12:57 PM, Douglas Scofield wrote:

We are curious how to maintain architecture-specific EasyBuild trees.  We are 
new to EasyBuild and already have many, many (mostly bioinformatics) tools 
installed in hand-maintained module and software trees.  In our centre, we have 
clusters running Sandy Bridge EP, Haswell EP, and Broadwell EP.  Most of our 
users are on Broadwell, so we if we compile with -march=native etc., we compile 
for Broadwell and for Sandy Bridge, which covers it and Haswell.

In our standard module tree we manage architecture automatically, keying off a 
$Cluster variable set by the module system.  We handle architectures as if we 
had modules versioned Tool/Version/Architecture, with the last bit hidden from 
the user.

We have also decided to (mostly) hide our EasyBuild tree from the user, and 
instead provide access to EasyBuild-built tools using what we are calling alias 
modules, which we place in our standard module tree.  An alias module performs 
a 'module use' of the easybuild tree and then loads the appropriate 
EasyBuild-built modules.  The large majority of our users do not care about 
toolchains, etc.  Those that do, we will have docs they can consult for working 
with EasyBuild modules directly.  The very large majority of our installed 
tools do not currently have easyconfigs.

We are guessing that our architecture solution with EasyBuild will end up being 
completely separate EasyBuild trees, accessed using distinct 'module use' 
paths.  The EasyBuild docs point to a 2015 presentation by Pablo Escobar 
describing an automounter solution which we are definitely not going to 
implement, but this suggests completely separate trees as well.

How is this typically handled by other centres ?

Thanks in advance,

Douglas
—
Douglas G. Scofield
Evolutionary Biology Centre, Uppsala University
douglas.scofi...@ebc.uu.se
douglasgscofi...@gmail.com









När du har kontakt med oss på Uppsala universitet med e-post så innebär det att 
vi behandlar dina personuppgifter. För att läsa mer om hur vi gör det kan du 
läsa här: http://www.uu.se/om-uu/dataskydd-personuppgifter/

E-mailing Uppsala University means that we will process your personal data. For 
more information on how this is performed, please read here: 
http://www.uu.se/en/about-uu/data-protection-policy



--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark,
Fysikvej Building 309, DK-2800 Kongens Lyngby, Denmark
E-mail: ole.h.niel...@fysik.dtu.dk
Homepage: http://dcwww.fysik.dtu.dk/~ohnielse/
Mobile: (+45) 5180 1620

[easybuild] GULP installation by EasyBuild?

[Ole Holm Nielsen]

Dear Easybuilders,

We have a user request to install the GULP materials simulation package 
from http://gulp.curtin.edu.au/gulp/


No GULP module is found on the EasyBuild list of software, so I would like 
to ask if anyone has already created a .eb file for GULP?


Thanks a lot,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

[easybuild] Lmod upgrade to version 8.2

[Ole Holm Nielsen]

Dear Easybuilders,

For those of you who prefer to install Lmod from a public repository, the 
Fedora EPEL now provides a fairly new Lmod version 8.2.7, see

https://bugzilla.redhat.com/show_bug.cgi?id=1777262

You may use Yum to update Lmod from the EPEL repository, or you may find 
the EL7 package here:

https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/l/Lmod-8.2.7-1.el7.x86_64.rpm

Please note that Lmod releases are made very frequently, see 
https://github.com/TACC/Lmod.  But it's good for us to be tracking the 
Lmod developments regularly.


--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

[easybuild] Failure when building GCCcore/8.2.0

[Ole Holm Nielsen]

I'm making slow progress on building the foss-2019a toolchain (for our 
GPAW module GPAW-19.8.1-foss-2019a-Python-3.7.2.eb) on a Intel Xeon Gold 
6230 CPU (Cascade Lake) running CentOS 7.6.


I fixed the isl issue described in 
https://github.com/easybuilders/easybuild-easyconfigs/issues/9692 before 
building GCCcore-8.2.0.eb.


After a very long time, the build process repeatedly aborts with an error:
  * collect2: fatal error: ld terminated with signal 7 [Bus error]
with this output:

== processing EasyBuild easyconfig 
/groups/others/ohni/skylake/software/EasyBuild/4.1.1/easybuild/easyconfigs/g/GCCcore/GCCcore-8.2.0.eb

== building and installing GCCcore/8.2.0...
== fetching files...
== creating build dir, resetting environment...
== unpacking...
== patching...
== preparing...
== configuring...
== building...
== FAILED: Installation ended unsuccessfully (build directory: 
/groups/others/ohni/skylake/build/GCCcore/8.2.0/system-system): build 
failed (first 300 chars): cmd " make -j 2  bootstrap " exited with exit 
code 2 and output:

echo stage3 > stage_final
make[1]: Entering directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj'
make[2]: Entering directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-syst (took 1 
hour 18 min 33 sec)
== Results of the build can be found in the log file(s) 
/tmp/eb-CLzF4F/easybuild-GCCcore-8.2.0-20200124.145944.vrjZV.log
ERROR: Build of 
/groups/others/ohni/skylake/software/EasyBuild/4.1.1/easybuild/easyconfigs/g/GCCcore/GCCcore-8.2.0.eb 
failed (err: 'build failed (first 300 chars): cmd " make -j 2  bootstrap " 
exited with exit code 2 and output:\necho stage3 > stage_final\nmake[1]: 
Entering directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj\'\nmake[2]: 
Entering directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-syst')



The last part of the build log file is:

g++ -std=gnu++98 -no-pie   -g -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-
long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H 
-static-libstdc++ -static-libgcc  -o cc1 c/c-lang.o c-family/stub-objc.o 
attribs.o c/c-errors.o c/c-decl.o c/c-typeck.o c/c-convert.o 
c/c-aux-info.o c/c
-objc-common.o c/c-parser.o c/c-fold.o c/gimple-parser.o 
c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o 
c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o 
c-family/c-lex.o c-family/c-omp.o c-fam
ily/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o 
c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o 
c-family/c-ubsan.o c-family/known-headers.o c-family/c-attribs.o 
c-family/c-warn.o

 c-family/c-spellcheck.o i386-c.o glibc-c.o \
  cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a 
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a 
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a 
../libiberty/libiberty.a ../libdecnum
ber/libdecnumber.a 
-L/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage2_stuff/lib 
-lisl 
-L/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj/./gmp/.libs 
-L/
lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj/./mpfr/src/.libs 
-L/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj/./mpc/src/.libs 
-lmpc -lmpfr -lgm

p -rdynamic -ldl  -L./../zlib -lz
collect2: fatal error: ld terminated with signal 7 [Bus error]
compilation terminated.
make[3]: *** [cc1] Error 1
make[3]: *** Waiting for unfinished jobs
rm gcc.pod
make[3]: Leaving directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj/gcc'

make[2]: *** [all-stage1-gcc] Error 2
make[2]: Leaving directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj'

make[1]: *** [stage1-bubble] Error 2
make[1]: Leaving directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj'

make: *** [bootstrap] Error 2
 (at easybuild/tools/run.py:529 in parse_cmd_output)
== 2020-01-24 16:18:18,131 easyblock.py:3109 WARNING build failed (first 
300 chars): cmd " make -j 2  bootstrap " exited with exit code 2 and output:

echo stage3 > stage_final
make[1]: Entering directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj'
make[2]: Entering directory 
`/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-syst
== 2020-01-24 16:18:18,131 easyblock.py:295 INFO Closing log for 
application name GCCcore version 8.2.0


Can anyone help me debug this problem?

Thanks a lot,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

Re: [easybuild] Failure when building GCCcore/8.2.0

[Ole Holm Nielsen]

Hi Kenneth,

On 1/24/20 4:52 PM, Kenneth Hoste wrote:
...
lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj/./mpfr/src/.libs 
-L/lustre/hpc/others/ohni/skylake/build/GCCcore/8.2.0/system-system/gcc-8.2.0/stage3_obj/./mpc/src/.libs 
-lmpc -lmpfr -lgm

p -rdynamic -ldl  -L./../zlib -lz
collect2: fatal error: ld terminated with signal 7 [Bus error]



This strongly suggests there was not enough memory available for GCC...


Thanks a lot for sharing your insight!  I have an interactive shell 
controlled by Slurm's srun, so I will have to submit the task with a 
larger memory.  Is it possible to estimate the memory requirement or get 
better error messages?


/Ole

[easybuild] OPAL ERROR (missing Slurm PMI support) when building GPAW module

[Ole Holm Nielsen]

I am trying to build the new GPAW module from 
https://github.com/easybuilders/easybuild-easyconfigs/pull/9834:


$ eb --from-pr=9834 GPAW-20.1.0-foss-2019b-Python-3.7.4.eb -r

This works without problems on our own Linux (CentOS 7.7) cluster with 
Slurm 19.05.


However, on a remote cluster running CentOS 7.6 with Slurm 18.08.1 I am 
having difficulties.  I have to run EB as a Slurm interactive task on a 
compute node which I access using Slurm's "srun" command.  Then the above 
build always fails during the testing stage with these errors:


== sanity checking...
== FAILED: Installation ended unsuccessfully (build directory: 
/dev/shm/GPAW/20.1.0/foss-2019b-Python-3.7.4): build failed (first 300 
chars): Sanity check failed: command 
"/groups/others/ohni/skylake/software/Python/3.7.4-GCCcore-8.3.0/bin/python 
-c "import gpaw"" failed; output:

OPAL ERROR: Not initialized in file pmix2x_client.c at line 112

and the log file says:

== 2020-02-14 11:27:00,210 run.py:219 INFO running cmd: 
/groups/others/ohni/skylake/software/Python/3.7.4-GCCcore-8.3.0/bin/python 
-c "import gpaw"
== 2020-02-14 11:27:00,487 extension.py:212 WARNING Sanity check for 
'GPAW' extension failed: command 
"/groups/others/ohni/skylake/software/Python/3.7.4-GCCcore-8.3.0/bin/python 
-c "import gpaw"" failed; output:
[node252.cluster:100651] OPAL ERROR: Not initialized in file 
pmix2x_client.c at line 112

--
The application appears to have been direct launched using "srun",
but OMPI was not built with SLURM's PMI support and therefore cannot
execute. There are several options for building PMI support under
SLURM, depending upon the SLURM version you are using:

  version 16.05 or later: you can use SLURM's PMIx support. This
  requires that you configure and build SLURM --with-pmix.

  Versions earlier than 16.05: you must use either SLURM's PMI-1 or
  PMI-2 support. SLURM builds PMI-1 by default, or you can manually
  install PMI-2. You must then build Open MPI using --with-pmi pointing
  to the SLURM PMI library location.

Please configure as appropriate and try again.
--
*** An error occurred in MPI_Init
*** on a NULL communicator
*** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
***and potentially your MPI job)

This seems strange because the slurm-libpmi RPM is in fact installed on 
the system:


$ rpm -qa | grep slurm
slurm-libpmi-18.08.1-1.el7.x86_64
slurm-example-configs-18.08.1-1.el7.x86_64
slurm-18.08.1-1.el7.x86_64
slurm-pam_slurm-18.08.1-1.el7.x86_64
slurm-slurmd-18.08.1-1.el7.x86_64

$ rpm -ql slurm-libpmi-18.08.1-1.el7.x86_64
/usr/lib64/libpmi.so
/usr/lib64/libpmi.so.0
/usr/lib64/libpmi.so.0.0.0
/usr/lib64/libpmi2.so
/usr/lib64/libpmi2.so.0
/usr/lib64/libpmi2.so.0.0.0

Also, the loaded OpenMPI version appears to be sane enough:

$ which mpirun
~/skylake/software/OpenMPI/3.1.4-GCC-8.3.0/bin/mpirun
$ mpirun --version
mpirun (Open MPI) 3.1.4
$ ompi_info | grep ras
 MCA ras: slurm (MCA v2.1.0, API v2.0.0, Component v3.1.4)
 MCA ras: simulator (MCA v2.1.0, API v2.0.0, Component 
v3.1.4)


Googling for the OPAL ERROR I found a posting saying that missing the 
CentOS 7 hwloc-devel RPM was the source of the problems: 
https://users.open-mpi.narkive.com/C9HOavWo/ompi-users-fwd-openmpi-3-1-0-on-aarch64


Has anyone else seen this error?  Could a missing hwloc-devel OS 
prerequisite be causing problems?  I have tried to load explicitly the EB 
module hwloc/1.11.12-GCCcore-8.3.0, but that did not help.


Thanks,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

[easybuild] Checksum error when building GCCcore/8.2.0

[Ole Holm Nielsen]

I'm working on a remote system (CentOS 7.6) and have installed the latest 
EB 4.1.1.


When building the foss-2019a.eb toolchain I get a checksum error for 
isl-0.20.tar.bz2 when building GCCcore/8.2.0, please see log file lines below.


Is there a fix for this error?

Thanks,
Ole

== 2020-01-16 14:14:41,190 easyblock.py:2857 INFO Starting source step
== 2020-01-16 14:14:41,191 easyblock.py:2863 INFO Running method 
checksum_step part of step source
== 2020-01-16 14:14:41,825 easyblock.py:1801 INFO Checksum verification 
for /groups/others/ohni/modules/sources/g/GCCcore/gcc-8.2.0.tar.gz using 
1b0f36be1045ff58cbb9c83743835367b860810f17f0195a4e093458b372020f passed.
== 2020-01-16 14:14:41,839 easyblock.py:1801 INFO Checksum verification 
for /groups/others/ohni/modules/sources/g/GCCcore/gmp-6.1.2.tar.bz2 using 
5275bb04f4863a13516b2f39392ac5e272f5e1bb8057b18aec1c9b79d73d8fb2 passed.
== 2020-01-16 14:14:41,848 easyblock.py:1801 INFO Checksum verification 
for /groups/others/ohni/modules/sources/g/GCCcore/mpfr-4.0.1.tar.bz2 using 
a4d97610ba8579d380b384b225187c250ef88cfe1d5e7226b89519374209b86b passed.
== 2020-01-16 14:14:41,852 easyblock.py:1801 INFO Checksum verification 
for /groups/others/ohni/modules/sources/g/GCCcore/mpc-1.1.0.tar.gz using 
6985c538143c1208dcb1ac42cedad6ff52e267b47e5f970183a3e75125b43c2e passed.
== 2020-01-16 14:14:41,951 build_log.py:169 ERROR EasyBuild crashed with 
an error (at easybuild/base/exceptions.py:124 in __init__): Checksum 
verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed. 
(at easybuild/framework/easyblock.py:1805 in checksum_step)
== 2020-01-16 14:14:41,952 easyblock.py:3109 WARNING build failed (first 
300 chars): Checksum verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed.
== 2020-01-16 14:14:41,952 easyblock.py:295 INFO Closing log for 
application name GCCcore version 8.2.0
== 2020-01-16 14:14:41,952 build_log.py:265 INFO FAILED: Installation 
ended unsuccessfully (build directory: 
/groups/others/ohni/modules/build/GCCcore/8.2.0/system-system): build 
failed (first 300 chars): Checksum verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed. 
(took 1 sec)
== 2020-01-16 14:14:41,953 build_log.py:265 INFO Results of the build can 
be found in the log file(s) 
/tmp/eb-iti_1V/easybuild-GCCcore-8.2.0-20200116.141439.jMWZa.log
== 2020-01-16 14:14:41,954 build_log.py:169 ERROR EasyBuild crashed with 
an error (at easybuild/base/exceptions.py:124 in __init__): build failed 
(first 300 chars): Checksum verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed. 
(at easybuild/main.py:116 in build_and_install_software)
== 2020-01-16 14:14:41,955 build_log.py:169 ERROR EasyBuild crashed with 
an error (at easybuild/base/exceptions.py:124 in __init__): Build of 
/groups/others/ohni/modules/software/EasyBuild/4.1.1/easybuild/easyconfigs/g/GCCcore/GCCcore-8.2.0.eb 
failed (err: 'build failed (first 300 chars): Checksum verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed.') 
(at easybuild/main.py:148 in build_and_install_software)


--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

Re: [easybuild] Checksum error when building GCCcore/8.2.0

[Ole Holm Nielsen]

Hi Jack,

Thanks for the feedback about checksums!  The current file 
isl-0.20.tar.bz2 which was downloaded by EB actually has a different checksum:


$ ls -l /groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2
-rw-r--r-- 1 ohni others 17121 Jan 16 14:00 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2


$ sha256sum /groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2
c968e1f20d7e48c395a0779b6b07e2723f003b1330c6deeb606e7db96b2cf6a4 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2


The official tar-ball (dated 2018-07-28) checksum has apparently changed:

$ wget https://isl.gforge.inria.fr/isl-0.20.tar.bz2
$ sha256sum isl-0.20.tar.bz2
c968e1f20d7e48c395a0779b6b07e2723f003b1330c6deeb606e7db96b2cf6a4 
isl-0.20.tar.bz2


So I guess the EB file GCCcore-8.2.0.eb needs to have the checksum updated?

Thanks,
Ole


On 1/16/20 3:29 PM, Jack Perdue wrote:

Howdy ,

The checksum given matches the  filie I have here:

$ sha256sum /sw/eb/sources/g/GCCcore/isl-0.20.tar.bz2
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 
/sw/eb/sources/g/GCCcore/isl-0.20.tar.bz2


but I downloaded that a year ago:

$ ls -al /sw/eb/sources/g/GCCcore/isl-0.20.tar.bz2
-rw-rw-r-- 1 j-perdue staff 1727820 Jan  2  2019 
/sw/eb/sources/g/GCCcore/isl-0.20.tar.bz2


You might try downloading it again. (???)

Jack Perdue
Lead Systems Administrator
High Performance Research Computing
TAMU Division of Research
j-per...@tamu.edu    http://hprc.tamu.edu
HPRC Helpdesk: h...@hprc.tamu.edu

On 1/16/20 7:21 AM, Ole Holm Nielsen wrote:
I'm working on a remote system (CentOS 7.6) and have installed the 
latest EB 4.1.1.


When building the foss-2019a.eb toolchain I get a checksum error for 
isl-0.20.tar.bz2 when building GCCcore/8.2.0, please see log file lines 
below.


Is there a fix for this error?

Thanks,
Ole

== 2020-01-16 14:14:41,190 easyblock.py:2857 INFO Starting source step
== 2020-01-16 14:14:41,191 easyblock.py:2863 INFO Running method 
checksum_step part of step source
== 2020-01-16 14:14:41,825 easyblock.py:1801 INFO Checksum verification 
for /groups/others/ohni/modules/sources/g/GCCcore/gcc-8.2.0.tar.gz using 
1b0f36be1045ff58cbb9c83743835367b860810f17f0195a4e093458b372020f passed.
== 2020-01-16 14:14:41,839 easyblock.py:1801 INFO Checksum verification 
for /groups/others/ohni/modules/sources/g/GCCcore/gmp-6.1.2.tar.bz2 
using 5275bb04f4863a13516b2f39392ac5e272f5e1bb8057b18aec1c9b79d73d8fb2 
passed.
== 2020-01-16 14:14:41,848 easyblock.py:1801 INFO Checksum verification 
for /groups/others/ohni/modules/sources/g/GCCcore/mpfr-4.0.1.tar.bz2 
using a4d97610ba8579d380b384b225187c250ef88cfe1d5e7226b89519374209b86b 
passed.
== 2020-01-16 14:14:41,852 easyblock.py:1801 INFO Checksum verification 
for /groups/others/ohni/modules/sources/g/GCCcore/mpc-1.1.0.tar.gz using 
6985c538143c1208dcb1ac42cedad6ff52e267b47e5f970183a3e75125b43c2e passed.
== 2020-01-16 14:14:41,951 build_log.py:169 ERROR EasyBuild crashed with 
an error (at easybuild/base/exceptions.py:124 in __init__): Checksum 
verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed. 
(at easybuild/framework/easyblock.py:1805 in checksum_step)
== 2020-01-16 14:14:41,952 easyblock.py:3109 WARNING build failed (first 
300 chars): Checksum verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed.
== 2020-01-16 14:14:41,952 easyblock.py:295 INFO Closing log for 
application name GCCcore version 8.2.0
== 2020-01-16 14:14:41,952 build_log.py:265 INFO FAILED: Installation 
ended unsuccessfully (build directory: 
/groups/others/ohni/modules/build/GCCcore/8.2.0/system-system): build 
failed (first 300 chars): Checksum verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed. 
(took 1 sec)
== 2020-01-16 14:14:41,953 build_log.py:265 INFO Results of the build 
can be found in the log file(s) 
/tmp/eb-iti_1V/easybuild-GCCcore-8.2.0-20200116.141439.jMWZa.log
== 2020-01-16 14:14:41,954 build_log.py:169 ERROR EasyBuild crashed with 
an error (at easybuild/base/exceptions.py:124 in __init__): build failed 
(first 300 chars): Checksum verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using 
b587e083eb65a8b394e833dea1744f21af3f0e413a448c17536b5549ae42a4c2 failed. 
(at easybuild/main.py:116 in build_and_install_software)
== 2020-01-16 14:14:41,955 build_log.py:169 ERROR EasyBuild crashed with 
an error (at easybuild/base/exceptions.py:124 in __init__): Build of 
/groups/others/ohni/modules/software/EasyBuild/4.1.1/easybuild/easyconfigs/g/GCCcore/GCCcore-8.2.0.eb 
failed (err: 'build failed (first 300 chars): Checksum verification for 
/groups/others/ohni/modules/sources/g/GCCcore/isl-0.20.tar.bz2 using

Re: [easybuild] Checksum error when building GCCcore/8.2.0

[Ole Holm Nielsen]

On 16-01-2020 16:49, Kenneth Hoste wrote:

On 16/01/2020 16:28, Lars Viklund wrote:
The file contains a file listing and is the result of 
https://isl.gforge.inria.fr/isl-0.20.tar.bz2 redirecting with a 302 to 
http://isl.gforce.inria.fr .


It seems like the site only offers downloads over plaintext, while 
someone changed the link to HTTPS in the easyconfig recently in 
https://github.com/easybuilders/easybuild-easyconfigs/commit/d93ef853012ef04e373cd19696e045408d8b5a8f 



Ouch. That's hard to catch without forcibly re-downloading every time we 
touch source URLs (which I guess we should have done here).


I someone hits this:

* manually download with wget or curl from 
http://isl.gforge.inria.fr/isl-0.20.tar.bz2


I confirm that manual download from the http site gives the correct 
checksum for isl-0.20.tar.bz2.  Now the building of GCCcore can proceed 
normally.



* move the downloaded isl-0.20.tar.bz2 to the /path/to/sources/g/GCCcore/


The checksum in the easyconfig file is correct, but the auto-download is 
broken...


Follow-up in 
https://github.com/easybuilders/easybuild-easyconfigs/issues/9692 .

Thanks,
Ole

Re: [easybuild] Re: EB bootstrap: ImportError: No module named tools.version

[Ole Holm Nielsen]

Dear Kenneth,

On 24-04-2020 20:38, Kenneth Hoste wrote:

Can you do a debug bootstrap, by also defining $EASYBUILD_BOOTSTRAP_DEBUG?

   export EASYBUILD_BOOTSTRAP_DEBUG=1


The output is copied below.  I hope you can make some sense of it...

Maybe you have an 'easybuild' folder in the directory where you're 
running the bootstrap from?


No such folder:
$ ls -la
total 72
drwxr-xr-x.  3 ohni camdvip77 Apr 24 08:43 .
drwxr-xr-x. 10 ohni camdvip  4096 Apr 24 08:16 ..
drwxr-xr-x.  2 ohni camdvip  4096 Apr 24 15:47 benchmarks
-rw-r--r--.  1 ohni camdvip 51564 Apr 24 08:43 bootstrap_eb.py
-rw-r--r--.  1 ohni camdvip 11529 Apr 24 08:16 README.md

Thanks,
Ole

Debug output


$ python bootstrap_eb.py $EASYBUILD_PREFIX
[[INFO]] EasyBuild bootstrap script (version 20200203.01, MD5: 
fcb6314d4e0747db9c28a71f8bb2870c)
[[INFO]] Found Python 2.7.5 (default, Aug  7 2019, 00:51:29) ; [GCC 
4.8.5 20150623 (Red Hat 4.8.5-39)]


[[INFO]] Installation prefix /home/niflheim/ohni/modules
[[DEBUG]] Going to use /tmp/tmpgaI94A as temporary directory
[[INFO]] Using modules tool specified by $EASYBUILD_MODULES_TOOL: Lmod
[[DEBUG]] sys.path after cleaning: 
['/home/niflheim/ohni/Git/GPAW-benchmark-2020', 
'/usr/lib64/python27.zip', '/usr/lib64/python2.7', 
'/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', 
'/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', 
'/usr/lib64/python2.7/site-packages', 
'/usr/lib64/python2.7/site-packages/gtk-2.0', 
'/usr/lib/python2.7/site-packages']

[[DEBUG]] Checking whether suitable setuptools installation is available...
[[DEBUG]] Found setuptools version 0.9.8
[[DEBUG]] Location of setuptools' easy_install module: 
/usr/lib/python2.7/site-packages/setuptools/command/easy_install.pyc
[[DEBUG]] Location of setuptools installation: 
/usr/lib/python2.7/site-packages

[[INFO]] Suitable setuptools installation already found, skipping stage 0...


[[INFO]] +++ STAGE 1: installing EasyBuild in temporary dir with 
easy_install...


[[DEBUG]] $ easy_install --help
[[DEBUG]] Active setuptools installation: 
/usr/lib/python2.7/site-packages/setuptools/__init__.pyc

[[DEBUG]] stdout for 'easy_install --help':

Global options:
  --verbose (-v)  run verbosely (default)
  --quiet (-q)run quietly (turns verbosity off)
  --dry-run (-n)  don't actually do anything
  --help (-h) show detailed help message
  --no-user-cfg   ignore pydistutils.cfg in your home directory

Options for 'easy_install' command:
  --prefix   installation prefix
  --zip-ok (-z)  install package as a zipfile
  --multi-version (-m)   make apps have to require() a version
  --upgrade (-U) force upgrade (searches PyPI for latest
 versions)
  --install-dir (-d) install package to DIR
  --script-dir (-s)  install scripts to DIR
  --exclude-scripts (-x) Don't install scripts
  --always-copy (-a) Copy all needed packages to install dir
  --index-url (-i)   base URL of Python Package Index
  --find-links (-f)  additional URL(s) to search for packages
  --delete-conflicting (-D)  no longer needed; don't use this
  --ignore-conflicts-at-my-risk  no longer needed; don't use this
  --build-directory (-b) download/extract/build in DIR; keep the
 results
  --optimize (-O)also compile with optimization: -O1 for
 "python -O", -O2 for "python -OO", and 
-O0 to

 disable [default: -O0]
  --record   filename in which to record list of 
installed

 files
  --always-unzip (-Z)don't install as a zipfile, no matter what
  --site-dirs (-S)   list of directories where .pth files work
  --editable (-e)Install specified packages in editable 
form

  --no-deps (-N) don't install dependencies
  --allow-hosts (-H) pattern(s) that hostnames must match
  --local-snapshots-ok (-l)  allow building eggs from local checkouts
  --version  print version information and exit
  --no-find-linksDon't load find-links defined in packages
 being installed

usage: bootstrap_eb.py [options] requirement_or_url ...
   or: bootstrap_eb.py --help


[[DEBUG]] stderr for 'easy_install --help':

[[DEBUG]] Preparing for path /tmp/tmpgaI94A/eb_stage1
[[DEBUG]] os.environ['PYTHONPATH'] after reset:
[[DEBUG]] $PATH: 
/tmp/tmpgaI94A/eb_stage1/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/dell/srvadmin/bin:/opt/dell/srvadmin/iSM/bin:/home/niflheim/ohni/.local/bin:/home/niflheim/ohni/bin
[[DEBUG]] $PYTHONPATH: 
/tmp/tmpgaI94A/eb_stage1/lib64/python2.7/site-packages:/tmp/tmpgaI94A/eb_stage1/lib/python2.7/site-packages

[[DEBUG]] $EASYBUILD_MODULES_TOOL set to 

[easybuild] Re: EB bootstrap: ImportError: No module named tools.version

[Ole Holm Nielsen]

On 24-04-2020 09:15, Ole Holm Nielsen wrote:

Dear EasyBuilders,

I am trying to create a clean EasyBuild setup for a benchmarking 
environment on a CentOS 7.7 server.  In my .bashrc file I have defined 
the clean environment with:


export EASYBUILD_MODULES_TOOL=Lmod
export EASYBUILD_PREFIX=$HOME/modules

I have created the empty folder $HOME/modules/all

Unfortunately the EB bootstrap fails in stage 1:

$ python bootstrap_eb.py $EASYBUILD_PREFIX
[[INFO]] EasyBuild bootstrap script (version 20200203.01, MD5: 
fcb6314d4e0747db9c28a71f8bb2870c)
[[INFO]] Found Python 2.7.5 (default, Aug  7 2019, 00:51:29) ; [GCC 
4.8.5 20150623 (Red Hat 4.8.5-39)]


[[INFO]] Installation prefix /home/niflheim/ohni/modules
[[INFO]] Using modules tool specified by $EASYBUILD_MODULES_TOOL: Lmod
[[INFO]] Suitable setuptools installation already found, skipping stage 
0...



[[INFO]] +++ STAGE 1: installing EasyBuild in temporary dir with 
easy_install...


[[INFO]] running pre-install command 'easy_install --quiet --upgrade 
--prefix=/tmp/tmpvYYVs6/eb_stage1 vsc-install<0.11.4'
[[INFO]] running pre-install command 'easy_install --quiet --upgrade 
--prefix=/tmp/tmpvYYVs6/eb_stage1 vsc-base<2.9.0'
[[INFO]] installing EasyBuild with 'easy_install --quiet --upgrade 
--prefix=/tmp/tmpvYYVs6/eb_stage1 easybuild'


[[INFO]] Note: a 'SyntaxError' may be reported for the 
easybuild/tools/py2vs3/py3.py module.
You can safely ignore this message, it will not affect the functionality 
of the EasyBuild installation.


[[INFO]] running post install command 'easy_install --upgrade 
--prefix=/tmp/tmpvYYVs6/eb_stage1 vsc-base<2.9.0'
[[ERROR]] Stage 1 failed, could not determine EasyBuild version (txt: 
Traceback (most recent call last):

   File "", line 1, in 
ImportError: No module named tools.version
).

This seems to be the same problem as discussed in 
https://github.com/easybuilders/easybuild-framework/issues/2712 which I 
thought was already solved.


The system already this CentOS 7 package python-setuptools, but not 
python-mock:


$ rpm -q python-setuptools python-mock
python-setuptools-0.9.8-7.el7.noarch
package python-mock is not installed


Correction: python-mock is also installed:

$ rpm -q python-setuptools python2-mock
python-setuptools-0.9.8-7.el7.noarch
python2-mock-1.0.1-10.el7.noarch

/Ole

[easybuild] EB bootstrap: ImportError: No module named tools.version

[Ole Holm Nielsen]

Dear EasyBuilders,

I am trying to create a clean EasyBuild setup for a benchmarking 
environment on a CentOS 7.7 server.  In my .bashrc file I have defined 
the clean environment with:


export EASYBUILD_MODULES_TOOL=Lmod
export EASYBUILD_PREFIX=$HOME/modules

I have created the empty folder $HOME/modules/all

Unfortunately the EB bootstrap fails in stage 1:

$ python bootstrap_eb.py $EASYBUILD_PREFIX
[[INFO]] EasyBuild bootstrap script (version 20200203.01, MD5: 
fcb6314d4e0747db9c28a71f8bb2870c)
[[INFO]] Found Python 2.7.5 (default, Aug  7 2019, 00:51:29) ; [GCC 
4.8.5 20150623 (Red Hat 4.8.5-39)]


[[INFO]] Installation prefix /home/niflheim/ohni/modules
[[INFO]] Using modules tool specified by $EASYBUILD_MODULES_TOOL: Lmod
[[INFO]] Suitable setuptools installation already found, skipping stage 0...


[[INFO]] +++ STAGE 1: installing EasyBuild in temporary dir with 
easy_install...


[[INFO]] running pre-install command 'easy_install --quiet --upgrade 
--prefix=/tmp/tmpvYYVs6/eb_stage1 vsc-install<0.11.4'
[[INFO]] running pre-install command 'easy_install --quiet --upgrade 
--prefix=/tmp/tmpvYYVs6/eb_stage1 vsc-base<2.9.0'
[[INFO]] installing EasyBuild with 'easy_install --quiet --upgrade 
--prefix=/tmp/tmpvYYVs6/eb_stage1 easybuild'


[[INFO]] Note: a 'SyntaxError' may be reported for the 
easybuild/tools/py2vs3/py3.py module.
You can safely ignore this message, it will not affect the functionality 
of the EasyBuild installation.


[[INFO]] running post install command 'easy_install --upgrade 
--prefix=/tmp/tmpvYYVs6/eb_stage1 vsc-base<2.9.0'
[[ERROR]] Stage 1 failed, could not determine EasyBuild version (txt: 
Traceback (most recent call last):

  File "", line 1, in 
ImportError: No module named tools.version
).

This seems to be the same problem as discussed in 
https://github.com/easybuilders/easybuild-framework/issues/2712 which I 
thought was already solved.


The system already this CentOS 7 package python-setuptools, but not 
python-mock:


$ rpm -q python-setuptools python-mock
python-setuptools-0.9.8-7.el7.noarch
package python-mock is not installed

Did the PR https://github.com/easybuilders/easybuild-framework/pull/2717 
not solve the problem after all?


Thanks,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

[easybuild] Looking for a COMSOL easyblock

[Ole Holm Nielsen]

Dear Easybuilders,

I have been asked to install a module for the latest COMSOL 5.5, but there 
is no COMSOL .eb file in EB 4.3.  I note that there was a PR concerning 
COMSOL two years ago:

https://github.com/easybuilders/easybuild-easyblocks/pull/1317

Can anyone share a working COMSOL .eb file for COMSOL 5.5 (or older)?

I assume that we should use the latest MATLAB 2020b for installation.  I 
used the MATLAB-2019b.eb and updated the version number.  One trick here 
is that the contents of the MATLAB ISO file must be converted into a 
.tar.gz file, and all files must first be made user-writable by: chmod -R 
u+w .


We already have COMSOL 5.3 installed, but I don't have a record of how we 
did it back then.


Thanks a lot for sharing your insights,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

Re: [easybuild] Tk-8.6.10-GCCcore-9.3.0.eb fails due to download issue

[Ole Holm Nielsen]

Hi Terje,

Thanks a lot, this alternative download site worked for me.

Best regards,
Ole

On 6/22/20 10:46 AM, Terje Kvernes wrote:

Hi Ole,

You could maybe try the following source?

curl -o 
/home/modules/software/EasyBuild/4.2.1/easybuild/easyconfigs/t/Tk/t/Tk/tk8.6.10-src.tar.gz
 https://ftp.osuosl.org/pub/blfs/conglomeration/tk/tk8.6.10-src.tar.gz

It’s not an official source, but it looks correct and you should then be able 
to restart the build.


On 22 Jun 2020, at 10:40, Ole Holm Nielsen  wrote:

I wanted to build Tk-8.6.10-GCCcore-9.3.0.eb but this fails during source code 
download:

ERROR: Build of 
/home/modules/software/EasyBuild/4.2.1/easybuild/easyconfigs/t/Tk/Tk-8.6.10-GCCcore-9.3.0.eb
 failed (err: "build failed (first 300 chars): Couldn't find file 
tk8.6.10-src.tar.gz anywhere, and downloading it didn't work either... Paths attempted 
(in order): 
/home/modules/software/EasyBuild/4.2.1/easybuild/easyconfigs/t/Tk/t/Tk/tk8.6.10-src.tar.gz,
 
/home/modules/software/EasyBuild/4.2.1/easybuild/easyconfigs/t/Tk/Tk/tk8.6.10-src.tar.gz, 
")

The SourceForge download page https://prdownloads.sourceforge.net/tcl seems to 
be messed up :-(  The version 8.6 is located in 
https://sourceforge.net/projects/tcl/files/Tcl/8.6.10/ but direct download from 
that page doesn't work and one gets into an infinite loop of advertisements :-(

Is there some other sane download site which could be configured in the 
EasyBuild .eb files ?

[easybuild] Tk-8.6.10-GCCcore-9.3.0.eb fails due to download issue

[Ole Holm Nielsen]

I wanted to build Tk-8.6.10-GCCcore-9.3.0.eb but this fails during source 
code download:


ERROR: Build of 
/home/modules/software/EasyBuild/4.2.1/easybuild/easyconfigs/t/Tk/Tk-8.6.10-GCCcore-9.3.0.eb 
failed (err: "build failed (first 300 chars): Couldn't find file 
tk8.6.10-src.tar.gz anywhere, and downloading it didn't work either... 
Paths attempted (in order): 
/home/modules/software/EasyBuild/4.2.1/easybuild/easyconfigs/t/Tk/t/Tk/tk8.6.10-src.tar.gz, 
/home/modules/software/EasyBuild/4.2.1/easybuild/easyconfigs/t/Tk/Tk/tk8.6.10-src.tar.gz, 
")


The SourceForge download page https://prdownloads.sourceforge.net/tcl 
seems to be messed up :-(  The version 8.6 is located in 
https://sourceforge.net/projects/tcl/files/Tcl/8.6.10/ but direct download 
from that page doesn't work and one gets into an infinite loop of 
advertisements :-(


Is there some other sane download site which could be configured in the 
EasyBuild .eb files ?


Thanks,
Ole

--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark

[easybuild] Code crashes with multi-node MPI jobs on AMD Rome nodes running OpenHPC 1.3

[Ole Holm Nielsen]

/modules/software/Python/3.8.6-GCCcore-10.2.0/lib/libpython3.8.so.1.0(PyEval_EvalCode+0x1b)[0x2ae7453b]
[sn537:02026] [29] 
/groups/physics/modules/software/Python/3.8.6-GCCcore-10.2.0/lib/libpython3.8.so.1.0(+0x1aa8e5)[0x2ae798e5]

[sn537:02026] *** End of error message ***



--
Ole Holm Nielsen
PhD, Senior HPC Officer
Department of Physics, Technical University of Denmark