drtimothyaldendavis / suitesparse

The official SuiteSparse library: a suite of sparse matrix algorithms authored or co-authored by Tim Davis, Texas A&M University.

---

SuiteSparse: A Suite of Sparse matrix packages at http://suitesparse.com

Mar 22, 2024, SuiteSparse VERSION 7.7.0

SuiteSparse is a set of sparse-matrix-related packages written or co-authored by Tim Davis, available at https://github.com/DrTimothyAldenDavis/SuiteSparse .

Primary author of SuiteSparse (codes and algorithms, excl. METIS): Tim Davis

Code co-authors, in alphabetical order (not including METIS or LAGraph): Patrick Amestoy, Mohsen Aznaveh, David Bateman, Jinhao Chen, Yanqing Chen, Iain Duff, Joe Eaton, Les Foster, William Hager, Raye Kimmerer, Scott Kolodziej, Chris Lourenco, Stefan Larimore, Lorena Mejia Domenzain, Erick Moreno-Centeno, Markus Mützel, Corey Nolel, Ekanathan Palamadai, Sivasankaran Rajamanickam, Sanjay Ranka, Wissam Sid-Lakhdar, and Nuri Yeralan.

LAGraph has been developed by the highest number of developers of any of the packages in SuiteSparse and deserves its own list. The list also appears in LAGraph/Contibutors.txt:

Janos B. Antal,    Budapest University of Technology and Economics, Hungary
Mohsen Aznaveh,    Texas A&M University
David A. Bader     New Jersey Institute of Technology
Aydin Buluc,       Lawrence Berkeley National Lab
Jinhao Chen,       Texas A&M University
Tim Davis,         Texas A&M University
Florentin Dorre,   Technische Univeritat Dresden, Neo4j
Marton Elekes,     Budapest University of Technology and Economics, Hungary
Balint Hegyi,      Budapest University of Technology and Economics, Hungary
Tanner Hoke,       Texas A&M University
James Kitchen,     Anaconda
Scott Kolodziej,   Texas A&M University
Pranav Konduri,    Texas A&M University
Roi Lipman,        Redis Labs (now FalkorDB)
Tze Meng Low,      Carnegie Mellon University
Tim Mattson,       Intel
Scott McMillan,    Carnegie Mellon University
Markus Muetzel
Michel Pelletier,  Graphegon
Gabor Szarnyas,    CWI Amsterdam, The Netherlands
Erik Welch,        Anaconda, NVIDIA
Carl Yang,         University of California at Davis, Waymo
Yongzhe Zhang,     SOKENDAI, Japan

METIS is authored by George Karypis.

Additional algorithm designers: Esmond Ng and John Gilbert.

Refer to each package for license, copyright, and author information.

---

Documentation

Refer to each package for the documentation on each package, typically in the Doc subfolder.

---

SuiteSparse branches

• dev: the default branch, with recent updates of features to appear in the next stable release. The intent is to keep this branch in fully working order at all times, but the features will not be finalized at any given time.
• stable: the most recent stable release.
• dev2: working branch. All submitted PRs should made to this branch. This branch might not always be in working order.

---

SuiteSparse Packages

Packages in SuiteSparse, and files in this directory:

• AMD

  approximate minimum degree ordering. This is the built-in AMD function in MATLAB.

  authors: Tim Davis, Patrick Amestoy, Iain Duff

• bin

  where programs are placed when compiled, for make local

• BTF

  permutation to block triangular form

  authors: Tim Davis, Ekanathan Palamadai

• build

  folder for default build tree

• CAMD

  constrained approximate minimum degree ordering

  authors: Tim Davis, Patrick Amestoy, Iain Duff, Yanqing Chen

• CCOLAMD

  constrained column approximate minimum degree ordering

  authors: Tim Davis, Sivasankaran Rajamanickam, Stefan Larimore.

  Algorithm design collaborators: Esmond Ng, John Gilbert (for COLAMD)

• ChangeLog

  a summary of changes to SuiteSparse. See */Doc/ChangeLog for details for each package.

• CHOLMOD

  sparse Cholesky factorization. Requires AMD, COLAMD, CCOLAMD, the BLAS, and LAPACK. Optionally uses METIS. This is chol and x=A\b in MATLAB.

  author for all modules: Tim Davis

  CHOLMOD/Modify module authors: Tim Davis and William W. Hager

  CHOLMOD/SuiteSparse_metis: a modified version of METIS, embedded into the CHOLMOD library. See the README.txt files for details. author: George Karypis. This is a slightly modified copy included with SuiteSparse via the open-source license provided by George Karypis. SuiteSparse cannot use an unmodified copy of METIS.

• CITATION.bib

  citations for SuiteSparse packages, in bibtex format.

• CMakeLists.txt

  optional, to compile all of SuiteSparse. See below.

• CODE_OF_CONDUCT.md

  community guidelines

• COLAMD

  column approximate minimum degree ordering. This is the built-in COLAMD function in MATLAB.

  authors (of the code): Tim Davis and Stefan Larimore

  Algorithm design collaborators: Esmond Ng, John Gilbert

• Contents.m

  a list of contents for 'help SuiteSparse' in MATLAB.

• CONTRIBUTING.md

  how to contribute to SuiteSparse

• CONTRIBUTOR-LICENSE.txt

  required contributor agreement

• CSparse

  a concise sparse matrix package, developed for my book, "Direct Methods for Sparse Linear Systems", published by SIAM. Intended primarily for teaching. Note that the code is (c) Tim Davis, as stated in the book.

  For production, use CXSparse instead. In particular, both CSparse and CXSparse have the same include filename: cs.h. This package is used for the built-in DMPERM in MATLAB.

  author: Tim Davis

• CXSparse

  CSparse Extended. Includes support for complex matrices and both int or long integers. Use this instead of CSparse for production use; it creates a libcsparse.so (or dylib on the Mac) with the same name as CSparse. It is a superset of CSparse. Any code that links against CSparse should also be able to link against CXSparse instead.

  author: Tim Davis, David Bateman

• Example

  a simple package that relies on almost all of SuiteSparse

• .github

  workflows for CI testing on GitHub.

• GraphBLAS

  graph algorithms in the language of linear algebra.

  https://graphblas.org

  authors: Tim Davis, Joe Eaton, Corey Nolet

• include

  make install places user-visible include files for each package here, after make local.

• KLU

  sparse LU factorization, primarily for circuit simulation. Requires AMD, COLAMD, and BTF. Optionally uses CHOLMOD, CAMD, CCOLAMD, and METIS.

  authors: Tim Davis, Ekanathan Palamadai

• LAGraph

  a graph algorithms library based on GraphBLAS. See also https://github.com/GraphBLAS/LAGraph

  Authors: many.

• LDL

  a very concise LDL' factorization package

  author: Tim Davis

• lib

  make install places shared libraries for each package here, after make local.

• LICENSE.txt

  collected licenses for each package.

• Makefile

  optional, to compile all of SuiteSparse using make, which is used as a simple wrapper for cmake in each subproject.

  • make

    compiles SuiteSparse libraries. Subsequent make install will install in CMAKE_INSTALL_PATH (might default to /usr/local/lib on Linux or Mac).

  • make local

    compiles SuiteSparse. Subsequent make install will install in ./lib, ./include. Does not install in CMAKE_INSTALL_PATH.

  • make global

    compiles SuiteSparse libraries. Subsequent make install will install in /usr/local/lib (or whatever the configured CMAKE_INSTALL_PREFIX is). Does not install in ./lib and ./include.

  • make install

    installs in the current directory (./lib, ./include), or in /usr/local/lib and /usr/local/include, (the latter defined by CMAKE_INSTALL_PREFIX) depending on whether make, make local, or make global has been done.

  • make uninstall

    undoes make install.

  • make distclean

    removes all files not in distribution, including ./bin, ./share, ./lib, and ./include.

  • make purge

    same as make distclean.

  • make clean

    removes all files not in distribution, but keeps compiled libraries and demos, ./lib, ./share, and ./include.

  Each individual subproject also has each of the above make targets.

  Things you don't need to do:

  • make docs

    creates user guides from LaTeX files

  • make cov

    runs statement coverage tests (Linux only)

• MATLAB_Tools

  various m-files for use in MATLAB

  author: Tim Davis (all parts)

  for spqr_rank: author Les Foster and Tim Davis

  • Contents.m

    list of contents

  • dimacs10

    loads matrices for DIMACS10 collection

  • Factorize

    object-oriented x=A\b for MATLAB

  • find_components

    finds connected components in an image

  • GEE

    simple Gaussian elimination

  • getversion.m

    determine MATLAB version

  • gipper.m

    create MATLAB archive

  • hprintf.m

    print hyperlinks in command window

  • LINFACTOR

    predecessor to Factorize package

  • MESHND

    nested dissection ordering of regular meshes

  • pagerankdemo.m

    illustrates how PageRank works

  • SFMULT

    C=S*F where S is sparse and F is full

  • shellgui

    display a seashell

  • sparseinv

    sparse inverse subset

  • spok

    check if a sparse matrix is valid

  • spqr_rank

    SPQR_RANK package. MATLAB toolbox for rank deficient sparse matrices: null spaces, reliable factorizations, etc. With Leslie Foster, San Jose State Univ.

  • SSMULT

    C=A*B where A and B are both sparse. This was the basis for the built-in C=A*B in MATLAB, until it was superseded by GraphBLAS in MATLAB R2021a.

  • SuiteSparseCollection

    for the SuiteSparse Matrix Collection

  • waitmex

    waitbar for use inside a mexFunction

• Mongoose

  graph partitioning.

  authors: Nuri Yeralan, Scott Kolodziej, William Hager, Tim Davis

• ParU

  a parallel unsymmetric pattern multifrontal method.

  Currently a pre-release.

  authors: Mohsen Aznaveh and Tim Davis

• RBio

  read/write sparse matrices in Rutherford/Boeing format

  author: Tim Davis

• README.md

  this file

• SPEX

  solves sparse linear systems in exact arithmetic.

  Requires the GNU GMP and MPRF libraries.

  This will be soon replaced by a more general package, SPEX v3 that includes this method (exact sparse LU) and others (sparse exact Cholesky, and sparse exact update/downdate). The API of v3 will be changing significantly.

  authors: Chris Lourenco, Jinhao Chen, Erick Moreno-Centeno, Lorena Lorena Mejia Domenzain, and Tim Davis.

  See https://github.com/clouren/SPEX for the latest version.

• SPQR

  sparse QR factorization. This the built-in qr and x=A\b in MATLAB. Also called SuiteSparseQR.

  Includes two GPU libraries: SPQR/GPUQREngine and SPQR/SuiteSparse_GPURuntime.

  author of the CPU code: Tim Davis

  author of GPU modules: Tim Davis, Nuri Yeralan, Wissam Sid-Lakhdar, Sanjay Ranka

• ssget

  MATLAB interface to the SuiteSparse Matrix Collection

  author: Tim Davis

• SuiteSparse_config

  library with common functions and configuration for all the above packages. CSparse, GraphBLAS, LAGraph, and MATLAB_Tools do not use SuiteSparse_config.

  author: Tim Davis

• SuiteSparse_demo.m

  a demo of SuiteSparse for MATLAB

• SuiteSparse_install.m

  install SuiteSparse for MATLAB

• SuiteSparse_paths.m

  set paths for SuiteSparse MATLAB mexFunctions

• SuiteSparse_test.m

  exhaustive test for SuiteSparse in MATLAB

• UMFPACK

  sparse LU factorization. Requires AMD and the BLAS.

  This is the built-in lu and x=A\b in MATLAB.

  author: Tim Davis

  algorithm design collaboration: Iain Duff

Refer to each package for license, copyright, and author information. All codes are authored or co-authored by Timothy A. Davis (email: [email protected]), except for METIS (by George Karypis), GraphBLAS/cpu_features (by Google), GraphBLAS/lz4, zstd, and xxHash (by Yann Collet, now at Facebook), and GraphBLAS/CUDA/jitify.hpp (by NVIDIA). Parts of GraphBLAS/CUDA are Copyright (c) by NVIDIA. Please refer to each of these licenses.

---

For distro maintainers (Linux, homebrew, spack, R, Octave, Trilinos, ...):

Thanks for packaging SuiteSparse! Here are some suggestions:

• GraphBLAS takes a long time to compile because it creates many fast "FactoryKernels" at compile-time. If you want to reduce the compile time and library size, enable the GRAPHBLAS_COMPACT mode, but keep the JIT compiler enabled. Then GraphBLAS will compile the kernels it needs at run-time, via its JIT compiler. Performance will be the same as the FactoryKernels once the JIT kernels are compiled. User compiled kernels are placed in ~/.SuiteSparse, by default. You do not need to distribute the source for GraphBLAS to enable the JIT compiler: just libgraphblas.so and GraphBLAS.h is enough.

• GraphBLAS needs OpenMP! It's fundamentally a parallel code so please distribute it with OpenMP enabled. Performance will suffer otherwise.

• CUDA acceleration: CHOLMOD and SPQR can benefit from their CUDA kernels. If you do not have CUDA or do not want to include it in your distro, this version of SuiteSparse skips the building of the CHOLMOD_CUDA and SPQR_CUDA libraries, and does not link against the GPUQREngine and SuiteSparse_GPURuntime libraries.

---

How to cite the SuiteSparse meta-package and its component packages:

SuiteSparse is a meta-package of many packages, each with their own published papers. To cite the whole collection, use the URLs:

• https://github.com/DrTimothyAldenDavis/SuiteSparse
• http://suitesparse.com (which is a forwarding URL to https://people.engr.tamu.edu/davis/suitesparse.html)

Please also cite the specific papers for the packages you use. This is a long list; if you want a shorter list, just cite the most recent "Algorithm XXX:" papers in ACM TOMS, for each package.

• For the MATLAB x=A\b, see below for AMD, COLAMD, CHOLMOD, UMFPACK, and SuiteSparseQR (SPQR).

• for GraphBLAS, and C=AB in MATLAB (sparse-times-sparse):

  T. A. Davis. Algorithm 1037: SuiteSparse:GraphBLAS: Parallel Graph Algorithms in the Language of Sparse Linear Algebra. ACM Trans. Math. Softw. 49, 3, Article 28 (September 2023), 30 pages. https://doi.org/10.1145/3577195

  T. Davis, Algorithm 1000: SuiteSparse:GraphBLAS: graph algorithms in the language of sparse linear algebra, ACM Trans on Mathematical Software, vol 45, no 4, Dec. 2019, Article No 44. https://doi.org/10.1145/3322125.

• for LAGraph:

  G. Szárnyas et al., "LAGraph: Linear Algebra, Network Analysis Libraries, and the Study of Graph Algorithms," 2021 IEEE International Parallel and Distributed Processing Symposium Workshops (IPDPSW), Portland, OR, USA, 2021, pp. 243-252. https://doi.org/10.1109/IPDPSW52791.2021.00046.

• for CSparse/CXSParse:

  T. A. Davis, Direct Methods for Sparse Linear Systems, SIAM Series on the Fundamentals of Algorithms, SIAM, Philadelphia, PA, 2006. https://doi.org/10.1137/1.9780898718881

• for SuiteSparseQR (SPQR): (also cite AMD, COLAMD):

  T. A. Davis, Algorithm 915: SuiteSparseQR: Multifrontal multithreaded rank-revealing sparse QR factorization, ACM Trans. on Mathematical Software, 38(1), 2011, pp. 8:1--8:22. https://doi.org/10.1145/2049662.2049670

