Fix for the garbage in X part is in.<br><br><a href="http://petsc.cs.iit.edu/petsc/releases/petsc-3.3/rev/9d679552ef45">http://petsc.cs.iit.edu/petsc/releases/petsc-3.3/rev/9d679552ef45</a><br><br>- Peter<br><br><div class="gmail_quote">
On Wed, Oct 17, 2012 at 3:34 PM, Peter Brune <span dir="ltr"><<a href="mailto:prbrune@gmail.com" target="_blank">prbrune@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div class="im">On Wed, Oct 17, 2012 at 3:01 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Wed, Oct 17, 2012 at 2:56 PM, Peter Brune <span dir="ltr"><<a href="mailto:prbrune@gmail.com" target="_blank">prbrune@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Wed, Oct 17, 2012 at 2:40 PM, Dmitry Karpeev <span dir="ltr"><<a href="mailto:karpeev@mcs.anl.gov" target="_blank">karpeev@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><div class="gmail_quote"><div>On Wed, Oct 17, 2012 at 2:11 PM, Jed Brown <span dir="ltr"><<a href="mailto:jedbrown@mcs.anl.gov" target="_blank">jedbrown@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Wed, Oct 17, 2012 at 2:02 PM, Shiyuan Gu <span dir="ltr"><<a href="mailto:sgu@anl.gov" target="_blank">sgu@anl.gov</a>></span> wrote:<br></div><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,�<div>� � I am using petsc-3.3-p2. �For my particular equation, for the first few iterations, the residual norm is effectively reduced and the solution X is very close to the exact solution (the residual norm is e-17). Then in the next iteration, SNES_KSPSolve(....) returns a newton step very close to zero which is correct, but the line search after it fails, and the function SNESLSCheckLocalMin_Private(...) is called. In the function SNESLSCheckLocalMin_Private(),�</div>
<div>the solution vector X is rewritten to X=J^T*F where J is the Jacobian and F is the residual. Since F is very close to zero, X is also zero which is wrong. �</div><div>Is there a way to skip the line search?(if the line search is not performed, there would be no problem for this particular equation). �How should we handle this situation?�</div>
</blockquote><div><br></div></div><div>You can turn off the line search with -snes_linesearch_type basic, but I recommend setting an appropriate atol and stol instead, to prevent attempting to solve the system more accurately than machine precision when given a good initial guess.</div>
</div></blockquote></div><div>Maybe it wouldn't be a bad idea to (a) not use the solution vector as a temporary in detecting the local minimum,</div></div></blockquote></div><div><br>Dumping garbage into X upon failure appears to be my careless mistake.� I'll fix it in 3.3.<br>
�</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br>�</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>(b) print the norm of the last solution before bailing out of the Newton loop?</div></div></blockquote></div><div><br>This can go into the -info output.</div></div></blockquote></div><div>Why not (also) let SNESMonitor() be called on that last solution?</div>
</div></blockquote></div><div><br>Oh, I interpreted "norm of the solution" literally rather than "norm of the function at that solution", which makes more sense.� However, as it quits after failing the line search and doesn't transfer the failed solution over.� This is indeed a divergence, so printing a failed norm probably isn't the right solution.� You can see what the line search is doing with -snes_linesearch_monitor.<br>
<br>We changed the behavior in petsc-dev a little bit with respect to this type of case, as we were seeing bad interaction between line search divergence in the case of small step sizes and small-normed solutions with the logic as it was in 3.3 and before.� This could be that type of problem, where the solution is well converged and the line search cannot make more progress.<br>
<br>In any case, I'll fix the problem with writing garbage into the solution.<br><br>In order to truly diagnose this, output with -snes_linesearch_monitor and -snes_converged reason would be nice.<span class="HOEnZb"><font color="#888888"><br>
<br>- Peter<br><br>
</font></span></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><br>�</div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><span><font color="#888888">
<div>Dmitry.�</div></font></span><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><span><font color="#888888"><br><br>- Peter<br>
�</font></span></div>
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><span><font color="#888888">
<div>Dmitry.</div></font></span><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div>
<div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div>Also, after the solution vector X is rewritten by SNESLSCheckLocalMin_Private(), the new residual �norm is not printed on screen (which is huge for this particular problem). �Since the residual norm printed on the screen is going to machine accuracy, �users might think that the SNESSolve converges nicely and the returned solution is correct. This seems a bit misleading in my opinion.</div>
</blockquote><div>�</div></div><div>Are you checking -snes_converged_reason?</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>Thanks.�</div><span><font color="#888888"><div><br></div><div>Shiyuan �</div><div>�</div>
</font></span></blockquote></div><br>
</blockquote></div></div><br>
</blockquote></div></div><br>
</blockquote></div></div><br>
</blockquote></div></div><br>
</blockquote></div><br>