Python 稀疏 Hermitian 矩阵的 LDLT 分解，有吗？
A Python LDLT factorization for sparse Hermitian matrices, is there one?
我有一些大的（N×N，对于 N=10,000 到 N=36,000,000）稀疏、复杂、Hermitian 矩阵，通常是非奇异的，我有一个光谱切片问题。具体来说，我需要知道正特征值的确切数量。
我需要一个 sparse LDLT 分解——有吗？理想情况下，它将是一个多前沿算法并且并行化得很好，并且可以选择只计算 D 而不是上三角矩阵或置换矩阵。
我目前在 Matlab 中使用 ldl()。这仅适用于实数矩阵，因此我需要创建一个更大的实数矩阵。此外，它总是计算 L 和 D。我需要一个更好的算法来适应 64GB RAM。我希望 Python 将更加可定制。 （如果是这样，我会学习Python。）我应该补充：我可以获得每个节点64GB RAM，并且可以获得6个节点。即使是一台 64GB RAM 的机器，我也不想浪费 RAM 存储 L 只是为了删除它。
也许有人为 MUMPS（MUltifrontal 大规模并行求解器）编写了 Python 前端？
我会使用非并行 Python 版本的 LDLT，因为我的很多研究都涉及许多中等大小的矩阵。
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 存储的 space 中，以使复杂矩阵（具有这种给定规模）的特征值计算成为可能并尽可能快。我的意思是，从 in-RAM 计算到任何形式的 out-of-RAM 存储的 "off-loading" 数据非常昂贵（大约 ~ +1E2 ~ +1E5 ~ 慢几个数量级）以至于任何此类计算过程都会产生第一个 "reading through" 21 PB 元素数据的年龄。
如果您的研究有资金或赞助来使用非常具体的计算设备基础设施，可能会有一些技巧来处理这些大量的数字，但不要指望将 21 PB 的蠕虫（数据）放入 64 GB 大（嗯，相当小）可以 "for free".
由于许多其他原因 and/or 动机，您可能会喜欢 Python，但不是因为便宜而更快 HPC-grade parallel-computing，也不是因为可以轻松处理 21PB 的数据64GB 设备中的数据，也不是为了消除 sparse-matrix 操作的主要和巨大的 [TIME] 域 add-on 成本，但在计算中使用时可见。使一些 xTB sparse-matrix 处理可行以在小于 1E2 [分钟] 而不是 2E3 内产生结果，我敢说我知道增加 [PSPACE][ 是多么困难=40=]-数据缩放，同时缩短经常[EXPTIME]的处理时间...真正的Hell-corner computational-complexity ...其中 sparse-matrix 表示通常会造成更多麻烦（同样，在 [SPACE] 和更多，好吧，在 [TIME] 中更糟出现新类型的惩罚）而不是帮助至少享受一些潜在的 [PSPACE]-储蓄
鉴于参数的范围，我可以肯定地打赌，即使是算法部分也无济于事，甚至 Quantum-Computing 设备的承诺将在我们的预期寿命中保持不变，无法增加如此巨大的空间 parameter-space 进入 QC annealer-based 非结构化 quantum-driven 最小化器（处理），用于任何相当长（持续时间短）的序列 parameter-blocks 转换为（有限的物理尺寸）qubit-field 问题 augmentation-process，由于 LLNL 等人的研究创新，QC 社区目前正在使用它。
抱歉，附近似乎没有这种魔法。
使用 MUMPS 可用的 python 前端不会改变游戏的 HPC-problem，但如果您想使用它，是的，有几个可用的前端。
规模上的高效 HPC-grade number-crunching 仍然是 [processing-time ] x [（随便）[=70= 的乘积问题的 root-cause ]的高效存储和检索].
希望您将获得并享受舒适（pythonic 用户热衷于留在其中）和您希望的 HPC-grade 性能（任何类型的后端）的正确组合有。
我有一些大的（N×N，对于 N=10,000 到 N=36,000,000）稀疏、复杂、Hermitian 矩阵，通常是非奇异的，我有一个光谱切片问题。具体来说，我需要知道正特征值的确切数量。
我需要一个 sparse LDLT 分解——有吗？理想情况下，它将是一个多前沿算法并且并行化得很好，并且可以选择只计算 D 而不是上三角矩阵或置换矩阵。
我目前在 Matlab 中使用 ldl()。这仅适用于实数矩阵，因此我需要创建一个更大的实数矩阵。此外，它总是计算 L 和 D。我需要一个更好的算法来适应 64GB RAM。我希望 Python 将更加可定制。 （如果是这样，我会学习Python。）我应该补充：我可以获得每个节点64GB RAM，并且可以获得6个节点。即使是一台 64GB RAM 的机器，我也不想浪费 RAM 存储 L 只是为了删除它。
也许有人为 MUMPS（MUltifrontal 大规模并行求解器）编写了 Python 前端？
我会使用非并行 Python 版本的 LDLT，因为我的很多研究都涉及许多中等大小的矩阵。
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 存储的 space 中，以使复杂矩阵（具有这种给定规模）的特征值计算成为可能并尽可能快。我的意思是，从 in-RAM 计算到任何形式的 out-of-RAM 存储的 "off-loading" 数据非常昂贵（大约 ~ +1E2 ~ +1E5 ~ 慢几个数量级）以至于任何此类计算过程都会产生第一个 "reading through" 21 PB 元素数据的年龄。
如果您的研究有资金或赞助来使用非常具体的计算设备基础设施，可能会有一些技巧来处理这些大量的数字，但不要指望将 21 PB 的蠕虫（数据）放入 64 GB 大（嗯，相当小）可以 "for free".
由于许多其他原因 and/or 动机，您可能会喜欢 Python，但不是因为便宜而更快 HPC-grade parallel-computing，也不是因为可以轻松处理 21PB 的数据64GB 设备中的数据，也不是为了消除 sparse-matrix 操作的主要和巨大的 [TIME] 域 add-on 成本，但在计算中使用时可见。使一些 xTB sparse-matrix 处理可行以在小于 1E2 [分钟] 而不是 2E3 内产生结果，我敢说我知道增加 [PSPACE][ 是多么困难=40=]-数据缩放，同时缩短经常[EXPTIME]的处理时间...真正的Hell-corner computational-complexity ...其中 sparse-matrix 表示通常会造成更多麻烦（同样，在 [SPACE] 和更多，好吧，在 [TIME] 中更糟出现新类型的惩罚）而不是帮助至少享受一些潜在的 [PSPACE]-储蓄
鉴于参数的范围，我可以肯定地打赌，即使是算法部分也无济于事，甚至 Quantum-Computing 设备的承诺将在我们的预期寿命中保持不变，无法增加如此巨大的空间 parameter-space 进入 QC annealer-based 非结构化 quantum-driven 最小化器（处理），用于任何相当长（持续时间短）的序列 parameter-blocks 转换为（有限的物理尺寸）qubit-field 问题 augmentation-process，由于 LLNL 等人的研究创新，QC 社区目前正在使用它。
抱歉，附近似乎没有这种魔法。
使用 MUMPS 可用的 python 前端不会改变游戏的 HPC-problem，但如果您想使用它，是的，有几个可用的前端。
规模上的高效 HPC-grade number-crunching 仍然是 [processing-time ] x [（随便）[=70= 的乘积问题的 root-cause ]的高效存储和检索].
希望您将获得并享受舒适（pythonic 用户热衷于留在其中）和您希望的 HPC-grade 性能（任何类型的后端）的正确组合有。