[petsc-dev] large bug in KSPSolve_Chebyshev() affects all multigrid solvers; all core developers including Mark please read this
Mark Adams
mfadams at lbl.gov
Thu Sep 20 05:00:03 CDT 2018
On Wed, Sep 19, 2018 at 7:44 PM Smith, Barry F. <bsmith at mcs.anl.gov> wrote:
>
> Look at the code in KSPSolve_Chebyshev().
>
> Problem 1) VERY MAJOR
>
> Once you start running the eigenestimates it always runs them, this is
> because the routine begins with
>
> if (cheb->kspest) {
>
> but once cheb->kspest is set it is never unset. This means, for
> example, that every time PCMG runs the smoother that uses Chebyshev it runs
> the eigenestimator (which uses GMRES) (even when it is suppose to be just
> smoothing since the eigenestimates were already made in the setup stage).
> This is totally wrong.
Yikes, does this code (a few lines down) address this?
if (amatid != cheb->amatid || pmatid != cheb->pmatid || amatstate !=
cheb->amatstate || pmatstate != cheb->pmatstate) {
Maybe you could run with CG as the outer solver and check that the number
of GMRES solve calls (maybe with GMRESOrtho/max_it) is equal to the number
of SNES iterations * (number of levels - 1).
> Sure enough, if I run, for example, src/snes/examples/tutorials/ex19.c
> with -pc_type gamg I see in the debugger that GMRES is being called by
> KSPSolve_Chebyshev as it smooths. For example,
>
> 0 MatSOR (mat=0x28689f0, b=0x29ee310, omega=1, flag=28, shift=0, its=1,
> lits=1, x=0x29f4070)
> at /sandbox/bsmith/petsc/src/mat/interface/matrix.c:3913
> #1 0x00007f59d2e353b9 in PCApply_SOR (pc=0x29aa770, x=0x29ee310,
> y=0x29f4070)
> at /sandbox/bsmith/petsc/src/ksp/pc/impls/sor/sor.c:31
> #2 0x00007f59d2fa6a7b in PCApply (pc=0x29aa770, x=0x29ee310, y=0x29f4070)
> at /sandbox/bsmith/petsc/src/ksp/pc/interface/precon.c:462
> #3 0x00007f59d2faa6a7 in PCApplyBAorAB (pc=0x29aa770, side=PC_LEFT,
> x=0x29f11c0, y=0x29f4070, work=0x29ee310)
> at /sandbox/bsmith/petsc/src/ksp/pc/interface/precon.c:691
> #4 0x00007f59d3084d46 in KSP_PCApplyBAorAB (ksp=0x29c4d30, x=0x29f11c0,
> y=0x29f4070, w=0x29ee310)
> at /sandbox/bsmith/petsc/include/petsc/private/kspimpl.h:309
> #5 0x00007f59d3086874 in KSPGMRESCycle (itcount=0x7ffd3d60143c,
> ksp=0x29c4d30)
> at /sandbox/bsmith/petsc/src/ksp/ksp/impls/gmres/gmres.c:152
> #6 0x00007f59d3087352 in KSPSolve_GMRES (ksp=0x29c4d30) at
> /sandbox/bsmith/petsc/src/ksp/ksp/impls/gmres/gmres.c:234
> #7 0x00007f59d30fae94 in KSPSolve (ksp=0x29c4d30, b=0x29dc900,
> x=0x29d9a30)
> at /sandbox/bsmith/petsc/src/ksp/ksp/interface/itfunc.c:780
> #8 0x00007f59d306a1e1 in KSPSolve_Chebyshev (ksp=0x29a9550) at
> /sandbox/bsmith/petsc/src/ksp/ksp/impls/cheby/cheby.c:367
> #9 0x00007f59d30fae94 in KSPSolve (ksp=0x29a9550, b=0x28653d0,
> x=0x2906a70)
> at /sandbox/bsmith/petsc/src/ksp/ksp/interface/itfunc.c:780
> #10 0x00007f59d2f59042 in PCMGMCycle_Private (pc=0x2832fd0,
> mglevelsin=0x2944b88, reason=0x0)
> at /sandbox/bsmith/petsc/src/ksp/pc/impls/mg/mg.c:20
> #11 0x00007f59d2f5e350 in PCApply_MG (pc=0x2832fd0, b=0x28653d0,
> x=0x2906a70)
> at /sandbox/bsmith/petsc/src/ksp/pc/impls/mg/mg.c:377
> #12 0x00007f59d2fa6a7b in PCApply (pc=0x2832fd0, x=0x28653d0, y=0x2906a70)
> at /sandbox/bsmith/petsc/src/ksp/pc/interface/precon.c:462
> #13 0x00007f59d31242d7 in KSP_PCApply (ksp=0x27df750, x=0x28653d0,
> y=0x2906a70)
> at /sandbox/bsmith/petsc/include/petsc/private/kspimpl.h:281
> #14 0x00007f59d31251ba in KSPInitialResidual (ksp=0x27df750,
> vsoln=0x28610d0, vt1=0x28ff7b0, vt2=0x2903450,
> vres=0x2906a70, vb=0x28653d0) at
> /sandbox/bsmith/petsc/src/ksp/ksp/interface/itres.c:67
> #15 0x00007f59d30872ef in KSPSolve_GMRES (ksp=0x27df750) at
> /sandbox/bsmith/petsc/src/ksp/ksp/impls/gmres/gmres.c:233
> #16 0x00007f59d30fae94 in KSPSolve (ksp=0x27df750, b=0x28653d0,
> x=0x28610d0)
> at /sandbox/bsmith/petsc/src/ksp/ksp/interface/itfunc.c:780
> #17 0x00007f59d3291d32 in SNESSolve_NEWTONLS (snes=0x26f2550) at
> /sandbox/bsmith/petsc/src/snes/impls/ls/ls.c:224
> #18 0x00007f59d320f7da in SNESSolve (snes=0x26f2550, b=0x0, x=0x285d440)
>
>
Can this just be the first time it is called, so it is doing the setup?
> Not only is the code wrong but it is also a huge inefficiency in the
> code running all these unneeded GMRES.
>
Just to be clear, this is inefficiency, but I don't see why it is
(mathematically) wrong.
> Problem 2) Less catastrophic
>
> When cheb->kspest is set the "regular" Chebyshev is also run (after the
> eigenvalues are estimated).
I don't see that. I see:
static PetscErrorCode KSPSolve_Chebyshev(KSP ksp)
.....
if (cheb->kspest) {
.....
if (amatid != cheb->amatid || pmatid != cheb->pmatid || amatstate !=
cheb->amatstate || pmatstate != cheb->pmatstate) {
... eig est
}
}
.. cheby ..
> I am pretty sure this is wrong because there is no reason to run the
> Chebyshev when estimating the eigenvalues? The eigenvalues are stored to be
> used later right?
> So what needs to be fixed? Well somehow cheb->kspest has to be turned
> off once the eigenvalues are computed, but turned back on each time the
> matrix changes. And (easier) when cheb->kspest is used then the actual
> Chebyshev iterations need to be turned off.
>
> I hope I am wrong and the code is correct but I'm pretty sure the code
> is not what it should be.
>
> Barry
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20180920/3438b61d/attachment.html>
More information about the petsc-dev
mailing list