• for SuiteSparseQR/GPU:

  Sencer Nuri Yeralan, T. A. Davis, Wissam M. Sid-Lakhdar, and Sanjay Ranka. 2017. Algorithm 980: Sparse QR Factorization on the GPU. ACM Trans. Math. Softw. 44, 2, Article 17 (June 2018), 29 pages. https://doi.org/10.1145/3065870

• for CHOLMOD: (also cite AMD, COLAMD):

  Y. Chen, T. A. Davis, W. W. Hager, and S. Rajamanickam, Algorithm 887: CHOLMOD, supernodal sparse Cholesky factorization and update/downdate, ACM Trans. on Mathematical Software, 35(3), 2008, pp. 22:1--22:14. https://dl.acm.org/doi/abs/10.1145/1391989.1391995

  T. A. Davis and W. W. Hager, Dynamic supernodes in sparse Cholesky update/downdate and triangular solves, ACM Trans. on Mathematical Software, 35(4), 2009, pp. 27:1--27:23. https://doi.org/10.1145/1462173.1462176

• for CHOLMOD/Modify Module: (also cite AMD, COLAMD):

  T. A. Davis and William W. Hager, Row Modifications of a Sparse Cholesky Factorization SIAM Journal on Matrix Analysis and Applications 2005 26:3, 621-639. https://doi.org/10.1137/S089547980343641X

  T. A. Davis and William W. Hager, Multiple-Rank Modifications of a Sparse Cholesky Factorization SIAM Journal on Matrix Analysis and Applications 2001 22:4, 997-1013. https://doi.org/10.1137/S0895479899357346

  T. A. Davis and William W. Hager, Modifying a Sparse Cholesky Factorization, SIAM Journal on Matrix Analysis and Applications 1999 20:3, 606-627. https://doi.org/10.1137/S0895479897321076

• for CHOLMOD/GPU Modules:

  Steven C. Rennich, Darko Stosic, Timothy A. Davis, Accelerating sparse Cholesky factorization on GPUs, Parallel Computing, Vol 59, 2016, pp 140-150. https://doi.org/10.1016/j.parco.2016.06.004

• for AMD and CAMD:

  P. Amestoy, T. A. Davis, and I. S. Duff, Algorithm 837: An approximate minimum degree ordering algorithm, ACM Trans. on Mathematical Software, 30(3), 2004, pp. 381--388. https://dl.acm.org/doi/abs/10.1145/1024074.1024081

  P. Amestoy, T. A. Davis, and I. S. Duff, An approximate minimum degree ordering algorithm, SIAM J. Matrix Analysis and Applications, 17(4), 1996, pp. 886--905. https://doi.org/10.1137/S0895479894278952

• for COLAMD, SYMAMD, CCOLAMD, and CSYMAMD:

  T. A. Davis, J. R. Gilbert, S. Larimore, E. Ng, Algorithm 836: COLAMD, an approximate column minimum degree ordering algorithm, ACM Trans. on Mathematical Software, 30(3), 2004, pp. 377--380. https://doi.org/10.1145/1024074.1024080

  T. A. Davis, J. R. Gilbert, S. Larimore, E. Ng, A column approximate minimum degree ordering algorithm, ACM Trans. on Mathematical Software, 30(3), 2004, pp. 353--376. https://doi.org/10.1145/1024074.1024079

• for UMFPACK: (also cite AMD and COLAMD):

  T. A. Davis, Algorithm 832: UMFPACK - an unsymmetric-pattern multifrontal method with a column pre-ordering strategy, ACM Trans. on Mathematical Software, 30(2), 2004, pp. 196--199. https://dl.acm.org/doi/abs/10.1145/992200.992206

  T. A. Davis, A column pre-ordering strategy for the unsymmetric-pattern multifrontal method, ACM Trans. on Mathematical Software, 30(2), 2004, pp. 165--195. https://dl.acm.org/doi/abs/10.1145/992200.992205

  T. A. Davis and I. S. Duff, A combined unifrontal/multifrontal method for unsymmetric sparse matrices, ACM Trans. on Mathematical Software, 25(1), 1999, pp. 1--19. https://doi.org/10.1145/305658.287640

  T. A. Davis and I. S. Duff, An unsymmetric-pattern multifrontal method for sparse LU factorization, SIAM J. Matrix Analysis and Computations, 18(1), 1997, pp. 140--158. https://doi.org/10.1137/S0895479894246905

• for the FACTORIZE m-file:

  T. A. Davis, Algorithm 930: FACTORIZE, an object-oriented linear system solver for MATLAB, ACM Trans. on Mathematical Software, 39(4), 2013, pp. 28:1-28:18. https://doi.org/10.1145/2491491.2491498

• for KLU and BTF (also cite AMD and COLAMD):

  T. A. Davis and Ekanathan Palamadai Natarajan. 2010. Algorithm 907: KLU, A Direct Sparse Solver for Circuit Simulation Problems. ACM Trans. Math. Softw. 37, 3, Article 36 (September 2010), 17 pages. https://dl.acm.org/doi/abs/10.1145/1824801.1824814

• for LDL:

  T. A. Davis. Algorithm 849: A concise sparse Cholesky factorization package. ACM Trans. Math. Softw. 31, 4 (December 2005), 587–591. https://doi.org/10.1145/1114268.1114277

• for ssget and the SuiteSparse Matrix Collection:

  T. A. Davis and Yifan Hu. 2011. The University of Florida sparse matrix collection. ACM Trans. Math. Softw. 38, 1, Article 1 (November 2011), 25 pages. https://doi.org/10.1145/2049662.2049663

  Kolodziej et al., (2019). The SuiteSparse Matrix Collection Website Interface. Journal of Open Source Software, 4(35), 1244. https://doi.org/10.21105/joss.01244

• for spqr_rank:

  Leslie V. Foster and T. A. Davis. 2013. Algorithm 933: Reliable calculation of numerical rank, null space bases, pseudoinverse solutions, and basic solutions using suitesparseQR. ACM Trans. Math. Softw. 40, 1, Article 7 (September 2013), 23 pages. https://doi.org/10.1145/2513109.2513116

• for Mongoose:

  T. A. Davis, William W. Hager, Scott P. Kolodziej, and S. Nuri Yeralan. 2020. Algorithm 1003: Mongoose, a Graph Coarsening and Partitioning Library. ACM Trans. Math. Softw. 46, 1, Article 7 (March 2020), 18 pages. https://doi.org/10.1145/3337792

• for SPEX:

  Christopher Lourenco, Jinhao Chen, Erick Moreno-Centeno, and T. A. Davis. 2022. Algorithm 1021: SPEX Left LU, Exactly Solving Sparse Linear Systems via a Sparse Left-Looking Integer-Preserving LU Factorization. ACM Trans. Math. Softw. June 2022. https://doi.org/10.1145/3519024

---

About the BLAS and LAPACK libraries

NOTE: if you use OpenBLAS, be sure to use version 0.3.27 or later.

To select your BLAS/LAPACK, see the instructions in SuiteSparseBLAS.cmake in SuiteSparse_config/cmake_modules. If SuiteSparse_config finds a BLAS with 64-bit integers (such as the Intel MKL ilp64 BLAS), it configures SuiteSparse_config.h with the SUITESPARSE_BLAS_INT defined as int64_t. Otherwise, if a 32-bit BLAS is found, this type is defined as int32_t. If later on, UMFPACK, CHOLMOD, or SPQR are compiled and linked with a BLAS that has a different integer size, you must override the definition with -DBLAS64 (to assert the use of 64-bit integers in the BLAS) or -DBLAS32, (to assert the use of 32-bit integers in the BLAS).

The size of the BLAS integer has nothing to do with sizeof(void *).

When distributed in a binary form (such as a Debian, Ubuntu, Spack, or Brew package), SuiteSparse should probably be compiled to expect a 32-bit BLAS, since this is the most common case. The default is to use a 32-bit BLAS, but this can be changed by setting the cmake variable SUITESPARSE_USE_64BIT_BLAS to ON.

By default, SuiteSparse hunts for a suitable BLAS library. To enforce a particular BLAS library use either:

CMAKE_OPTIONS="-DBLA_VENDOR=OpenBLAS" make
cd Package ; cmake -DBLA_VENDOR=OpenBLAS .. make

To use the default (hunt for a BLAS), do not set BLA_VENDOR, or set it to ANY. In this case, if SUITESPARSE_USE_64BIT_BLAS is ON, preference is given to a 64-bit BLAS, but a 32-bit BLAS library will be used if no 64-bit library is found. However, if both SUITESPARSE_USE_64BIT_BLAS and SUITESPARSE_USE_STRICT are ON, then only a 64-bit BLAS is considered.

When selecting a particular BLAS library, the SUITESPARSE_USE_64BIT_BLAS setting is strictly followed. If set to true, only a 64-bit BLAS library will be used. If false (the default), only a 32-bit BLAS library will be used. If no such BLAS is found, the build will fail.

---

QUICK START FOR THE C/C++ LIBRARIES:

Type the following in this directory (requires system priviledge to do the sudo make install):

    mkdir -p build && cd build
    cmake ..
    cmake --build .
    sudo cmake --install .

All libraries will be created and installed into the default system-wide folder (/usr/local/lib on Linux). All include files needed by the applications that use SuiteSparse are installed into /usr/local/include/suitesparse (on Linux).

To build only a subset of libraries, set SUITESPARSE_ENABLE_PROJECTS when configuring with CMake. E.g., to build and install CHOLMOD and CXSparse (including their dependencies), use the following commands:

    mkdir -p build && cd build
    cmake -DSUITESPARSE_ENABLE_PROJECTS="cholmod;cxsparse" ..
    cmake --build .
    sudo cmake --install .

For Windows (MSVC), import the CMakeLists.txt file into MS Visual Studio. Be sure to specify the build type as Release; for example, to build SuiteSparse on Windows in the command window, run:

    mkdir -p build && cd build
    cmake ..
    cmake --build . --config Release
    cmake --install .

Be sure to first install all required libraries: BLAS and LAPACK for UMFPACK, CHOLMOD, and SPQR, and GMP and MPFR for SPEX. Be sure to use the latest libraries; SPEX requires MPFR 4.0.2 and GMP 6.1.2 (these version numbers do NOT correspond to the X.Y.Z suffix of libgmp.so.X.Y.Z and libmpfr.so.X.Y.Z; see the SPEX user guide for details).

To compile the libraries and install them only in SuiteSparse/lib (not /usr/local/lib), do this instead in the top-level of SuiteSparse:

    mkdir -p build && cd build
    cmake -DCMAKE_INSTALL_PREFIX=.. ..
    cmake --build .
    cmake --install .

If you add /home/me/SuiteSparse/lib to your library search path (LD_LIBRARY_PATH in Linux), you can do the following (for example):

    S = /home/me/SuiteSparse
    cc myprogram.c -I$(S)/include/suitesparse -lumfpack -lamd -lcholmod -lsuitesparseconfig -lm

To change the C and C++ compilers, and to compile in parallel use:

    cmake -DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER==g++ ..

for example, which changes the compiler to gcc and g++.

This will work on Linux/Unix and the Mac. It should automatically detect if you have the Intel compilers or not, and whether or not you have CUDA.

See SuiteSparse_config/cmake_modules/SuiteSparsePolicy.cmake to select your BLAS.

You may also need to add SuiteSparse/lib to your path. If your copy of SuiteSparse is in /home/me/SuiteSparse, for example, then add this to your ~/.bashrc file:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/me/SuiteSparse/lib
export LD_LIBRARY_PATH

For the Mac, use this instead:

DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/home/me/SuiteSparse/lib
export DYLD_LIBRARY_PATH

Default install location of files is below, where PACKAGE is one of the packages in SuiteSparse:

* `CMAKE_INSTALL_PREFIX/include/suitesparse/`: include files
* `CMAKE_INSTALL_PREFIX/lib/`: compiled libraries
* `CMAKE_INSTALL_PREFIX/lib/cmake/SuiteSparse/`: `*.cmake` scripts
    for all of SuiteSparse
* `CMAKE_INSTALL_PREFIX/lib/cmake/PACKAGE/`: `*Config.cmake` scripts for a
    specific package
* `CMAKE_INSTALL_PREFIX/lib/pkgconfig/PACKAGE.pc`: `.pc` scripts for
    a specific package pkgconfig

---

QUICK START FOR MATLAB USERS (Linux or Mac):

Suppose you place SuiteSparse in the /home/me/SuiteSparse folder.

Add the SuiteSparse/lib folder to your run-time library path. On Linux, add this to your ~/.bashrc script, assuming /home/me/SuiteSparse is the location of your copy of SuiteSparse:

    LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/me/SuiteSparse/lib
    export LD_LIBRARY_PATH

For the Mac, use this instead, in your ~/.zshrc script, assuming you place SuiteSparse in /Users/me/SuiteSparse:

    DYLD_LIBRARY_PATH=$DYLD_LIBRARY_PATH:/Users/me/SuiteSparse/lib
    export DYLD_LIBRARY_PATH

Compile all of SuiteSparse with make local.

Next, compile the GraphBLAS MATLAB library. In the system shell while in the SuiteSparse folder, type make gbmatlab if you want to install it system-wide with make install, or make gblocal if you want to use the library in your own SuiteSparse/lib.

Then in the MATLAB Command Window, cd to the SuiteSparse directory and type SuiteSparse_install. All packages will be compiled, and several demos will be run. To run a (long!) exhaustive test, do SuiteSparse_test.

Save your MATLAB path for future sessions with the MATLAB pathtool or savepath commands. If those methods fail because you don't have system-wide permission, add the new paths to your startup.m file, normally in Documents/MATLAB/startup.m. You can also use the SuiteSparse_paths m-file to set all your paths at the start of each MATLAB session.

---

Compilation options

You can set specific options for CMake with the command (for example):

    cmake -DCHOLMOD_PARTITION=OFF -DBUILD_STATIC_LIBS=OFF -DCMAKE_BUILD_TYPE=Debug ..

That command will compile all of SuiteSparse except for CHOLMOD/Partition Module (because of -DCHOLMOD_PARTITION=OFF). Debug mode will be used (the build type). The static libraries will not be built (since -DBUILD_STATIC_LIBS=OFF is set).

• SUITESPARSE_ENABLE_PROJECTS:

  Semicolon separated list of projects to be built or all. Default: all in which case the following projects are built:

  suitesparse_config;mongoose;amd;btf;camd;ccolamd;colamd;cholmod;cxsparse;ldl;klu;umfpack;paru;rbio;spqr;spex;graphblas;lagraph

  Additionally, csparse can be included in that list to build CSparse.

• CMAKE_BUILD_TYPE:

  Default: Release, use Debug for debugging.

• SUITESPARSE_USE_STRICT:

  SuiteSparse has many user-definable settings of the form SUITESPARSE_USE_* or (package)_USE_* for some particular package. In general, these settings are not strict. For example, if SUITESPARSE_USE_OPENMP is ON then OpenMP is preferred, but SuiteSparse can be used without OpenMP so no error is generated if OpenMP is not found. However, if SUITESPARSE_USE_STRICT is ON then all *_USE_* settings are treated strictly and an error occurs if any are set to ON but the corresponding package or setting is not available. The *_USE_SYSTEM_* settings are always treated as strict. Default: OFF.

