Home My Page Projects PaStiX
Summary Activity Forums Lists Docs News Files

Forum: help

Monitor Forum | Start New Thread Start New Thread
RE: Memory leak with repeated calls to NUMFACT? [ Reply ]
By: Pierre Ramet on 2016-01-29 08:25
Thank you for trying our solver and for sending us this report.
Could you enable verbose option with IPARM_VERBOSE set to API_VERBOSE_YES and send us the output in order to identify the step where you get the sigkill ?
Best regards,

Memory leak with repeated calls to NUMFACT? [ Reply ]
By: Guo Luo on 2016-01-26 14:50
Dear Pastix developers,

I am using pastix 5.2.1 to solve a 1D Helmholtz equation

-\Delta u + \mu u = f

for different values of \mu (> 0) and different right-hand sides f. Since the matrix equations resulting from discretization have the same structure, my code employs the following strategy to solve the problem:

initialize the pastix solver with
perform symbolic factorization with
for each value of \mu:
numerically factorize the matrix corresponding to -\Delta u + \mu u with
for each right-hand side f:
solve the matrix equation corresponding to -\Delta u + \mu u = f with
end for
end for

This strategy works fine, except that it always gets a signal 9 (killed) after being launched for a while. I checked with my system administrator, and he said the problem is most likely caused by exhaustion of physical memories. Since I never had this problem when the value of \mu is fixed (i.e. when the *same* matrix equation is solved with different right-hand sides f), I believe it is the repeated calls to NUMFACT that caused the problem. I tried monitoring the memory usage of the code (by reading "/proc/self/statm"), and found that after each call to NUMFACT the memory usage increases. I tried cleaning up the solver with


after each call to NUMFACT, but it didn't help - the memory usage still increases steadily. Based on these observations, I suspect that there might be some memory leak hidden in the step of NUMFACT, which can't be recovered by the calls to CLEAN. It would be great if you can help look into this issue and find a fix. Thanks a lot.

By the way, I tried solving the same problem with the same strategy using the MUMPS package, and it worked fine. Calls to memory monitoring subroutines show that the memory usage remains steady throughout the entire run. The only reason I chose to use pastix, not MUMPS, to solve the problem is that pastix supports 64-bit memory indexing, while MUMPS doesn't. So it would be great if you can help me find a solution.

Best Regards,
Guo Luo