umfpack reports out of memory for relatively small problem during factorization

[SteveMaas1978]

Describe the bug I have a well-conditioned, symmetric matrix of 86K equations and 65M nonzeroes. During factorization (umfpack_di_numeric) the return value is -1, which apparently means out-of-memory. Digging a bit deeper through the umfpack code, it eventually fails when growing the front. But it's not failing due to an actual memory allocation attempt. Instead, some internal logic apparently decides that there is not enough memory and just quits, which seems odd.

To be clear, I just started with umfpack, and so far, have only been using the out-of-the-box settings. Not sure if there are any configuration settings I need to tweak. Also, smaller matrices are working fine and the solution looks correct. Therefore, I don't think there is an issue with how I'm calling umfpack.

To Reproduce Unfortunately, can't share code since it's implemented in a bigger package (FEBio). I could share the matrix if that would help?

Expected behavior I have 128Gb on my machine, which should be plenty for a problem of this size. For comparison, the MKL pardiso solver solves the same problem without any issues.

Desktop (please complete the following information):

• OS: Windows
• compiler: Visual Studio
• BLAS and LAPACK library: MKL
• Version: built from dev branch

(This issue was also reproduced on a mac)

Thanks in advance for any insight!

Steve

[DrTimothyAldenDavis]

Your matrix problem is likely too large for the 32 bit umfpack methods. Use the dl functions instead.

[SteveMaas1978]

Thanks! That did it!

If you don't mind that I ask an unrelated question in the same thread, are there any configuration settings that we should look at that would impact the performance. After doing a comparison with MKL pardiso, we get the following stats for the above-mentioned problem:

MKL Pardiso: 3 sec, mem 1.7 Gb. umfpack: 24 sec, mem 7.5 Gb.

I want to point out that I'm using MKL blas and lapack for umfpack as well, so both umfpack and MKL pardiso should be using the same versions of these libraries.

Any tips that would get the performance closer to pardiso would be greatly appreciated.

Thanks,

Steve

[DrTimothyAldenDavis]

It's hard to say. If the matrix is roughly symmetric in pattern with a 'healthy' diagonal (enough nonzeros that are not tiny) then UMFPACK should select its symmetric strategy; otherwise it would select the unsymmetric strategy. I would need to know more about the matrix; sometimes it's better to select the strategy yourself.

Also the fill-reducing ordering for the 2 methods might be different.

Are you timing just the factorization? Or the ordering as well?

UMFPACK can use CHOLMOD's interface to METIS, and sometimes that gives a much better ordering.

[SteveMaas1978]

Thanks for the feedback! This will get me started. It sounds like the symmetric vs unsymmetric strategies and the fill-reducing ordering might be good places to start experimenting.

Regarding your question, the timings include everything: ordering, factorization, and 3 back solves (and a bit of overhead for assembling the matrix).

I'll definitely look into METIS as well. Thanks again!

Best,

Steve