• SUITESPARSE_USE_CUDA:

  If set to ON, CUDA is enabled for all of SuiteSparse. Default: ON,

  CUDA on Windows with MSVC appears to be working with this release, but it should be considered as a prototype and may not be fully functional. I have limited resources for testing CUDA on Windows. If you encounter issues, disable CUDA and post this as an issue on GitHub.

• CHOLMOD_USE_CUDA:

  Default: ON. Both SUITESPARSE_USE_CUDA and CHOLMOD_USE_CUDA must be enabled to use CUDA in CHOLMOD.

• SPQR_USE_CUDA:

  Default: ON. Both SUITESPARSE_USE_CUDA and SPQR_USE_CUDA must be enabled to use CUDA in SPQR.

• CMAKE_INSTALL_PREFIX:

  Defines the install location (default on Linux is /usr/local). For example, this command while in a folder build in the top level SuiteSparse folder will set the install directory to /stuff, used by the subsequent sudo cmake --install .:

    cmake -DCMAKE_INSTALL_PREFIX=/stuff ..
    sudo cmake --install .

• SUITESPARSE_PKGFILEDIR:

  Directory where CMake Config and pkg-config files will be installed. By default, CMake Config files will be installed in the subfolder cmake of the directory where the (static) libraries will be installed (e.g., lib). The .pc files for pkg-config will be installed in the subfolder pkgconfig of the directory where the (static) libraries will be installed.

  This option allows to install them at a location different from the (static) libraries. This allows to install multiple configurations of the SuiteSparse libraries at the same time (e.g., by also setting a different CMAKE_RELEASE_POSTFIX and CMAKE_INSTALL_LIBDIR for each of them). To pick up the respective configuration in downstream projects, set, e.g., CMAKE_PREFIX_PATH (for CMake) or PKG_CONFIG_PATH (for build systems using pkg-config) to the path containing the respective CMake Config files or pkg-config files.

• SUITESPARSE_INCLUDEDIR_POSTFIX:

  Postfix for installation target of header from SuiteSparse. Default: suitesparse, so the default include directory is: CMAKE_INSTALL_PREFIX/include/suitesparse

• BUILD_SHARED_LIBS:

  If ON, shared libraries are built. Default: ON.

• BUILD_STATIC_LIBS:

  If ON, static libraries are built. Default: ON, except for GraphBLAS, which takes a long time to compile so the default for GraphBLAS is OFF unless BUILD_SHARED_LIBS is OFF.

• SUITESPARSE_CUDA_ARCHITECTURES:

  A string, such as "all" or "35;50;75;80" that lists the CUDA architectures to use when compiling CUDA kernels with nvcc. The "all" option requires CMake 3.23 or later. Default: "52;75;80".

• BLA_VENDOR:

  A string. Leave unset, or use "ANY" to select any BLAS library (the default). Or set to the name of a BLA_VENDOR defined by FindBLAS.cmake. See: https://cmake.org/cmake/help/latest/module/FindBLAS.html#blas-lapack-vendors

• SUITESPARSE_USE_64BIT_BLAS:

  If ON, look for a 64-bit BLAS. If OFF: 32-bit only. Default: OFF.

• SUITESPARSE_USE_OPENMP:

  If ON, OpenMP is used by default if it is available. Default: ON.

  GraphBLAS, LAGraph, and ParU will be vastly slower if OpenMP is not used. CHOLMOD will be somewhat slower without OpenMP (as long as it still has a parallel BLAS/LAPACK). Three packages (UMFPACK, CHOLMOD, and SPQR) rely heavily on parallel BLAS/LAPACK libraries and those libraries may use OpenMP internally. If you wish to disable OpenMP in an entire application, select a single-threaded BLAS/LAPACK, or a parallel BLAS/LAPACK that does not use OpenMP (such as the Apple Accelerate Framework). Using a single-threaded BLAS/LAPACK library will cause UMFPACK, CHOLMOD, and SPQR to be vastly slower.

  WARNING: GraphBLAS may not be thread-safe if built without OpenMP or pthreads (see the GraphBLAS User Guide for details).

• SUITESPARSE_CONFIG_USE_OPENMP:

  If ON, SuiteSparse_config uses OpenMP if it is available. Default: SUITESPARSE_USE_OPENMP. It is not essential and only used to let SuiteSparse_time call omp_get_wtime.

• CHOLMOD_USE_OPENMP:

  If ON, OpenMP is used in CHOLMOD if it is available. Default: SUITESPARSE_USE_OPENMP.

• GRAPHBLAS_USE_OPENMP:

  If ON, OpenMP is used in GraphBLAS if it is available. Default: SUITESPARSE_USE_OPENMP.

• LAGRAPH_USE_OPENMP:

  If ON, OpenMP is used in LAGraph if it is available. Default: SUITESPARSE_USE_OPENMP.

• PARU_USE_OPENMP:

  If ON, OpenMP is used in ParU if it is available. Default: SUITESPARSE_USE_OPENMP.

• SPEX_USE_OPENMP:

  If ON, OpenMP is used in SPEX if it is available. Default: SUITESPARSE_USE_OPENMP.

• SUITESPARSE_DEMOS:

  If ON, build the demo programs for each package. Default: OFF.

• SUITESPARSE_USE_SYSTEM_BTF:

  If ON, use BTF libraries installed on the build system. If OFF, automatically build BTF as dependency if needed. Default: OFF.

• SUITESPARSE_USE_SYSTEM_CHOLMOD:

  If ON, use CHOLMOD libraries installed on the build system. If OFF, automatically build CHOLMOD as dependency if needed. Default: OFF.

• SUITESPARSE_USE_SYSTEM_AMD:

  If ON, use AMD libraries installed on the build system. If OFF, automatically build AMD as dependency if needed. Default: OFF.

• SUITESPARSE_USE_SYSTEM_COLAMD:

  If ON, use COLAMD libraries installed on the build system. If OFF, automatically build COLAMD as dependency if needed. Default: OFF.

• SUITESPARSE_USE_SYSTEM_CAMD:

  If ON, use CAMD libraries installed on the build system. If OFF, automatically build CAMD as dependency if needed. Default: OFF.

• SUITESPARSE_USE_SYSTEM_CCOLAMD:

  If ON, use CCOLAMD libraries installed on the build system. If OFF, automatically build CCOLAMD as dependency if needed. Default: OFF.

• SUITESPARSE_USE_SYSTEM_GRAPHBLAS:

  If ON, use GraphBLAS libraries installed on the build system. If OFF, automatically build GraphBLAS as dependency if needed. Default: OFF.

• SUITESPARSE_USE_SYSTEM_SUITESPARSE_CONFIG:

  If ON, use SuiteSparse_config libraries installed on the build system. If OFF, automatically build SuiteSparse_config as dependency if needed. Default: OFF.

• SUITESPARSE_USE_FORTRAN

  If ON, use the Fortran compiler to determine how C calls Fortan, and to build several optional Fortran routines. If OFF, use SUITESPARSE_C_TO_FORTRAN to define how C calls Fortran. Default: ON.

• SUITESPARSE_C_TO_FORTRAN

  A string that defines how C calls Fortran (i.e., functions exported by the BLAS library). This setting is used if no working Fortran compiler could be detected or SUITESPARSE_USE_FORTRAN is set to OFF. This string is to be read as the argument list and the body of a preprocessor macro. The first argument to that macro is any Fortran function name in lowercase letters. The second argument is the same function name in uppercase letters. The body defines by which function name Fortran functions are called. This is necessary because Fortran is case-insensitive, and different Fortran compilers use different name mangling conventions. If a MSVC C/C++ compiler is used, this defaults to "(name,NAME) name" (i.e., lower case without trailing underscore). That is the name mangling convention for the Intel Fortran compiler on Windows. If any other C/C++ compilers are used, this defaults to "(name,NAME) name##_" (i.e., lower case with trailing underscore). That is the name mangling convention for most of the commonly used Fortran compilers (like ifx on platforms other than Windows, gfortran, flang, ...). The latter name mangling convention is also used by default by OpenBLAS (independent on the platform or the compiler used to build OpenBLAS). You might need to configure with -DSUITESPARSE_C_TO_FORTRAN="(name,NAME) name##_" if you'd like to build SuiteSparse using a MSVC compiler and link to OpenBLAS.

Additional options are available for specific packages:

• UMFPACK_USE_CHOLMOD:

  If ON, UMFPACK uses CHOLMOD for additional (optional) ordering options. Default: ON.

• KLU_USE_CHOLMOD:

  If ON, KLU uses CHOLMOD for additional (optional) ordering options. Default: ON.

CHOLMOD is composed of a set of Modules that can be independently selected; all options default to ON:

• CHOLMOD_GPL

  If OFF, do not build any GPL-licensed module (MatrixOps, Modify, Supernodal, and GPU modules)

• CHOLMOD_CHECK

  If OFF, do not build the Check module.

• CHOLMOD_MATRIXOPS

  If OFF, do not build the MatrixOps module.

• CHOLMOD_CHOLESKY If OFF, do not build the Cholesky module. This also disables the Supernodal and Modify modules.

• CHOLMOD_MODIFY

  If OFF, do not build the Modify module.

• CHOLMOD_CAMD

  If OFF, do not link against CAMD and CCOLAMD. This also disables the Partition module.

• CHOLMOD_PARTITION

  If OFF, do not build the Partition module.

• CHOLMOD_SUPERNODAL

  If OFF, do not build the Supernodal module.

---

Possible build/install issues

One common issue can affect all packages: getting the right #include files that match the current libraries being built. It's possible that your Linux distro has an older copy of SuiteSparse headers in /usr/include or /usr/local/include, or that Homebrew has installed its suite-sparse bundle into /opt/homebrew/include or other places. Old libraries can appear in in /usr/local/lib, /usr/lib, etc. When building a new copy of SuiteSparse, the cmake build system is normally (or always?) able to avoid these, and use the right header for the right version of each library.

As an additional guard against this possible error, each time one SuiteSparse package #include's a header from another one, it checks the version number in the header file, and reports an #error to the compiler if a stale version is detected. In addition, the Example package checks both the header version and the library version (by calling a function in each library). If the versions mismatch in any way, the Example package reports an error at run time.

For example, CHOLMOD 5.1.0 requires AMD 3.3.0 or later. If it detects an older one in amd.h, it will report an #error:

    #include "amd.h"
    #if ( ... AMD version is stale ... )
    #error "CHOLMOD 5.1.0 requires AMD 3.3.0 or later"
    #endif

and the compilation will fail. The Example package makes another check, by calling amd_version and comparing it with the versions from the amd.h header file.

If this error or one like it occurs, check to see if you have an old copy of SuiteSparse, and uninstall it before compiling your new copy of SuiteSparse.

There are other many possible build/install issues that are covered by the corresponding user guides for each package, such as finding the right BLAS, OpenMP, and other libraries, and how to compile on the Mac when using GraphBLAS inside MATLAB, and so on. Refer to the User Guides for more details.

---

Interfaces to SuiteSparse

MATLAB/Octave/R/Mathematica interfaces:

Many built-in methods in MATLAB and Octave rely on SuiteSparse, including C=A*B x=A\b, L=chol(A), [L,U,P,Q]=lu(A), R=qr(A), dmperm(A), p=amd(A), p=colamd(A), ... See also Mathematica, R, and many many more. The list is too long.

Julia interface:

https://github.com/JuliaSparse/SparseArrays.jl

python interface to GraphBLAS by Anaconda and NVIDIA:

https://pypi.org/project/python-graphblas

Intel's Go interface to GraphBLAS:

https://pkg.go.dev/github.com/intel/forGraphBLASGo

See scikit-sparse and scikit-umfpack for the Python interface via SciPy:

https://github.com/scikit-sparse/scikit-sparse https://github.com/scikit-umfpack/scikit-umfpack

See math.js by Jos de Jong for a JavaScript port of CSparse:

https://github.com/josdejong/mathjs

See russell for a Rust interface:

https://github.com/cpmech/russell

---

Acknowledgements

Markus Mützel contributed the most recent update of the SuiteSparse build system for all SuiteSparse packages, extensively porting it and modernizing it.

I would also like to thank François Bissey, Sebastien Villemot, Erik Welch, Jim Kitchen, and Fabian Wein for their valuable feedback on the SuiteSparse build system and how it works with various Linux / Python distros and other package managers. If you are a maintainer of a SuiteSparse packaging for a Linux distro, conda-forge, R, spack, brew, vcpkg, etc, please feel free to contact me if there's anything I can do to make your life easier. I would also like to thank Raye Kimmerer for adding support for 32-bit row/column indices in SPQR v4.2.0.

See also the various Acknowledgements within each package.

suitesparse's Issues

Can't get the correct answer by using AMD and LDL

Describe the bug
Hello, if I use the default order to solve the small example in the LDL's userguide, I can get the right answer. However, when I
use AMD and then to solve the same example, the answer is incorrect, I donn't know the reason.

Expected behavior
The example is from LDL's userguide.
The default order is [0,1,2,3,4,5,6,7,8,9], the answer is [.1 .2 .3 .4 .5 .6 .7 .8 .9 1]
when I use AMD, the order is [2 3 5 0 7 8 6 1 4 9 ] and the answer is incorrect.

Thank you!

Installation problem with MATLAB in Windows 10

I'm trying to install SuiteSparse 5.7.2 on MATLAB R2020a using Windows 10 and Microsoft Visual C++ 2019. However, the following issue appers:

Installing SuiteSparse for MATLAB version 9.8.0.1323502 (R2020a)

Compiling UMFPACK for MATLAB Version 9.8.0.1323502 (R2020a)
with 64-bit BLAS
with CHOLMOD, CAMD, CCOLAMD, and METIS
............................b64.c
B:\Francisco\Documents\MATLAB\SuiteSparse-5.7.2\metis-5.1.0\GKlib\GKlib.h(68): fatal error C1083: No se puede abrir el archivo incluir: 'regex.h': No such file or directory


UMFPACK not installed

Compiling CHOLMOD with METIS 5.1.0 for MATLAB Version 9.8.0.1323502 (R2020a)
with 64-bit BLAS

.b64.c
B:\Francisco\Documents\MATLAB\SuiteSparse-5.7.2\metis-5.1.0\GKlib\GKlib.h(68): fatal error C1083: No se puede abrir el archivo incluir: 'regex.h': No such file or directory


CHOLMOD not installed

....

compile version4.4.6, I can't get .so libraries

hi,
Sorry to bother but I don't really know what is wrong. Here is my command:
make
make INSTALL_LIB=/dat01/tangxingfen/3drecon/dependencies/install/suitesparse4/lib INSTALL_INCLUDE=/dat01/tangxingfen/3drecon/dependencies/install/suitesparse4/include install
after install, I can't find any .so libraries in the lib path, only .a libraries. I wonder how to solve this problem.
Thank you

Fix compilation warnings with GPU support enabled

Below is a patch to fix the following compilation warnings

