<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Peter,<br>
<br>
My version of PETSc (v3.4.3) does not contain the bug fix you
mentioned:<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
"+ ierr =
SNESLineSearchSetNorms(linesearch,xnorm,fnorm,ynorm);CHKERRQ(ierr);"
<br>
Would that be a problem? <br>
<br>
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>
Cheers,<br>
Dafang<br>
<br>
<div class="moz-cite-prefix">On 03/17/2014 06:27 PM, Peter Brune
wrote:<br>
</div>
<blockquote
cite="mid:CAKKtykxMrk5c5b2iRaGBP3xR4_O6v_dP5fk0fGWkHok7y4Ckdg@mail.gmail.com"
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">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 class="HOEnZb">
<div class="h5"><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 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>