# Reality check: How useful exactly are SuiteSparse and LDLFactorizations' LDLT?

**URL:** https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607
**Category:** General Usage
**Created:** [April 17, 2022, 6:58pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607 "2022-04-17T18:58:02Z")
**Posts on this page:** 12
**Page:** 1

<div class="post-metadata">

### Author: ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [April 17, 2022, 6:58pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/1 "2022-04-17T18:58:02Z")

</div>

[https://github.com/JuliaSmoothOptimizers/LDLFactorizations.jl/issues/101](https://github.com/JuliaSmoothOptimizers/LDLFactorizations.jl/issues/101)

I realize that calling for a native implementation of a multi-frontal or supernodal factorization  
is a tall order: people spend decades of their life on these efforts. But I think it would be a useful  
addition, truly empowering for Julia devotees who have to deal with large sparse matrices.  
Perhaps a good target for some funding to make it happen!

---

<div class="post-metadata">

### Author: ![goerch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerch/32/29122_2.png) [@goerch](https://discourse.julialang.org/u/goerch)
#### Post date: [April 17, 2022, 7:14pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/2 "2022-04-17T19:14:01Z")

</div>

Sorry, I don’t understand: what exactly is the problem interfacing fast external codes (we are doing it all the time AFAIU)?

---

<div class="post-metadata">

### Author: ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [April 17, 2022, 8:03pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/3 "2022-04-17T20:03:18Z")

</div>

Codes such as HLS or SuiteSparse cannot work directly with CSC (or other common format) matrices. So, the matrix is converted into internal representation recognized by the library. Hence, suddenly one has doubled the amount of storage because both the original sparse matrix and the internal rep are held in memory at the same time.

---

<div class="post-metadata">

### Author: ![goerch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerch/32/29122_2.png) [@goerch](https://discourse.julialang.org/u/goerch)
#### Post date: [April 17, 2022, 8:06pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/4 "2022-04-17T20:06:48Z")

</div>

OK, I can see how this is a problem memory wise, but is it dominating the computation (that would be surprising for me)?

---

<div class="post-metadata">

### Author: ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [April 17, 2022, 8:41pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/5 "2022-04-17T20:41:11Z")

</div>

As long as you have double the amount of memory that you actually need, the computation can be unaffected by the increased amount of memory requested. However,  
it is quite easy to get an “Out of memory” error when using SuiteSparse. Then the speed  
of the computation is immaterial. 😉

---

<div class="post-metadata">

### Author: ![goerch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/goerch/32/29122_2.png) [@goerch](https://discourse.julialang.org/u/goerch)
#### Post date: [April 17, 2022, 8:49pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/6 "2022-04-17T20:49:16Z")

</div>

> [@PetrKryslUCSD](#):
>
> As long as you have double the amount of memory that you actually need, the computation can be unaffected by the increased amount of memory requested

I see. But this sounds more like a call to support more memory layouts in the involved packages then (I wondered about the missing support for CSR and COO already)?

---

<div class="post-metadata">

### Author: ![mtanneau](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mtanneau/32/17787_2.png) [@mtanneau](https://discourse.julialang.org/u/mtanneau)
#### Post date: [April 17, 2022, 9:22pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/7 "2022-04-17T21:22:39Z")

</div>

When dealing with sparse factorizations, it is typically the case that the factors require a lot (as in, a LOT) more memory than the initial matrix.  
Thus, while it is correct that calling SuiteSparse’s LDLt or Cholesky will duplicate the input data, this increase in memory is often negligible when compared to how much memory you use for the factorization itself.

I use LDLFactorizations inside the LP solver [Tulip.jl](https://github.com/ds4dm/Tulip.jl) to solve KKT systems, when the arithmetic is anything other than `Float64`. It’s great to be able to do that out of the box.

That being said: most of the problems out there are in `Float64`. There are amazing libraries (like HSL, Pardiso, Mumps, etc…) with decades of development that we can already use, at the price of a minimal overhead. Unless a large share of user start solving linear systems in “exotic” arithmetic, I don’t see the need for a julia-native sparse factorization library.  
More specifically: I would not advise anyone to start such an endeavor, but it someone does I’ll happily use it.

---

<div class="post-metadata">

### Author: ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [April 17, 2022, 10:01pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/8 "2022-04-17T22:01:29Z")

</div>

> [@mtanneau](#):
>
> When dealing with sparse factorizations, it is typically the case that the factors require a lot (as in, a LOT) more memory than the initial matrix.  
> Thus, while it is correct that calling SuiteSparse’s LDLt or Cholesky will duplicate the input data, this increase in memory is often negligible when compared to how much memory you use for the factorization itself.

This is a good point. Nevertheless, memory not used is memory available.

---

<div class="post-metadata">

### Author: ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [April 17, 2022, 10:53pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/9 "2022-04-17T22:53:14Z")

</div>

> [@mtanneau](#):
>
> That being said: most of the problems out there are in `Float64` . There are amazing libraries (like HSL, Pardiso, Mumps, etc…) with decades of development that we can already use, at the price of a minimal overhead.

Also, the keyword is oftern “we can already use”. Most of these libraries have heavy dependencies which make installation on some architectures a serious undertaking. PETSC, MUMPS, HLS, … Try to install these on Windows… With Julia one can get used to the idea of write once, run anywhere, but these packages bust that wide open.

---

<div class="post-metadata">

### Author: ![Gravlax](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@Gravlax](https://discourse.julialang.org/u/Gravlax)
#### Post date: [April 20, 2022, 3:58pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/10 "2022-04-20T15:58:33Z")

</div>

I think one issue is that efficient sparse direct factorisations actually rely on CSR format while other sparse operations (matrix-vector product) rely on CSC. So, even if one codes up a (faster?) Cholesky factorisation than Cholmod in Julia, I would expect that conversions steps (CSC to CSR, or even COO to CSC to CSR) will still be needed. I’m far from being an expert but I do use Suitesparse. I usually sparse from COO (triplets), this converts it automatically to CSC. Then (I guess) it 's internally converted to CSR prior to factorization. It would be nice to avoid some steps but are they avoidable?

---

<div class="post-metadata">

### Author: ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)
#### Post date: [April 20, 2022, 4:18pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/11 "2022-04-20T16:18:38Z")

</div>

Row-based storage of the sparse matrix is better for parallel execution of matrix vector products. However, I believe that Suitesparse use a column-based storage. CSparse definitely does.

---

<div class="post-metadata">

### Author: ![Gravlax](https://avatars.discourse-cdn.com/v4/letter/g/dbc845/32.png) [@Gravlax](https://discourse.julialang.org/u/Gravlax)
#### Post date: [April 20, 2022, 5:57pm UTC](https://discourse.julialang.org/t/reality-check-how-useful-exactly-are-suitesparse-and-ldlfactorizations-ldlt/79607/12 "2022-04-20T17:57:37Z")

</div>

OK, I got all mixed up 😃  
Looks like UMFPACK and Cholmod do use CSC, it’s Pardiso that uses CSR (and variants in intel Pardiso).
