scipy.sparse.linalg.spsolve удивительное поведение для больших разреженных матриц в системах Linux

Question

Я вычисляю решение линейной системы Ax = b с A большой (обычно 200 000 строк и столбцов для связанной плотной матрицы) разреженной матрицы и ba разреженная матрица около 100 столбцов.

Когда я запускаю мой код на системах Windows, (Python 2,7, SciPy 0.14.0), следующую команду

from scipy.sparse.linalg import spsolve 
... 
Temp = spsolve(A.tocsc(),b.tocsc()) 

проходит гладко и требует около 7 Гб оперативной памяти.

Запуск точно такой же код с точно такими же матрицами на системах Linux (CPU же, такое же количество оперативной памяти: 64 Гб, Linux Mint 17.3, Python 2.7, SciPy 0.13.3) требует более 20 ГБ оперативной памяти, и он выходит из строя со следующим сообщением об ошибке:

<function umfpack_di_numeric at ...> failed with UMFPACK_ERROR_out_of_memory (см 1)

из-за этой ошибки я я исключал любую проблему, касающуюся матриц A и b (в отличие от некоторых из упомянутых решений in this post), и я пытаюсь найти исправление, характерное для Linux ... Но я не знаю, где чтобы начать ... Кто-нибудь будет иметь представление о том, что происходит? И почему такая проблема будет специфичной для систем Linux?

Вы найдете ниже сообщение об ошибке полной:

Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 1489, in __call__ return self.func(*args) File "...", line 1533, in mmvConstruction ... File "...", line 1555, in modes_cb Temp = spsolve(k[inter][:,inter].tocsc(),k[inter][:,exter].tocsc()) File "/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/linsolve.py", line 151, in spsolve Afactsolve = factorized(A) File "/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/linsolve.py", line 352, in factorized umf.numeric(A) File "/usr/lib/python2.7/dist-packages/scipy/sparse/linalg/dsolve/umfpack/umfpack.py", line 450, in numeric umfStatus[status])) RuntimeError:<function umfpack_di_numeric at ...> failed with UMFPACK_ERROR_out_of_memory

Update: до сих пор пытаются выяснить, решение ... кажется, что последняя версия BLAS на Linux Монетный двор довольно старый: 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, точка: 0.76 s - Окно: версия 1.9.1, MaxInt 2147483647, точкой: 0,037 с. Я изучаю, может ли OPENBLAS на Linux быть решением этой проблемы ...

Обновление 2: Я понял, что проблема может быть связана с оборудованием. Действительно, более старый ПК с одинаковыми библиотеками в одном дистрибутиве Linux Mint (Rosa 17.3) обеспечивает гораздо более удовлетворительные результаты. Тест, упомянутый в первом обновлении, дает на этом старом ПК: Linux: версия 1.8.2, maxint 9223372036854775807, точка: 0,054 с.

Answer 1

Ну, после тщательных расследований я теперь убежден, что проблема, которую я имел, связана с тем, что Linux Mint (Rosa 17.3) не может быть оптимизирован для самых последних процессоров.

Сравнение, упомянутое в обновлении моего сообщения, подчеркнуло, что установка программного обеспечения верна.Затем я установил Fedora 23 на ПК, установка последовательно:

• libblas
• питона
• питон-SciPy

Тогда я побежал точно такой же код с теми же матрицами и не было никаких проблем: потребление ОЗУ ограничивалось приблизительно 7 ГБ, аналогично тому, что наблюдалось в системах Windows.