<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Peter,<br>
<br>
Running with "snes_linesearch_monitor" would give the following
results which I presented in my original email:<br>
<blockquote>My simulation input consists of two scalar values (p1
and p2), each of which acts as a constant pressure boundary
condition.<br>
<br>
Case 1, diverge: <br>
p1= -10.190869 p2= -2.367555 <br>
NL step 0, |residual|_2 = 1.621402e-02<br>
Line search: Using full step: fnorm 1.621401550027e-02 gnorm
7.022558235262e-05<br>
NL step 1, |residual|_2 = 7.022558e-05<br>
Line search: Using full step: fnorm 7.022558235262e-05 gnorm
1.636418730611e-06<br>
NL step 2, |residual|_2 = 1.636419e-06<br>
Nonlinear solve did not converge due to DIVERGED_LINE_SEARCH
iterations 2<br>
<hr size="2" width="100%">Case 2: converge:<br>
p1= -10.190747 p2= -2.367558<br>
NL step 0, |residual|_2 = 1.621380e-02<br>
Line search: Using full step: fnorm 1.621379778276e-02 gnorm
6.976373804153e-05<br>
NL step 1, |residual|_2 = 6.976374e-05<br>
Line search: Using full step: fnorm 6.976373804153e-05 gnorm
4.000992847275e-07<br>
NL step 2, |residual|_2 = 4.000993e-07<br>
Line search: Using full step: fnorm 4.000992847275e-07 gnorm
1.621646014441e-08<br>
NL step 3, |residual|_2 = 1.621646e-08<br>
Nonlinear solve converged due to CONVERGED_SNORM_RELATIVE
iterations 3<br>
</blockquote>
<hr size="2" width="100%">Also, running with "-snes_stol=0"
effectively suppressed the occurrence of CONVERGED_SNORM_RELATIVE.
Instead, most nonlinear solves took more iterations and ended with
CONVERGED_FNORM_RELATIVE at a smaller residual error. In some cases
(roughly 10 out of 5000), the nonlinear solves failed with
DIVERGED_LINE_SEARCH<br>
<br>
Cheers,<br>
Dafang<br>
<br>
<div class="moz-cite-prefix">On 03/18/2014 10:15 AM, Peter Brune
wrote:<br>
</div>
<blockquote
cite="mid:CAKKtyky1X03y41-0+7xuQvRGAO8kTGpZiv3vjsgc9907gSBEfg@mail.gmail.com"
type="cite">
<div dir="ltr">Is there more output from the line search? What
happens when you run with -snes_linesearch_monitor? I remember
there being a reason that I didn't put this update in the
maintenance branch. Let me figure out exactly why and get back
to you.<br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Mar 17, 2014 at 5:37 PM,
Dafang Wang <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:dafang.wang@jhu.edu" target="_blank">dafang.wang@jhu.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi Peter,<br>
<br>
My version of PETSc (v3.4.3) does not contain the bug
fix you mentioned:<br>
"+ ierr =
SNESLineSearchSetNorms(linesearch,xnorm,fnorm,ynorm);CHKERRQ(ierr);"
<br>
Would that be a problem? <br>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> I typically used
the default value of -snes_stol, never setting it to
zero. I will let you know soon if you believe this is
important.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>It would certainly be worth a try.</div>
<div><br>
</div>
<div>- Peter</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Cheers,<br>
Dafang
<div>
<div><br>
<br>
<div>On 03/17/2014 06:27 PM, Peter Brune wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>This may be related to a bug we had
reported before to petsc-maint:</div>
<div><br>
</div>
<div><a moz-do-not-send="true"
href="https://bitbucket.org/petsc/petsc/commits/ced04f9d467b04aa83a18d3f8875c7f72c17217a"
target="_blank">https://bitbucket.org/petsc/petsc/commits/ced04f9d467b04aa83a18d3f8875c7f72c17217a</a><br>
</div>
<div><br>
</div>
<div> What version of PETSc are you running?
Also, what happens if you set -snes_stol to
zero?</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>- Peter</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Mar 17, 2014 at
5:19 PM, Dafang Wang <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:dafang.wang@jhu.edu"
target="_blank">dafang.wang@jhu.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex"> Hi Barry,<br>
<br>
Thanks for your tips. I have read the
webpage you mentioned many times before, but
still I have been stuck on the line-search
problem for weeks.<br>
<br>
I cannot guarantee my Jacobian is correct
but I believe an incorrect Jacobian is very
unlikely. My Jacobian-calculation code has
been under test for a year with both
analytical and realistic models, and the
results have been good until recently when I
ran a very realistic physical model.<br>
<br>
Also, I looked up the implementation of
SNESSolve_NEWTONLS() in "ls.c". According to
the algorithm, when the function
"SNESLineSearchApply()" does not succeed,
one may encounter two possible outcomes:
CONVERGED_SNORM_RELATIVE (if the search step
is too small) or otherwise,
DIVERGED_LINE_SEARCH. Does this mean that
both these two outcomes indicate that the
line search fails?<br>
<br>
I ask this question because my simulation
encountered many CONVERGED_SNORM_RELATIVE. I
treated them as if my nonlinear system
converged, accepted the nonlinear solution,
and then proceeded to the next time step of
my simulation. Apparently, such practice has
worked well in most cases, (even when I
encountered suspicious DIVERGED_LINE_SEARCH
behaviors). However, I wonder if there are
any potential pitfalls in my practice such
as missing a nonlinear solve divergence and
taking a partial solution as the correct
solution.<br>
<br>
Thank you very much for your time and help.<br>
<br>
Best,<br>
Dafang
<div>
<div><br>
<br>
On 03/15/2014 11:15 AM, Barry Smith
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> Failed
line search are almost always due to
an incorrect Jacobian. Please let us
know if the suggestions at <a
moz-do-not-send="true"
href="http://www.mcs.anl.gov/petsc/documentation/faq.html#newton"
target="_blank">http://www.mcs.anl.gov/petsc/documentation/faq.html#newton</a>
don’t help.<br>
<br>
Barry<br>
<br>
On Mar 14, 2014, at 8:57 PM, Dafang
Wang <<a moz-do-not-send="true"
href="mailto:dafang.wang@jhu.edu"
target="_blank">dafang.wang@jhu.edu</a>>
wrote:<br>
<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"> Hi,<br>
<br>
Does anyone know what the error code
DIVERGED_LINE_SEARCH means in the
SNES nonlinear solve? Or what
scenario would lead to this error
code?<br>
<br>
Running a solid mechanics
simulation, I found that the
occurrence of DIVERGED_LINE_SEARCH
was very unpredictable and sensitive
to the input values to my nonlinear
system, although my system should
not be that unstable. As shown by
the two examples below, my system
diverged in one case and converged
in the other, although the input
values in these two cases differed
by only 1e-4,<br>
<br>
Moreover, the Newton steps in the
two cases were very similar up to NL
step 1. Since then, however, Case 1
encountered a line-search divergence
whereas Case 2 converged
successfully. This is my main
confusion. (Note that each residual
vector contains 3e04 DOF, so when
their L2 norms differ within 1e-4,
the two systems should be very
close.)<br>
<br>
My simulation input consists of two
scalar values (p1 and p2), each of
which acts as a constant pressure
boundary condition.<br>
<br>
Case 1, diverge:<br>
p1= -10.190869 p2= -2.367555<br>
NL step 0, |residual|_2 =
1.621402e-02<br>
Line search: Using full step:
fnorm 1.621401550027e-02 gnorm
7.022558235262e-05<br>
NL step 1, |residual|_2 =
7.022558e-05<br>
Line search: Using full step:
fnorm 7.022558235262e-05 gnorm
1.636418730611e-06<br>
NL step 2, |residual|_2 =
1.636419e-06<br>
Nonlinear solve did not converge due
to DIVERGED_LINE_SEARCH iterations 2<br>
Case 2: converge:<br>
p1= -10.190747 p2= -2.367558<br>
NL step 0, |residual|_2 =
1.621380e-02<br>
Line search: Using full step:
fnorm 1.621379778276e-02 gnorm
6.976373804153e-05<br>
NL step 1, |residual|_2 =
6.976374e-05<br>
Line search: Using full step:
fnorm 6.976373804153e-05 gnorm
4.000992847275e-07<br>
NL step 2, |residual|_2 =
4.000993e-07<br>
Line search: Using full step:
fnorm 4.000992847275e-07 gnorm
1.621646014441e-08<br>
NL step 3, |residual|_2 =
1.621646e-08<br>
Nonlinear solve converged due to
CONVERGED_SNORM_RELATIVE iterations
3<br>
<br>
Aside from the input values, the
initial solution in both cases may
differ very slightly. (Each case is
one time step in a time-sequence
simulation. The two cases behaved
nearly identically up to the last
time step before the step shown
above, so their initial solutions
may differ by a cumulative error but
such error should be very small.)
Is it possible that little
difference in initial guess leads to
different local minimum regions
where the line search in Case 1
failed?<br>
<br>
Any comments will be greatly
appreciated.<br>
<br>
Thanks,<br>
Dafang<br>
-- <br>
Dafang Wang, Ph.D<br>
Postdoctoral Fellow<br>
Institute of Computational Medicine<br>
Department of Biomedical Engineering<br>
Johns Hopkins University<br>
Hackerman Hall Room 218<br>
Baltimore, MD, 21218<br>
</blockquote>
</blockquote>
<br>
-- <br>
Dafang Wang, Ph.D<br>
Postdoctoral Fellow<br>
Institute of Computational Medicine<br>
Department of Biomedical Engineering<br>
Johns Hopkins University<br>
Hackerman Hall Room 218<br>
Baltimore, MD, 21218<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
<div>-- <br>
Dafang Wang, Ph.D <br>
Postdoctoral Fellow <br>
Institute of Computational Medicine <br>
Department of Biomedical Engineering <br>
Johns Hopkins University <br>
Hackerman Hall Room 218 <br>
Baltimore, MD, 21218</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
<div class="moz-signature">-- <br>
Dafang Wang, Ph.D <br>
Postdoctoral Fellow <br>
Institute of Computational Medicine <br>
Department of Biomedical Engineering <br>
Johns Hopkins University <br>
Hackerman Hall Room 218 <br>
Baltimore, MD, 21218</div>
</body>
</html>