ginkgo icon indicating copy to clipboard operation
ginkgo copied to clipboard

Add a multi-level Schwarz preconditioner

Open pratikvn opened this issue 2 years ago • 6 comments

This PR adds a multi-level Schwarz preconditioner to Ginkgo. The main objective is to be able to use this as preconditioners for Krylov solvers, but combined with IR, it can be used as a solver as well.

TODO:

  • [x] Store coarse solvers as Multigrid levels (RAP) ~~+ [ ] Incorporate Overlap.~~

Currently, this is a single GPU version, but the core class and implementation should carry over to the distributed setup.

pratikvn avatar Jul 29 '22 08:07 pratikvn

format!

pratikvn avatar Aug 01 '22 07:08 pratikvn

format!

pratikvn avatar Aug 01 '22 07:08 pratikvn

Is the implementation intended for single-executor or distributed use? The interface seems to imply the former

upsj avatar Aug 01 '22 13:08 upsj

Note: This PR changes the Ginkgo ABI:

Functions changes summary: 0 Removed, 270 Changed (7047 filtered out), 1283 Added functions
Variables changes summary: 0 Removed, 0 Changed, 0 Added variable

For details check the full ABI diff under Artifacts here

ginkgo-bot avatar Aug 02 '22 09:08 ginkgo-bot

@upsj What do you think of two separate classes, one for distributed and one for single GPU , differing in namespaces gko::preconditioner::Schwarz and gko::distributed::preconditioner:Schwarz.

pratikvn avatar Aug 09 '22 10:08 pratikvn

@pratikvn sorry for leaving this hanging. Yes, that's what I had in mind. It might be that there is some overlap (haha 😁) in the kernels that can be used to set up overlap information, but the interfaces are probably too different to be useful. Still, I think the interfaces should both be designed with overlap in mind, do you have a prototype with overlap capabilities somewhere that we can use as guidance?

upsj avatar Aug 17 '22 10:08 upsj

Closing as the same interface for distributed and non-distributed is not reasonable.

pratikvn avatar Sep 23 '22 12:09 pratikvn

@upsj, I had a preliminary overlap interface somewhere, I will have to dig that up. But it was still only contiguous overlaps (ranges) and not disjoint. To be more generic, It would be better to have an interface that supports disjoint overlaps, which I still need to think about a bit.

pratikvn avatar Sep 23 '22 12:09 pratikvn