<br><br><div class="gmail_quote">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 class="im">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><br>Dumping garbage into X upon failure appears to be my careless mistake.  I'll fix it in 3.3.<br>
 </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><br>This can go into the -info output.<br><br>- Peter<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><span class="HOEnZb"><font color="#888888">

<div>Dmitry.</div></font></span><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>
<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><br>