[petsc-users] Turning off TSADAPT still adapts time step

[Barry Smith]

> On Apr 27, 2015, at 12:24 PM, Jed Brown <jed at jedbrown.org> wrote:
> 
> Mark Lohry <mlohry at princeton.edu> writes:
> 
>> -snes_converged_reason:
>> 
>> Nonlinear solve did not converge due to DIVERGED_LOCAL_MIN iterations 4
>> 
>> (which is expected)
> 
> If you set -snes_stol $something_large then SNES will exit
> SNES_CONVERGED_SNORM_RELATIVE instead of SNES_DIVERGED_LINE_SEARCH when
> it stagnates.
> 
>>> Add -snes_converged_reason.  What do you want to do when the solver
>>> fails?  Pretend like it succeeded and get the wrong answer?  Usually
>>> people shorten the time step and retry, which is what you see happening
>>> here.
>> Well yes, actually - I expected it to fail for this test case but it 
>> stubbornly gets the right answer. 
> 
> Sorry about that.  ;-)
> 
>> The explicit integrator has no problem keeping a fixed timestep and
>> throwing the expected NaNs when it blows up.
>> 
>> It's alarming to see the unexpected behavior of setting TSADAPTNONE and 
>> seeing it actually adapting (in a rudimentary fashion) the timestep, and 
>> keeping that reduced timestep even after the stiffness goes away.
> 
> We figured it's not very useful to just crash or get the wrong answer,
> so the solver-based control is decoupled from error-based control.

   This should be made clear in the documentation and the API. Currently it is very murky especially with messages such as

TSAdapt 'none': step  20 stage rejected t=800        + 4.000e+01 retrying with dt=1.000e+01

which start with the TSAdapt word but then talk about rejecting step which one would naturally think has something to do with TSAdapt.

   Perhaps if every rejected line indicated why such as 

TSAdapt 'none': step  20 stage rejected (nonlinear solve failed due to xxxx)  t=800        + 4.000e+01 retrying with dt=1.000e+01

or 

TSAdapt 'something': step  20 stage rejected (error control to large due to xxxx)  t=800        + 4.000e+01 retrying with dt=1.000e+01

Barry