In file included from ../Supernodal/cholmod_super_numeric.c:73:0:
../Supernodal/../GPU/t_cholmod_gpu.c: In function 'r_cholmod_l_gpu_updateC':
../Supernodal/../GPU/t_cholmod_gpu.c:494:33: warning: passing argument 6 of 'createRelativeMapOnDevice' from incompatible pointer type [-Wincompatible-pointer-types]
&(Common->gpuStream[iDevBuff]) );
^
In file included from ../Supernodal/../GPU/t_cholmod_gpu.c:20:0,
from ../Supernodal/cholmod_super_numeric.c:73:
../Include/cholmod_gpu_kernels.h:27:5: note: expected 'cudaStream_t {aka struct CUstream_st *}' but argument is of type 'struct CUstream_st **'
int createRelativeMapOnDevice ( Int *d_Map, Int *d_Ls, Int *d_RelativeMap,
^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../Supernodal/cholmod_super_numeric.c:73:0:
../Supernodal/../GPU/t_cholmod_gpu.c:609:5: warning: implicit declaration of function 'addUpdateOnDevice'; did you mean 'addUpateOnDevice'? [-Wimplicit-function-declaration]
addUpdateOnDevice ( gpu_p->d_A[0], devPtrC,
^~~~~~~~~~~~~~~~~
addUpateOnDevice
In file included from ../Supernodal/cholmod_super_numeric.c:75:0:
../Supernodal/../GPU/t_cholmod_gpu.c: In function 'c_cholmod_l_gpu_updateC':
../Supernodal/../GPU/t_cholmod_gpu.c:494:33: warning: passing argument 6 of 'createRelativeMapOnDevice' from incompatible pointer type [-Wincompatible-pointer-types]
&(Common->gpuStream[iDevBuff]) );
^
In file included from ../Supernodal/../GPU/t_cholmod_gpu.c:20:0,
from ../Supernodal/cholmod_super_numeric.c:73:
../Include/cholmod_gpu_kernels.h:27:5: note: expected 'cudaStream_t {aka struct CUstream_st *}' but argument is of type 'struct CUstream_st **'
int createRelativeMapOnDevice ( Int *d_Map, Int *d_Ls, Int *d_RelativeMap,
^~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../Supernodal/cholmod_super_numeric.c:75:0:
../Supernodal/../GPU/t_cholmod_gpu.c:613:5: warning: implicit declaration of function 'addComplexUpdateOnDevice'; did you mean 'addComplexUpateOnDevice'? [-Wimplicit-function-declaration]
addComplexUpdateOnDevice ( gpu_p->d_A[0], devPtrC,
^~~~~~~~~~~~~~~~~~~~~~~~
addComplexUpateOnDevice

diff --git a/CHOLMOD/GPU/t_cholmod_gpu.c b/CHOLMOD/GPU/t_cholmod_gpu.c
index 39a4298..c697340 100644
--- a/CHOLMOD/GPU/t_cholmod_gpu.c
+++ b/CHOLMOD/GPU/t_cholmod_gpu.c
@@ -491,7 +491,7 @@ int TEMPLATE2 (CHOLMOD (gpu_updateC))
                                 (Int *)(gpu_p->d_Ls),
                                 (Int *)(gpu_p->d_RelativeMap),
                                 pdi1, ndrow2,
-                                &(Common->gpuStream[iDevBuff]) );
+                                Common->gpuStream[iDevBuff] );

     /* ---------------------------------------------------------------------- */
     /* do the CUDA SYRK */
@@ -608,11 +608,11 @@ int TEMPLATE2 (CHOLMOD (gpu_updateC))
 #ifdef REAL
     addUpdateOnDevice ( gpu_p->d_A[0], devPtrC,
         gpu_p->d_RelativeMap, ndrow1, ndrow2, nsrow,
-        &(Common->gpuStream[iDevBuff]) );
+        Common->gpuStream[iDevBuff] );
 #else
     addComplexUpdateOnDevice ( gpu_p->d_A[0], devPtrC,
         gpu_p->d_RelativeMap, ndrow1, ndrow2, nsrow,
-        &(Common->gpuStream[iDevBuff]) );
+        Common->gpuStream[iDevBuff] );
 #endif

     /* Record an event indicating that kernels for
diff --git a/CHOLMOD/Include/cholmod_gpu_kernels.h b/CHOLMOD/Include/cholmod_gpu_kernels.h
index ba05f12..fed28a7 100644
--- a/CHOLMOD/Include/cholmod_gpu_kernels.h
+++ b/CHOLMOD/Include/cholmod_gpu_kernels.h
@@ -27,10 +27,10 @@ int createMapOnDevice ( Int *d_Map, Int *d_Ls, Int psi, Int nsrow );
 int createRelativeMapOnDevice ( Int *d_Map, Int *d_Ls, Int *d_RelativeMap,
                            Int pdi1, Int ndrow, cudaStream_t astream );

-int addUpateOnDevice ( double *d_A, double *devPtrC, Int *d_RelativeMap,
+int addUpdateOnDevice ( double *d_A, double *devPtrC, Int *d_RelativeMap,
     Int ndrow1, Int ndrow2, Int nsrow, cudaStream_t astream );

-int addComplexUpateOnDevice ( double *d_A, double *devPtrC, Int *d_RelativeMap,
+int addComplexUpdateOnDevice ( double *d_A, double *devPtrC, Int *d_RelativeMap,
     Int ndrow1, Int ndrow2, Int nsrow, cudaStream_t astream );

 int sumAOnDevice ( double *a1, double *a2, const double alpha, int nsrow,

cannot install Suite Sparse 5.7.1 on my RHEL 7 machine

Describe the bug
I am trying to install SuiteSparse 5.7.1 on my RHEL box

To Reproduce

1. download SuiteSparse-5.7.1.tar.gz

2. tar zxvf SuiteSparse-5.7.1.tar.gz

3. cd SuiteSparse-5.7.1
4. make
   ....
   [ 23%] Building CXX object CMakeFiles/mongoose_lib_dbg.dir/Source/Mongoose_QPNapDown.o
   [ 24%] Building CXX object CMakeFiles/mongoose_lib_dbg.dir/Source/Mongoose_QPNapsack.o
   [ 25%] Building CXX object CMakeFiles/mongoose_lib_dbg.dir/Source/Mongoose_QPNapUp.o
   [ 25%] Building C object CMakeFiles/mongoose_lib_dbg.dir/External/mmio/Source/mmio.c.o
   cc1: warning: command line option â-Woverloaded-virtualâ is valid for C++/ObjC++ but not for C [enabled by default]
   [ 26%] Linking CXX static library lib/libmongoose_dbg.a
   make[4]: Leaving directory /home/rrajasek/SuiteSparse-5.7.1/Mongoose/build' [ 26%] Built target mongoose_lib_dbg make[4]: Entering directory /home/rrajasek/SuiteSparse-5.7.1/Mongoose/build'
   Scanning dependencies of target mongoose_unit_test_graph
   make[4]: Leaving directory /home/rrajasek/SuiteSparse-5.7.1/Mongoose/build' make[4]: Entering directory /home/rrajasek/SuiteSparse-5.7.1/Mongoose/build'
   [ 27%] Building CXX object CMakeFiles/mongoose_unit_test_graph.dir/Tests/Mongoose_UnitTest_Graph_exe.o
   [ 28%] Linking CXX executable tests/mongoose_unit_test_graph
   lib/libmongoose_dbg.a(Mongoose_IO.o): In function Mongoose::read_graph(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)': /home/rrajasek/SuiteSparse-5.7.1/Mongoose/Source/Mongoose_IO.cpp:34: undefined reference to std::__cxx11::basic_string<char, std::char_traits, std::allocator >::c_str() const'
   lib/libmongoose_dbg.a(Mongoose_IO.o): In function Mongoose::read_matrix(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, char (&) [4])': /home/rrajasek/SuiteSparse-5.7.1/Mongoose/Source/Mongoose_IO.cpp:39: undefined reference to std::__cxx11::basic_string<char, std::char_traits, std::allocator >::c_str() const'
   lib/libmongoose_dbg.a(Mongoose_IO.o): In function Mongoose::read_matrix(char const*, char (&) [4])': /home/rrajasek/SuiteSparse-5.7.1/Mongoose/Source/Mongoose_IO.cpp:85: undefined reference to std::__cxx11::basic_string<char, std::char_traits, std::allocator >::basic_string(char const*, std::allocator const&)'
   /home/rrajasek/SuiteSparse-5.7.1/Mongoose/Source/Mongoose_IO.cpp:85: undefined reference to std::basic_ostream<char, std::char_traits<char> >& std::operator<< <char, std::char_traits<char>, std::allocator<char> >(std::basic_ostream<char, std::char_traits<char> >&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' /home/rrajasek/SuiteSparse-5.7.1/Mongoose/Source/Mongoose_IO.cpp:85: undefined reference to std::__cxx11::basic_string<char, std::char_traits, std::allocator >::~basic_string()'
   /home/rrajasek/SuiteSparse-5.7.1/Mongoose/Source/Mongoose_IO.cpp:85: undefined reference to std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()' collect2: error: ld returned 1 exit status make[4]: *** [tests/mongoose_unit_test_graph] Error 1 make[4]: Leaving directory /home/rrajasek/SuiteSparse-5.7.1/Mongoose/build'
   make[3]: *** [CMakeFiles/mongoose_unit_test_graph.dir/all] Error 2
   make[3]: Leaving directory /home/rrajasek/SuiteSparse-5.7.1/Mongoose/build' make[2]: *** [all] Error 2 make[2]: Leaving directory /home/rrajasek/SuiteSparse-5.7.1/Mongoose/build'
   /bin/sh: ./bin/demo: No such file or directory
   make[1]: *** [default] Error 127
   make[1]: Leaving directory `/home/rrajasek/SuiteSparse-5.7.1/Mongoose'
   make: *** [go] Error 2

Expected behavior
clean install of SuiteSparse

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: RHEL 7
• compiler

gcc --version

gcc (GCC) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

• BLAS and LAPACK library, if applicable
  Not sure about whether I need this or not

Additional context
I have verified with Dr Davis that my cmake works.

On platform Android (ARM64), when calling CHOLMOD methods through Eigen's inteface, CholmodSimplicialLDLT and CholmodSimplicialLLT work correctly, but CholmodSupernodalLLT crashes.

Describe the bug
Platform: Android (ARM64)

Suitesparse Version: 5.6.0 (the cmake file is used from jlblancoc/suitesparse-metis-for-windows)
(try 5.5.0 and 4.5.0, crash occur samely)

Concise descriptions of problem:
when calling CHOLMOD methods through Eigen's inteface, CholmodSimplicialLDLT and CholmodSimplicialLLT work correctly, but CholmodSupernodalLLT crashes.

Detail descriptions of problem:
fault address of memory access
the calling process:
Eigen/src/CholmodSupport/CholmodSupport.h:271
SuiteSparse/CHOLMOD/Include/../Cholesky/cholmod_factorize.c:265:
CHOLMOD(super_numeric) (S, F, beta, L, Common) ;

SuiteSparse/CHOLMOD/Include/../Supernodal/t_cholmod_super_numeric.c:864:
LAPACK_dpotrf ("L",nscol2,Lx + L_ENTRY*psx, nsrow,info) ;

clapack/SRC/dpotrf.c:152:
dpotf2_(uplo, n, &a[a_offset], lda, info);

clapack/SRC/dpotf2.c:190:
ajj = a[j + j * a_dim1] - ddot_(&i__2, &a[j + a_dim1], lda, &a[j + a_dim1], lda);
the bug is the access of a from j = 2.

The clapack 3.2.1 is used (from simonlynen/android_libs/lapack/)

To Reproduce
Steps to reproduce the behavior.

Source code:

#include "Eigen/Sparse"
#include "Eigen/Dense"
#include
#include
#include "Eigen/CholmodSupport"
#include "cholmod.h"

void insertCoefficient(int id, int i, int j, double w, std::vector<Eigen::Triplet>& coeffs,
Eigen::VectorXd& b, const Eigen::VectorXd& boundary)
{
int n = int(boundary.size());
int id1 = i+j*n;
if(i==-1 || i==n) b(id) -= w * boundary(j); // constrained coefficient
else if(j==-1 || j==n) b(id) -= w * boundary(i); // constrained coefficient
else coeffs.push_back(Eigen::Triplet(id,id1,w)); // unknown coefficient
}

void buildProblem(std::vector<Eigen::Triplet>& coefficients, Eigen::VectorXd& b, int n)
{
b.setZero();
Eigen::ArrayXd boundary = Eigen::ArrayXd::LinSpaced(n, 0,M_PI).sin().pow(2);
for(int j=0; j<n; ++j)
{
for(int i=0; i<n; ++i)
{
int id = i+j*n;
insertCoefficient(id, i-1,j, -1, coefficients, b, boundary);
insertCoefficient(id, i+1,j, -1, coefficients, b, boundary);
insertCoefficient(id, i,j-1, -1, coefficients, b, boundary);
insertCoefficient(id, i,j+1, -1, coefficients, b, boundary);
insertCoefficient(id, i,j, 4, coefficients, b, boundary);
}
}
}

int main()
{
int n = 100;
int m = n*n;

std::vector<Eigen::Triplet<double> > coefficients;            
Eigen::VectorXd b(m); 
Eigen::VectorXd x(m); 
buildProblem(coefficients, b, n);
Eigen::SparseMatrix<double> A(m,m);
A.setFromTriplets(coefficients.begin(), coefficients.end());	

StartTimer(here)
//Eigen::CholmodSimplicialLDLT<Eigen::SparseMatrix<double>> solver;
Eigen::CholmodSupernodalLLT<Eigen::SparseMatrix<double>> solver;
solver.compute(A);
x = solver.solve(b);
EndTimer(here)

}

Desktop (please complete the following information):

• OS: Android
• compiler: clang
• BLAS and LAPACK library:
  CLAPACK 3.2.1 (from simonlynen/android_libs/lapack/) and BLAS in it.
• Suitesparse Version: 5.6.0
  (the cmake file is used from jlblancoc/suitesparse-metis-for-windows)
  (try 5.5.0 and 4.5.0, crash occur samely)
• Eigen Version: 3.3.7

Other demo tryings:
using the matrix: Cholmod/Demo/Matrix/n5
using the demo: Cholmod/Demo/cholmod_demo.c
crash also occurs:

---------------------------------- cholmod_demo:
SuiteSparse version 5.6.0
norm (A,inf) = 95
norm (A,1) = 95
CHOLMOD sparse: A: 210-by-210, nz 2135, upper. OK
CHOLMOD dense: B: 210-by-1, OK
bnorm 1.99524
Analyze: flop 1.17203e+06 lnz 12991
Factorizing A
Segmentation fault

suitesparse 5.8.0 build error with clang 10

When I was building suitesparse 5.8.0 on FreeBSD 12-STABLE (which uses clang 10.0 as cc), I got the following error:

cc -O2 -pipe  -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -Wall -Wextra -Wpedantic -Werror -Wall -Wextra -Wpedantic -Werror -isystem /usr/local/include  -O3 -fexceptions -fPIC -fopenmp -I../Include -I../../COLAMD/Include -I../../AMD/Include -I../../SuiteSparse_config  -c ../Source/slip_create_mpq_array.c
In file included from ../Source/slip_create_mpq_array.c:15:
../Source/slip_internal.h:663:18: error: implicit conversion from 'long' to 'double' changes value from
      9223372036854775807 to 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion]
    else if (x > INT64_MAX)
               ~ ^~~~~~~~~
/usr/include/x86/_stdint.h:90:19: note: expanded from macro 'INT64_MAX'
#define INT64_MAX       0x7fffffffffffffff

This error occurred multiple times, aborting the build.
To fix this, I made the conversion in slip_internal.h explicit using the following patch:

--- SLIP_LU/Source/slip_internal.h.orig
 2020-07-03 16:11:39 UTC
+++ SLIP_LU/Source/slip_internal.h
@@ -660,11 +660,11 @@ static inline int64_t slip_cast_double_to_int64 (doubl
     {
         return (0) ;
     }
-    else if (x > INT64_MAX)
+    else if (x > (double)INT64_MAX)
     {
         return (INT64_MAX) ;
     }
-    else if (x < INT64_MIN)
+    else if (x < (double)INT64_MIN)
     {
         return (INT64_MIN) ;
     }

I'm not sure what (if anything) to do about the warning that implicit conversion changes the value by one? Should I also have changed > to >=?

Understand 'problem too large' error

Hi Dr Davis, thanks for this great package, it seems to be foundational for a lot of software that works with matrices.

I'm trying to build a large sparse matrix (250,000,000 rows by ~4000 columns) in R, and I am running into an error from this package: Error: Cholmod error 'problem too large' at file ../Core/cholmod_sparse.c, line 92.

I'm trying to understand this error. The condition that leads to this error is if (!ok || nrow > Int_max || ncol > Int_max || nzmax > Int_max). Is there a way to find out what the value of Int_max is? Or is it more likely that !ok is what is throwing the error? Is there any way to increase my hardware capacity to ensure the dimensions do not cause overflow? It doesn't seem to be a memory issue - upgrading my server from 256GiB to 432GiB doesn't help. I am using Intel MKL for BLAS/LAPACK, as you recommend.

I'd really appreciate any insight you might have into what might be causing this issue.

/usr/bin/ld: warning: libsuitesparseconfig.so.4.4.6, needed by libamd.so, may conflict with libsuitesparseconfig.so.5

When building for AMD on the latest github SuiteSparse code I get a warning similar to the one shown in the title.

The build proceeds and installs the lib and include files for AMD and when I add the locations for these to a Trilinos reconfigure the build proceeds there as well. But when I attempt to configure for a Xyce build I get an error that AMD support isn't available in the Trilinos build I just created.

In trying to track down the issue I thought I'd ask here. Does the presence of libsuitesparseconfig.so.4.4.6 from an apt install of libsuitesparse-dev (Xenial) conflict in any meaningful way with libsuitesparseconfig.so.5 which could prevent Trilinos from building properly for AMD?

I removed libsuitesparseconfig.so.4.4.6 from /usr/lib/x86_64-linux-gnu/ and built for AMD, but it turns out that it's a requirement.

Also, I'm wondering why libsuitesparseconfig.so.4.4.6 is required when libsuitesparseconfig.so.5 is available?

Invalid read in GB_wait with hypersparse matrix

valgrind is complaining about an invalid memory read during GrB_Matrix_assign of a hyper sparse matrix. Later I'm dying with corrupted GrB objects. I'm confident they are related, though I have not done you the courtesy of making a minimal reproducer.

==51679== Invalid read of size 8
==51679== at 0x20086D17: GB_wait (GB_wait.c:274)
==51679== by 0x2005917C: GB_block (GB_block.c:33)
==51679== by 0x200689F9: GB_subassigner (GB_subassigner.c:1441)
==51679== by 0x20055982: GB_assign (GB_assign.c:634)
==51679== by 0x2003D9A6: GrB_Matrix_assign (GrB_Matrix_assign.c:46)

==51679== Address 0xed6bce8 is 8 bytes before a block of size 8 alloc'd
==51679== at 0x442E01F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==51679== by 0x200531AE: GB_Global_malloc_function (GB_Global.c:345)
==51679== by 0x2005DA69: GB_malloc_memory (GB_malloc_memory.c:125)
==51679== by 0x2005FA1D: GB_new (GB_new.c:191)
==51679== by 0x201CC1E0: GB_builder (GB_builder.c:787)
==51679== by 0x20086A7F: GB_wait (GB_wait.c:160)
==51679== by 0x2005917C: GB_block (GB_block.c:33)
==51679== by 0x200689F9: GB_subassigner (GB_subassigner.c:1441)
==51679== by 0x20055982: GB_assign (GB_assign.c:634)
==51679== by 0x2003D9A6: GrB_Matrix_assign (GrB_Matrix_assign.c:46)

Heres the relevant slice of GB_wait.c. It looks to me like we're reading Ah[-1] when kA==0, and glancing at GB_new it does not seem to allocate A->h such that A->h[-1] is valid memory. So I declare you are OffByOne. Forgive me if I am mistaken.

    if (A->is_hyper)
    { 
        // find tjfirst in A->h 
        int64_t pright = A->nvec - 1 ;
        bool found ;
        int64_t *GB_RESTRICT Ah = A->h ;
        GB_SPLIT_BINARY_SEARCH (tjfirst, Ah, kA, pright, found) ;
        // Ah [0 ... kA-1] excludes vector tjfirst.  The list
        // Ah [kA ... A->nvec-1] includes tjfirst.
        ASSERT (kA >= 0 && kA <= A->nvec) ;
        ASSERT (GB_IMPLIES (kA > 0 && kA < A->nvec, Ah [kA-1] < tjfirst)) ;
        ASSERT (GB_IMPLIES (found, Ah [kA] == tjfirst)) ;
        anz0 = A->p [kA] ;
        jlast = Ah [kA-1] ; // ### THIS IS WHERE VALGRIND HATES THE READ ###
    }
    else
    { 
        kA = tjfirst ;
        anz0 = A->p [tjfirst] ;
        jlast = tjfirst - 1 ;
    }

And the contents of my A struct (not from the same run that valgrind was watching so ignore memory addresses).

{magic = 32199698172899170, type = 0x44176ac0 <GB_opaque_GrB_FP64>, 
  type_size = 8, hyper_ratio = 0.0625, plen = 1, vlen = 100, vdim = 100, 
  nvec = 1, nvec_nonempty = 1, h = 0x2aaac4001b30, p = 0x2aaac4000fe0, 
  i = 0x2aaac4003180, x = 0x2aaac40041a0, nzmax = 1, hfirst = 0, 
  Pending = 0x0, nzombies = 0, AxB_method_used = GxB_DEFAULT, 
  queue_next = 0x0, queue_prev = 0x0, enqueued = false, p_shallow = false, 
  h_shallow = false, i_shallow = false, x_shallow = false, is_hyper = true, 
  is_csc = false, is_slice = false}

Also Mask the Matrix in GrB_vxm

As per Paul's paper, Optimal algebraic Breadth-First Search for sparse graphs, when conducting a BFS it's optimally performant to mask away the previously visited vertices from the adjacency matrix before executing the multiplication.

What's the most performant way to accomplish this with GraphBLAS? Because there is no way to also mask the matrix input to GrB_vxm correct?

I assume using GrB_Col_assign and GrB_Row_assign to "delete" the edges for each vertex touched in the previous BFS round? Which would also require copying the original adjacency matrix so as to not alter the primary graph.

Do you have an intuition as to the order of magnitude of vertices at which this tweak will yield a performance benefit, rather than costing more to setup? 10^3... 10^6?

SuiteSparse vs MATLAB : Cholesky factorization of large sparse symmetric positive definite matrix

Dear developers,
I have a very large sparse symmetric positive-definite matrices A with sizes ~ (200 k x 200 k) which I need to factorize;
Matlab decomposition function AF=decomposition(A, 'chol') is solving the problem in small sizes much more faster rather then chol(A) (of matlab) and chol2(A) of SuiteSparse. The reason is unclear for me.

I wanted to ask, whether SuiteSparse's chol2 always fast with respect to decomposition function of MATLAB?

I attached an example matrix for your checking.
Achol.zip

Thank you,

Best regards,

Murod

Error in installing Mongoose on MacOS

I met an error in installing Mongoose. I fixed it as follows.

First, in /Mongoose/MATLAB/mongoose_make.m, line 53-54, it should be
config_src = { '../../SuiteSparse_config/SuiteSparse_config' };
instead of
config_src = { '../SuiteSparse_config/SuiteSparse_config' };

Second, after I modify mongoose_make.m, another error occurs
../Include/Mongoose_Internal.hpp:31:10: fatal error: 'SuiteSparse_config.h' file not found #include "SuiteSparse_config.h"

I copy /SuiteSparse_config/SuiteSparse_config.h to /Mongoose/Include/ and this error is solved.

The setting of my laptop is as follows:
MacOS Catalina 10.15.3.
MATLAB Version 9.4.0.813654 (R2018a)
with 64-bit BLAS

This is a great software and it will be better if these errors can be removed.

make finds mkl; sudo make install INSTALL=/usr/local does not find mkl

Describe the bug
make appears to complete successfully.

sudo make install INSTALL=/usr/local
make fails and terminates with

/usr/bin/ld: cannot find -lmkl_intel_lp64
/usr/bin/ld: cannot find -lmkl_core
/usr/bin/ld: cannot find -lmkl_intel_thread
/usr/bin/ld: cannot find -liomp5
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:544: /usr/local/lib/libcholmod.so.3.0.14] Error 1
make[2]: Leaving directory '/home/pbedenbaugh/SuiteSparse-5.8.1/CHOLMOD/Lib'
make[1]: *** [Makefile:66: install] Error 2
make[1]: Leaving directory '/home/pbedenbaugh/SuiteSparse-5.8.1/CHOLMOD'
make: *** [Makefile:55: install] Error 2

Desktop (please complete the following information):
Using Windows 10 + WSL2 + Ubuntu 20.04

LIBRARY_PATH=./:/opt/intel/compilers_and_libraries_2020.3.279/linux/mkl/lib/intel64_lin:/opt/intel/compilers_and_libraries_2020.3.279/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2020.3.279/linux/tbb/lib/intel64_lin/gcc4.8:/home/pbedenbaugh/intel/compilers_and_libraries_2020.2.254/linux/daal/lib/intel64_lin:/home/pbedenbaugh/intel/compilers_and_libraries_2020.2.254/linux/mpi/intel64/lib

LD_LIBRARY_PATH=./:/opt/intel/compilers_and_libraries_2020.3.279/linux/mkl/lib/intel64_lin:/opt/intel/compilers_and_libraries_2020.3.279/linux/compiler/lib/intel64_lin:/opt/intel/compilers_and_libraries_2020.3.279/linux/tbb/lib/intel64_lin/gcc4.8:/home/pbedenbaugh/intel/compilers_and_libraries_2020.2.254/linux/daal/lib/intel64_lin:/home/pbedenbaugh/intel/compilers_and_libraries_2020.2.254/linux/mpi/intel64/lib

---

SuiteSparse package compilation options:

SuiteSparse Version: 5.8.1
SuiteSparse top folder: /home/pbedenbaugh/SuiteSparse-5.8.1
Package: LIBRARY= libsuitesparseconfig
Version: VERSION= 5.8.1
SO version: SO_VERSION= 5
System: UNAME= Linux
Install directory: INSTALL= /home/pbedenbaugh/SuiteSparse-5.8.1
Install libraries in: INSTALL_LIB= /home/pbedenbaugh/SuiteSparse-5.8.1/lib
Install include files in: INSTALL_INCLUDE= /home/pbedenbaugh/SuiteSparse-5.8.1/include
Install documentation in: INSTALL_DOC= /home/pbedenbaugh/SuiteSparse-5.8.1/share/doc/suitesparse-5.8.1
Optimization level: OPTIMIZATION= -O3
parallel make jobs: JOBS= 8
BLAS library: BLAS= -lmkl_intel_lp64 -lmkl_core -lmkl_intel_thread -liomp5 -lpthread -lm
LAPACK library: LAPACK=
Intel TBB library: TBB= -ltbb
Other libraries: LDLIBS= -lm -lrt -Wl,-rpath=/home/pbedenbaugh/SuiteSparse-5.8.1/lib
static library: AR_TARGET= libsuitesparseconfig.a
shared library (full): SO_TARGET= libsuitesparseconfig.so.5.8.1
shared library (main): SO_MAIN= libsuitesparseconfig.so.5
shared library (short): SO_PLAIN= libsuitesparseconfig.so
shared library options: SO_OPTS= -L/home/pbedenbaugh/SuiteSparse-5.8.1/lib -shared -Wl,-soname -Wl,libsuitesparseconfig.so.5 -Wl,--no-undefined
shared library name tool: SO_INSTALL_NAME= echo
ranlib, for static libs: RANLIB= ranlib
static library command: ARCHIVE= ar rv
copy file: CP= cp -f
move file: MV= mv -f
remove file: RM= rm -f
pretty (for Tcov tests): PRETTY= grep -v "^#" | indent -bl -nce -bli0 -i4 -sob -l120
C compiler: CC= cc
C++ compiler: CXX= g++
CUDA compiler: NVCC= echo
CUDA root directory: CUDA_PATH=
OpenMP flags: CFOPENMP= -fopenmp
C/C++ compiler flags: CF= -O3 -fexceptions -fPIC -fopenmp
LD flags: LDFLAGS= -L/home/pbedenbaugh/SuiteSparse-5.8.1/lib
Fortran compiler: F77= f77
Fortran flags: F77FLAGS=
Intel MKL root: MKLROOT= /opt/intel/compilers_and_libraries_2020.3.279/linux/mkl/lib/intel64_lin
Auto detect Intel icc: AUTOCC= no
UMFPACK config: UMFPACK_CONFIG=
CHOLMOD config: CHOLMOD_CONFIG=
SuiteSparseQR config: SPQR_CONFIG=
CUDA library: CUDART_LIB=
CUBLAS library: CUBLAS_LIB=
METIS and CHOLMOD/Partition configuration:
Your METIS library: MY_METIS_LIB=
Your metis.h is in: MY_METIS_INC=
METIS is used via the CHOLMOD/Partition module, configured as follows.
If the next line has -DNPARTITION then METIS will not be used:
CHOLMOD Partition config:
CHOLMOD Partition libs: -lccolamd -lcamd -lmetis
CHOLMOD Partition include: -I/home/pbedenbaugh/SuiteSparse-5.8.1/CCOLAMD/Include -I/home/pbedenbaugh/SuiteSparse-5.8.1/CAMD/Include -I/home/pbedenbaugh/SuiteSparse-5.8.1/metis-5.1.0/include
MAKE: make
CMake options: -DCMAKE_INSTALL_PREFIX=/home/pbedenbaugh/SuiteSparse-5.8.1 -DCMAKE_CXX_COMPILER=g++ -DCMAKE_C_COMPILER=cc

Linking SuiteSparse against Lapack error.

Describe the bug
I'm trying to build SuiteSparse-5.7.2 on Centos 7.2, using gcc / gfortran 9.3.0. Linking it against a
self built lappack / ATLAS.

We run this on a cluster using the 'modules' suite which allows us to have several versions of a
program or library installed, this is why some of the libraries are installed in non-standard locations.

My command line for build is :

make BLAS="-lsatlas -lgfortran" LAPACK="-llapack -llapacke -llapack -lsatlas"
CC=which gcc CXX=which c++ F77=which gfortran
LDFLAGS="-Lpwd/lib -L$ATLASLIB -L$LPLIB"

ATLASLIB and LPLIB point to the directories where ATLAS and Lapack are installed.

Atlas is the latest version, 3.10.3, Lapack is 3.9.0

To Reproduce
Begin compiling with the above command line, after a while it will bomb out spewing a whole bunch
of unresolved symbols :

( cd SPQR && make )
make[1]: Entering directory /storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/SPQR' ( cd Lib ; make --jobs=8 ) make[2]: Entering directory /storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/SPQR/Lib'
make install INSTALL=/storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2
make[3]: Entering directory /storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/SPQR/Lib' /usr/local/packages/gcc-9.3.0/bin/c++ -L/storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/lib -L/usr/local/packages/ATLAS-3.10.3/lib -L/usr/local/packages/lapack-3.9.0/lib64 -shared -Wl,-soname -Wl,libspqr.so.2 -Wl,--no-undefined spqr_rmap.o SuiteSparseQR_C.o SuiteSparseQR_expert.o spqr_parallel.o spqr_kernel.o spqr_analyze.o spqr_assemble.o spqr_cpack.o spqr_csize.o spqr_fcsize.o spqr_debug.o spqr_front.o spqr_factorize.o spqr_freenum.o spqr_freesym.o spqr_freefac.o spqr_fsize.o spqr_maxcolnorm.o spqr_rconvert.o spqr_rcount.o spqr_rhpack.o spqr_rsolve.o spqr_stranspose1.o spqr_stranspose2.o spqr_hpinv.o spqr_1fixed.o spqr_1colamd.o SuiteSparseQR.o spqr_1factor.o spqr_cumsum.o spqr_shift.o spqr_happly.o spqr_panel.o spqr_happly_work.o SuiteSparseQR_qmult.o spqr_trapezoidal.o spqr_larftb.o spqr_append.o spqr_type.o spqr_tol.o -o /storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/lib/libspqr.so.2.0.9 -lm -lrt -Wl,-rpath=/storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/lib -lamd -lcolamd -lcholmod -lsuitesparseconfig -llapack -llapacke -llapack -lsatlas -lsatlas -lgfortran spqr_front.o: In function long spqr_front(long, long, long, double, long, long, double*, long*, char*, double*, double*, double*, double*, cholmod_common_struct*)':
spqr_front.cpp:(.text.Z10spqr_frontIdElllldllPT_PlPcS1_S1_PdS4_P21cholmod_common_struct[Z10spqr_frontIdElllldllPT_PlPcS1_S1_PdS4_P21cholmod_common_struct]+0x51c): undefined reference to dlarfg_' spqr_front.cpp:(.text._Z10spqr_frontIdElllldllPT_PlPcS1_S1_PdS4_P21cholmod_common_struct[_Z10spqr_frontIdElllldllPT_PlPcS1_S1_PdS4_P21cholmod_common_struct]+0x68a): undefined reference to dlarf'
spqr_front.o: In function long spqr_front<std::complex<double> >(long, long, long, double, long, long, std::complex<double>*, long*, char*, std::complex<double>*, std::complex<double>*, double*, double*, cholmod_common_struct*)': spqr_front.cpp:(.text._Z10spqr_frontISt7complexIdEElllldllPT_PlPcS3_S3_PdS6_P21cholmod_common_struct[_Z10spqr_frontISt7complexIdEElllldllPT_PlPcS3_S3_PdS6_P21cholmod_common_struct]+0x58b): undefined reference to zlarfg'
spqr_front.cpp:(.text._Z10spqr_frontISt7complexIdEElllldllPT_PlPcS3_S3_PdS6_P21cholmod_common_struct[_Z10spqr_frontISt7complexIdEElllldllPT_PlPcS3_S3_PdS6_P21cholmod_common_struct]+0x700): undefined reference to zlarf_' collect2: error: ld returned 1 exit status make[3]: *** [/storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/lib/libspqr.so.2.0.9] Error 1 make[3]: Leaving directory /storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/SPQR/Lib'
make[2]: *** [library] Error 2
make[2]: Leaving directory /storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/SPQR/Lib' make[1]: *** [all] Error 2 make[1]: Leaving directory /storage/stsxab/CentosBuild-2020/SuiteSparse/SuiteSparse-5.7.2/SPQR'
make: *** [go] Error 2

The odd thing is that the missing symbols seem to be in the linked liblapack.so :

nm liblapack.so | grep zlarf_

00000000005cb380 T zlarf_

Cheers.

Phill.

README incorrect

The README says make install compiles SuiteSparse and installs in /usr/local however that's only true if you append INSTALL=/usr/local, otherwise it gets installed under in top level source, so either the default needs to change, or the README.

Testing cholmod with matrix “nd6k.mtx”, the time with cuda (Quadro RTX 6000) is slower than that of cpu (without openmp), mainly because of the analyze time.

I test cholmod using matrix: nd6k (https://www.cise.ufl.edu/research/sparse/MM/ND/nd6k.tar.gz)

---

The code is:

int main()
{
struct timeval t1, t2;
double elapsedTime;

const char* matFile = "nd6k.mtx";
FILE* fp = fopen(matFile, "r");
assert(fp != NULL);

cholmod_sparse *A ;
cholmod_dense *x, *b;
cholmod_factor *L ;

cholmod_common* c = (cholmod_common*)malloc(sizeof(cholmod_common));
cholmod_l_start (c) ; /* start CHOLMOD */
c->useGPU = 1;
c->supernodal = CHOLMOD_SUPERNODAL;

