[CP2K:9656] Re: OpenBLAS not working with cp2k?
sassy... at sassy.formativ.net
Thu Nov 9 23:09:05 UTC 2017
Hi Alfio and Ari,
interesting. I am wondering whether the problem is that I am not using the
threaded or OMP version and you are using it.
The problem I encountered in the past with OMP is that each process started to
spin up X OpenBLAS processes which lead to a complete overload of the machine.
In other words: if you had say 8 cores and 8 instances of the program running,
echo of the instance started 8 OpenBLAS processes. The result was an overload
of the machine.
Thus, I was building OpenBLAS as a non-threaded/non-OMP version to simply
avoid this problem.
One of the reasons I am building the ssmp version of cp2k was to play around a
bit whether OpenMP is for my single node 'faster' than MPI.
I guess I will build OpenBLAS with both threads and OpenMP enabled and see
what will happen.
Thanks for your help so far.
All the best from London
Am Donnerstag, 9. November 2017, 02:07:00 GMT schrieb Alfio Lazzaro:
> Dear Jörg,
> we test CP2K against OpenBLAS in our regtests (see
> by using the CP2K toolchain.
> In particular, I see that we are using openblas-0.2.20 (same as you). I see
> in the toolchain script that we use
> make -j $nprocs \
> USE_THREAD=1 \
> USE_OPENMP=1 \
> LIBNAMESUFFIX=omp \
> CC=$(basename $CC) \
> FC=$(basename $FC)
> I would suggest to try directly the toolchain and see if it works on your
> Il giorno giovedì 9 novembre 2017 00:47:26 UTC+1, sassy ha scritto:
> > Dear all
> > I am puzzled: I found a very strange behaviour when I am trying to build
> > cp2k,
> > both the latest release and the previous 4.x one, with OpenBLAS. Compiling
> > and
> > linking is all working fine but when I am running the regtests they almost
> > all
> > crash with this error message:
> > dbcsr_tensor_unittest.out
> > Program received signal SIGSEGV: Segmentation fault - invalid memory
> > reference.
> > Backtrace for this error:
> > #0 0x63d08d in ???
> > #1 0x63c72d in ???
> > #2 0x6b97ef in ???
> > at /build/glibc-p3Km7c/glibc-2.24/nptl/../sysdeps/unix/sysv/linux/
> > x86_64/sigaction.c:0
> > #3 0x0 in ???
> > EXIT CODE: 139 MEANING: RUNTIME FAIL
> > Thus, I was using an older ATLAS build to narrow down the problem and loo
> > and
> > behold, now the regtests are working. I am currently trying out the ssmp
> > build
> > as that is for my desktop machine and I reasoned that threading might be
> > better there than MPI.
> > Incidentally, the same problem happens when I am using the 4.x version and
> > OpenMPI. I am using OpenBLAS-0.2.20.
> > Has somebody noticed that before or am I doing something completely wrong
> > on
> > two different clusters?
> > I am using gfortran-6.3.0 for the ssmp build just in case that might be a
> > problem and OpenBLAS was build like that:
> > $ make DYNAMIC_ARCH=1 USE_THREAD=0
> > For ATLAS I am using the serial build as well. I am using the provided
> > Linux-
> > x86-64-gfortran-ssmp makefile, obviously changed the paths to reflect my
> > environment and removed the -static flag.
> > Please let me know if you need more information but I find that strange.
> > All the best from a cold London
> > Jörg
More information about the CP2K-user