python - 用于稀疏 Hermitian 矩阵的 Python LDLT 分解，有吗？

Question

我有一些大的(N×N，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(MUltifrontal 大规模并行求解器)编写了一个 Python 前端？

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

Answer 1

I need a better algorithm to fit with 64GB RAM. I am hoping Python will be more customizable. (If so, I will learn 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 元素数据的年龄。

如果您的研究有资金或赞助来使用相当特定的计算设备基础设施，则可能有一些技巧来处理如此大量的数字，但不要期望收到放入 64 GB 大容量的 21 PB 蠕虫(数据) (嗯，相当小)可以“免费”。

您可能会因为许多其他原因和/或动机而喜欢 Python，但不是因为更便宜但更快的 HPC 级并行计算，也不是因为可以轻松处理 64GB 设备内的 21PB 数据，也不是因为任何类型的毁灭性操作。主要而巨大[TIME] - 稀疏矩阵操作的域附加成本是可见的，但在计算中使用期间。在使一些 xTB 稀疏矩阵处理变得可行以在小于 1E2 [min] 而不是 2E3 的时间内产生结果后，我敢说我知道增加 [PSPACE] 是多么困难。 -数据缩放和缩短经常[EXPTIME] 同时处理持续时间...真正的计算复杂性的 hell 角落...稀疏矩阵表示通常会带来更多的麻烦(同样，在[SPACE]以及更多，好吧，更糟糕的是[TIME](随着新型惩罚的出现)，而不是帮助至少享受一些潜在的[PSPACE] -储蓄

考虑到参数的范围，我可以肯定地打赌，即使是算法部分也无济于事，甚至量子计算设备的 promise 也将在我们的预期生命周期中保留，无法将如此巨大的参数空间扩展到QC退火器中基于非结构化量子驱动的最小化器(处理)，用于将任何相当长(短持续时间)的参数 block 序列转换为(有限的物理尺寸)量子位场问题增强过程，正如 QC 社区目前正在使用的那样，谢谢LLNL 等人的研究创新。

抱歉，附近似乎没有这样的魔法。

使用 MUMPS 的可用 Python 前端不会改变游戏的 HPC 问题，但如果您想使用它，是的，有几个可用的前端。

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

希望您能够获得并享受您希望拥有的舒适性(Pythonic 用户热衷于留在其中)和 HPC 级性能(任何类型的后端)的正确组合。