Hi,
I figured it out, and it was my fault...
I was not zeroing out the matrix before assembling the Jacobian. Once I did
this, every linesearch converges and each SNES converge in 1 iteration, as
expected.
Sorry for the confusion.
Blaise
On Aug 15, 2012, at 10:51 AM, Barry Smith wrote:
>
>
Blaise,
We are confused. Can you run both the bt and l2 with all those options and
send ALL the output from each of the two runs.
Thanks
Barry
On Aug 14, 2012, at 6:24 PM, Blaise Bourdin wrote:
> Hi,
>
>
> On Aug 14, 2012, at 5:58 PM, Barry Smith wrote:
>
>>
>> Blais
Most likely not a bug; more like a feature. BT is meant to take the full
step when the descent condition is fine. The descent condition can be fine
without making a ton of progress. Taking the full step avoids a lot of
work (extra function evaluations) when the solve is working right, but
messes
Likely a bug in our bt. It says it is taking a full step but then seems to
take a half-step (based on the result from l2Line search: lambdas = [1,
0.5, 0], fnorms = [2.1936e-08, 1.87107, 3.74214]
> [0] SNESLineSearchApply_BT(): Initial fnorm 3.742138023215e+00 gnorm
> 1.871069011453e+
Hi,
On Aug 14, 2012, at 5:58 PM, Barry Smith wrote:
>
> Blaise,
>
>You can run with -snes_linesearch_monitor -info
> -ksp_monitor_true_residual -ksp_converged_reason
>
>
> to get much more information about what is happening and why the line search
> is failing.
Focussing on the
Blaise,
You can run with -snes_linesearch_monitor -info
-ksp_monitor_true_residual -ksp_converged_reason
to get much more information about what is happening and why the line search is
failing.
If that doesn't help you can send the code and we can play with it.
Barry
On
HI,
I am trying to understand if the following behavior is normal / expected:
I am solving a quasi-static evolution where at each time step, SNESSolve is
called. My validation problem is a _static_ problem with 2 time steps (i.e. 2
successive calls to SNESSolve with the same operator, jacobian,
