[petsc-users] SNES line search

[Peter Brune]

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.

- 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/47457651/attachment.html>