I am trying to solve a system of equations (A x = b) for 3D heat diffusion (i.e. each equation has at most 7 terms not including the constant b term) using UMFPACK with boost numeric bindings to C++.e.g.:namespace umf = boost::numeric::bindings::umfpack;umf::umf_solve(A,x,b);I can populate the A matrix and the b vector for a 200K+ set of equations while using roughly 200MB of memory. Then while in the UMFPACK routines, the memory used by my program jumps up to 2.3GB+.Furthermore, at some point above ~211K equations, the routine passes back all zeros for x, without throwing an error. I assume this is related to some kind of memory limit.This is the same on every machine I've tested on (my MacBook, my Ubuntu VM, and a node on a Red Hat supercomputer).My questions are:Why is UMFPACK returning zeros without an error?Why does UMFPACK require so much memory?What options do I have for solving the system for larger sets of equations?
How Do I solve large systems given UMFPACK memory limitations?
linear algebra;c++;blas;memory management;umfpack
I can't give you a good answer for 1, but I can give you decent answers for 2 and 3.I'm not terribly familiar with the Boost interface to UMFPACK. In the C interface, normally, you call UMFPACK routines that will allocate memory. If the memory cannot be allocated because there is not enough free memory available, UMFPACK will return a null pointer. You can then test for routines returning null pointers to handle errors; this approach is standard in C programming. Looking at the documentation, it seems like you'll have to check the return values of each function; it doesn't look like the library throws any exceptions. If you don't check return values, and only examine the solution returned by UMFPACK, that could explain the behavior you observe.UMFPACK is a sparse direct solver; it carries out a sparse LU factorization of your $A$ matrix. As $A$ becomes larger, more of the entries of the LU factorization become structurally nonzero -- they are filled in, and this phenomenon is called fill-in -- and structurally nonzero entries are represented explicitly in memory because they could be numerically nonzero. Fill-in is why you run out of memory; memory limitations tend to make sparse direct solvers unattractive for problems exceeding around 100K unknowns.Use an iterative method for solving sparse linear equations instead of a sparse direct method. These methods don't necessarily require you to explicitly store $A$; they typically only require a method for calculating the matrix-vector product $Ax$ for any $x$. For best results, you should supply a preconditioner for the iterative method. For a diffusion problem, multigrid is a good preconditioner; multigrid methods are also worth using without a preconditioner for diffusion equations. Other people can probably offer better advice on iterative methods to use for this type of problem.