A = cholmod_l_read_sparse (fp, c) ; /* read in a matrix */
cholmod_l_print_sparse (A, "A", c) ; /* print the matrix */
fclose(fp);

if (A == NULL || A->stype == 0) /* A must be symmetric */
{
    cholmod_l_free_sparse (&A, c) ;
    cholmod_l_finish (c) ;
    return (0) ;
}

b = cholmod_l_ones (A->nrow, 1, A->xtype, c) ; /* b = ones(n,1) */

gettimeofday(&t1, NULL);
L = cholmod_l_analyze (A, c) ; /* analyze */
gettimeofday(&t2, NULL); 
elapsedTime = (t2.tv_sec - t1.tv_sec) * 1000.0;
elapsedTime += (t2.tv_usec - t1.tv_usec) / 1000.0;
printf("analyze Time: %.4f ms\n", elapsedTime);

gettimeofday(&t1, NULL);
cholmod_l_factorize (A, L, c) ; /* factorize */
gettimeofday(&t2, NULL);
elapsedTime = (t2.tv_sec - t1.tv_sec) * 1000.0;
elapsedTime += (t2.tv_usec - t1.tv_usec) / 1000.0;
printf("factorize Time: %.4f ms\n", elapsedTime);

gettimeofday(&t1, NULL);
x = cholmod_l_solve (CHOLMOD_A, L, b, c) ; /* solve Ax=b */
gettimeofday(&t2, NULL);
elapsedTime = (t2.tv_sec - t1.tv_sec) * 1000.0;
elapsedTime += (t2.tv_usec - t1.tv_usec) / 1000.0;
printf("solve Time: %.4f ms\n", elapsedTime);

