Issue with solving sparse system with spsolve

[ivarlon]

I am having issues solving Au = b when I use the armadillo method spsolve(). I can solve the system if I use dense instead of sparse matrices and use the method solve(). To make matters really weird, I initially got spsolve to work, but it ate up all my 8 GBs of RAM. And then after some tries it refused to work entirely. Now it crashes every time, no matter how small I set the matrices A and B.

FWIW, I am on Windows. I get most Armadillo functionality to work, but I see that spsolve() uses the SuperLU library, and I am unsure if I have this installed.

[anderkve]

Hi @ivarlon!

I am having issues solving Au = b when I use the armadillo method spsolve(). I can solve the system if I use dense instead of sparse matrices and use the method solve(). To make matters really weird, I initially got spsolve to work, but it ate up all my 8 GBs of RAM. And then after some tries it refused to work entirely. Now it crashes every time, no matter how small I set the matrices A and B.

That's very strange...

I guess you've seen what the documentation says about the `solve' option, which can be "superlu" or "lapack":

https://arma.sourceforge.net/docs.html#spsolve

Have you tried setting it explicitly to "superlu"?

On my Ubuntu machine, if I run it with the default setting, or with explicitly choosing "superlu", it uses less than 1GB of memory. But if I swap to "lapack" it consumes all memory and it crashes (as expected).

One thing to try: run the command export OMP_NUM_THREADS=1 before running your code. The superlu solver is parallelised with OpenMP (at least my version is), and depending on how it is parallelised, running with many threads might require more memory.

[anderkve]

Btw, if you share a link to your code on GitHub, I might have time to take a quick look tonight or tomorrow.

[ivarlon]

Thanks for the suggestions. It crashed if I set the solver explicitly to SuperLU, but if I set it to Lapack it works for large enough steps h. But if I use h=.005 with 201*201 points it doesn't have enough RAM.

[anderkve]

OK. How large step sizes do you have to use? Do you still get reasonable-looking results? If so, it's fine to use that and just explain this limitation in the report.

The other options I can think of is trying to uninstall and reinstall armadillo. Alternatively, implement your own solver -- my suggestion in that case would be to go for e.g. the easiest iterative method we discussed in the course, which on component form should be pretty straightforward to implement.

[ivarlon]

I'm using twice what's suggested, h=.01, but I could probably reduce it a little bit. Results look unspectacular so far... I'll see if reinstalling armadillo is viable. Would one get extra points for implementing a self written solver?

[anderkve]

I'm using twice what's suggested, h=.01

Yeah, that probably still gives quite reasonable results (though I haven't checked myself.)

Would one get extra points for implementing a self written solver?

We haven't discussed explicitly rewarding extra points for that, but it of course would contribute positively towards the overall impression of the work. But writing a good report is certainly more important than writing your own solver, so if you are short on time I'd focus on writing the report (e.g. with the results you get with h=0.01) before attempting a new solver.