适用于稀疏Hermitian矩阵的Python LDLT分解,有没有?

时间:2019-07-08 15:27:33

标签: python matrix parallel-processing sparse-matrix

我有一些大的(稀疏,复杂的Hermitian矩阵)(对于N = 10,000到N = 36,000,000,通常是非奇数的),对此我有频谱切片问题。具体来说,我需要知道正特征值的确切数量。

我需要稀疏 LDLT分解-有吗?理想情况下,它将是一种多边算法并且具有很好的并行性,并且可以选择仅计算D而不计算上三角或置换矩阵。

我目前在Matlab中使用ldl()。这仅适用于实数矩阵,因此我需要创建一个更大的实数矩阵。另外,它总是计算L和D。我需要一个更好的算法来配合64GB RAM。我希望Python将更具可定制性。 (如果是这样,我将学习Python。)我应该补充:每个节点可以获得64GB的RAM,并且可以获取6个节点。即使只有一台具有64GB RAM的计算机,我也想停止浪费存储L的RAM,而只是删除它。

也许有人为MUMPS(多边大规模并行求解器)编写了Python前端?

我将使用非并行的LDLT Python版本,因为我的很多研究都涉及许多中等大小的矩阵。

1 个答案:

答案 0 :(得分:1)

  

我需要一个更好的算法以适合64GB RAM。我希望Python可以更自定义。 (如果是这样,我将学习Python。)

如果可能的话:

|>>> ( 2. * 8 ) * 10E3 ** 2 / 1E12            # a 64GB RAM can store matrices ~1.6 GB
0.0016                                        #        the [10k,10k] of complex64
|                                             #        or  [20k,20k] of    real64
|>>> ( 2. * 8 ) * 63E3 ** 2 / 1E12            # a 64GB RAM can store matrices in-RAM
0.063504                                      #        max [63k,63k] of type complex
|                                             #        but
|>>> ( 2. * 8 ) * 36E6 ** 2 / 1E12            #        the [36M,36M] one has
20736.0                                       # ~ 21PB of data
+0:00:09.876642                               #        Houston, we have a problem
#---------------------------------------------#--------and [2M7,2M7] has taken    
                                                                   ~ month
                                                                  on HPC cluster

研究需求很明确,但没有这样的语言(无论是Matlab,Python,汇编程序,Julia还是LISP)都可以将 21 PB的数据存储到仅64 GB的空间中。物理RAM存储,以使复杂的矩阵(具有给定的比例)特征值计算成为可能并尽可能快。我的意思是,将数据从RAM中的计算“卸载”到任何形式的RAM之外的存储都非常昂贵(大约慢+ 1E2〜+ 1E5个数量级),以至于任何这样的情况计算过程将产生仅“读取” 21 PB元素数据的年龄。

如果您的研究有足够的资金或赞助来使用非常特定的计算设备基础结构,则可能会有一些技巧来处理这种数量的堆,但不要期望将21 PB的蠕虫(数据)放入64 GB的大型磁盘中(嗯,相当小)可以“免费”。

您可能会因为许多其他原因和/或动机而喜欢使用Python,但这并不是由于更便宜,更快速的HPC级并行计算,也没有因为在64GB设备中轻松处理21PB数据,或进行任何形式的an没稀疏矩阵操作的主要和巨大[TIME]域附加成本是可见的,但在计算中却使用。我敢说要使xTB稀疏矩阵处理在不到1E2 [min]而不是2E3的时间内产生结果,我知道我要增加 [PSPACE] 数据缩放并同时缩短通常 [EXPTIME] 的处理时间...真正的计算复杂性的地狱角 ...稀疏矩阵表示通常会带来更多的头痛(至少在[SPACE]中更是如此,随着新的惩罚类型的出现,在[TIME]中更糟,更糟糕的是)而不是帮助至少享受一些潜在的{{ 1}}-节省

鉴于参数的范围,我可以肯定地说,即使算法部分也无济于事,甚至量子计算设备的承诺仍会存在,因为我们的预期寿命无法将如此庞大的参数空间扩大到QC退火炉中QC社区当前正在使用的基于非结构化的量子驱动的最小化器(处理),用于将参数块的任何合理的长(短持续时间)序列转换为(有限物理尺寸)量子位场问题增强过程,谢谢LLNL等人的研究创新。

对不起,似乎没有魔力在附近。

使用适用于MUMPS的python前端不会改变游戏的HPC问题,但是,如果您想使用它,可以的,其中有几个可用。

高效的HPC级数字运算仍然是[处理时间] x [(无论如何)数据表示的有效存储和检索]乘积问题的根本原因。

希望您将获得并享受适当的舒适度组合(pythonic用户渴望留在其中)以及您希望拥有的HPC级性能(无论是哪种类型的后端)。