我是一名 PETSc 开发人员，所以对我的建议持保留态度，但我会使用 PETSc，因为

1. 问题规模足够大，执行开销应该最小，
2. 您可以在各种稀疏和密集求解器之间轻松切换（1/2 稀疏应该被视为密集，但在您的尺寸下使用 1/9 的稀疏求解器可能会有所回报），
3. 一套全球化技术快速实验，这对于困难的问题很重要，以及
4. 您将获得监控和调试工具，因此您无需编写自己的脚手架即可调试和理解收敛。

人们对这种类型的线性系统有何建议？我知道 trilinos、petsc 和日晷，但不知道其他替代品或接触过它们。

一般来说，PETSc、Trilinos 和 KINSOL（来自 SUNDIALS）在可扩展性方面是最好的。从生态系统的角度来看，PETSc 似乎最灵活，因为它不试图接管main或试图成为一个框架；许多软件包（SLEPc、libmesh、deal.II、PyClaw、MOOSE、TAO（在它被折叠成 PETSc 之前）、FEniCS）成功地构建在 PETSc 之上。

Trilinos 具有更多框架/生态系统的感觉，因为 Trilinos 由许多包组成；软件包仍然建立在 Trilinos 之上，例如 FEniCS 和 deal.II。从邮件列表流量来看，到 FEniCS 的 PETSc 接口往往比 Trilinos 接口得到更多的使用。

KINSOL 是最不灵活的。它基本上是牛顿求解器或定点迭代求解器，具有少量迭代线性求解器的接口。它可能是最容易完全学习的，但没有像 PETSc 那样的运行时灵活性。在 KINSOL 和 PETSc 之间进行选择，我会选择 PETSc；仅代码维护和质量就更好，PETSc 更强大。

我意识到由于示例中相对缺乏稀疏性，大型求解器过于矫枉过正，但它会伤害吗？

可能不是。例如，由于 PETSc 初始化数据结构会产生一些开销，但我只遇到过两个人确实有充分的理由抱怨它（在一种情况下，PETSc 开发人员在减少 PETSc 内存占用方面做得很好） . JedBrown 会更清楚；我只是一个 PETSc 用户。