foss/2017b toolchain definition (REVIEW)#4768
Conversation
|
Test report by @boegel |
|
|
||
| skipsteps = ['configure'] | ||
|
|
||
| buildopts = 'BINARY=64 USE_THREAD=1 CC="$CC" FC="$F77" NO_AFFINITY=1' |
|
Test report by @boegel |
| easyblock = 'ConfigureMake' | ||
|
|
||
| name = 'OpenBLAS' | ||
| version = '0.2.19' |
There was a problem hiding this comment.
This is the most recent, but relatively old, version (released Sept'16).
I reached out to the OpenBLAS maintainer (@xianyi), this was his reply: We will release OpenBLAS in one or two weeks.
So, probably worth waiting for...
|
|
||
| toolchain = {'name': 'dummy', 'version': 'dummy'} | ||
|
|
||
| gccver = '6.3.0-2.28' |
There was a problem hiding this comment.
GCC 6.4.0 is imminent: https://gcc.gnu.org/ml/gcc/2017-06/msg00101.html (hat tip @ocaisa)
|
note: installing Python 2.7.13 + all dependencies on top of Details |
| easyblock = 'ConfigureMake' | ||
|
|
||
| name = 'OpenBLAS' | ||
| version = '0.2.19' |
There was a problem hiding this comment.
OpenBLAS 0.2.20 is expected to be released soon (see OpenMathLib/OpenBLAS#1223); I suggest we postpone setting foss/2017b in stone until it's available?
There was a problem hiding this comment.
Seems like they screwed something up with the OpenBLAS 0.2.20 release. Another quick 0.2.21 release is planned, probably worth waiting for this? See OpenMathLib/OpenBLAS#1258.
Thoughts @easybuilders/easybuild-easyconfigs-maintainers?
There was a problem hiding this comment.
Since the 0.2.21 release isn't happening, I went forward with using 0.2.20 and applying two patches on top of it, so we can finalise foss/2017b...
| skipsteps = ['configure'] | ||
|
|
||
| buildopts = 'BINARY=64 USE_THREAD=1 CC="$CC" FC="$F77" NO_AFFINITY=1' | ||
| installopts = "USE_THREAD=1 PREFIX=%(installdir)s" |
There was a problem hiding this comment.
...and remove NO_AFFINITY=1 too for the reasons given in #4524
There was a problem hiding this comment.
adding USE_OPENMP=1 and dropping NO_AFFINITY=1 done, see 91fc9ed
verdurin
left a comment
There was a problem hiding this comment.
Minor typos and SLURM comment suggestion
| comp_mpi_tc_name = 'gompi' | ||
| comp_mpi_tc = (comp_mpi_tc_name, version) | ||
|
|
||
| # compiler toolchain depencies |
|
|
||
| # compiler toolchain depencies | ||
| # we need GCC and OpenMPI as explicit dependencies instead of gompi toolchain | ||
| # because of toolchain preperation functions |
| configopts += '--enable-mpirun-prefix-by-default ' # suppress failure modes in relation to mpirun path | ||
| configopts += '--with-hwloc=$EBROOTHWLOC ' # hwloc support | ||
| configopts += '--disable-dlopen ' # statically link component, don't do dynamic loading | ||
|
|
There was a problem hiding this comment.
Worth adding a commented out option here for SLURM integration?
E.g. configopts += '--with-slurm --with-pmi=/usr/include/slurm --with-pmi-libdir=/usr
as a reference?
There was a problem hiding this comment.
@verdurin I think that should go in the documentation somewhere, e.g. how to site-customise OpenMPI?
| toolchainopts = {'usempi': True} | ||
|
|
||
| sources = [SOURCELOWER_TAR_GZ] | ||
| source_urls = ['http://www.netlib.org/benchmark/%(namelower)s'] |
| skipsteps = ['configure'] | ||
|
|
||
| buildopts = 'BINARY=64 USE_THREAD=1 CC="$CC" FC="$F77" NO_AFFINITY=1' | ||
| installopts = "USE_THREAD=1 PREFIX=%(installdir)s" |
| toolchainopts = {'pic': True} | ||
|
|
||
| source_urls = [homepage] | ||
| sources = [SOURCELOWER_TGZ] |
|
Y'all know, if you used GCCcore (vs. GCC) for hwloc and numactl they could be reused when building iompi/2017b |
| name = 'OpenBLAS' | ||
| version = '0.2.19' | ||
|
|
||
| lapackver = '3.7.0' |
There was a problem hiding this comment.
LAPACK 3.7.1 is out, so we should bump this too
There was a problem hiding this comment.
Or not, we should probably stick with the shipped LAPACK instead, see OpenMathLib/OpenBLAS#1273...
|
@JackPerdue good point, now using existing |
|
Test report by @boegel |
|
Test report by @boegel |
|
Test report by @verdurin |
|
Test report by @JackPerdue |
|
Test report by @wpoely86 |
|
@wpoely86 Hmm... Any ideas? I don't have any |
|
@akesandgren Looks like your stack isn't consistent with the new PR (two versions of |
| (large_src, '.'), | ||
| (timing_src, '.'), | ||
| 'OpenBLAS-%(version)s_fix-Intel-L1-cache-size-detection.patch', | ||
| 'OpenBLAS-%(version)s_revert-honor-cpuset.patch', |
There was a problem hiding this comment.
I checked with one of the OpenBLAS co-maintainers whether going forward with OpenBLAS 0.2.20 with these two patches on top makes sense w.r.t. stability, and he confirmed it was.
No need to keep stalling this and hope for a 'quick' OpenBLAS 0.2.21 that includes these fixes...
|
Test report by @JackPerdue |
|
@ocaisa @akesandgren Hmm, no, it's something else... The However, the check was done using It makes sense that See also easybuilders/easybuild-framework#2186. @akesandgren Please do a |
|
We don't have |
|
Yeah, i finally managed to get a correct sandbox test setup. @ocaisa was just to fast and read a report i deleted. |
|
For my last test (7 of 7) I didn't see the munge issue. We have munge installed for slurm but I made sure to remove munge-devel (which doesn't seem to have a libmunge.la on RHEL7) beforehand. |
|
Test report by @wpoely86 |
|
Was dropping LAPACK-3.7.0 intentional? |
|
@JackPerdue Yes, see discussion in OpenMathLib/OpenBLAS#1273 |
|
Test report by @akesandgren |
|
Going in, thanks @boegel! |
(created using
eb --new-pr)requires
#4794for GCC 6.4.0