cholmod_l_gpu_stats(c);
cholmod_l_free_factor (&L, c) ; /* free matrices */
cholmod_l_free_sparse (&A, c) ;
cholmod_l_free_dense (&x, c) ;
cholmod_l_free_dense (&b, c) ;
cholmod_l_finish (c) ; /* finish CHOLMOD */

return (0) ;

}

Using cpu:
analyze Time: 1138.2430 ms
factorize Time: 10002.1580 ms
solve Time: 99.5780 ms

SYRK CPU calls 799 time 3.4990e+00
GPU calls 0 time 0.0000e+00
GEMM CPU calls 628 time 2.0249e+00
GPU calls 0 time 0.0000e+00
POTRF CPU calls 172 time 2.8340e+00
GPU calls 0 time 0.0000e+00
TRSM CPU calls 171 time 1.1318e+00
GPU calls 0 time 0.0000e+00

Using gpu
analyze Time: 16036.8460 ms
factorize Time: 1495.4660 ms
solve Time: 158.9000 ms

SYRK CPU calls 559 time 5.7435e-02
GPU calls 240 time 1.0373e-01
GEMM CPU calls 427 time 5.9693e-02
GPU calls 240 time 3.4453e-03
POTRF CPU calls 166 time 2.6762e-02
GPU calls 6 time 1.7808e-01
TRSM CPU calls 166 time 3.8800e-01
GPU calls 5 time 6.5708e-02

The analyze of gpu mode is much slower than that of cpu mode.

I wander:

1. Whether the calling process is correct?
2. If the calling process is correct, why the analyze of gpu is slow?

Provide SuiteSparseConfig.cmake

It would ease using SuiteSparse with CMake, if SuiteSparse would provide a SuitSparseconfig.cmake file, that CMake can use to identify the SuiteSparse installation and get all locations and parameters.

CMake offers the helper function configure_package_config_file, to get this done without too much work. If you are interested, I can provide an according merge request.

Build issue - relocation R_X86_64_PC32 against symbol `dpotrf2_'

Problem building this:

I've previously built lapack. But it linked weirdly:
/usr/bin/ld: //usr/local/lib/liblapack.a(dpotrf2.f.o): relocation R_X86_64_PC32 against symbol `dpotrf2_' can not be used when making a shared object; recompile with -fPIC

No idea where to go with this. Thanks for any input!

Are low-rank updates for sparse Cholesky factorizations possible from MATLAB API?

(Thank you for this great library and making it so easy to install)

