Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMG defaults #1264

Closed
MarcelKoch opened this issue Jan 26, 2023 · 10 comments
Closed

AMG defaults #1264

MarcelKoch opened this issue Jan 26, 2023 · 10 comments
Labels
is:enhancement An improvement of an existing feature. is:proposal Maybe we should do something this way. type:multigrid This is related to multigrid

Comments

@MarcelKoch
Copy link
Member

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 MarcelKoch added is:enhancement An improvement of an existing feature. is:proposal Maybe we should do something this way. type:multigrid This is related to multigrid labels Jan 26, 2023
@MarcelKoch
Copy link
Member Author

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
Copy link
Member

yhmtsai commented Feb 21, 2023

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
Copy link
Member Author

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
Copy link
Member

yhmtsai commented Feb 22, 2023

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
Copy link
Member

yhmtsai commented Feb 22, 2023

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
Copy link
Member Author

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
Copy link
Member Author

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

@yhmtsai
Copy link
Member

yhmtsai commented Feb 22, 2023

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
Copy link
Member Author

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 added a commit that referenced this issue Mar 17, 2023
Based on the discussion in #1264 this PR changes some of the default settings of the AMG. The overall goal it to make it possible that our default AMG (no extra settings except the coarsening and stopping criterion) helps to reduce the necessary number of iterations adequately. 
This PR changes the default smoother to one iteration of `IR` with `Jacobi` preconditioner, and the coarse grid solve to a direct LU solver.

Additionally, examples are provided to show the simplified AMG creation.
@MarcelKoch
Copy link
Member Author

Closed by #1291

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
is:enhancement An improvement of an existing feature. is:proposal Maybe we should do something this way. type:multigrid This is related to multigrid
Projects
None yet
Development

No branches or pull requests

2 participants