-
Notifications
You must be signed in to change notification settings - Fork 366
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
GMRES #3648
GMRES #3648
Conversation
} | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is some generalization of this loop eventually intended to be added to either GRESMLMG
or GMRES
?
Could we perhaps generalize this to replace gmres
with other solver types that have thus far been used only as bottom solvers? Some examples would include the CG
and BiCGStab
methods. I imagine it could be any class that implements solve
and apply
methods and gets initialized by some MLLinOpT object.
As is, MLMG
seems to force the user to always use the smoother for the non-bottom steps, which uses up the overwhelming majority of computational time. It would be nice if one could make that an option. I imagine the boundary conditions would have to handled more carefully in the case of the non-smoother methods at the finer levels.
It would also be nice if one could select GMRES
as an option in MLMG
as the bottom solver.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your comments. This PR is just first the step of adding GMRES support. Yes, eventually we would like to be able to use GMRES as a bottom solver in MLMG and use MLMG as a multigrid preconditioner for GMRES. The GMRES class will probably be more or less the same, but we need to make some changes to MLMG and the interface class GMRESMLMG.
As is, MLMG seems to force the user to always use the smoother for the non-bottom steps,
MLMG calls linop.smooth
. So it's up to the linear operator class on what to do. Nevertheless, I think the name smooth
is appropriate, because that's how multigrid works. The relaxation step is supposed to smooth out the high-frequency modes of the error. I don't know what is in your mind as not a "smoother". I suspect whatever that is, it needs to behave like a smoother in terms of eliminating high-frequency errors for it to be effective.
Add a GMRES solver class template
This is still work in progress. So the interface may not be stable yet.