Compiling UMFPACK

March 2, 2008 by · 48 Comments
Filed under: Sparse Matrices 

 

Introduction

UMFPACK is Unsymmetric MultiFrontal direct solver for sparse matrices developed by Prof Timothy A. Davis:

http://www.cise.ufl.edu/research/sparse/umfpack/

The goal of this chapter is consider how to compile UMFPACK under gcc. I will use gcc under Cygwin but the procedure should be the same on Linux. Additionally I will describe how to use the UMFPACK library compiled with gcc under Cygwin from within Microsoft Visual Studio.

The plan is as follows. First we compile UMFPACK without BLAS. This is a good starting point for those who are new to Unix environment. The next step is to compile UMFPACK with the optimised BLAS in order to reach the best efficiency of the library (I will employ ATLAS). The two final steps are for people working on Windows – to compile UMFPACK under MinGW and to use this library from within Microsoft Visual Studio.

Fetching and unpacking

UMFPACK depends on AMD and UFConfig. Hence it is necessary to download and unpack three archives from the UMFPACK site. I will use wget to get archives and tar/gz to unpack them.

$ wget http://www.cise.ufl.edu/research/sparse/umfpack/UMFPACK-5.2.0.tar.gz

$ wget http://www.cise.ufl.edu/research/sparse/UFconfig/UFconfig-3.1.0.tar.gz

$ wget http://www.cise.ufl.edu/research/sparse/amd/AMD-2.2.0.tar.gz

Let us check that we have the files

$ ls
AMD-2.2.0.tar.gz UFconfig-3.1.0.tar.gz UMFPACK-5.2.0.tar.gz

and then unpack them

$ tar zxvf UMFPACK-5.2.0.tar.gz

Use TAB for name completion. That is, type tar zxvf UM and press TAB.

$ tar zxvf UFconfig-3.1.0.tar.gz

$ tar zxvf AMD-2.2.0.tar.gz

Explore the directories and files. Short information is in UMFPACK/README.txt and the documentation is in UMFPACK/Doc. Pay attention to UMFPACK/Makefile. This is the main makefile that will be used to build the library.

There are different configuration settings. They are made by editing file UFconfig/UFconfig.mk. The variables defined in this file will be included in all makefiles.

Compiling without BLAS

Let us start by disabling the use of BLAS. The performance will suffer but this is the simplest way to start working. In this case, we need just to specify a C compiler in UFconfig.mk. There are some Fortran files in the UMFPACK distribution but by default they are not used. For gcc it suffers to change the next lines

CC = gcc
CFLAGS = -O3

The lines below are not to use BLAS. First it is necessary to comment out variables BLAS and LAPACK

#BLAS = -lblas -lgfortran -lgfortranbegin
#LAPACK = -llapack

Second is to modify

UMFPACK_CONFIG = -DNBLAS

Finally on Windows it is good to add *.exe to the variable

CLEAN = *.o *.obj *.ln *.bb *.bbg *.da *.tcov *.gcov gmon.out *.bak *.d *.exe

On Windows gcc adds .exe to binaries and this setting will clean them. Otherwise later on you may need to clean them manually.

The modified file is UFconfig.mk.noblas. You can just replace with it UFconfig/UFconfig.mk.

Now we go to the directory UMFPACK and run make

$ cd UMFPACK

$ make

Now make reads Makefile in this directory and executes it. It builds the AMD library in AMD/Lib, the UMFPACK library in UMFPACK/Lib, and then demos in UMFPACK/Demo. After that it runs demos and compares output with the output included with the library. One sees some differences but they are not essential.

That’s it. Now you have AMD/Lib/libamd.a, UMFPACK/Lib/libumfpack.a and compiled demos in UMFPACK/Demo, that you can use as starting points on how to use UMFPACK in your code.

Compiling with ATLAS

UMFPACK uses calls to BLAS to reach the maximum efficiency. I will use ATLAS (you can find precompiled ATLAS with Cygwin at atlas-3.6-win.tar.gz) and assume that it is located at $HOME/lib/atlas

$ ls $HOME/lib/atlas
libatlas.a libblas.a libcblas.a libf77blas.a liblapack.a

If you put it in another location, please modify the path to ATLAS below accordingly.

Let us first change the lines that told UMFPACK not to use BLAS and see what happens. Change in UFconfig.mk the line with UMFPACK_CONFIG to

UMFPACK_CONFIG =

or just comment it out. Now we have to delete previously compiled object files

$ make purge

and compile UMFPACK again without -DNBLAS

$ make

What happens is that make compiles the AMD and UMFPACK libraries but fails to link demos. There should be linking errors

gcc -O3 -I../Include -I../../AMD/Include -I../../UFconfig -o umfpack_di_demo umfpack_di_demo.c ../Lib/libumfpack.a ../../AMD/Lib/libamd.a -lm
../Lib/libumfpack.a(umf_di_blas3_update.o):umf_blas3_update.c:(.text+0xe8): undefined reference to `_dtrsm_'
../Lib/libumfpack.a(umf_di_blas3_update.o):umf_blas3_update.c:(.text+0x184): undefined reference to `_dgemm_'
../Lib/libumfpack.a(umf_di_blas3_update.o):umf_blas3_update.c:(.text+0x1ff): undefined reference to `_dger_'
../Lib/libumfpack.a(umf_di_local_search.o):umf_local_search.c:(.text+0x4e4): undefined reference to `_dgemv_'
../Lib/libumfpack.a(umf_di_local_search.o):umf_local_search.c:(.text+0x6b0): undefined reference to `_dtrsv_'

Here we see a list of functions that now have been inserted in the UMFPACK library and which the linker could not find. However, the libraries AMD and UMFPACK by themselves are done and one can already use them.

There is a useful tool nm that allows us to see the symbols defined in the libraries. The command

$ nm Lib/libumfpack.a | grep dgemm
U _dgemm_
U _dgemm_

confirms us that the symbol _dgemm_ has been used in the UMFPACK library but is not defined there (symbol U). On the other hand, we can see that this function is defined in libf77blas.a (symbol T)

$ nm $HOME/lib/atlas/libf77blas.a | grep _dgemm_
U _atl_f77wrap_dgemm__
00000000 T _dgemm_
00000000 T _atl_f77wrap_dgemm__

This means that we have to tell make to use ATLAS libraries when it compiles demos. To this end it is necessary to define correctly the BLAS variable that we commented out previously

BLAS = -L$(HOME)/lib/atlas -lf77blas -latlas -lg2c

-L defines the path to the libraries and you may need to modify it appropriately. The path should be absolute or relative to UMFPACK/Demo, as gcc will be executed in this directory. UMFPACK uses Fortran interface to BLAS that is defined in libf77blas.a and the implementation by itself is in libatlas.a. libf77blas.a has been compiled with g77 and as such it needs libg2c.a.

Now

$ make

should build demos correctly. Note that this time it does not build the libraries again.

The modified UFconfig.mk set to use ATLAS is here (UFconfig.mk.atlas) but it may be necessary to change -L in BLAS to the right location.

Compiling under MinGW

Cygwin is a tool to port Unix applications to Windows. As such, it emulates Unix API on Windows and the final application is linked to cygwin1.dll that implements the interface. One can see it with cygcheck, for example

$ cygcheck Demo/umfpack_simple.exe
Demo/umfpack_simple.exe
C:\cygwin\bin\cygwin1.dll
C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\RPCRT4.dll
C:\WINDOWS\system32\Secur32.dll

If we would like to use UMFPACK with Microsoft Visual Studio, we need to make sure that the compiled libraries do not call Unix API. This is possible if one uses the flag -mno-cygwin, which forces gcc to use MinGW.

Add -mno-cygwin to CFLAGS in UFconfig.mk

CFLAGS = -O3 -mno-cygwin

Note that CFLAGS is defined two times and it is necessary to add this to the second definition or to comment the second definition out. The file with the change can be found here (UFconfig.mk.mingw).

Now

$ make purge

$ make

and the libraries compiled with -mno-cygwin are ready. Note that in this case the differences in output files will be much bigger. The first reason is that with -mno-cygwin the application writes the end of line as CR LF and in the output supplied with UMFPACK the end of line is just LF. This can be circumvented with -b for diff

$ diff -b my_umfpack_di_demo.out umfpack_di_demo.out

Still, there will be more differences as the formatting of numbers is different anyway.

Using UMFPACK with Microsoft Visual Studio

Microsoft Visual C compiler can be called from the command line and this is possible directly from within the Cygwin environment. To this end, it is necessary to modify the path and to define several environment variables required by cl. You can look at Using Microsoft Visual C under Gygwin to see how I have done it under tsch.

When everything is done correctly, the command cl should produce something like below

$ cl
Microsoft (R) 32-Bit C/C++-Optimierungscompiler Version 14.00.50727.762 für 80x86
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.

Syntax: cl [ Option... ] Dateiname... [ /link Linkeroption... ]

The Microsoft linker recognizes the libraries compiled by gcc under Cygwin. What we need to do is to just rename them from *.a to *.lib.

Let us take as an example umfpack_simple.c from UMPFACK/Demo. Make a directory ms in the directory where we have started

$ cd ..

$ ls
AMD UFconfig UMFPACK AMD-2.2.0.tar.gz
UFconfig-3.1.0.tar.gz UMFPACK-5.2.0.tar.gz

$ mkdir ms

$ cd ms

and copy this file here. Then copy and rename libamd.a, libumfpack.a, libf77blas.a, libatlas.a by changing the extension from *.a to *.lib. Additionally we need libg2c.a for libf77blas.a and libgcc.a, as libg2c.a uses some symbols from it. You should take these two libraries from /lib/gcc/i686-pc-mingw32/3.4.4 (not from /lib/gcc/i686-pc-cygwin/3.4.4/).

At the end you should have the next files

$ ls
libamd.lib libf77blas.lib libgcc.lib umfpack_simple.c
libatlas.lib libg2c.lib libumfpack.lib

Now the command

$ cl -MD -I../UMFPACK/Include -I../AMD/Include -I../UFconfig umfpack_simple.c libumfpack.lib libamd.lib libf77blas.lib libatlas.lib libg2c.lib libgcc.lib

does the job. It compiles umfpack_simple.c and links the object file with the libraries. The flags -I tells cl where to find the headers from UMFPACK. You may need to modify the path if you have made this directory in another place. Interestingly enough that cl understands correctly the direct slash as the sigh for directory. -MD is the regime with which the MinGW libraries are working best. In this case actually it is possible to compile without it but there will some warnings from the linker. If you understand the command, you can make also this settings directly in GUI.

Finally the question how I have found that it is necessary to add libgcc.lib. The answer is simple. Try to compile without it. Then you immediately see some symbols missing and simple manipulations with nm shows that they are in libgcc.a.

By editing makefiles in UMPFACK it is possible to compile AMD and UMFPACK directly with cl. This should be relatively simple. What will be more challenging is to compile ATLAS with cl. Alternatively you can use the optimised Intel BLAS.

Related Paper

Compiling UMFPACK with Microsoft Visual C

Discussion

How to create MS VC++ project for UMFPACK
use umfpack in fortran

Social Tagging:

Comments

48 responses to “Compiling UMFPACK”

Leave your response
  1. John Frankish says:
    24.02.2011 at 6:31 am

    Hi,

    It would be good to explain how to compile and link amd and unfpack as shared libs under linux

    Thanks
    John

  2. Evgenii Rudnyi says:
    24.02.2011 at 9:02 pm

    Basically you need to change the lines in makefiles that put all object files together. I have once compiled UMFPACK as DLL under cygwin, it went rahter straightforward. Next week I probably could describe it for cygwin, but I do not Linux at hand.

  3. John Frankish says:
    26.02.2011 at 9:49 am

    Thanks – in fact I managed by modifying the Makefiles in line with the diff file for the Debian packages for umfpack and amd.

    If there’s any interest, I could email the Makefiles

  4. Evgenii Rudnyi says:
    26.02.2011 at 10:46 am

    If you want it to, I can make for example a folder

    http://matrixprogramming.com/files/contrib/john.frankish/

    and put it there.

  5. Evgenii Rudnyi says:
    02.03.2011 at 2:13 pm

    John, I have copied you makefiles to the link aboved. Thanks a lot.

  6. Steve says:
    03.03.2011 at 11:42 pm

    Hi Evgenii,

    Thanks for this great posting. Regarding to your instruction, I have encountered two problems:

    I encountered the first problem when going with ‘Compiling with ATLAS’.
    I have placed the atlas file in the following directory:

    $ ls $E:UMFPACK/UMFPACK/lib/windows
    libatlas.a libblas.a libcblas.a libf77blas.a liblapack.a

    and have corrected the command:

    BLAS = -L$E:UMFPACK/UMFPACK/lib/windows -lf77blas -latlas -lg2c

    To my own directory.

    However, when I type the make command, the following error occurs:

    ——————————————————–
    gcc -O3 -I../Include -I../../AMD/Include -I../../UFconfig -o umfpack_di_demo um
    fpack_di_demo.c ../Lib/libumfpack.a ../../AMD/Lib/libamd.a -L:/UMFPACK/UMFPACK/l
    ib/windows -lf77blas -latlas -lg2c -lm
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find
    -lf77blas
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find
    -latlas
    /usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/bin/ld: cannot find
    -lg2c
    collect2: ld returned 1 exit status
    make[1]: *** [umfpack_di_demo] Error 1
    make[1]: Leaving directory `/cygdrive/e/UMFPACK/UMFPACK/Demo’
    make: *** [library] Error 2
    —————————————————————

    The second problem is with ‘Compiling under MinGW’. I was using your UFconfig.mk.mingw as my UFconfig.mk. however, when I typed the make command, it has the following error:

    ————————————————
    $ make
    ( cd ../AMD ; make library )
    make[1]: Entering directory `/cygdrive/e/UMFPACK/AMD’
    ( cd Lib ; make )
    make[2]: Entering directory `/cygdrive/e/UMFPACK/AMD/Lib’
    gcc -O3 -mno-cygwin -I../Include -I../../UFconfig -c ../Source/amd_global.c -o
    amd_global.o
    gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler.

    make[2]: *** [amd_global.o] Error 1
    make[2]: Leaving directory `/cygdrive/e/UMFPACK/AMD/Lib’
    make[1]: *** [library] Error 2
    make[1]: Leaving directory `/cygdrive/e/UMFPACK/AMD’
    make: *** [library] Error 2
    ————————————————-

    Any help will be appreciated.

    Thanks
    Steve.

  7. Evgenii Rudnyi says:
    04.03.2011 at 11:04 am

    >BLAS = -L$E:UMFPACK/UMFPACK/lib/windows

    Try to use the full path here (or make a space between -L and the argument). It seems that something is wrong with macro expansion.

    >-mno-cygwin
    Correct, they have removed support of mingw in gcc 4.* Frankly speaking, I do not know what to do here. An option for example would be to use gcc 3.* under cygwin although it is not that nice. Well, first do it without -mno-cygwin.

  8. Steve says:
    04.03.2011 at 11:12 pm

    Hi Evgenii,

    >BLAS = -L$E:UMFPACK/UMFPACK/lib/windows
    Try to use the full path here (or make a space between -L and the argument). It seems that something is wrong with macro expansion

    – For this problem, I think I am using a full path here. And I also tried adding a space there, but it is still not working.

    For the second problem, is there any alternatives to compile except using cygwin and mingw?

    Thanks,
    Steve.

  9. Evgenii Rudnyi says:
    05.03.2011 at 9:28 am

    On Unix $ means that there is a macro variable. The full path in Cygwin will be something like

    /cygdrive/e/umfpack/lib/windows

    For the second problem, if you would like to compile a code that does not depend on cygwin1.dll, the simplest nowadays is to use MS VC, as it is free.

    http://matrixprogramming.com/2008/05/umfpack-vc

    Alternatively you could use mingw directly.

  10. Dzoni says:
    17.03.2011 at 3:03 pm

    Hi,
    I use these routines,
    somebody before compiled them under linux ubuntu.
    now i am trying to port thi program on windows xp,
    and that is very difficult. Instead of developing,
    my code i am wresteling with boost for more then 3 days.
    Still nothings goes as described and if it wasn’t my job,
    i would stop torturing my self long ago. Why they shouldn’t
    precompile that for us if they realy wants us to use their software. The last problem i faced to is that the same error aperars after make command, no matther if i delete whole makefile. people stay away if you are able to.

  11. Evgenii Rudnyi says:
    17.03.2011 at 4:13 pm

    I am not sure if I get your point. MUMPS is a free software and if you cannot manage to port it, then basically it is your problem. If you would like to do something new, then you must learn it. The life is difficult but this is exactly why it is also interesting.

    Alternatively you can just compile MUMPS under Cygwin. In this case, you need to change nothing.

  12. Dzoni says:
    24.03.2011 at 4:30 pm

    PLEASEEEEEE PEOPLE SOMEONE HELP

  13. Evgenii Rudnyi says:
    26.03.2011 at 11:22 am

    If you need help, you have to describe your problem first. You should understand that no one will compile the library for you. If you find it too difficult, just buy MKL, what is the problem.

  14. Ying Liu says:
    15.09.2011 at 1:46 pm

    Hi,
    Thanks for this great posting. But I have encountered a problem:
    I build umfpack in the Mingw32,but it doesn’t have g77, just gfortran, so I build the atlas(libf77blas.a) by gfortran, and it works well.

    CC = gcc
    CFLAGS = -O3 -mno-cygwin
    BLAS = -L/home/Administrator/umfpack/atlas/lib/ -lf77blas -latlas -lgfortran

    The problem is Using UMFPACK with Microsoft Visual Studio
    , the command is like that:
    cl -MD -I../UMFPACK/Include -I../AMD/Include -I../UFconfig umfpack_simple.c
    libumfpack.lib libamd.lib libf77blas.lib libatlas.lib libgfortran.lib libgcc.li
    b
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
    Copyright (C) Microsoft Corporation. All rights reserved.

    umfpack_simple.c
    Microsoft (R) Incremental Linker Version 9.00.21022.08
    Copyright (C) Microsoft Corporation. All rights reserved.

    /out:umfpack_simple.exe
    umfpack_simple.obj
    libumfpack.lib
    libamd.lib
    libf77blas.lib
    libatlas.lib
    libgfortran.lib
    libgcc.lib
    libgfortran.lib(write.o) : error LNK2001: unresolved external symbol ___mingw_sp rintf
    libgfortran.lib(open.o) : error LNK2001: unresolved external symbol ___mingw_spr intf
    libgfortran.lib(main.o) : error LNK2001: unresolved external symbol ___mingw_spr intf
    libgfortran.lib(transfer.o) : error LNK2019: unresolved external symbol ___mingw _sprintf referenced in function _require_type
    libgfortran.lib(unix.o) : error LNK2001: unresolved external symbol ___mingw_spr intf
    libgfortran.lib(format.o) : error LNK2001: unresolved external symbol ___mingw_s printf
    libgfortran.lib(list_read.o) : error LNK2001: unresolved external symbol ___ming w_sprintf
    libgfortran.lib(unix.o) : error LNK2019: unresolved external symbol __CRT_MT ref erenced in function _flush_all_units_1
    libgfortran.lib(unit.o) : error LNK2001: unresolved external symbol __CRT_MT
    libgfortran.lib(random.o) : error LNK2001: unresolved external symbol __CRT_MT
    libgfortran.lib(unix.o) : error LNK2019: unresolved external symbol ___mingw_vsn printf referenced in function __gfortrani_st_vprintf
    libgfortran.lib(list_read.o) : error LNK2019: unresolved external symbol ___ming w_snprintf referenced in function _nml_read_obj.clone.8
    libgfortran.lib(write.o) : error LNK2001: unresolved external symbol ___mingw_sn printf
    libgfortran.lib(open.o) : error LNK2001: unresolved external symbol ___mingw_snp rintf
    libgfortran.lib(read.o) : error LNK2019: unresolved external symbol ___strtof re ferenced in function __gfortrani_convert_real
    libgfortran.lib(read.o) : error LNK2019: unresolved external symbol ___strtold r eferenced in function __gfortrani_convert_real
    libgfortran.lib(read.o) : error LNK2019: unresolved external symbol ___strtod re ferenced in function __gfortrani_convert_real
    umfpack_simple.exe : fatal error LNK1120: 7 unresolved externals

    so I find the lib in gcc/lib:libmingwex.alibmingwthrd.a libmsvcr90.a
    an then it links well
    cl -MD -I../UMFPACK/Include -I../AMD/Include -I../UFconfig umfpack_simple.c libumfpack.lib libamd.lib libf77blas.lib libatlas.lib libgfortran.lib libgcc.lib libmingwex.lib libmingwthrd.lib libmsvcr90.lib
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
    Copyright (C) Microsoft Corporation. All rights reserved.

    umfpack_simple.c
    Microsoft (R) Incremental Linker Version 9.00.21022.08
    Copyright (C) Microsoft Corporation. All rights reserved.

    /out:umfpack_simple.exe
    umfpack_simple.obj
    libumfpack.lib
    libamd.lib
    libf77blas.lib
    libatlas.lib
    libgfortran.lib
    libgcc.lib
    libmingwex.lib
    libmingwthrd.lib
    libmsvcr90.lib

    but when running it,there is the problem:
    umfpack_simple.exe encountered a problem and needs to close. We apologize for the inconvenience.

    there must someone dll is wrong! I don’t know how to use the UMFPACK in MSVC

  15. Evgenii Rudnyi says:
    16.09.2011 at 9:58 pm

    A good idea to start compiling UMFPACK without BLAS. If this is working, then presumably the problem is with ATLAS. To this end, it would be then good to run some simple examples with ATLAS.

  16. Ying Liu says:
    17.09.2011 at 12:28 pm

    Yes,I had started compling UMFPACK without BLAS, then with ATLAS, and finially the Demos. It all works good!

  17. Ying Liu says:
    17.09.2011 at 12:41 pm

    And also, I compile and link the example with Visual C++ like that:
    http://matrixprogramming.com/2008/03/compilelinkvc

  18. Néstor says:
    19.09.2011 at 11:17 am

    Hi all!

    I am trying to compile UMFPACK with atlas and I get the following error:

    gcc -O3 -I../Include -I../../AMD/Include -I../../UFconfig -o umfpack_di_demo umfpack_di_demo.c ../Lib/libumfpack.a ../../AMD/Lib/libamd.a -xlic_lib=sunperf -lm
    ../Lib/libumfpack.a(umf_di_local_search.o): In function `umfdi_local_search’:
    umf_local_search.c:(.text+0x4c0): undefined reference to `dtrsv_’
    umf_local_search.c:(.text+0×634): undefined reference to `dgemv_’
    ../Lib/libumfpack.a(umf_di_blas3_update.o): In function `umfdi_blas3_update’:
    umf_blas3_update.c:(.text+0x11d): undefined reference to `dtrsm_’
    umf_blas3_update.c:(.text+0x1de): undefined reference to `dgemm_’
    umf_blas3_update.c:(.text+0x2ae): undefined reference to `dger_’
    collect2: ld returned 1 exit status
    make: *** [umfpack_di_demo] Error 1

    Notice that instead of: ‘_dger_’,”_dgemm_’,'_dtrsm_’ …
    as in the tutorial, the error I get is related with:
    ‘dger_’,”dgemm_’,'dtrsm_’ …

    When I try :

    $ nm $HOME/lib/atlas/libf77blas.a | grep _dgemm_

    Errors appears … so no dependeces can be found ..

    I have tried to define the BLASS variable in the .mk file as:

    BLAS = -L$(HOME)/lib/windows -lf77blas -latlas -lg2c

    After that, I get the following error while compiling:

    gcc -O3 -I../Include -I../../AMD/Include -I../../UFconfig -o umfpack_di_demo umfpack_di_demo.c ../Lib/libumfpack.a ../../AMD/Lib/libamd.a -L/xbar/nas1/home4/mek/nerga/lib/windows -lf77blas -latlas -lg2c -lm
    /usr/bin/ld: cannot find -lg2c
    collect2: ld returned 1 exit status

    Any idea about what I am doing wrong ??

    Thank you in advance!

    Néstor.

  19. Néstor says:
    19.09.2011 at 11:18 am

    Sorry,

    I am using a Sun Solaris system …

    Thank you again.

    Néstor.

  20. Evgenii Rudnyi says:
    19.09.2011 at 9:03 pm

    Hard to say what is going on on Solaris.
    1) You cannot use libraries from Windows on Solaris.
    2) There is 64-bit and 32-bit Solaris and hence 32-bit and 64-bit libraries. Whether it is possible to mix them, I do not know.
    3) Some linkers do not show the first underscore, so this may not be a problem.
    4) On Sun there is the optimized BLAS in sunperf. The question is to check how BLAS functions are called there.
    Finally you can start by compiling UMFPACK without BLAS. Is this working?

  21. Ying Liu says:
    20.09.2011 at 5:13 am

    I’m sorry I didn’t describe the problem clearly!
    .
    The next is my step:
    1:compling UMFPACK without BLAS(succeed)
    2:compiling UMFPACK with ATLAS(succeed)
    3:compiling Demos in UMFPACK(succeed)
    4:Using UMFPACK with Microsoft Visual Studio(the problem!)
    ————————————————–
    cl -MD -I../UMFPACK/Include -I../AMD/Include -I../UFconfig umfpack_simple.c
    libumfpack.lib libamd.lib libf77blas.lib libatlas.lib libgfortran.lib libgcc.li
    b
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
    Copyright (C) Microsoft Corporation. All rights reserved.

    umfpack_simple.c
    Microsoft (R) Incremental Linker Version 9.00.21022.08
    Copyright (C) Microsoft Corporation. All rights reserved.

    /out:umfpack_simple.exe
    umfpack_simple.obj
    libumfpack.lib
    libamd.lib
    libf77blas.lib
    libatlas.lib
    libgfortran.lib
    libgcc.lib
    libgfortran.lib(write.o) : error LNK2001: unresolved external symbol ___mingw_sp rintf
    libgfortran.lib(open.o) : error LNK2001: unresolved external symbol ___mingw_spr intf
    libgfortran.lib(main.o) : error LNK2001: unresolved external symbol ___mingw_spr intf
    libgfortran.lib(transfer.o) : error LNK2019: unresolved external symbol ___mingw _sprintf referenced in function _require_type
    libgfortran.lib(unix.o) : error LNK2001: unresolved external symbol ___mingw_spr intf
    libgfortran.lib(format.o) : error LNK2001: unresolved external symbol ___mingw_s printf
    libgfortran.lib(list_read.o) : error LNK2001: unresolved external symbol ___ming w_sprintf
    libgfortran.lib(unix.o) : error LNK2019: unresolved external symbol __CRT_MT ref erenced in function _flush_all_units_1
    libgfortran.lib(unit.o) : error LNK2001: unresolved external symbol __CRT_MT
    libgfortran.lib(random.o) : error LNK2001: unresolved external symbol __CRT_MT
    libgfortran.lib(unix.o) : error LNK2019: unresolved external symbol ___mingw_vsn printf referenced in function __gfortrani_st_vprintf
    libgfortran.lib(list_read.o) : error LNK2019: unresolved external symbol ___ming w_snprintf referenced in function _nml_read_obj.clone.8
    libgfortran.lib(write.o) : error LNK2001: unresolved external symbol ___mingw_sn printf
    libgfortran.lib(open.o) : error LNK2001: unresolved external symbol ___mingw_snp rintf
    libgfortran.lib(read.o) : error LNK2019: unresolved external symbol ___strtof re ferenced in function __gfortrani_convert_real
    libgfortran.lib(read.o) : error LNK2019: unresolved external symbol ___strtold r eferenced in function __gfortrani_convert_real
    libgfortran.lib(read.o) : error LNK2019: unresolved external symbol ___strtod re ferenced in function __gfortrani_convert_real
    umfpack_simple.exe : fatal error LNK1120: 7 unresolved externals
    ——————————————————————
    so I find the lib in gcc/lib:libmingwex.alibmingwthrd.a libmsvcr90.a
    an then it links well
    cl -MD -I../UMFPACK/Include -I../AMD/Include -I../UFconfig umfpack_simple.c libumfpack.lib libamd.lib libf77blas.lib libatlas.lib libgfortran.lib libgcc.lib libmingwex.lib libmingwthrd.lib libmsvcr90.lib
    Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
    Copyright (C) Microsoft Corporation. All rights reserved.

    umfpack_simple.c
    Microsoft (R) Incremental Linker Version 9.00.21022.08
    Copyright (C) Microsoft Corporation. All rights reserved.

    /out:umfpack_simple.exe
    umfpack_simple.obj
    libumfpack.lib
    libamd.lib
    libf77blas.lib
    libatlas.lib
    libgfortran.lib
    libgcc.lib
    libmingwex.lib
    libmingwthrd.lib
    libmsvcr90.lib

    but when running it,there is the problem:
    umfpack_simple.exe encountered a problem and needs to close. We apologize for the inconvenience.

  22. Néstor says:
    20.09.2011 at 11:36 am

    Thanks for your answer Evgenii,

    UMFPACK compiles perfectly without BLAS.
    ————————————————————
    So I guess I should:

    A) Forget about ATLAS
    B) Get some insight on how the SunPerf package works.

    ————————————————————
    Although for my surprise UMFPACK without BLAS is already much faster than LAPACK in order to solve my linear system (3000×3000 sparse matrix). LAPACK takes aprox 2 seconds, while UMFPACK (without BLAS) solves it in aprox 0,1.

    ————————————————————
    It is expected a big improvement in speed when BLAS is included?? Also for such a “small” sparse matrix ?? my matrix is approx 90% sparse.

  23. Evgenii Rudnyi says:
    25.09.2011 at 6:49 pm

    To Ying Liu.

    It was me who has not written clear. I would adice to compile with Microsoft Visual Studio but without BLAS. This way you see, if your problem is ATLAS related or not.

  24. Evgenii Rudnyi says:
    25.09.2011 at 6:54 pm

    To Néstor.

    BLAS brings advantage when the dense matrix size is bigger than about 100, see for example results for a matrix 1000×1000

    http://matrixprogramming.com/2008/01/matrixmultiply#Conclusion

    Yet, the dense matrices employed in UMFPACK are much smaller than the original sparse matrix, so in the case of your matrix, I guess, BLAS may not bring too much.

  25. Néstor says:
    26.09.2011 at 9:41 am

    Thanks Evgenii,

    I am running it without Blass and it is really fast:

    It takes around 0.05 seconds to solve my system while LAPACK solver was taking almost 3 s. I guess I do not need BLAS, I am quite happy with the speedup ! :)

    Thanks for your help.

    Néstor.

  26. Néstor says:
    26.09.2011 at 7:23 pm

    One question more,

    Which is the most efficient way of transforming a SPARSE MATRIX from COO format to CCF format ?? Has umfpack any function for that ??

    And can UMPFACK work with the COO format ??

    Thank you in advance.

    Néstor.

  27. Evgenii Rudnyi says:
    26.09.2011 at 8:29 pm

    No, UMFPACK cannot work with the coordinate format directly (MUMPS does). You may want to look at BeBOP

    http://matrixprogramming.com/2008/07/bebop

    or use my SparseMatrix, see

    http://matrixprogramming.com/2011/06/sample-code-in-c-to-run-sparse-solvers

  28. Néstor says:
    14.10.2011 at 9:52 am

    Hi again !

    Now i am trying to compile UMFPACK with ATLAS in a UNIX cluster and I have the same problem as before with the solaris machine …

    The path to blas I set it to: BLAS = -L ../../lib/windows -lf77blas -latlas -lg2c

    ————————————————————

    The error messages I get are:

    icc -O3 -I../Include -I../../AMD/Include -I../../UFconfig -o umfpack_di_demo umfpack_di_demo.c ../Lib/libumfpack.a ../../AMD/Lib/libamd.a -L ../../lib/windows -lf77blas -latlas -lg2c -lm
    umfpack_di_demo.c(96): (col. 5) remark: LOOP WAS VECTORIZED.
    ../Lib/libumfpack.a(umf_di_local_search.o)(.text+0x6ea): In function `umfdi_local_search’:
    : undefined reference to `dtrsv_’
    ../Lib/libumfpack.a(umf_di_local_search.o)(.text+0x9cf): In function `umfdi_local_search’:
    : undefined reference to `dgemv_’
    ../Lib/libumfpack.a(umf_di_blas3_update.o)(.text+0xf0): In function `umfdi_blas3_update’:
    : undefined reference to `dtrsm_’
    ../Lib/libumfpack.a(umf_di_blas3_update.o)(.text+0x18c): In function `umfdi_blas3_update’:
    : undefined reference to `dgemm_’
    ../Lib/libumfpack.a(umf_di_blas3_update.o)(.text+0x1fe): In function `umfdi_blas3_update’:
    : undefined reference to `dger_’
    make[1]: *** [umfpack_di_demo] Error 1
    make[1]: Leaving directory `/home/afm/afmnrg/Q^3UIC_intel/SPARS/UMFPACK/Demo’

    ————————————————————
    Any idea what I am doing wrong ??

  29. Evgenii Rudnyi says:
    15.10.2011 at 4:03 pm

    The message says that the linker cannot find the blas routines. To understand why, try for example

    nm libf77blas.a | grep -i dgemm

    to see what functions are there.

  30. Néstor says:
    17.10.2011 at 9:44 am

    When I write :

    nm libf77blas.a | grep -i dgemm

    it prints in screen …

    ————————————————————

    nm: srotg.o: File format not recognized
    nm: srotmg.o: File format not recognized
    nm: sscal.o: File format not recognized
    nm: snrm2.o: File format not recognized
    nm: sasum.o: File format not recognized
    nm: isamax.o: File format not recognized
    nm: saxpy.o: File format not recognized
    nm: scopy.o: File format not recognized
    nm: sswap.o: File format not recognized
    nm: srot.o: File format not recognized
    nm: srotm.o: File format not recognized
    nm: sdot.o: File format not recognized
    nm: dsdot.o: File format not recognized
    nm: sdsdot.o: File format not recognized
    nm: ATL_F77wrap_srotg.o: File format not recognized
    nm: ATL_F77wrap_srotmg.o: File format not recognized
    nm: ATL_F77wrap_sscal.o: File format not recognized
    nm: ATL_F77wrap_snrm2.o: File format not recognized
    nm: ATL_F77wrap_sasum.o: File format not recognized
    nm: ATL_F77wrap_isamax.o: File format not recognized
    nm: ATL_F77wrap_saxpy.o: File format not recognized
    nm: ATL_F77wrap_scopy.o: File format not recognized
    nm: ATL_F77wrap_sswap.o: File format not recognized
    nm: ATL_F77wrap_srot.o: File format not recognized
    nm: ATL_F77wrap_srotm.o: File format not recognized
    nm: ATL_F77wrap_sdot.o: File format not recognized
    nm: ATL_F77wrap_dsdot.o: File format not recognized
    nm: ATL_F77wrap_sdsdot.o: File format not recognized

    ————————————————————

    and it keeps going with many other files, I think it does not reconize even one of the files.

    What does it mean ???

    Thank you in advance.

    Néstor.

  31. Evgenii Rudnyi says:
    17.10.2011 at 11:08 pm

    This means that the ATLAS library that you use does not belong to the platform on which you would like to employ it (say the library from Windows will not work on Unix). Basically you have to compile ATLAS for that platform (or to use another optimized BLAS for that platform).

  32. Néstor says:
    18.10.2011 at 10:50 am

    Thanks for the info Evgenii !

    I have downloaded a precompiled version of ATLAS for LINUX and now it compiles perfectly !

    It is only a 5% faster than without BLAS … at least it was worth the try !

    Thanks for all your help.

    Néstor.

  33. M says:
    06.01.2012 at 9:18 am

    Hey Evgenii,

    I’m trying to install umfpack on my Windows machine, and the download link for the precompiled atlas doesn’t seem to include libg2c.a – any idea where I could find it?

    Thanks!
    M

  34. Evgenii Rudnyi says:
    06.01.2012 at 11:16 am

    It is included with gcc 3 in Cygwin. Yet I should say that my ATLAS version is quite old and it might be good to search for somewhat newer version of BLAS:

    http://matrixprogramming.com/2010/08/blas-basic-linear-algebra-system

  35. zhipengq qin says:
    02.11.2012 at 11:54 pm

    Hi, Evgenii,

    Thank you very much about your article.

    However, I met a problem when I tried to install the Fortran interface after the C library has been built.

    I built the C library as you said successfully, and it is without BLAS. And then, I typed “make fortran64″ to build the Fortran interface, the computer told me that:

    > gcc -O3 -DNBLAS -I../Include -I../../AMD/Include -I../../UFconfig -c umf4_f77wrapper.c -o umf4_f77wrapper.o
    > gcc -O3 -DNBLAS -I../Include -I../../AMD/Include -I../../UFconfig -c umf4_f77zwrapper.c -o umf4_f77zwrapper.o
    > f77 -O -o umf4hb umf4hb.f umf4_f77wrapper.o \
    > ../Lib/libumfpack.a ../../AMD/Lib/libamd.a -lm
    > make[1]: f77: Command not found
    > make[1]: *** [fortran] Error 127
    > make[1]: Leaving directory `/home/zqin/UMFPACK/Demo’
    > make: *** [fortran] Error 2

    Should I modify the UFconfig.mk file?

    Thanks.

  36. Evgenii Rudnyi says:
    03.11.2012 at 10:34 am

    In gcc 3 the fortran compiler was g77. In gcc 4 however it is gfortran. Hence first check what a fortran compiler your gcc has and then modify configuration files accordingly.

  37. zhipengq qin says:
    04.11.2012 at 1:28 am

    Thank you Evgenii Rudnyi.

    I have build the library on a 32-bit machine, it works well.

    I also wish to build the library on a 64-bit machine, what should I do to modify the UFconfig.mk? From the UserGuide, it said, “Edit your SuiteSparse config/SuiteSparse config.mk
    le and select the 64-bit option.” But how to select the 64-bit option.

    I just do the same thing as you said, and type make gfortran64, the library seems to be built, however, it could not work well.

    Thank you again. Look forward for your response.

  38. Evgenii Rudnyi says:
    04.11.2012 at 6:30 pm

    You need to understand what compilers on your system available and how you should call them. You see, the command

    >f77 -O -o umf4hb umf4hb.f umf4_f77wrapper.o \
    ../Lib/libumfpack.a ../../AMD/Lib/libamd.a -lm

    does not work as there is no f77. Then the question is what do you have instead. First try this command manually and when you understand what it should look like, then you should modify configuration files accordingly.

  39. zhipengq qin says:
    05.11.2012 at 12:14 am

    Hi, Evgenii,

    Maybe I did not explain my second question clearly.

    I have solved the first question under your help. I found my C compiler is gcc4, and the fortran compiler is gfortran. And I built the library successful in a 32-bit machine.

    Then I tried to do the same thing in a 64-bit machine, the C compiler is also gcc4, and the fortran compiler is also gfortran. The library has been built, however, when I call the function “umfsys”, the value of Info array is -8, which means the UMF matrix is invalid.

    Is there something wrong about my fortran program?

    Thank you very much.

  40. zhipengq qin says:
    05.11.2012 at 2:59 am

    Hi, Evgenii,

    I wish to explain what I was doing further in order to receive your help.

    My objective is to build a UMF library and use it to solve linear system by a fortran code.

    At first, I tried to build this library on a 32-bit machine without the BLAS. However, I did not make clear about what the compiler is, under your help, I solve this problem, and use the fortran code to call all the routine in the library successfully.

    Then, I tried to do the same thing on a 64-bit machine. At this time, I use “make fortran64″ comment, the UMF had been compiled successfully, however, the problem arises when I call the “umfsys” routine in fortran program. The value of error code (Info array) is -8, the user guide says that this means the matrix is invalid.

    Right now, I wish to know what else I need to do when I turn from 32-bits to 64-bits?

    Thank you very much.

  41. Evgenii Rudnyi says:
    08.11.2012 at 9:51 pm

    You need to check that the size of integer is the same (4 or 8 Bytes) in C and Fortran compilers.

  42. Jordi says:
    19.11.2012 at 7:08 pm

    Hi Evgenii,
    Thanks for sharing this guide. I followed your instructions and had no problems compiling UMFPACK with Atlas for vsc++ 2005. But I don’t know if there is a significant penalty for using the compiled version with cygwin rather than the compiled version in linux. Has anyone used UMFPACK both in windows and linux and can shred some light into this matter?

    Thanks!

  43. wangjian says:
    24.11.2012 at 3:50 pm

    hi,evgenii
    i don’t know if umfpack can link with fortran on windows.if it can,did i need to rewrite the interface (umf4_f77wrapper.c)?

  44. wangjian says:
    24.11.2012 at 3:59 pm

    ps:now i can’t use umfpack on vs,my main program is written in fortran .but c program can do well,so i think it’s the key with interface.

  45. Evgenii Rudnyi says:
    24.11.2012 at 7:21 pm

    I have not used UMFPACK under Fortran, sorry. Otherwise, I was able to compile UMFPACK with Visual Studio:

    http://matrixprogramming.com/2008/05/umfpack-vc

  46. wangjian says:
    28.11.2012 at 3:49 am

    hi,Evgenii Rudnyi
    thank you very much about your articals.I have success to solve this question.it just need me to rewrite the interfcae.

  47. Ho Ba says:
    17.05.2013 at 10:13 am

    Hi

    can you explain (by details) for me how to use libumfpack.dll
    under Cygwin.
    please send an example in fortran under Cygwin.

  48. Evgenii Rudnyi says:
    17.05.2013 at 3:31 pm

    The best is to ask by Cygwin on how to compile and use DLLs. There should be an example in Cygwin docs.

    I have a small description

    http://matrixprogramming.com/2008/03/usingfortranfromc

    where there is an example of Fortran under Cygwin. Yet, now instead of g77 one should use gfortran.

Your response

Notify me of followup comments via e-mail. You can also subscribe without commenting.