I understand that the built-in cholupdate in MATLAB only supports dense positive definite matrices. I'd like to do this with a sparse matrix. I've installed SuiteSparse's MATLAB tools via SuiteSparse_install, but I can't find in the API whether such up-/down-dates are exposed. (The cholupdate still points to MATLAB's built in dense one).

The SuiteSparse/MATLAB_Tools/Factorize/Demo/factorize_demo.m uses chol_update but it appears to be the MATLAB built in dense one, too.

Are low-rank updates for sparse Cholesky factorizations possible from the MATLAB API?

If not, are low-rank updates for sparse Cholesky factorizations possible from the C/C++ API?

I see that there's a ldlupdate, should I being using this instead of chol? If so, should I expect a performance hit switching from ldl factorization to chol?

Workspace Y repeatedly reallocated in cholmod_l_solve2

Describe the bug
Repeatedly calling cholmod_l_solve2 with the same inputs reallocates workspace matrix Y on each call for simplical factorisations under certain conditions, this causes excessive calls to malloc/free when solving a large number of systems.

To Reproduce

1. Compile the cholmod_l_demo demo, and debug with matrix Matrix/bcsstk01.tri, noting that at line 388 of cholmod_l_demo.c the solver is called repeatedly with the same inputs.

2. Within the solver, at line 1635 of cholmod_solve.c, the handle Y_Handle is passed to ensure_dense to check that it is suitable for the current solve. On the first run, this will be allocated appropriately, note that, e.g., the leading dimension Y_Handle->d is set equal to 4.

3. The workspace matrix Y is then used in a call to ptrans on line 1649, upon return the leading dimension Y_Handle->d is now set to 1.

4. On the next call to the solver, ensure_dense will reallocate Y because a check that the leading dimension is equal to 4 will fail.

Expected behavior
I did not expect the workspace Y to be reallocated.

Desktop (please complete the following information):

• OS: MacOS 10.15.4, Windows 10 2004
• compiler: Clang (MacOS), MinGW cross compile (Windows)
• BLAS and LAPACK library: OpenBLAS
• Version: master and previous

Additional context
This behaviour was identified when tracking excessive allocation in a Julia program (which uses CHOLMOD for its sparse factorisation routines), https://discourse.julialang.org/t/in-place-cholesky-solve-with-zero-allocation-simplical-vs-supernodal/41115/6.

GraphBLAS needs to be linked to libatomic on some platforms

In SuiteSparse 5.7, a call to __atomic_compare_exchange was introduced in GraphBLAS/Source/Template/GB_AxB_saxpy3_template.h.

Under some circumstances, the compiler turns those __atomic statements into a call to a function provided by the libatomic library. However, the GraphBLAS build system does not link executables to libatomic in that case, resulting in a build failure (occurring in reduce_demo).

In Debian, the problem manifests at least with the ARM 32-bit (little endian) and MIPS 32-bit (little endian) architectures, see the respective build logs:
https://buildd.debian.org/status/fetch.php?pkg=suitesparse&arch=armel&ver=1%3A5.7.1%2Bdfsg-1&stamp=1582754466&raw=0
https://buildd.debian.org/status/fetch.php?pkg=suitesparse&arch=mipsel&ver=1%3A5.7.1%2Bdfsg-1&stamp=1582758238&raw=0

SLIP LU userguide not rebuilt by "make docs"

Hi,

I’ve noticed that the SLIP LU userguide is not rebuilt by top-level "make docs", as for the other libraries.

Is that an overlook?

Thanks for your work,

SuiteSparse_long is a 32bit integer for 32bit Windows executables

Describe the bug
SuiteSparse_long is defined with the following stanza in SuiteSparse_config.h:

#ifndef SuiteSparse_long

#ifdef _WIN64

#define SuiteSparse_long __int64
#define SuiteSparse_long_max _I64_MAX
#define SuiteSparse_long_idd "I64d"

#else

#define SuiteSparse_long long
#define SuiteSparse_long_max LONG_MAX
#define SuiteSparse_long_idd "ld"

#endif
#define SuiteSparse_long_id "%" SuiteSparse_long_idd
#endif

For Windows 32bit, _WIN64 is not defined. So SuiteSparse_long is defined as the 32bit "long".

See also this downstream issue in Octave: https://savannah.gnu.org/bugs/index.php?58795

To Reproduce
Compile SuiteSparse for Windows 32bit.

Expected behavior
SuiteSparse_long should be 64bit on all platforms.
"_WIN32" is defined for Windows 32bit and 64bit targets. Maybe it should be used in the condition instead of "_WIN64".
https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=vs-2019

Screenshots
not applicable

Desktop (please complete the following information):

• OS: Windows 32bit
• compiler i686-w64-mingw32-gcc
• BLAS and LAPACK library, if applicable
• Version any

Additional context
None.

Can't compile with GCC 7.4.0

Bug
The package does not compile out-of-the-box (or with considerable configuration) using GCC 7.4.0.

To reproduce
Run the following command:
make CC=/path/to/gcc CXX=/path/to/g++ F77=/path/to/gfortran <OTHER OPTIONS>
For me, the other options I included were paths to a previous Metis install and MKL.

I did track down part of the problem, but not the whole thing. For SPQR, using -Dinline= in the compiler flags appears to be the culprit. Removing that option allowed that module to compile without error. I ran into further problems with missing prototypes on a later module (GraphBLAS), however. I did a quick grep to see if it was a missing header, but, because some functions were defined by macros, grep couldn't find any matching prototype. All the missing prototypes were casting double to something else (float, uint64_t, etc.).

Desktop

• OS: CentOS
• Compiler: gcc 7.4.0
• BLAS and LAPACK library: MKL
• Version: 5.6.0 (latest as of writing)

error run cholmod_super_numeric with GPU_BLAS

I have modified ceres witch used by colmap(https://github.com/colmap/colmap) to use suitesparse(with GPU accelerating).

but I encountered a problem:
CHOLMOD (gpu_updateC) function return error in t_cholmod_gpu.c line 504
I added some logs to show cublashandle which was NULL.

Then, I traced CHOLMOD (gpu_updateC) which called by TEMPLATE (cholmod_super_numeric)

there are gpu_init and gpu_end in TEMPLATE (cholmod_super_numeric), but i didn't see any initialize cublashandle in gpu_init.

Is this a problem?

SuiteSparse 5.4.0 CHOLMOD GPU acceleration result error (windows + mkl + cuda v10.2)

CHOLMOD works well without GPU acceleration. However, when GPU acceleration enabled, it always throws the exception "matrix not positive definite" (the test matrix is positive definite for sure).

can not make

Describe the bug
A clear and concise description of what the bug is.
[100%] Built target complex_demo
[100%] Built target import_demo
[100%] Built target openmp_demo
make[4]: Leaving directory '/home/gaotao/data/package/SuiteSparse/GraphBLAS/build'
[100%] Built target mis_demo
[100%] Built target kron_demo
make[3]: Leaving directory '/home/gaotao/data/package/SuiteSparse/GraphBLAS/build'
make[2]: Leaving directory '/home/gaotao/data/package/SuiteSparse/GraphBLAS/build'
make[1]: Leaving directory '/home/gaotao/data/package/SuiteSparse/GraphBLAS'
( cd SLIP_LU && make )
make[1]: Entering directory '/home/gaotao/data/package/SuiteSparse/SLIP_LU'
( cd Lib ; make )
make[2]: Entering directory '/home/gaotao/data/package/SuiteSparse/SLIP_LU/Lib'
make install INSTALL=/home/gaotao/data/package/SuiteSparse
make[3]: Entering directory '/home/gaotao/data/package/SuiteSparse/SLIP_LU/Lib'
cc -L/home/gaotao/data/package/SuiteSparse/lib -shared -Wl,-soname -Wl,libsliplu.so.1 -Wl,--no-undefined slip_matrix_div.o slip_create_mpq_array.o SLIP_free.o SLIP_LU_factorize.o SLIP_realloc.o slip_matrix_mul.o slip_get_largest_pivot.o slip_ref_triangular_solve.o SLIP_backslash.o slip_create_mpz_array.o slip_get_nonzero_pivot.o SLIP_LU_solve.o slip_back_sub.o slip_cumsum.o slip_get_pivot.o SLIP_malloc.o slip_sparse_collapse.o SLIP_calloc.o slip_dfs.o slip_get_smallest_pivot.o SLIP_matrix_allocate.o slip_sparse_realloc.o slip_cast_array.o slip_expand_double_array.o SLIP_gmp.o SLIP_matrix_copy.o SLIP_matrix_check.o slip_cast_matrix.o slip_expand_mpfr_array.o SLIP_initialize.o SLIP_matrix_free.o slip_check_solution.o slip_expand_mpq_array.o SLIP_initialize_expert.o SLIP_matrix_nnz.o SLIP_create_default_options.o SLIP_finalize.o SLIP_LU_analysis_free.o slip_permute_x.o slip_permute_b.o slip_create_mpfr_array.o slip_forward_sub.o SLIP_LU_analyze.o slip_reach.o -o /home/gaotao/data/package/SuiteSparse/lib/libsliplu.so.1.0.2 -lm -lrt -Wl,-rpath=/home/gaotao/data/package/SuiteSparse/lib -lsuitesparseconfig -lamd -lcolamd -lm -lgmp -lmpfr
/usr/bin/ld: cannot find -lgmp
/usr/bin/ld: cannot find -lmpfr
collect2: error: ld returned 1 exit status
Makefile:69: recipe for target '/home/gaotao/data/package/SuiteSparse/lib/libsliplu.so.1.0.2' failed
make[3]: *** [/home/gaotao/data/package/SuiteSparse/lib/libsliplu.so.1.0.2] Error 1
make[3]: Leaving directory '/home/gaotao/data/package/SuiteSparse/SLIP_LU/Lib'
Makefile:53: recipe for target 'library' failed
make[2]: *** [library] Error 2
make[2]: Leaving directory '/home/gaotao/data/package/SuiteSparse/SLIP_LU/Lib'
Makefile:24: recipe for target 'C' failed
make[1]: *** [C] Error 2
make[1]: Leaving directory '/home/gaotao/data/package/SuiteSparse/SLIP_LU'
Makefile:18: recipe for target 'go' failed
make: *** [go] Error 2
gaotao@gaotao-desktop:~/data/package/SuiteSparse$

To Reproduce
Steps to reproduce the behavior.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS] Ubuntu 18.04 ARMv8 Processor rev 3 (v8l) × 4
• compiler [e.g. gcc 7.4, icc 19.0]
• BLAS and LAPACK library, if applicable
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

CUDA11 Support

Is your feature request related to a problem? Please describe.
CUDA11 drops support for compute_30.

Describe the solution you'd like
Detect the CUDA version & conditionally include compute_30 if supported.

Describe alternatives you've considered
I currently manually remove support compute_30 by removing it from SuiteSparse_config/SuiteSparse_config.mk

Additional context
CUDA version can be detected in make with nvcc --version | grep -o 'release [0-9]*' | grep -o '[0-9]*'

How can I get the supernodal LDL^T factorization of a symmetric quasidefinite matrix ?

Hello, I have a question when I use CHOLMOD to solve the KKT matrix ( a symmetric quasidefinite matrix) in the interior point mathod. If I set L->is_super = false there is no problem, but if I omit this set, there is a warnning:

CHOLMOD warning: matrix not positive definite. file: ../Supernodal/t_cholmod_super_numeric.c line: 911

The userguide tells me if L->is_super = TRUE, the supernodal LL^T factorization is computed in page 116. How can I get the supernodal LDL^T factorization of a symmetric quasidefinite matrix ? Thank you!

Allow re-use of factorization on multiple threads

I'm using CHOLMOD (via Haskell, but I don't think that's important here) and I'd like to analyze a matrix structure once and then re-factor on multiple threads. I tried this, using copy_factor to make a factor for each thread, and it failed with various seg-faults and other complaints from which I concluded/guessed that there must be some workspace in Common that is being re-used (?).

So for now I've "solved" this by re-analyzing once per cpu and keeping a concurrent queue of common/factor pairs which get re-used by the various threads. But that is clearly a waste of work.

Is there any way to analyze just once and then make the rest of this work?

Thanks!

`make ..` after `cmake ..` is not working for me

Describe the bug
Make is not doing the proper thing according to the library build instructions on the github readme.

To Reproduce

1. Download the latest SuiteSparse-5.7.2.zip.
2. Open up a standard windows command prompt, already having Cmake installed and MSYS's make installed using pacman -S make and adding C:\msys64\usr\bin to your Path env variable.
3. cd to SuiteSparse/GraphBLAS/build
4. Try copy / pasting : cd GraphBLAS/build ; cmake .. ; make ; cd ../Demo ; ./demo
   and running. Complains about directory not found.
5. Try breaking up the command, do:
   cmake .. (appears to work)
   make .. (fails)
6. The last part fails and here is a detail of the total command line interaction:

> cmake ..
-- CMake version: 3.17.0-rc1
-- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.18363.
-- Building dynamic GraphBLAS library only
-- CMAKE build type:          Release
-- CMAKE C Flags release:     /MD /O2 /Ob2 /DNDEBUG
-- CMAKE compiler ID:         MSVC
-- CMAKE thread library:
-- CMAKE have pthreads:
-- CMAKE have Win32 pthreads: 1
-- CMAKE have OpenMP:         TRUE
-- Automatic selection of synchronization method for user threads
-- Using OpenMP to synchronize user threads
-- Using OpenMP for internal parallelism
-- CMAKE C flags: /DWIN32 /D_WINDOWS /W3 /O2 -wd"4244" -wd"4146" -wd"4018" -wd"4996" -wd"4047" -wd"4554" /MD /O2 /Ob2 /DNDEBUG -openmp -DUSER_OPENMP_THREADS  -openmp -DHAVE_WINDOWS_THREADS
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/FruitfulApproach/Desktop/HutterPrizeSubmission/SuiteSparse-5.7.2/GraphBLAS/build

> make ..
make: Nothing to be done for '..'.

Expected behavior
For the build to go through.

Screenshots

Desktop:

• OS: Windows 10 Home
• compiler: Whichever would be used by compiling with latest MSYS (dowloaded today)
• Version: downloaded today, SuiteSparse 5.7.2

Additional context
I tried doing this in MSYS's provided bash shell and the same exact error occurs, namely:
make: Nothing to be done for '..'.

Compilation for CHOLDMOD GPU failed to link to library

Describe the bug
"g++ test4.o -L. -lcholmod -lspqr -lsuitesparseconfig -L/usr/local/cuda/lib64 -lcudart -lcublas
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: test4.o: in function main': test4.cpp:(.text+0x469): undefined reference to cholmod_l_gpu_memorysize(unsigned long*, unsigned long*, cholmod_common_struct*)'
collect2: error: ld returned 1 exit status"

To Reproduce
`#include "SuiteSparseQR.hpp"
#include
#define Long SuiteSparse_long
#include "SuiteSparseGPU_Runtime.hpp"
#include "cholmod_gpu.h"

void check_residual
(
cholmod_sparse *A,
cholmod_dense *X,
cholmod_dense *B,
cholmod_common *cc
)
{
Long m = A->nrow ;
Long n = A->ncol ;
Long rnk ;
double rnorm, anorm, xnorm, atrnorm ;
double one [2] = {1,0}, minusone [2] = {-1,0}, zero [2] = {0,0} ;
cholmod_dense *r, *atr ;

// get the rank(A) estimate
rnk = cc->SPQR_istat [4] ;

// anorm = norm (A,1) ;
anorm = cholmod_l_norm_sparse (A, 1, cc) ;

// rnorm = norm (A*X-B)
r = cholmod_l_copy_dense (B, cc) ;
cholmod_l_sdmult (A, 0, one, minusone, X, r, cc) ;
rnorm = cholmod_l_norm_dense (r, 2, cc) ;

// xnorm = norm (X)
xnorm = cholmod_l_norm_dense (X, 2, cc) ;

// atrnorm = norm (A'*r)
atr = cholmod_l_zeros (n, 1, r->xtype, cc) ;        // atr = zeros (n,1)
cholmod_l_sdmult (A, 1, one, zero, r, atr, cc) ;    // atr = A'*r
atrnorm = cholmod_l_norm_dense (atr, 2, cc) ;       // atrnorm = norm (atr)
if (anorm > 0) atrnorm /= anorm ;

if (m <= n && anorm > 0 && xnorm > 0)
{
    // find the relative residual, except for least-squares systems
    rnorm /= (anorm * xnorm) ;
}
printf ("relative norm(Ax-b): %8.1e rank: %6ld  "
    "rel. norm(A'(Ax-b)) %8.1e\n", rnorm, rnk, atrnorm) ;
cholmod_l_free_dense (&r, cc) ;
cholmod_l_free_dense (&atr, cc) ;

}

int main (void)
{
//This time I am just going to use only 1 set of data and 1 QR solver only
//Because I do not know how to inject my data into the qsparse database yet

//Construct matrix of checked form in sparse format - triplet form
int nrow, ncol;
nrow = 10000 ; ncol = nrow;

//Count the number of zeros
int nz = 0;
for (int i = 0; i <nrow; i++) {
for (int j = 0; j < ncol; j++) {
// if ((i==j)) {
nz++;
// }
}
}

printf("Total number of nnz:%d\n", nz);
long* r = (long )malloc(nzsizeof(long));
long* c = (long )malloc(nzsizeof(long));
double* a = (double )malloc(nzsizeof(double)); //I use double instead of complex. Just for testing purposes only.
if(r==NULL||c==NULL||a==NULL) exit(EXIT_FAILURE);

int count = 0;
for (int i = 0; i <nrow; i++) {
for (int j = 0; j < ncol; j++) {
// if ((i==j)) {
*(r+count) = i;
*(c+count) = j;
*(a+count) = rand()%100;
count++;
// }
}
}

// for (int i=0; i<nz; i++) printf("%d ",(r+i));
// printf("\n");
// for (int i=0; i<nz; i++) printf("%d ",(c+i));
// printf("\n");
// for (int i=0; i<nz; i++) printf("%lf ",(a+i));
// for (int i=0; i<nz; i++) printf("%lf ",(1/((a+i))));
// printf("\n\n");

//Initiate cholmod engine
cholmod_common Common, *cc ;
cc = &Common ; // cc: address of Common class
cholmod_l_start (cc) ;

size_t total_mem, available_mem ;
double t;
t = SuiteSparse_time ( ) ;
cc->useGPU = 1 ;
t = SuiteSparse_time ( ) - t ;
int ok = cholmod_l_gpu_memorysize (&total_mem, &available_mem, cc) ;
cc->gpuMemorySize = available_mem ;
printf("GPU Memory:%f\n", available_mem);
if (cc->gpuMemorySize <= 1)
{
printf ("no GPU available\n") ;
}
printf ("available GPU memory: %g MB, warmup time: %g\n",
(double) (cc->gpuMemorySize) / (1024 * 1024), t) ;

//Define, allocate and transfer result to triplet
cholmod_triplet A_triplet;
A_triplet = *cholmod_l_allocate_triplet(nrow,ncol,nz,0,CHOLMOD_REAL,cc);
if(&A_triplet==NULL) exit(EXIT_FAILURE);
A_triplet.nrow=nrow;
A_triplet.ncol=ncol;
A_triplet.nnz=nz;
A_triplet.nzmax=nz;

A_triplet.stype=0;
A_triplet.itype=CHOLMOD_INT;
A_triplet.xtype=CHOLMOD_REAL;
A_triplet.dtype=CHOLMOD_DOUBLE;

A_triplet.i = r;
A_triplet.j = c;
A_triplet.x = a;

//Change from triplet to sparse
cholmod_sparse A;
A = *cholmod_l_triplet_to_sparse(&A_triplet,nz,cc);

cholmod_dense B;
B = *cholmod_l_ones (nrow, 1, CHOLMOD_REAL, cc) ;

cholmod_dense X;
X = *SuiteSparseQR (SPQR_ORDERING_DEFAULT, SPQR_DEFAULT_TOL, &A, &B, cc) ;

check_residual(&A, &B, &X, cc);

double* ans = (double *)X.x;
// for (int i=0;i<nrow;i++) {
// printf("%f\n",(ans[i]));
// }

double firstAns = 0;
for (int i=0;i<nrow;i++) {
firstAns += ans[i] * a[i];
}
printf("First answer: %f\n", firstAns);

}
`

My folder contains:
phoon@linux-i3pz:~/Documents/Cholmod_SPQR_test/compile_gpu> ls libcholmod.a test4.o

CHOLMOD/Lib/Makefile cholmod_gpu_kernels.o rule doesn't use NVCCFLAGS

Line 537: has flags that should probably be set by SuiteSparse_config:

$(NVCC) -I../../SuiteSparse_config -Xcompiler -fPIC -O3  -gencode=arch=compute_20,code=sm_20 -gencode=arch=compute_30,code=sm_30 -gencode=arch=compute_35,code=sm_35 -c ../GPU/cholmod_gpu_kernels.cu

Add option for building without GraphBLAS and Mongoose

Is your feature request related to a problem? Please describe.
Seeing that GraphBLAS and Mongoose have their own repositories and can be built independently of SuiteSparse, it is more convenient for us as Linux distro packagers to do that. Unfortunately, the makefile does not allow us to do that easily.

Describe the solution you'd like
Add an option like IGNORE_STANDALONE_TOOLS that would prevent GraphBLAS and Mongoose from building and installing like MY_METIS_LIB does for metis.

Describe alternatives you've considered
Alternately, distros could:

1. Build individual libraries explicitly (basically reproducing the commands run by make in their own scripts and deleting the unwanted lines). — This might be something we want to do in the future but at the moment the libraries are too interlinked.
2. Edit the Makefile to remove unwanted lines. — This is what we are doing now.

Error in CSparse Makefile

I had compilation errors for CSparse when using icc. I had to add the following lines to the top of the Makefile to get it to work.

SUITESPARSE ?= $(realpath $(CURDIR)/..)
export SUITESPARSE
include ../SuiteSparse_config/SuiteSparse_config.mk

编译的库文件，模拟器可用，ios真机不可用

Describe the bug
您好，我在macos上编译生成的.a静态库文件，然后用于ios工程，报的错误是Undefined symbol：_cholmod_analyze _cholmod_amd _cholmod_finish _cholmod_change_factor _cholmod_free_factor _cholmod_factorize _cholmod_solve _cholmod_start

这个报错大概意思就是我链接错了库，之前我在别的项目上找的cholmod，不管在模拟器上，还是ios真机上，都会有这个错误。然后对您提供的suitesparse重新编译，模拟器上可用了，但是ios真机上不可用

我想问一下，ios真机可用，我应该如何编译
无论如何，非常感谢！

SuiteSparse hangs during "make" on Ubuntu 20.04

Describe the bug

1. Trying to install from source: clonning the SuiteSparse repo from github and running "make" the compilation/tests hang at after
   ./qrdemo < ../Matrix/west0067.mtx
   Matrix 67-by-67 nnz: 294
   relative norm(Ax-b): 5.6e-17 rank: 67 rel. norm(A'(Ax-b)) 2.8e-15

To Reproduce
Try "make" on a system running the latest update of Ubuntu 20.04 (more config info below).

Expected behavior
It should have compiled and ran all tests during make.

Screenshots
Attached a screen shot, showing the configuration on the left and the compilation of Suitesparse on the right.

Desktop (please complete the following information):

• OS: PopOs 20.04 (Ubuntu 20.04)
• compiler gcc 9.3.0
• BLAS and LAPACK library, if applicable: libblas-dev 3.9.0 liblapack 3.9.0
• Version [e.g. 22]

Additional context

1. identical behavior with libopenblas-dev instead of libblas-dev
2. With system installed libsuitesparse: On Ubuntu 20.04 with "apt install libsuitesparse-dev" LU decomposition of an indefinite 2000x2000 nonsingular matrix hangs with no error messages. On a smaller (70x70) similar matrices works.

CHOLMOD supernodal factorization performance degradation due to OpenMP

In my application I'm using the CHOLMOD Supernodal factorisation to solve sparse systems of somewhat small size (100-10000). I'm seeing excessive usage of CPU and performance degradation caused by OpenMP thread synchronisation.

My application with default settings runs for 161.27 seconds with average CPU usage of 250-300%. It does other things aside from solving systems, so probably only 50% of time is spent inside the solvers.

Once I disable OpenMP with export OMP_THREAD_LIMIT=1, my application runs for 155.98 seconds with average CPU usage of 99.9%.

I can also reduce general CPU usage with the GOMP_SPINCOUNT=500 environment variable (to around 150%), however, this comes with a further increased run time.

I can see four threads taking CPU, with one at 99.9%, and the others at 50% and for the other 3 gdb always showing:

(gdb) bt
#0  0x00007fffa96ab112 in do_spin (val=1731152, addr=0x7fff3001d044) at /build/gcc/src/gcc/libgomp/config/linux/x86/futex.h:130
#1  0x00007fffa96ab112 in do_wait (val=1731152, addr=0x7fff3001d044) at /build/gcc/src/gcc/libgomp/config/linux/wait.h:66
#2  0x00007fffa96ab112 in gomp_barrier_wait_end (bar=0x7fff3001d040, state=1731152) at /build/gcc/src/gcc/libgomp/config/linux/bar.c:48
#3  0x00007fffa96a8a98 in gomp_simple_barrier_wait (bar=0x7fff3001d040) at /build/gcc/src/gcc/libgomp/config/posix/simple-bar.h:60
#4  0x00007fffa96a8a98 in gomp_thread_start (xdata=<optimized out>) at /build/gcc/src/gcc/libgomp/team.c:124
#5  0x00007ffff6d47a9d in start_thread () at /usr/lib/libpthread.so.0
#6  0x00007fffa95adb23 in clone () at /usr/lib/libc.so.6
(gdb) 

I'm using Arch Linux 1.4, SuiteSpare 5.3.0-1, GCC 7.4.1 and Eigen that wraps the CHOLMOD code. With Eigen's own sparse solver I'm seeing 99.9% CPU usage and run time of 175.2 seconds -- so clearly the problem is inside SuiteSparse.

CHOLMOD GPU memory poll

In PETSc, I would like to be able to use CHOLMOD from various MPI ranks sharing the same GPU (e.g. on SUMMIT using MPS)

The current CHOLMOD code seems fragile in this respect since, after the inquiry to cudaMemGetInfo, a series of "memory queries" is performed trough gpu_poll https://github.com/DrTimothyAldenDavis/SuiteSparse/blob/master/CHOLMOD/GPU/cholmod_gpu.c#L57

Since we cannot guarantee flow control on cudaMalloc + cudaFree (eg like having an omp critical region), it may happen that 2 MPI processes accessing the same GPU will have a different "available memory" view.
I fixed the issue for me by just returning the output from cudaMemGetInfo in cholmod_gpu_memorysize and then passing a proper maxGpuMemBytes

Not sure you like the solution, but I think this issue should be fixed someway.

install_name_tool missing in a few Makefiles

Describe the bug
Calls to install_name_tool is needed when moving dynamic libraries around in OSX. These calls are missing in the "install" sections of several of the Makefiles:
AMD/Lib/Makefile
CAMD/Lib/Makefile
CCOLAMD/Lib/Makefile
CHOLMOD/Lib/Makefile
COLAMD/Lib/Makefile
SuiteSparse_config/Makefile
UMFPACK/Lib/Makefile

To Reproduce
'make install' and link libraries under OSX. The executables will not be able to find the dynamic libraries.

Desktop (please complete the following information):
OSX

I fixed this in my copy and can make a pull request.

how to build suitesparse lib for ceres-slover in android platform ?

Hello author, I want to use SuitSparse lib on the Android OS platform. However, it appears difficult to look for reliable guidance on it. Could you give me some suggestions? Your help is really appreciated.

Problem installing UMPACK, CHOLMOD, KLU, and SuiteSparseQR in Matlab R2018a

Describe the bug
UMPACK, CHOLMOD, KLU, and SuiteSparseQR not being installed due to recurrent error with \metis-5.1.0\gk_arch.h (screen shot attached)

To Reproduce
Enter SuiteSparse_install into Matlab command window

Expected behavior
All components of SuiteSparse should install\compile without errors

Screenshots

Desktop:

• OS: Windows 8.1 64-bit
• C & C++ Compiler: MinGW64
• Matlab Version: 9.4.0.813654 (R2018a)
• BLAS version: Intel MKL Version 2017.0.31 Product Build 20170606 for Intel(R) 64 architecture applications, CNR branch AVX2
  -LAPACK version: Intel MKL Version 2017.0.31 Product Build 20170606 for Intel(R) 64 architecture applications, CNR branch AVX2, Linear Algebra PACKage Version 3.7.0

[CCOLAMD] Variable `cs` set but not used

Describe the bug
A clear and concise description of what the bug is.

CCOLAMD/Source/ccolamd.c:1563:9: warning: variable ‘cs’ set but not used [-Wunused-but-set-variable]
1563 |     Int cs ;
     |         ^~                                       

To Reproduce
Steps to reproduce the behavior.

git clone
cd CCOLAMD
make

Expected behavior
A clear and concise description of what you expected to happen.

No warnings

Screenshots
If applicable, add screenshots to help explain your problem.

N/A

Desktop (please complete the following information):

• OS: Arch Linux
• compiler: gcc 9.3.0
• BLAS and LAPACK library, if applicable N/A
• CCOLAMD Version: latest from master

Additional context
Add any other context about the problem here.

N/A

broken makefile when specifying additional LDFLAGS

The following patch fixes the issue

diff --git a/SuiteSparse_config/SuiteSparse_config.mk b/SuiteSparse_config/SuiteSparse_config.mk
index 0a091882..c400ea5b 100644
--- a/SuiteSparse_config/SuiteSparse_config.mk
+++ b/SuiteSparse_config/SuiteSparse_config.mk
@@ -153,7 +153,7 @@ SUITESPARSE_VERSION = 5.6.0
     # It places its shared *.so libraries in SuiteSparse/lib.
     # Linux also requires the -lrt library (see below)
     LDLIBS ?= -lm
-    LDFLAGS += -L$(INSTALL_LIB)
+    override LDFLAGS += -L$(INSTALL_LIB)
 
     # NOTE: Use of the Intel MKL BLAS is strongly recommended.  The OpenBLAS can
     # result in severe performance degradation, in CHOLMOD in particular.

Does klu support multithread and multi-cores?

Why CHOLMOD symbolic factorization is noticeably slower when using GPUs?

I was wondering why the analysis phase of nd6k is 8 seconds when using the GPU code path, while it is only half a second otherwise. This is on a Tesla V100.

$ CHOLMOD_USE_GPU=1 ./cholmod_l_demo < nd6k/nd6k.mtx

---------------------------------- cholmod_l_demo:
cholmod version 3.0.13
SuiteSparse version 5.6.0
norm (A,inf) = 203.333
norm (A,1)   = 203.333
CHOLMOD sparse:  A:  18000-by-18000, nz 3457658, upper.  OK
CHOLMOD dense:   B:  18000-by-1,   OK
bnorm 1.99994
Analyze: flop 2.0028e+11 lnz 5.12026e+07
Factorizing A
CHOLMOD factor:  L:  18000-by-18000  supernodal, LL'.  nz 51837614  OK
nmethods: 1
Ordering: AMD     fl/lnz     3911.5  lnz/anz       14.8
ints in L:          243323, doubles in L:        73141163
factor flops 2.0028e+11 nnz(L)        51202639 (w/no amalgamation)
nnz(A*A'):         3457658
flops / nnz(L):    3911.5
nnz(L) / nnz(A):     14.8
analyze cputime:        8.3228
factor  cputime:         1.5911 mflop: 125872.2
solve   cputime:         0.1117 mflop:   1833.1
overall cputime:        10.0256 mflop:  19997.2
solve   cputime:         0.0583 mflop:   3514.8 (100 trials)
solve2  cputime:         0.0000 mflop:      0.0 (100 trials)
peak memory usage:          847 (MB)
residual (|Ax-b|/(|A||x|+|b|)): 6.45e-16 9.98e-16 
residual  1.4e-16 (|Ax-b|/(|A||x|+|b|)) after iterative refinement
rcond     3.0e-04


CHOLMOD GPU/CPU statistics:
SYRK  CPU calls          882 time   1.3239e-01
      GPU calls          219 time   1.8781e-01
GEMM  CPU calls          710 time   4.8436e-02
      GPU calls          219 time   1.0794e-03
POTRF CPU calls          217 time   1.2513e-02
      GPU calls            5 time   5.5199e-02
TRSM  CPU calls          217 time   3.8627e-02
      GPU calls            4 time   6.4623e-02
time in the BLAS: CPU   2.3196e-01 GPU   3.0872e-01 total:   5.4068e-01
assembly time   0.0000e+00    0.0000e+00

$ CHOLMOD_USE_GPU=0 ./cholmod_l_demo < nd6k/nd6k.mtx

---------------------------------- cholmod_l_demo:
cholmod version 3.0.13
SuiteSparse version 5.6.0
norm (A,inf) = 203.333
norm (A,1)   = 203.333
CHOLMOD sparse:  A:  18000-by-18000, nz 3457658, upper.  OK
CHOLMOD dense:   B:  18000-by-1,   OK
bnorm 1.99994
Analyze: flop 2.0028e+11 lnz 5.12026e+07
Factorizing A
CHOLMOD factor:  L:  18000-by-18000  supernodal, LL'.  nz 51837614  OK
nmethods: 1
Ordering: AMD     fl/lnz     3911.5  lnz/anz       14.8
ints in L:          243323, doubles in L:        73141163
factor flops 2.0028e+11 nnz(L)        51202639 (w/no amalgamation)
nnz(A*A'):         3457658
flops / nnz(L):    3911.5
nnz(L) / nnz(A):     14.8
analyze cputime:        0.5894
factor  cputime:         2.6333 mflop:  76057.6
solve   cputime:         0.1248 mflop:   1641.0
overall cputime:         3.3475 mflop:  59891.8
solve   cputime:         0.0438 mflop:   4671.7 (100 trials)
solve2  cputime:         0.0000 mflop:      0.0 (100 trials)
peak memory usage:          847 (MB)
residual (|Ax-b|/(|A||x|+|b|)): 5.44e-16 8.24e-16 
residual  1.4e-16 (|Ax-b|/(|A||x|+|b|)) after iterative refinement
rcond     3.0e-04


CHOLMOD GPU/CPU statistics:
SYRK  CPU calls         1101 time   2.8955e-01
      GPU calls            0 time   0.0000e+00
GEMM  CPU calls          880 time   1.5136e-01
      GPU calls            0 time   0.0000e+00
POTRF CPU calls          222 time   7.6078e-02
      GPU calls            0 time   0.0000e+00
TRSM  CPU calls          221 time   7.7946e-01
      GPU calls            0 time   0.0000e+00
time in the BLAS: CPU   1.2964e+00 GPU   0.0000e+00 total:   1.2964e+00
assembly time   0.0000e+00    0.0000e+00

Linking against Intel MKL BLAS recommended; OpenBLAS can cause 100x slowdown

For version 5.4, Suitesparse_config.mk recommended openblas. For version 5.6, intel mkl is now recommended and the config file looks like wants to link against intel openmp.

TL;DR is the cholmod performance degradation related to the threading library (pthreads vs GNU openmp vs intel openmp)? Can you explain a little more (or just link to a discussion about the issue). Does this issue affect version 5.4 when linked against openblas/pthreads?

Some background about why I'm curious about which threading library to use:

I am a "causal" user of suitesparse mostly as it can be used by other packages such as Sundials, numpy, scikit-umfpack, sparseqr, scikit-sparse, etc...

I've built my own Suitesparse shared libraries (and the downstream packages mentioned above) on linux systems (mostly ubuntu) for several years now - one set of libraries linked against openblas/pthreads and one linked against mkl/GNU openmp. Mostly I stick with openblas/pthreads as I get sufficient performance boost without the head aches related to trying to understand which thread library to use (or how).

However, after noting the (new) recommendation for Suitesparse 5.6 and subsequently trying to work out what to do about it, I've run across discussions like this or this as well as the intel mkl linking recommendations here.

The hobgoblin in my little mind is now screaming at me to be foolishly consistent and either link Suitesparse and all subsequent downstream packages that depend on it against GNU openmp or against intel openmp - but not both (mixed) and certainly not mixed with pthreads.

Is this consistent with your understanding about threading library choice with respect to Suitesparse?

Linux build issue

Building SuiteSparse-5.8.1 under Ubuntu 20.04 is failing with the linker complaining that libsuitesparseconfig is not found.

I think the problem is in SuiteSparse_config/SuiteSparse_config.mk. Changing line 361 to

LDLIBS += -L$(INSTALL_LIB) -lrt -Wl,-rpath=$(INSTALL_LIB)

(adding the library path) seems to fix the problem.

Ubuntu: sudo apt install libsuitesparse-dev instead of installing from source

Please add a note that Ubuntu users can just write

sudo apt install libsuitesparse-dev

No need of installing from source