-
Notifications
You must be signed in to change notification settings - Fork 93
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
Add a Multilevel schwarz preconditioner #1431
base: develop
Are you sure you want to change the base?
Conversation
f6c6240
to
58e6482
Compare
58e6482
to
bf971dc
Compare
bf971dc
to
60889dc
Compare
60889dc
to
bf971dc
Compare
bf971dc
to
b795413
Compare
a10beb2
to
8667fa1
Compare
24c6f7d
to
8df491e
Compare
8df491e
to
9101732
Compare
9101732
to
2c5d816
Compare
Error: The following files need to be formatted:
You can find a formatting patch under Artifacts here or run |
e988e0e
to
e2714c8
Compare
As a first step, I just added a two-level preconditioner with equal weighting for the local solution and the coarse solution. I think it maybe makes sense to try this out in some applications and then think about arbitrary number of levels, additive/multiplicative etc. |
format! |
Co-authored-by: Pratik Nayak <[email protected]>
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.
Generally looks good, I left some minor nits.
Did you have a case, where the coarse grid solve was beneficial? Right now the provided example doesn't seem to benefit from the coarse grid solve.
Also, since the coarse and local solves are not computed in parallel, as you mentioned, which will probably be the case for a while, maybe implement it as a multiplicative version directly.
* Operator factory to generate the triplet (prolong_op, coarse_op, | ||
* restrict_op). | ||
*/ | ||
std::shared_ptr<const LinOpFactory> GKO_DEFERRED_FACTORY_PARAMETER( | ||
galerkin_ops); |
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.
I'm not too convinced of the name and the doc. At least to me, galerkin_ops
is too unspecific, maybe something like coarse_level_factory
would be better suited. Also the doc should contain that this will be used to create a coarse level system, maybe
Operator factory to generate the coarse system `A_c = R * A * P`.
|
||
restrict->apply(dense_b, csol_cache_.get()); | ||
this->coarse_solver_->apply(csol_cache_.get(), csol_cache_.get()); | ||
prolong->apply(this->half_, csol_cache_.get(), this->half_, dense_x); |
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.
I don't think it's typical to weight these solutions. For example the book Domain Decomposition by Smith, Bjorstad, and Gropp, just sums all contributions up (p. 47) regardless of if they are from the subdomains, or the coarse grid.
} else { | ||
this->set_solver(parameters_.generated_local_solver); | ||
} | ||
|
||
|
||
if (parameters_.galerkin_ops && parameters_.coarse_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.
maybe there should be an exception, if only one of those is set. I think that would be a configuration error, and the user should be notified.
if (as<gko::multigrid::MultigridLevel>(this->galerkin_ops_) | ||
->get_coarse_op()) { |
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.
Can this actually be null? If so, maybe that should be considered an error.
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.
I think adjustments to the copy/move are necessary. However, they seem to be already incomplete as of now, so that might also be done in a separate PR.
as<gko::multigrid::MultigridLevel>(this->galerkin_ops_) | ||
->get_coarse_op()); | ||
auto exec = coarse->get_executor(); | ||
auto comm = coarse->get_communicator(); |
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.
unused
auto comm = coarse->get_communicator(); |
@@ -79,6 +80,7 @@ int main(int argc, char* argv[]) | |||
static_cast<gko::size_type>(argc >= 3 ? std::atoi(argv[2]) : 100); | |||
const auto num_iters = | |||
static_cast<gko::size_type>(argc >= 4 ? std::atoi(argv[3]) : 1000); | |||
std::string schw_type = argc >= 5 ? argv[4] : "multi-level"; |
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.
Just as a note, I was running this example with
mpirun -n 4 ./distributed-solver reference 10000 1000
and the one-level
version was faster and used less iteration. So maybe it should be the default.
This PR uses the distributed coarse level generation from PGM to use as a coarse level for the additive Schwarz preconditioner. The only requirement is that the galerkin product generator ($RAP$ ) generate a
multigrid::MultigridLevel
which is a triplet ofrestrict
,prolong
andcoarse
operators. The user additionally also needs to set the solver for the coarse level.TODO
Possible issues