ginkgo-project / ginkgo

Numerical linear algebra software package
https://ginkgo-project.github.io/
BSD 3-Clause "New" or "Revised" License
406 stars 89 forks source link

AMG defaults #1264

Closed MarcelKoch closed 1 year ago

MarcelKoch commented 1 year ago

I think we should discuss how reasonable defaults for our AMG look like. IMO, it should be possible to write

auto solver = Cg<>::build().with_preconditioner(Multigrid::build().on(exec))...

and expect that a reasonable AMG is constructed. Since our AMG is not called AMG, but Multigrid, which implies more generality, I would also think that the following would be fine to specify how the levels are build:

auto solver = Cg<>::build().with_preconditioner(Multigrid::build()
                                                  .with_mg_level(Pgm<>::build().on(exec)).on(exec))...

But neither work right now. They result in an exception, due to missing stopping criterion, or, if that is fulfilled, in non-convergence.

Before going into specifics, we need to clarify if we want to support the syntax above or not. Any thoughts on this are welcome.

MarcelKoch commented 1 year ago

I would like to bring up that the configuration in the example multigrid-preconditioned-solver also doesn't work. Of course, in the example the solver converges, but if that configuration is applied to a simple finite difference discretization of the Laplace operator, the needed solver iteration scale linearly with the mesh width. IMO, that means that the AMG is not correctly configured, and thus sets a bad example. BTW, the issue seems to be that the coarse grid solve is not exact. If an exact solver (iterative solver with tol ~ eps) is used than is the iteration number doesn't scale linearly anymore.

yhmtsai commented 1 year ago

for the laplace operator, should it use the geometric coasrening method? The criterion issue is applied to all solvers. They always need to set the criterion to use.

MarcelKoch commented 1 year ago

You are right, I'm missing the criterion. But the argument still holds. Other preconditioner/solver work with just the criterion, but the AMG doesn't. A different coarsening method might be better suited for the laplace operator, but as I mentioned, that does not seem to be the issue. Solving exactly on the coarse grid seems to fix the convergence rate.

yhmtsai commented 1 year ago

I do not understand what's the meaning of incorrect settings. Do you mean we should have a better coarse solver as the default?

yhmtsai commented 1 year ago

I think current setting without any passing presmoother or coarse solver will give you the Identity like IR's inner solver or preconditioner from other solvers

MarcelKoch commented 1 year ago

AMGs are widely considered as one of the most powerful preconditioners. Generally, a user would expect from an AMG that it converges in a significantly lower number of iterations compared to say Jacobi, or Gauss-Seidel. And, perhaps more importantly, they would also expect that the number of iterations grows very slowly with the problem size. Both of these are not true with either the default settings or the example settings. Because of this, I consider our default settings incorrect. E.g. petsc and hypre have correct defaults, in the sense that the convergence rate is usually low enough.

MarcelKoch commented 1 year ago

Honestly, I think having our AMG defaulting to the identity is very user unfriendly.

yhmtsai commented 1 year ago

I see. Do you have any idea about the default coarse solver? GMRES or DirectSolver in the coarse solver? we can also have a selector to choose them

MarcelKoch commented 1 year ago

I'm not sure about the maturity of our direct solver, so I would go with GMRES. Now about the smoothers. I think we can only choose between Ir with scalar Jacobi or Ilu (with exact Ilu factorization). If you are working on Chebychev iterations, that would also be a good choice.

MarcelKoch commented 1 year ago

Closed by #1291