<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 1, 2016 at 5:26 PM, Barry Smith <span dir="ltr"><<a href="mailto:bsmith@mcs.anl.gov" target="_blank">bsmith@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"><span class=""><br>
> On Feb 1, 2016, at 2:16 PM, Barry Smith <<a href="mailto:bsmith@mcs.anl.gov">bsmith@mcs.anl.gov</a>> wrote:<br>
><br>
><br>
>> On Feb 1, 2016, at 1:46 PM, Xiangdong <<a href="mailto:epscodes@gmail.com">epscodes@gmail.com</a>> wrote:<br>
>><br>
>> Hello everyone,<br>
>><br>
>> I have a question on snes with line search. Under what circumstance, applying the (globalized) line search can perform WORSE than without line search (i.e. full newton step ls type basic)?<br>
>><br>
>> When I apply snes with my problem, I found that at some time steps, snes diverges with linesearch_bt, but can converge with linesearch_basic (using same initial guess). For the same problem, there are also some steps, at which linearsearch_basic fails, but linesearch_bt converges.<br>
><br>
>   Here are you referring to "time steps"?  When doing time stepping, depending on the evolution of the equations, the nonlinear systems can become more difficult to solver or easier to solve. One can often adjust the time-step size to make sure the nonlinear equations are never to difficult. So for example if the nonlinear solver is taking more than, say, 10 Newton steps, or is failing, decrease the timestep by some factor and try again. If the nonlinear solver needs only 1 or 2 Newton steps one can try increasing the time-step. Ideally this is also done in conjunction with an ODE error estimator to control the error by adjusting the timestep. Some of the PETSc implicit TS ODE integrators do this automatically. Generally adjusting the timestep is a more reliable way to insure convergence than trying to produce a completely robust nonlinear solver (as Matt points out if you did develop a completely robust nonlinear solver you could retire on your fame).<br>
<br>
</span>   Of course this will not always work, if the solution develops a singularity in finite time or is "really nasty" the time-step could be driven to zero; but having a more robust nonlinear solver won't help in that situation either.<br></blockquote><div><br></div><div>Actually my problem is not that ill-conditioned. Here is my situation. Let us say at time step n the snes_linesearch_basic failed. I have at least two options now: i) cut the dt immediately, ii) switch to snes_linesearch_bt with the same dt. Sometimes, switching to a different linesearch method without cutting dt will make snes converge, but sometimes not (then I need to cut dt, which is bad since more nonlinear iterations were wasted). Based on what you mentioned, it is impossible to decide which option is good and I just need to simply pick one.</div><div><br></div><div>Thanks.</div><div><br></div><div>Xiangdong</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
  Barry<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
><br>
>   Barry<br>
><br>
><br>
>> Is there a general guide line to decide whether linesearch should be used?<br>
>><br>
>> Thanks.<br>
>><br>
>> Xiangdong<br>
><br>
<br>
</div></div></blockquote></div><br></div></div>