我有一个矩阵，其大小为（假设甚至）。在矩阵的每一行中，只有大约的条目已填写（可以在 10 到 40 之间，具体取决于计算上的可行性）。我不确定使用稀疏矩阵是否适合存储和计算 -与整体矩阵大小相比，相对意义上的非零条目并不多，但绝对意义上仍然有很多。
作为一个额外的问题，如果使用稀疏矩阵确实是要走的路，那么我可以合理地求解线性方程组的近似数量级大小是多少，即，用直接求解器？不幸的是，我不太清楚什么样的大小是合理的，这会影响我正在考虑的解决问题的方法是否可行（当然，确切的数字取决于我的资源有可用 - 从更一般的意义上说，我想知道大小和资源/时间之间的这种依赖关系是什么样的，但具体的例子也会有帮助，即我可以在几个小时内在普通桌面上做多大的系统大小） .
这种缩放相当普遍，稀疏直接分解方法通常用于多达几十万行和列的矩阵。当你到达，您将有一百万行，每列有一千个非零条目。这进入了稀疏直接分解变得不切实际的范围，您需要查看迭代方法。
在，您将需要大约 10 GB 的空间来以双精度存储矩阵，这在现代 PC 上应该没有问题。然而，当你到达，您将需要大约 10^19 字节的存储空间，这超出了当前超级计算机的容量。
这实际上取决于您打算使用什么方法。如果您存储矩阵密集，那么您将使用密集分解例程，其成本将随矩阵大小三次缩放，因此对于你的情况。这限制了即使在当今最好的超级计算机上也是如此。
您可以使用稀疏表示和直接求解器稍微进一步推动这一点，但根据您对每行有多少非零的评论，我非常怀疑稀疏直接求解器是否真的会胜过密集求解器。原因是稀疏直接求解器将尝试计算未知数和方程的填充减少重新排序，但是稀疏矩阵越少，效果就越差。我怀疑最终，即使在您的情况下进行了最佳重新排序，生成的因式分解仍将是完全密集的，因此给我们留下与密集情况相同的限制。
考虑到上述评论，我们可能会考虑像 GMRES 这样的迭代求解器。对于您的情况，这些方法的主要障碍不是计算成本，而是内存。这些将比上面提到的直接求解器更好地扩展，但很少以黑盒方式工作。你可以先尝试一下黑盒，看看它是否有效，但经验表明它不会在更大的情况下收敛
要解决此问题，您将需要一些预处理器。有一些黑盒预处理器可供选择，它们可能会起作用，但这需要一些实验才能找到。根据经验，一个好的预条件器将占用与矩阵本身一样多的内存来存储。因此，在这种情况下，将矩阵稀疏存储以便为内存中的预处理器腾出更多空间可能是有意义的。此外，大多数可用的黑盒预处理器都要求您将矩阵设为稀疏格式，因此，如果您不想自己重写这些矩阵，下一步可能是转换为稀疏格式。
这忽略了其他一些可能会影响您所做工作的问题：例如您实际可用的内存量。（正如评论所建议的：这里的“内存”是指您使用的任何存储，无论是 DRAM、Burst Buffer、磁盘，......）