[petsc-users] odd SNES behavior

[Peter Brune]

Mark -

I can reproduce on a simple single processor example.  It appears that the
MatMFFD is being used within GAMG instead of the preconditioning matrix.
Therefore, SNESComputeFunction is being called at each chebychev iteration
on the coarse grid.  For instance, I get backtraces like:

#0  SNESComputeFunction (snes=0x870250, x=0xb1a020, y=0xc5e150) at
/home/prbrune/packages/petsc-dev/src/snes/interface/snes.c:1993
#1  0x00007ffff68964cf in MatMult_MFFD (mat=0xa82e30, a=0xc54350,
y=0xc5e150) at
/home/prbrune/packages/petsc-dev/src/mat/impls/mffd/mffd.c:404
#2  0x00007ffff6692070 in MatMult (mat=0xa82e30, x=0xc54350, y=0xc5e150) at
/home/prbrune/packages/petsc-dev/src/mat/interface/matrix.c:2156
#3  0x00007ffff705fa81 in KSP_MatMult (ksp=0xbf6410, A=0xa82e30,
x=0xc54350, y=0xc5e150) at
/home/prbrune/packages/petsc-dev/include/petsc-private/kspimpl.h:198
#4  0x00007ffff706686d in KSPSolve_Chebyshev (ksp=0xbf6410) at
/home/prbrune/packages/petsc-dev/src/ksp/ksp/impls/cheby/cheby.c:502
#5  0x00007ffff6f7c53c in KSPSolve (ksp=0xbf6410, b=0xa6e9a0, x=0xb41990)
at /home/prbrune/packages/petsc-dev/src/ksp/ksp/interface/itfunc.c:430
#6  0x00007ffff6f4d9ae in PCMGMCycle_Private (pc=0xa22bf0,
mglevelsin=0xbd72c8, reason=0x0) at
/home/prbrune/packages/petsc-dev/src/ksp/pc/impls/mg/mg.c:19
#7  0x00007ffff6f52280 in PCApply_MG (pc=0xa22bf0, b=0xa6e9a0, x=0xb41990)
at /home/prbrune/packages/petsc-dev/src/ksp/pc/impls/mg/mg.c:330
#8  0x00007ffff6e32b23 in PCApply (pc=0xa22bf0, x=0xa6e9a0, y=0xb41990) at
/home/prbrune/packages/petsc-dev/src/ksp/pc/interface/precon.c:390
#9  0x00007ffff6fa8a4d in KSP_PCApply (ksp=0x9e60f0, x=0xa6e9a0,
y=0xb41990) at
/home/prbrune/packages/petsc-dev/include/petsc-private/kspimpl.h:221
#10 0x00007ffff6fa98f3 in KSPInitialResidual (ksp=0x9e60f0, vsoln=0xa79030,
vt1=0xb2d4f0, vt2=0xb37b90, vres=0xb41990, vb=0xa6e9a0)
    at /home/prbrune/packages/petsc-dev/src/ksp/ksp/interface/itres.c:64
#11 0x00007ffff7031a88 in KSPSolve_GMRES (ksp=0x9e60f0) at
/home/prbrune/packages/petsc-dev/src/ksp/ksp/impls/gmres/gmres.c:234
#12 0x00007ffff6f7c53c in KSPSolve (ksp=0x9e60f0, b=0xa6e9a0, x=0xa79030)
at /home/prbrune/packages/petsc-dev/src/ksp/ksp/interface/itfunc.c:430
#13 0x00007ffff714b1ea in SNES_KSPSolve (snes=0x870250, ksp=0x9e60f0,
b=0xa6e9a0, x=0xa79030) at
/home/prbrune/packages/petsc-dev/src/snes/interface/snes.c:4418
#14 0x00007ffff70d8ec5 in SNESSolve_NEWTONLS (snes=0x870250) at
/home/prbrune/packages/petsc-dev/src/snes/impls/ls/ls.c:217
#15 0x00007ffff7142e9b in SNESSolve (snes=0x870250, b=0x0, x=0xa24840) at
/home/prbrune/packages/petsc-dev/src/snes/interface/snes.c:3649
#16 0x0000000000402c83 in main (argc=9, argv=0x7fffffffde08) at ex5.c:157

Is the wrong matrix getting sent to the smoothers somewhere?

- Peter







On Wed, Mar 6, 2013 at 11:25 AM, Mark F. Adams <mark.adams at columbia.edu>wrote:

> I have a SNES solve if I switch the pc_type between gamg and hypre I get
> some odd results:
>
> 1) The gamg solve takes two more Newton iterations and converges for a
> different reason.  This could be OK, but it seems odd.
>
> 2) The more mystifying issue is that the gamg solve seems to take just a
> few more total linear solve iterations but does about 5x as many function
> evaluations.
>
> I've attached two log files.  Any ideas what is going on here?  It seems
> like it should be impossible for the choice of PC to effect the nonlinear
> solve like this.
>
> Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20130306/842f9c51/attachment.html>