[petsc-users] SNES line search

[Peter Brune]

On Wed, Oct 17, 2012 at 3:01 PM, Dmitry Karpeev <karpeev at mcs.anl.gov> wrote:

>
>
> On Wed, Oct 17, 2012 at 2:56 PM, Peter Brune <prbrune at gmail.com> wrote:
>
>>
>>
>> On Wed, Oct 17, 2012 at 2:40 PM, Dmitry Karpeev <karpeev at mcs.anl.gov>wrote:
>>
>>>
>>>
>>> On Wed, Oct 17, 2012 at 2:11 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:
>>>
>>>> On Wed, Oct 17, 2012 at 2:02 PM, Shiyuan Gu <sgu at anl.gov> wrote:
>>>>
>>>>> Hi,
>>>>>     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(),
>>>>> 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.
>>>>> 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?
>>>>>
>>>>
>>>> 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.
>>>>
>>> Maybe it wouldn't be a bad idea to (a) not use the solution vector as a
>>> temporary in detecting the local minimum,
>>>
>>
>> Dumping garbage into X upon failure appears to be my careless mistake.
>> I'll fix it in 3.3.
>>
>>
>>>
>>>
>>>
>> (b) print the norm of the last solution before bailing out of the Newton
>>> loop?
>>>
>>
>> This can go into the -info output.
>>
> Why not (also) let SNESMonitor() be called on that last solution?
>

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.

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.

In any case, I'll fix the problem with writing garbage into the solution.

In order to truly diagnose this, output with -snes_linesearch_monitor and
-snes_converged reason would be nice.

- Peter


>
>
Dmitry.
>
>>
>>
>> - Peter
>>
>>
>>>  Dmitry.
>>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Are you checking -snes_converged_reason?
>>>>
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> Shiyuan
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20121017/bae7df4d/attachment-0001.html>