[petsc-users] snes failures

[Barry Smith]

   Send the code and I can play with it.

  Barry

> On 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 
> 
>  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
>