[SciPy-User] Correctly compiling SciPy with UMFPACK support?

Ioan-Alexandru Lazar alexlz@lmn.pub...
Tue Aug 10 18:30:12 CDT 2010

Hello everyone,

I know that SciPy vanilla support for UMFPACK is going to be deprecated
due to license issues, so I hope I am not incorrectly directing my

I have spent the last two days trying to build SciPy with UMFPACK.
Normally, I would simply use the packages available from my distribution;
however, I want SciPy to use a version of UMFPACK I am compiling myself
using AMD's ACML (because I need multithreaded BLAS support).

Unfortunately, there's something that I don't seem to be getting straight
because regardless of how I do it, I end up with an error message.

If I am using scikits.umfpack or scipy version 0.7.0, the error message I
eventually receive is:

Traceback (most recent call last):
  File "/home/alexlz/Projects/2010/llssolve/scipytest.py", line 16, in
    umf = scikits.umfpack.UmfpackContext("zi")
line 278, in __init__
    self.control = nm.zeros( (UMFPACK_CONTROL, ), dtype = nm.double )
NameError: global name 'UMFPACK_CONTROL' is not defined

If I am using scipy.sparse.linalg.dsolve.umfpack in scipy version 0.8.0,
it complains that I have not compiled it with UMFPACK support.

However, I am quite certain that I have done so -- __umfpack.so appears in
the module directory and in fact, if I replace it with the __umfpack.so
file that my distribution installed in its systemwide installation
directory, it works; however, that one is not linked against ACML's BLAS.
I am further baffled by this because building the UMFPACK module actually
works -- I have made sure it doesn't fail, as I've read around the mailing
list and noted that building it fails silently if it cannot be correctly
compiled, being an optional extension of SciPy.

I am compiling UMFPACK using the following options (snippets from

CFLAGS = -fPIC -m64 -O3 -fexceptions
-L/home/alexlz/src/CBLAS/lib/LINUX -I/home/alexlz/src/CBLAS/src

# Fortran compiler (not normally required)
F77 = gfortran
F77LIB =

# C and Fortran libraries
LIB = -lm -lgomp -lgfortran

BLAS = -lcblas -lacml_mp -lgfortran

(Note: cblas is required because ACML doesn't follow the Netlib calling
convention. Also, note that I'm not trying to use it to build the entire
SciPy package -- I'm only interested in having multithreaded BLAS with

And the relevant entries in my site.cfg are:

library_dirs = /home/alexlz/libraries
include_dirs = /home/alexlz/includes
amd_libs = amd
library_dirs = /home/alexlz/libraries
include_dirs = /home/alexlz/includes
umfpack_libs = umfpack

Judging from the behavior (replacing the wrapper-built __umfpack.so with
the one supplied by my systemwide distribution) I am assuming this is an
issue with the way I am building it, especially considering that the
__umfpack.so I'm building and the one in the systemwide installation have
radically different sizes (mine is about 1M). However, I haven't found
anything in the installation instruction -- I appear to be building it
correctly for all I know. It doesn't work regardless of whether I am using
the scikits.umfpack version or the one to be deprecated from scipy.

Do you have any hint as to what I am doing wrong? I am currently out of

Thank you,
Alexandru Lazar,
LMN, Politehnica University of Bucharest

PS: If this is not an option, I would be grateful for any other suggestion
about how to use a version of UMFPACK compiled with a multithreaded BLAS.
Not necessarily the one from ACML (which is actually a bit complicated
because they're not following the netlib calling convention so I'm forced
to use CBLAS as well). If a readily-built binary is available, or there's
any other approach to this, I'd be happy to hear about it.

The background: I am trying to build my HPC application using Python, and
this is the only obstacle I am currently encountering. Unfortunately, the
very peculiar structure of the matrices I'm dealing with means that using
SuperLU is not an option, *but* a multithreaded BLAS library and UMFPACK
gives us a significant speedup on the 8-core nodes in our cluster.

More information about the SciPy-User mailing list