@bmunguia
@EduardoMolina and I have discussed this over the past few weeks and are also in favor of using an external library. I don't have a strong opinion on the library we choose, but he seems to be in favor of PETSc from ANL, which has a 2-clause BSD license and is used by ADflow (formerly SUmb), among other solvers. Eduardo could probably provide more details.

Another one that's come up in our discussions is HYPRE from LLNL which has a GNU LGPL.

@juanjosealonso
(...) While PETSc is a wonderful library (and parallel), I would hesitate to use it as the solution for the problem that we are trying to solve: it is not the easiest thing to compile and it is most definitely not lightweight. If one also wanted to replace Krylov-space solvers and preconditioners in SU2 the PETSc might make more sense….but it still forces the developer to conform to their view of the world (including matrix setup and decomposition). (...)

@erangit
I also support external libraries usage (no need to repeat the many advantages as it is well described above) but I think we should be very wary of portability issues. For instance in SUMB, PETSc was used for the Krylov solvers and more. While indeed it worked well and in parallel mode, each new implementation was a nightmare. LAPACK/BLAS package, on the other hand, provides a much easier implementation experience. Certainly, this is not the only consideration but it should be taken into account. Currently, resulting from the significant contributions of the members of this developers group, SU2 implementation works like a charm. I think we should strive to conserve this feature, especially if we aim at attracting more users and developers into the community. (...)

@vdweide
(...) @bmunguia and @EduardoMolina, what type of application did you have in mind for PETSc? The only thing I can think of is a full Newton solver. And no matter how much I like PETSc, @juanjosealonso and @erangit have a point here. Looks like I start to belong to the group of old conservatives as well....

@economon
(...) If you really would like to give PETSc a shot, I recommend talking with @anilvar who had an interface for connecting it to SU2 in one of our branches.

@pcarruscag
(...) being able to use PETSc or HYPRE would be interesting as it would give us access to AMG, and @talbring 's branch feature_template_linear_solver would make such an integration compatible with AD. (...)

@EduardoMolina
(...) When Brian (@bmunguia ) and I mentioned PETSc, it was an idea to try a different Newton-Krylov (with preconditioner) library in order to improve the convergence of SU2.
Since the slow convergence of the SU2-FV is the main feedback that I received from other users from industry and academia, I think it worth try an external library and evaluate the performance. (...)

@pcarruscag
(...) That is something I am also interested in as for some of my structural cases the current linear solvers simply do not converge. (...)

@economon
I would add one practical comment for consideration: it is worth checking whether the main restriction we have is related to approximations in the Jacobian that limit the effective CFL we can use or whether the convergence of the linear solver itself is a problem (speed or complete lack of convergence). A quick test without resorting to another library is to increase the fill-in for ILU-preconditioned GMRES, which is very expensive/slow but should converge difficult problems, and to check how high we can take the CFL when allowing each nonlinear iteration to converge to a tight tolerance in the linear solver, say 1e-14 (you can output the linear solver residuals to verify convergence). If we can take the CFL higher with a more performant linear solver, then it could be worth the effort to try other options.
If the CFL must remain low for stability, then perhaps we should look at the quality of the Jacobians we construct to see if we can improve, or even try exact Jacobians with AD if we can afford it. A more advanced CFL ramping strategy could also be helpful here to get us closer to a solution before trying to aggressively converge.

I think that is everyone.

Linear Solvers (for large sparse systems) #648

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions