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

Barry Smith bsmith at mcs.anl.gov
Tue Apr 28 13:40:40 CDT 2015

> On Apr 28, 2015, at 1:31 PM, Jed Brown <jed at jedbrown.org> wrote:
> Barry Smith <bsmith at mcs.anl.gov> writes:
>>>>  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
> *Stages* are not rejected due to local truncation error because the
> error estimate only occurs at step completion.  Stages are rejected
> because the solve fails or the user's checkstage function rejects it.

   And only YOU and Emil in the whole freaking world know this!!!!!  Thus the message is just plain incomplete. At a minimum it should say stage rejected do to failed nonlinear solver or else say "rejected by user in check stage function".

> When a *step* is rejected due to an error estimate, the output currently
> reads:
>  TSAdapt 'basic': step  25 rejected t=0.00175892 + 5.270e-05 wlte= 4.92 family='arkimex' scheme=0:'4' dt=3.185e-05
> You can see that wlte (weighted local truncation error) is greater than
> 1.
>>> I'm concerned about these lines being too long and practically
>>> unreadable.
>>   It is silly to have something like it is now that is clearly
>>   confusing to users when adding 3 or 4 words to the output would
>>   remove that confusion.
> What exactly would you want it to say?  You want it to dig into SNES and
> KSP to do a postmortem analysis of why the solver failed, and print all
> of that in a summary?  We don't do that in SNES; we just say
> SNES_DIVERGED_LINEAR_SOLVE and the user can add -ksp_converged_reason to
> find out why.

   Well at a minimum it should say that the nonlinear solver failed and not assume that the user has Jed's knowledge and KNOWS that "stage rejected" means failed nonlinear solver. I do think that a short postmortem analysis would be useful here because requiring the user to also use -ksp_converged_reason means the user has to RESTART the APPLICATION and the converged reason is printed ALL the time cluttering the output when it has just converged fine. So yes it should at least say "why" the SNES failed.

More information about the petsc-users mailing list