[GenABEL-dev] ACML and make check

[Frank, Alvaro Jesus]

I do not recommend using distributed libraries. Use self compiled libraries. It will not fail if done so. Yours may compile, but no one guarantees that OPENMP=1 was used in the compilation for it.

All errors pointed out were not present in series of 3 different environments. 3 machines, 3 libraries each. All different architectures. I corrected configure.ac anyway. The LAPACKE_sposv_work are from -static linking with unsuitable libraries. Therefore self-compilation. 

We could, just like with normal omicabel, supply static precompiled versions, with both AMD and a proper OpenBLAS OPENMP=1, DYNAMIC_ARCH=0, etc. Committed the changes anyway. There is no more static linking and the user is responsible for having the libraries available at run-time with sudo rights. 

I don't have an environment where this commit fails.

P.S: I still need to compile the test without having to abort it manually. Screen output in real time is still a requirement for me.

-A Frank
________________________________________
From: L.C. Karssen [lennart at karssen.org]
Sent: Friday, July 25, 2014 3:59 PM
To: Frank, Alvaro Jesus; genabel-devel at lists.r-forge.r-project.org
Subject: Re: ACML and make check

Hi Alvaro,

On 25-07-14 13:00, Frank, Alvaro Jesus wrote:
> Hi Lennart,
>
> I committed an ugly/nice hack to allow the usage of AMD's ACML library
> with omicabelnomm. This was required due to the program having VERY bad
> performance issues making it unusable on old Opteron systems prior to
> the 6200 versions. This are all that have non AVX instructions. I might
> have broken a few Jenkins warnings due to this, but those will be fixed
> later.
> Normal OMICABEL should be tested against ACML this too. Using MKL on the
> Opteron System, with 10 traits and 400000 snps. the runtime takes over
> 10 hours. This does not seem like a normal behavior.
>
> AMD ACMl also allows to use GPU without ANY change, the system just
> needs to support OpenCL, which NVIDIA and AMD do. I have no access to an
> Opteron/AMD system that has GPU so I cant test it yet.

That's cool! Unfortunately I don't have access to an AMD GPU either :-(.

>
> The changes also allow for static linking now. So no need to have root
> access. The howtocompile file reflects this now.
>
> I also have a very improtant request. Your change of make check will not
> display the output of the testing program as it runs. I previosly
> compiled the test file and manually called it, giving me a very quick
> workflow to test the system. But now my 1 cmd do it all workflow is
> broken, having to use make check to compile test.cpp and then having to
> abort it manually to later re-call it manually to be able to see the
> output in real time. Is there a way to change make check to allow for
> real time output? I tried gooooogoling this, but failed with the most
> common solutions.
>

The default way of running tests has changed in a recent automake
update. It now allows tests to be run in parallel (assuming more than
one exists). That's why the screen output isn't printed to screen anymore.

The actual screen output of the test can be found in the file
tests/test_omicabelnomm.log. So you can check that after the 'make
check' run.

Of course, nothing prevents you from running 'tests/test_omicablenomm'
after you've run './configure' followed by 'make'. 'make check' makes
sense only if the exit status of the tests returns 0 or 1 for success or
failure, respectively.

> A rewrite of Algorithm.cpp is coming next. it will break the
> validity/give wrong results perhaps at first.

Actually, the current HEAD already gives me compile errors:

++ -static -O3 -I../libs/include/ -I./libs/include/ -fopenmp
-D_openblas_   -L./libs/lib/ -L../libs/lib/ -o omicabelnomm
src/AIOwrapper.o src/Algorithm.o src/Utility.o src/main.o  -llapacke
-lopenblas -lgfortran
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapacke.a(lapacke_sgels_work.o):
In function `LAPACKE_sgels_work':
(.text+0x1a3): undefined reference to `sgels_'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapacke.a(lapacke_sgels_work.o):
In function `LAPACKE_sgels_work':
(.text+0x28c): undefined reference to `sgels_'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapacke.a(lapacke_sposv_work.o):
In function `LAPACKE_sposv_work':
(.text+0x151): undefined reference to `sposv_'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/liblapacke.a(lapacke_sposv_work.o):
In function `LAPACKE_sposv_work':
(.text+0x240): undefined reference to `sposv_'
collect2: error: ld returned 1 exit status
make: *** [omicabelnomm] Error 1


Did your commit change anything in the lapack requirements?


Thanks,

Lennart.



>
> Thank You.
>
> Alvaro Frank

--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
L.C. Karssen
Utrecht
The Netherlands

lennart at karssen.org
http://blog.karssen.org
GPG key ID: A88F554A
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-