我正在计算一个线性系统Ax=b的解,其中A是一个大型(通常为200,000行和列数)稀疏矩阵,b是一个约100列的稀疏矩阵。当我在Windows系统上运行我的代码(Python 2.7,scipy 0.14.0)时,以下命令会出现问题:
异常在Tkinter回调中 跟踪(最近的调用最先): 文件“/usr/lib/python2.7/lib-tk/Tkinter.py”,第1489行,在__call__中 返回self.func(* args) 文件“...”,第1533行,在mmvConstruction中 ... 文件“...”,第1555行,在modes_cb中 Temp = spsolve(k [inter] [:,inter] .tocsc(),k [inter] [:,exter] .tocsc()) 文件“/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/linsolve.py”,第151行,在spsolve中 Afactsolve = factorized(A) 文件“/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/linsolve.py”,第352行,在factorized中 umf.numeric(A) 文件“/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/umfpack/umfpack.py”,第450行,在numeric中 umfStatus [status]))) 运行时错误:<function umfpack_di_numeric at ...>失败,UMFPACK_ERROR_out_of_memory 更新:仍在努力寻找解决方案......看起来 Linux Mint 上的最新版本 BLAS 相当古老:1.8.2。在 Windows 上,我使用 BLAS 1.9.1。当使用此处提供的
from scipy.sparse.linalg import spsolve
...
Temp = spsolve(A.tocsc(),b.tocsc())
程序运行流畅,需要约7GB的RAM内存。
在Linux系统上(同样的CPU,同样的RAM内存:64GB,Linux Mint 17.3,Python 2.7,Scipy 0.13.3),使用完全相同的代码和矩阵需要超过20GB的RAM内存,并且会崩溃并显示以下错误信息:
<function umfpack_di_numeric at ...> failed with UMFPACK_ERROR_out_of_memory
(请参见1)
由于此错误与操作系统有关,我排除了与矩阵A和b有关的任何问题(与本文中提到的某些解决方案不同),并试图找到特定于Linux的解决方法...但我不知道从哪里开始...是否有人有任何想法?为什么这样的问题会特定于Linux系统?
请查看完整的错误信息如下:异常在Tkinter回调中 跟踪(最近的调用最先): 文件“/usr/lib/python2.7/lib-tk/Tkinter.py”,第1489行,在__call__中 返回self.func(* args) 文件“...”,第1533行,在mmvConstruction中 ... 文件“...”,第1555行,在modes_cb中 Temp = spsolve(k [inter] [:,inter] .tocsc(),k [inter] [:,exter] .tocsc()) 文件“/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/linsolve.py”,第151行,在spsolve中 Afactsolve = factorized(A) 文件“/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/linsolve.py”,第352行,在factorized中 umf.numeric(A) 文件“/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/umfpack/umfpack.py”,第450行,在numeric中 umfStatus [status]))) 运行时错误:<function umfpack_di_numeric at ...>失败,UMFPACK_ERROR_out_of_memory 更新:仍在努力寻找解决方案......看起来 Linux Mint 上的最新版本 BLAS 相当古老:1.8.2。在 Windows 上,我使用 BLAS 1.9.1。当使用此处提供的
test_numpy.py
文件:https://gist.github.com/osdf/3842524#file-test_numpy-py时,我注意到 Linux 和 Windows 之间存在非常显著的差异:Linux:版本 1.8.2,maxint 9223372036854775807,dot:0.76 s - Windows:版本 1.9.1,maxint 2147483647,dot:0.037 s。我正在调查是否在 Linux 上使用 OPENBLAS 可以解决这个问题......
更新2: 我意识到问题可能与硬件有关。实际上,一台较旧的PC,在相同的Linux Mint发行版(Rosa 17.3)上安装了完全相同的库,提供了更加令人满意的结果。第一个更新中提到的基准测试在这台旧PC上为:Linux:版本1.8.2,maxint 9223372036854775807,dot: 0.054秒。
apt-get install liblapack-dev
。关于 scipy,我仅安装了apt-get install python-scipy
而没有进行任何重新编译。 - Alain