-
Notifications
You must be signed in to change notification settings - Fork 94
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
Comments
I would like to bring up that the configuration in the example |
for the laplace operator, should it use the geometric coasrening method? |
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. |
I do not understand what's the meaning of incorrect settings. |
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 |
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. |
Honestly, I think having our AMG defaulting to the identity is very user unfriendly. |
I see. |
I'm not sure about the maturity of our direct solver, so I would go with GMRES. |
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.
Closed by #1291 |
I think we should discuss how reasonable defaults for our AMG look like. IMO, it should be possible to write
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:
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.
The text was updated successfully, but these errors were encountered: