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>