[petsc-dev] MR 2036 : Better implementation of multipreconditioning

Pierre Gosselet gosselet at lmt.ens-cachan.fr
Fri Oct 11 09:19:37 CDT 2019

Dear all,
Barry kindly identified many flaws in our implementation, which gives
us many opportunities to improve our code (which is currently under MR 
https://gitlab.com/petsc/petsc/merge_requests/2036).  Among his many
comments and suggestions, there are two points for which we
particularly need advice:

1) Regarding the organization of the code. Till now, we had put
multipreconditioned solvers with their classical solver (mpcg with cg,
mpomin with gcr) which made it unnatural to factorize code. Our new
proposition is to have a directory for multipreconditioned solvers:
src/ksp/ksp/impl/mpsolvers/{mp.h, mp.c, mpcg.c, mpomim.c} mp.{c,h} will
gather common pieces of code (maybe mpsolvers or mpksp instead of just

2) We need communication between the multipreconditioned solver and its
preconditioner. It seems that the combination
[Container/Compose()/Query()] makes it possible for the solver to read
data from the preconditioner.
But we also need the preconditioner (which can be regular pc, like asm)
to know that its parent solver requires multipreconditioning. In these
cases, the setup phase requires for instance some special allocations. 
A possibility is to force all mp solvers to have names starting with
"mp" so that the pc can check hdr.parent.type_name. But there probably
are better mechanisms to transfer this piece of information, rather
than hacking the name of the parent ksp.

thank you for your answers,
pierre and nicolas

Pierre Gosselet
CR CNRS (research agent) 
LMT -- ENS Paris-Saclay/UMR8535
61 av. du président Wilson, 94235 CACHAN
tel: +33 1 47405333

More information about the petsc-dev mailing list