Thank you Lawrence, sorry for my mistake. Maybe the "Pull Request" explanation in https://bitbucket.org/petsc/petsc/wiki/pull-request-instructions-git should not link to https://bitbucket.org/petsc/petsc/pull-request/new
I hope reviewers will find some interest in our proposal. Best regards pierre Le mardi 11 juin 2019 à 15:00 +0100, Lawrence Mitchell a écrit : > Pierre, > > did you attempt to open the pull request in bitbucket.org/petsc/petsc > (not allowed unless you have petsc write access), or in your fork > (allowed, and you can target at petsc/petsc master)? > > Lawrence > > > On 11 Jun 2019, at 14:55, Smith, Barry F. via petsc-dev < > > [email protected]> wrote: > > > > > > Hmm, I can't explain this. Just a guess did you make a new branch > > with its own name or just work in master? I don't think it should > > matter but could you try making a branch not called master if yours > > is called master. > > > > > > > On Jun 11, 2019, at 7:39 AM, Pierre Gosselet < > > > [email protected]> wrote: > > > > > > Dear Barry, > > > I have done all the steps described in > > > https://bitbucket.org/petsc/petsc/wiki/pull-request-instructions-git > > > unfortunately, when I click on "create pull request", > > > I get a "access denied" page. > > > > > > My branch gosselet/multiprecond can be found here: > > > https://bitbucket.org/pierre_gosselet/petscfork/src/master/ > > > > > > Best regards > > > pierre > > > > > > Le vendredi 07 juin 2019 à 17:58 +0000, Smith, Barry F. a écrit : > > > > Pierre, > > > > > > > > Thanks for your generous offer. Maybe you could point us to a > > > > repository with the branch with your additions so we could take > > > > a > > > > look at it and see how it could be adopted into PETSc? > > > > > > > > Barry > > > > > > > > > > > > > On Jun 7, 2019, at 11:07 AM, Pierre Gosselet via petsc-dev < > > > > > [email protected]> wrote: > > > > > > > > > > Dear Petsc developers, > > > > > > > > > > I am Pierre Gosselet, researcher in computational mechanics > > > > > from > > > > > France > > > > > (ENS Paris Saclay / Univ. Lille). Lately I have been working > > > > > on > > > > > multipreconditioned solvers arising from domain decomposition > > > > > (DD). > > > > > I have co-authored some papers with Nicole Spillane whom you > > > > > probably know. > > > > > > > > > > Together with Nicolas Tardieu from EDF we have done some > > > > > developments > > > > > in PetSc and we would be happy to share them. Nicolas told me > > > > > I had > > > > > better send you a short notice before making a pull request. > > > > > > > > > > We have implemented a MultiPreconditioned Conjugate Gradients > > > > > solver > > > > > for the SPD case and a MultiPreconditioned Orthomin solver > > > > > for > > > > > general > > > > > matrices. > > > > > > > > > > These solvers rely on a method with signature > > > > > PCApplyMultiPrecond(PC, Vec in, Mat out) > > > > > We proposed an implementation of this method in the > > > > > (Restrictive) > > > > > Additive Schwarz (R)ASM framework: > > > > > PCApplyMultiPrecond_ASM(...). > > > > > When preconditioning, each subdomain provides a column which > > > > > is > > > > > used to > > > > > expand the search space. There is an experimental use of the > > > > > information in NearNullSpace in order to speed up the > > > > > convergence > > > > > (ersatz of Nicholaides' two-level (R)ASM). > > > > > > > > > > In practice, there are new files for the solvers (mpcg.c and > > > > > mpomin.c), > > > > > some features were added in asm.c, and there are few lines > > > > > added > > > > > in other files in order to declare the solvers. We tried to > > > > > make a > > > > > nice implementation and integration, but we would be happy to > > > > > have > > > > > our > > > > > code reviewed for better performance. > > > > > > > > > > > > > > > Unfortunately, from the very limited numerical experiments > > > > > that we > > > > > have > > > > > conducted, we do not have tremendous examples to show, the > > > > > extra > > > > > costs > > > > > associated with multipreconditioning are not always > > > > > compensated by > > > > > the > > > > > improved convergence. In fact, it appears that > > > > > multipreconditioned > > > > > solvers do not behave as well in the (R)ASM framework as in > > > > > other > > > > > DD > > > > > frameworks, like FETI(DP) or BDD(C), where the spectrum has a > > > > > more > > > > > favorable shape and where adaptive strategies are available. > > > > > > > > > > Anyhow our developments offer opportunities to test mpcg and > > > > > mpomin, to > > > > > implement new multipreconditioned solvers and new > > > > > multipreconditioning > > > > > frameworks (one just need to implement > > > > > PCApplyMultiPrecond_???). > > > > > > > > > > I hope you will be interested by these developments, > > > > > best regards > > > > > pierre > > > > > > > > > > > > > > > -- > > > > > Pierre Gosselet > > > > > CR CNRS (research agent) > > > > > LMT -- ENS Paris-Saclay/UMR8535 > > > > > 61 av. du président Wilson, 94235 CACHAN > > > > > tel: +33 1 47405333 > > > > > > > > -- > > > Pierre Gosselet > > > CR CNRS (research agent) > > > LMT -- ENS Paris-Saclay/UMR8535 > > > 61 av. du président Wilson, 94235 CACHAN > > > tel: +33 1 47405333 > > > -- Pierre Gosselet CR CNRS (research agent) LMT -- ENS Paris-Saclay/UMR8535 61 av. du président Wilson, 94235 CACHAN tel: +33 1 47405333
