<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 18, 2016 at 4:17 PM, Juha Jaykka <span dir="ltr"><<a href="mailto:juhaj@iki.fi" target="_blank">juhaj@iki.fi</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wednesday 18 May 2016 13:48:52 Matthew Knepley wrote:<br>
> On Wed, May 18, 2016 at 1:38 PM, Juha Jaykka <<a href="mailto:juhaj@iki.fi">juhaj@iki.fi</a>> wrote:<br>
> > Dear list,<br>
> ><br>
> > I'm designing a short training course on HPC, and decided to use PETSc as<br>
> > an<br>
> > example of a good way of getting things done quick, easy, and with good<br>
> > performance, and without needing to write one's own code for things like<br>
> > linear or non-linear solvers etc.<br>
> ><br>
> > However, my SNES example turned out to be problematic: I chose the<br>
> > (static)<br>
> > sine-Gordon equation for my example, mostly because its exact solution is<br>
> > known so it is easy to compare with numerics and also because it is, after<br>
> > all, a dead simple equation. Yet my code refuses to converge most of the<br>
> > time!<br>
> ><br>
> > Using -snes_type ngs always succeeds, but is also very slow. Any other<br>
> > type<br>
> > will fail once I increase the domain size from ~100 points (the actual<br>
> > number<br>
> > depends on the type). I always keep the lattice spacing at 0.1. The<br>
> > failure is<br>
> > also always the same: DIVERGED_LINE_SEARCH. Some types manage to take one<br>
> > step<br>
> > and get stuck, some types manage to decrease the norm once and then<br>
> > continue<br>
> > forever without decreasing the norm but not complaining about divergence<br>
> > either (unless they hit one of the max_it-type limits), and ncg is the<br>
> > worst<br>
> > of all: it always (with any lattice size!) fails at the very first step.<br>
> ><br>
> > I've checked the Jacobian, and I suspect it is ok as ngs converges and the<br>
> > other types except ncg also converge nicely unless the domain is too big.<br>
><br>
> Nope, ngs does not use the Jacobian, and small problems can converge with<br>
> wrong Jacobians.<br>
><br>
> Any ideas of where this could go wrong?<br>
><br>
><br>
> 1) Just run with -snes_fd_color -snes_fd_color_use_mat -mat_coloring_type<br>
> greedy and<br>
> see if it converges.<br>
<br>
</div></div>It does not. And I should have mentioned earlier, that I tried -snes_mf, -<br>
snes_mf_operator, -snes_fd and -snes_fd_color already and none of those<br>
converges. Your suggested options result in<br></blockquote><div><br></div><div>For solver questions, I always need to see the result of</div><div><br></div><div> -snes_view -snes_monitor -ksp_converged_reason -ksp_monitor_true_residual -snes_converged_reason</div><div><br></div><div>Turn on LU for the linear solver so it plays no role.</div><div><br></div><div> Thanks,</div><div><br></div><div> Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
0 SNES Function norm 1.002496882788e+00<br>
Line search: lambdas = [1., 0.], ftys = [1.01105, 1.005]<br>
Line search terminated: lambda = 168.018, fnorms = 1.58978<br>
1 SNES Function norm 1.589779063742e+00<br>
Line search: lambdas = [1., 0.], ftys = [5.57144, 4.11598]<br>
Line search terminated: lambda = 4.82796, fnorms = 8.93164<br>
2 SNES Function norm 8.931639387159e+00<br>
Line search: lambdas = [1., 0.], ftys = [2504.72, 385.612]<br>
Line search terminated: lambda = 2.18197, fnorms = 157.043<br>
3 SNES Function norm 1.570434892800e+02<br>
Line search: lambdas = [1., 0.], ftys = [1.89092e+08, 1.48956e+06]<br>
Line search terminated: lambda = 2.00794, fnorms = 40941.5<br>
4 SNES Function norm 4.094149042511e+04<br>
Line search: lambdas = [1., 0.], ftys = [8.60081e+17, 2.56063e+13]<br>
Line search terminated: lambda = 2.00003, fnorms = 2.75067e+09<br>
5 SNES Function norm 2.750671622274e+09<br>
Line search: lambdas = [1., 0.], ftys = [1.75232e+37, 7.76449e+27]<br>
Line search terminated: lambda = 2., fnorms = 1.24157e+19<br>
6 SNES Function norm 1.241565256983e+19<br>
Line search: lambdas = [1., 0.], ftys = [7.27339e+75, 7.14012e+56]<br>
Line search terminated: lambda = 2., fnorms = 2.52948e+38<br>
7 SNES Function norm 2.529479470902e+38<br>
Line search: lambdas = [1., 0.], ftys = [1.25309e+153, 6.03796e+114]<br>
Line search terminated: lambda = 2., fnorms = 1.04992e+77<br>
8 SNES Function norm 1.049915566775e+77<br>
Line search: lambdas = [1., 0.], ftys = [3.71943e+307, 4.31777e+230]<br>
Line search terminated: lambda = 2., fnorms = inf.<br>
9 SNES Function norm inf<br>
<br>
Which is very similar (perhaps even identical) to what ncg does with cp<br>
linesearch even without your suggestions. And yes, I also forgot to say, all<br>
the results I referred to were with -snes_linesearch_type bt.<br>
<br>
While testing a bit more, though, I noticed that when using -snes_type ngs the<br>
norm first goes UP before starting to decrease:<br>
<br>
0 SNES Function norm 1.002496882788e+00<br>
1 SNES Function norm 1.264791228033e+00<br>
2 SNES Function norm 1.296062264876e+00<br>
3 SNES Function norm 1.290207363235e+00<br>
4 SNES Function norm 1.289395207346e+00<br>
etc until<br>
1952 SNES Function norm 9.975720236748e-09<br>
<br>
<br>
> <a href="http://scicomp.stackexchange.com/questions/30/why-is-newtons-method-not-conv" rel="noreferrer" target="_blank">http://scicomp.stackexchange.com/questions/30/why-is-newtons-method-not-conv</a><br>
> erging<br>
<br>
None of this flags up any problems and -snes_check_jacobian consistently gives<br>
something like<br>
<br>
9.55762e-09 = ||J - Jfd||/||J|| 3.97595e-06 = ||J - Jfd||<br>
<br>
and looking at the values themselves with -snes_check_jacobian_view does not<br>
flag any odd points which might be wrong but not show up in the above norm.<br>
<br>
There is just one point which I found in all this testing. Running with a<br>
normal run but with -mat_mffd_type ds added, fails with<br>
<br>
Linear solve did not converge due to DIVERGED_INDEFINITE_PC iterations 2<br>
Nonlinear solve did not converge due to DIVERGED_LINEAR_SOLVE iterations 0<br>
<br>
<br>
instead of failing the line search. Where did the indefinite PC suddenly come<br>
from?<br>
<br>
Another point perhaps worth noting is that at a particular grid size, all the<br>
failing solves always produce the same result with the same function norm<br>
(which at 200 points equals 4.6458600451067145e-01), so at least they are<br>
failing somewhat consistently. This is except the mffd above, of course. The<br>
resulting iterate in the failing cases has an oscillatory nature, with the<br>
number of oscillations increasing with the domain increasing: if my domain is<br>
smaller than about -6 to +6 all the methods converge. If the domain is about<br>
-13 to +13, the "solution" starts to pick up another oscillation etc.<br>
<br>
Could there be something hairy in the sin() term of the sine-Gordon, somehow?<br>
An oscillatory solution seems to point the finger towards an oscillatory term<br>
in the equation, but I cannot see how or why it should cause oscillations.<br>
<br>
This is also irrespective of whether my Jacobian gets called, so I think I can<br>
be pretty confident the problem is not in the Jacobian, but someplace else<br>
instead. (That said, the Jacobian may still of course have some other<br>
problem.)<br>
<br>
Cheers,<br>
Juha<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>