Skip to content

R test suite LAPACK error with AOCL

2 messages · Christian Tuma, Peter Dalgaard

Original
Christian Tuma
# 
Hello,

We are running an AMD-Genoa compute cluster. For this system I compiled 
R-4.4.2 configured and linked against AMD Optimizing CPU Libraries 
(AOCL) downloaded from

https://www.amd.com/en/developer/aocl.html

When running the R test suite (make check), I get this error:

$ cat tests/lapack.Rout.fail
...
 > ##  -------  tests of non-finite values  -----------------
 >
 > a <- matrix(NaN, 3, 3,, list(one=1:3, two=letters[1:3]))
 > b <- cbind(1:3, NA)
 > dimnames(b) <- list(One=4:6, Two=11:12)
 > bb <- 1:3; names(bb) <- 11:12
 > ## gave error with LAPACK 3.11.0
 > ## names(dimnames(.)), ("two", "Two") are lost {FIXME?}:
 > ## IGNORE_RDIFF_BEGIN
 > stopifnot(is.na(print(solve(a, b )))) # is.na(): NA *or* NaN
Error in solve.default(a, b) :
   Lapack routine dgesv: system is exactly singular: U[1,1] = 0
Calls: stopifnot -> print -> solve -> solve.default
Execution halted

Now I wonder whether AOCL are supported by R or not. Did somebody 
already use this combination successfully? Is this test suite error a 
serious problem? Is a workaround available?

This is my R installation configuration line:

$ CC=gcc CFLAGS="-O3 -march=znver4" \
  CXX=g++ CXXFLAGS="-O3 -march=znver4" \
  FC=gfortran FCFLAGS="-O3 -march=znver4" \
  LDFLAGS="-Wl,-rpath=$GCC_PATH/lib64" \
  ../configure \
  --with-blas="-L/usr/lib64 -Wl,-rpath=$AOCL_ROOT/lib_LP64 
-L$AOCL_ROOT/lib_LP64 -lblis -lflame" \
  --with-lapack \
  --enable-year2038

I am using the GCC (13.3.0).

 > sessionInfo()
R version 4.4.2 (2024-10-31)
Platform: x86_64-pc-linux-gnu
Running under: Rocky Linux 9.4 (Blue Onyx)

Matrix products: default
BLAS:   /sw/numerics/aocl/5.0.0/gcc/lib_LP64/libblis.so.5.0.0
LAPACK: /sw/numerics/aocl/5.0.0/gcc/lib_LP64/libflame.so;  LAPACK 
version 3.11.0
...


With Intel MKL instead of AOCL the test suite passes without errors. But 
this is an AMD system, so here I tend to prefer AOCL over MKL.

Any ideas? Thank you.


Best wishes,
Christian
Peter Dalgaard
# 
Optimized numeric libraries are prone to getting slightly different results, which can trip up the checks. Howver, this case seems to be one of not passing NaN values properly:

What should happen is this
[,1] [,2]
a  NaN   NA
b  NaN   NA
c  NaN   NA
two
one   a   b   c
  1 NaN NaN NaN
  2 NaN NaN NaN
  3 NaN NaN NaN
but somewhere along the way, the computations are creating a 0 out of the NaN in the coefficient matrix. This look like dangerous behaviour that R cannot support.

-pd