[petsc-users] snes failures

[Matthew Knepley]

On Wed, May 18, 2016 at 4:17 PM, Juha Jaykka <juhaj at iki.fi> wrote:

> On Wednesday 18 May 2016 13:48:52 Matthew Knepley wrote:
> > On Wed, May 18, 2016 at 1:38 PM, Juha Jaykka <juhaj at iki.fi> wrote:
> > > Dear list,
> > >
> > > I'm designing a short training course on HPC, and decided to use PETSc
> as
> > > an
> > > example of a good way of getting things done quick, easy, and with good
> > > performance, and without needing to write one's own code for things
> like
> > > linear or non-linear solvers etc.
> > >
> > > However, my SNES example turned out to be problematic: I chose the
> > > (static)
> > > sine-Gordon equation for my example, mostly because its exact solution
> is
> > > known so it is easy to compare with numerics and also because it is,
> after
> > > all, a dead simple equation. Yet my code refuses to converge most of
> the
> > > time!
> > >
> > > Using -snes_type ngs always succeeds, but is also very slow. Any other
> > > type
> > > will fail once I increase the domain size from ~100 points (the actual
> > > number
> > > depends on the type). I always keep the lattice spacing at 0.1. The
> > > failure is
> > > also always the same: DIVERGED_LINE_SEARCH. Some types manage to take
> one
> > > step
> > > and get stuck, some types manage to decrease the norm once and then
> > > continue
> > > forever without decreasing the norm but not complaining about
> divergence
> > > either (unless they hit one of the max_it-type limits), and ncg is the
> > > worst
> > > of all: it always (with any lattice size!) fails at the very first
> step.
> > >
> > > I've checked the Jacobian, and I suspect it is ok as ngs converges and
> the
> > > other types except ncg also converge nicely unless the domain is too
> big.
> >
> > Nope, ngs does not use the Jacobian, and small problems can converge with
> > wrong Jacobians.
> >
> > Any ideas of where this could go wrong?
> >
> >
> > 1) Just run with -snes_fd_color  -snes_fd_color_use_mat
> -mat_coloring_type
> > greedy and
> >     see if it converges.
>
> It does not. And I should have mentioned earlier, that I tried -snes_mf, -
> snes_mf_operator, -snes_fd and -snes_fd_color already and none of those
> converges. Your suggested options result in
>

For solver questions, I always need to see the result of

  -snes_view -snes_monitor -ksp_converged_reason -ksp_monitor_true_residual
-snes_converged_reason

Turn on LU for the linear solver so it plays no role.

  Thanks,

     Matt


>   0 SNES Function norm 1.002496882788e+00
>       Line search: lambdas = [1., 0.], ftys = [1.01105, 1.005]
>       Line search terminated: lambda = 168.018, fnorms = 1.58978
>   1 SNES Function norm 1.589779063742e+00
>       Line search: lambdas = [1., 0.], ftys = [5.57144, 4.11598]
>       Line search terminated: lambda = 4.82796, fnorms = 8.93164
>   2 SNES Function norm 8.931639387159e+00
>       Line search: lambdas = [1., 0.], ftys = [2504.72, 385.612]
>       Line search terminated: lambda = 2.18197, fnorms = 157.043
>   3 SNES Function norm 1.570434892800e+02
>       Line search: lambdas = [1., 0.], ftys = [1.89092e+08, 1.48956e+06]
>       Line search terminated: lambda = 2.00794, fnorms = 40941.5
>   4 SNES Function norm 4.094149042511e+04
>       Line search: lambdas = [1., 0.], ftys = [8.60081e+17, 2.56063e+13]
>       Line search terminated: lambda = 2.00003, fnorms = 2.75067e+09
>   5 SNES Function norm 2.750671622274e+09
>       Line search: lambdas = [1., 0.], ftys = [1.75232e+37, 7.76449e+27]
>       Line search terminated: lambda = 2., fnorms = 1.24157e+19
>   6 SNES Function norm 1.241565256983e+19
>       Line search: lambdas = [1., 0.], ftys = [7.27339e+75, 7.14012e+56]
>       Line search terminated: lambda = 2., fnorms = 2.52948e+38
>   7 SNES Function norm 2.529479470902e+38
>       Line search: lambdas = [1., 0.], ftys = [1.25309e+153, 6.03796e+114]
>       Line search terminated: lambda = 2., fnorms = 1.04992e+77
>   8 SNES Function norm 1.049915566775e+77
>       Line search: lambdas = [1., 0.], ftys = [3.71943e+307, 4.31777e+230]
>       Line search terminated: lambda = 2., fnorms = inf.
>   9 SNES Function norm            inf
>
> Which is very similar (perhaps even identical) to what ncg does with cp
> linesearch even without your suggestions. And yes, I also forgot to say,
> all
> the results I referred to were with -snes_linesearch_type bt.
>
> While testing a bit more, though, I noticed that when using -snes_type ngs
> the
> norm first goes UP before starting to decrease:
>
>   0 SNES Function norm 1.002496882788e+00
>   1 SNES Function norm 1.264791228033e+00
>   2 SNES Function norm 1.296062264876e+00
>   3 SNES Function norm 1.290207363235e+00
>   4 SNES Function norm 1.289395207346e+00
> etc until
> 1952 SNES Function norm 9.975720236748e-09
>
>
> >
> http://scicomp.stackexchange.com/questions/30/why-is-newtons-method-not-conv
> > erging
>
> None of this flags up any problems and -snes_check_jacobian consistently
> gives
> something like
>
> 9.55762e-09 = ||J - Jfd||/||J|| 3.97595e-06  = ||J - Jfd||
>
> and looking at the values themselves with -snes_check_jacobian_view does
> not
> flag any odd points which might be wrong but not show up in the above norm.
>
> There is just one point which I found in all this testing. Running with a
> normal run but with -mat_mffd_type ds added, fails with
>
>   Linear solve did not converge due to DIVERGED_INDEFINITE_PC iterations 2
> Nonlinear solve did not converge due to DIVERGED_LINEAR_SOLVE iterations 0
>
>
> instead of failing the line search. Where did the indefinite PC suddenly
> come
> from?
>
> Another point perhaps worth noting is that at a particular grid size, all
> the
> failing solves always produce the same result with the same function norm
> (which at 200 points equals 4.6458600451067145e-01), so at least they are
> failing somewhat consistently. This is except the mffd above, of course.
> The
> resulting iterate in the failing cases has an oscillatory nature, with the
> number of oscillations increasing with the domain increasing: if my domain
> is
> smaller than about -6 to +6 all the methods converge. If the domain is
> about
> -13 to +13, the "solution" starts to pick up another oscillation etc.
>
> Could there be something hairy in the sin() term of the sine-Gordon,
> somehow?
> An oscillatory solution seems to point the finger towards an oscillatory
> term
> in the equation, but I cannot see how or why it should cause oscillations.
>
> This is also irrespective of whether my Jacobian gets called, so I think I
> can
> be pretty confident the problem is not in the Jacobian, but someplace else
> instead. (That said, the Jacobian may still of course have some other
> problem.)
>
> Cheers,
> Juha
>
>


-- 
What most experimenters take for granted before they begin their
experiments is infinitely more interesting than any results to which their
experiments lead.
-- Norbert Wiener
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20160518/add0361f/attachment-0001.html>